As an Engineering Manager, I frequently observe teams working on projects where something doesn’t feel right.
The signs are painfully obvious: no consensus on why the project matters, long-winded discussions that go nowhere, people unclear about who should be doing what.
Teammates say they’re not “on the same page”. Or, worse– they feel it, but don’t say it.
The project may get done someday, but the journey is less efficient and more painful than it needs to be.
Debugging project teams stuck in this unaligned state is challenging because it’s hard to figure out where to start looking for the root cause.
The framework I’ve found most helpful to get started asks whether everyone on the team agrees on:
What I usually find is that a team is obsessed with something lower in the list (usually the How or When) while questions higher in the list (Why, What, or Who) suffer from lack of clarity.
For example, the team spends its entire weekly meeting talking about when different project components will land, but they’re blocked on key design decisions that don’t resolve because of lack of clarity in the jobs to be done (the Why and What).
It’s critical for teams to align on each question before shifting focus to the next question.
Why is the root of everything.
Why should we care? Why should we solve this problem over everything else? Why are we in this meeting?
A clear Why is critical because nothing else matters if a compelling reason for working on this project doesn’t exist.
What captures what success looks like.
It could be the state of the world when the problem is solved, when the customer is happy, when some time period is over.
What is not tactics– i.e. the execution steps that will make the solution a reality. That would be covered in How.
Who defines the roles of people involved
The RACI matrix is a useful tool here. While it may seem overkill for a lot of projects, I’ve observed countless “simple” projects encounter failure states because of lack of ownership and accountability.
Clear roles help teams make hard decisions. When 100% consensus is not attainable, it’s important to have a single owner for the decision and commitment from others to agree or disagree and commit.
How develops strategy and tactics for solving the problem.
This comes after Who to make clear who should drive different aspects of the How. For example, a technical lead may drive architecture design while other engineers drive implementation details.
How is messy. By working through details, teams may discover gaps in the earlier questions. In those cases, it’s critical to iterate the Why, What, and Who.
When concerns time management.
Teams in execution mode tend to obsess over when things are going to start, get unblocked, or finish.
Projections need to be revised, though, when answers to the earlier questions change. For example, it’s tempting to generalize estimates in terms of “engineer-hours”, but the reality is that time required can vary based on who’s doing the work.
While this framework is helpful for diagnosing the lack of alignment, fixing the problem requires tactics specific to the particular situations.
I often find it helpful to offer the observed diagnosis directly– perhaps jumping into a long-winded discussion to ask, for example: “Hey, it feels like we’re spending a lot of time talking about how to build this, but are we all clear on why we should build this?”
Even if the initial diagnosis is off-base, the ensuing discussion usually brings teams closer to being “on the same page”.
December 2021