Chapter 9: Discussion and Questions

[Scott]

here we go.

[Ravi]

My big takeaway from this chapter is "if you cannot communicate, you cannot succeed".

The section on clarifying roles was my favorite. We all have a lot of baggage from dealing with team members that have not met our expectations on projects. I agree with Scott that by clearly defining roles you can solve many issues.

When I work on new projects, you can tell which team members had a good or poor experience from their previous assignment. Upbeat, smiling with a can-do attitude versus "I hate my job" and "Should I update my resume".

When a project is about to fail, someone on the team knew beforehand but did not speak up. Dysfunctional relationships, fear of blame, and lack of trust in leaders usually prevent team members from warning PMs. I've actually seen managers censor their team members to paint a rosy picture for projects.

I read some where that most projects are late, so, you can assume that most people don't have good experiences on projects. Based on that hypothesis, I think Scott's approach of level setting the roles and building a rapport with the team is extremely important. I would also add that when you work with engineers and PM's, you see a pattern of triggers that lead to relationship issues or mis-behavior. Some of the engineers that I work with dislike writing specs or attend bug triage meetings. Some PM's get upset if we don't use their templates, etc... Many techniques can be used to diffuse these annoyances. But, if you are not aware then you cannot connect the dots.

Hmmm. Maybe we should wear heart monitors and create a dashboard for the PM so he can take the pulse of a project.

[Scott]

It can be hard to talk about roles - especially if you're not in charge. It's just an awkward conversation to start so people avoid them. But whenever I start working with someone knew a question on my mind, and that I'll often say, is "how do we work best together? what do you expect of me and me of you?" - even if what's said is predictable it reaffirms those beliefs and makes it easier to refer back to that covenant should things go wrong later.

[Shiran]

I just started working with a new senior business analyst who's super smart but has no experience in software development. Reading about the list of responsibilities was a Eureka moment for me. I will try building that list cooperatively with him, as I'm sure it will set us on the right footing.

It's also interesting how the 5-phase communication framework mimics the life cycle of issues in bug trackers (reported, assigned, acknowledged, accepted, resolved, closed, etc.)