Intro

When we consider a software development team as a system, we have to understand the dynamics of pressures that are in play in order to understand ultimately how a teams performance will play out. It is true that a well aligned set of folks who are all part of a high functioning team will be able to holistically take care of all the concerns this approach proposes to solve, but this approach proposes to solve responsibilities and team dynamics for the other 99% of us.

When we have unclear responsibilities and expectations in any situation in life, misunderstandings occur, multiply and poor experiences result. In my experience, when responsibilities are left poorly defined typically either no-one takes a responsibility, leading to it being neglected and everyone being frustrated that “other people” aren’t pulling their weight. Or everyone takes ownership of the responsibility, which leads to disagreement, disengagement and ultimately no-one has clear accountability and therefore we have the same situation as if no-one had taken responsibility.

Said another way; We need a responsibility to be clearly associated with a role and for that role to be accountable for that responsibility.

Let us start by going through the responsibilities. To delivery something as a software team, surely we have to start with what we need to deliver, right?

What? 

What are we building? A solutions to a problem, obviously, but what is the solution. The answer as to how solve this question is actually the key to unlocking this concept. There is no one person who can define the “What?” answer and there are no two situations where the balance of responsibility around “What?” is the same. Let me walk you through my thoughts on the “How?” the “Why?” and the “When?” before we come back to the address this elephant in the room. Ok… How? 

Anyone who has ever spent any time with Engineers, at least anyone who has known me as an Engineer, knows I/we love this question. White boards, architectural diagrams, activity diagrams. We can spend all day, week and month solving the how we could perfectly solve this problem at multiple levels of maturity and scale. The “How?” problem is very firmly the domain of the Engineer and we love it for that.

Why??

This ones sounds a little odd until we realise that when building a solution we need to understand why the problem needs to be solved before we can get back to the “What?” of the solution. Why does the user need to be notified by our system? Why do they need a report? Why do they need whatever-other-functionality-we’re-going-to-build? Having a product person who can define and answer the “Why?” question is critical to be able to get to the solution of what we are going to be building.

So, Engineering does “How?” and Product does “Why?”. We’re good to get to the “What?” now right?

Nope.

While there are always going to be a bunch of other constraints like Operating Expense, [something] and [something], to keep this a sane and not a multi-dimensional problem that becomes too hard to draw simple diagrams around, I believe that the most critical question to address in the third dimension is “When?”

When?!?!

Well, as soon as possible, of course, But not too soon, because if you ask Product to make it too soon with the scope they desire then we’ll have a poor quality product that’ll be expensive or even impossible to maintain. And don’t ask Engineering to make it too soon because then you’ll end up with a well architected and maintainable solution that… doesn’t really solve the client “Why?”

So asking either Product or Engineering to own the why will ultimately lead to compromise of the others criterion for success. Do we need someone else in the mix here?

Please allow me to introduce the concept of the TPM.

WHAT???

Now we can address the answer of what it is that we are building given the scope and vision of Product in the why phase of definition, the technical constraints Engineering bring in the how phase and the timeline tracking brought to reality by TPM in then when phase. Now we have a definition of what it is that we are intending to build. 

Well… assuming you’re working in an Agile world or something akin to it, you had a definition of what. But the world moves on and pretty soon you’ll be on a sprint boundary, time will have passed, we’ll have learned things and we’ll all be looking at those product scope constraints differently.

Time to evolve the plan, but at least we all understand what we’re responsible now, right?