Three Essential Questions of Every Team

When I started to write this article, there are movies playing in my mind and it brings me to the memory of many conversations I have now and in the past as listed below.

How big should the team be? Two pizza team?
What kind of role should I have in the team?
Should I have a local team or distributed team?
Do I have the right team structure?
Should I have a cross-functional team? Should I have a BA/QA/IM/PM?
What’s the difference between a project team and a product team?
What’s a platform team?
What’s the one model that suits my organization?
How can we adopt Spotify model?

This writing is not trying to provide answers for the above. Instead, I will urge you to take one step back together with me, think about before you setup a new team or join a new team, what would be the top 3 questions to focus on? A good team is a foundation of a scalable organization, it’s important to get it right and get it up-to-date.

First Principles

A first principle is a basic assumption that cannot be deduced any further. Over two thousand years ago, Aristotle defined a first principle as “the first basis from which a thing is known.” First principle thinking is to active question every assumption you think you ‘know’ about a given problem or scenario and then create solution from the scratch.

On the other side, reasoning by analogy thinking is to build solution based on prior assumptions, or widely know as “best practices”. This seems to be the one key thinking behind most team design/organization design today, hence comes the popularity of “Spotify model”, “Two pizza team”.

So it’s time to go to the very basic of the team and I found there are 3 questions are essential to a great team.

1. What is the problem/opportunity?

A problem well stated is a problem half-solved. Go back to the problem that the team try to solve is not a once-off activity, as when team progress, the problem will shift/evolve or become a total different one. That would be the time for the leaders to think about a restructure:)

When you define the problem/opportunity, do make sure you address:

Who is the customer?
What is the problem?
What are the resources?
What are the constraints?
What are your tradeoffs?
When should this be solved?
What options are there?

Though sometimes you don’t always need a team to solve a problem; yet it’s always a signal if the team can’t clearly articulate the problem they’re working on, and their customer.

2. What is the business outcome?

There are many problems, but not all of them need a team to work on. Business outcome is the way to articulate the value/benefit of solving the specific problem, it often becomes another feedback point. Stop working on the problem, if you can’t tell the value.

Value means different thing to different organization/people, here are a few examples to refer to:

Improve speed to market
Improve reliability and scalability
Realize specific business opportunity via new feature
Capability enablement
Developer experience
Improve business engagement
Reduce maintenance cost

3. What capability do you need to deliver the outcome?

Once you’re clear with the problem and business outcome, next thing is to define the capability you need to deliver the outcome. Note here is “capability”, not “roles”. Often when you see a 100% of developer team, that does not mean you do not need business analysis capability, it only means someone who does not have title are actually providing that capability.

When you plan the capability, consider following:

prolem define/analysis capability
problem solving capability
continuous improvement capability
team building capability

Summary

If we agree code is developers’ artifact, then team is leaders’ artifact. Team shouldn’t be static and it should be continously evolved, when the problem domain shifts.

As a leader, it worth to make these 3 questions and answers visible and regularly revisit it to make sure the team is working on the right thing in the right way, with the right capability.

If you’re struggling to answer these 3 questions, stop working on what you’re doing, go find out what’s going wrong.