In a recent retrospective, I realized my perspective on composition of great team changes every ~1.5 years. So the question emerged - is there a base for the opinions? Let’s set a baseline for this year’s thoughts and examine next year ;)

We’ll enquire across the dimensions of product, processes and people. Each section asks a set of questions and outlines good or bad aspects.

1. Product

1.1 Customer empathy

• Do we understand customers?
• Are we using our own product?
• What is the current customer base?
• How often do we meet customers?
• How do we capture customer feedback? How often do we triage them?
• Do we know the personas and their needs?
• Do we keep needs before features?

Choose a team which has a deep understanding of the customer base and how they make money. The team must understand the compete and their moat.

⚠ Stay away if you get answers pivoted around compete only. E.g. the competitive product has this feature. We are building it to take away market. Instead expect an answer in terms of customer needs rather than compete feature set.

1.2 Looking ahead

• How do we define success?
• Do we have key priorities and a plan of action?
• Have we learnt from the past?
  • What was our definition of success for last year?
  • What did we learn?
• How are we funding each of the priorities?

Choose a team whose words meet acts. E.g. if the top customer need is X, but it is funded with only 1 individual. Beware. Another way to evaluate this - ask where are the key engineers working? Typically people put their money on the most important part of the problem.

⚠ A team without clear definition of success or an exotic definition is setup for failure.

1.3 Technology

• How does the stack look today?
• What are the key pain points?
• How will the stack look tomorrow?
• Who drives the architecture and how? // side note: look up the individual(s) profiles
• How does our stack compare with the state-of-art?
• What are some of the principles for decision making?

Evaluate if the team understands the shortcomings of tech stack and has a plan to address them. In the order of priority functionality usually trumps architecture; and it bites in the end.

⚠ Run away if someone tells you super-awesome-tech future without a crisp definition of the challenges. Ask for numbers and data. Ask what exists and what is getting built.

2. Processes

2.1 Stakeholders

• What are some of the rules of day to day work?
• What is the stake for success?
• Who are the key individuals?
• How much skin they have in the product? What’s the impact of failure?
• How do they stakeholders influence product scope, execution?
• How many world class architects do they have in the team?

A world class team is extremely well-aligned. Stakeholders (Directors, VPs) are action oriented and put their best foot forward to fix ambiguity. They have tons of trust and respect on their teams; this enables teams to focus on bigger battles knowing someone has their back.

⚠ Stay away if the team has rules like - everyone must be in office at 10 a.m. Creativity must not be confined to a specific time and place. And definitely that cannot be the choice of a stakeholder.

⚠ Stay away from a team where exactly 2 people have a stake - you and your colleague. This is hard to figure. One reliable approach is to get opinion from people who have left the team.

⚠ Stay away if the team does a feature saying the VP asked for it. That’s a shorthand to say we’re incompetant and hence rely on our VP to define the exact feature.

2.2 Engineering

• What are the principles we follow to plan and execute?
• Where is the product backlog? Can I see it?
• How do we capture learnings?
• What are the stages of a taking a technical decision to shipping?
• How many unit tests do we have? How long do they take to run?
• How long does the build process take?
• How does the developer innerloop look?
• Are we using modern developer tools?
• What are the product quality metrics we capture?

A good engineering team knows where it excels. It acts as a self sustaining unit and cares deeply about the day to day life of a developer. It has metrics around productivity.

⚠ Stay away if day in life of a developer sucks. Some indicators are longer edit-build-test-debug cycles, setting up dependencies to test requires a PhD etc..

⚠ Stay away if you don’t get data driven answers for metrics.

⚠ Stay away if you see an inbalance between execution responsibility and decision making. E.g. if the team only executes and the decision maker is atleast 1-2 oceans away and is rarely held accountable for failures.

⚠ Stay away if the team is doing engineering without much focus on customer value. If you hear words like we improved reliability to 5 9’s; ask how many customers were impacted by it and why did the reliability go down in first place? Critically examine if reliability improvements are the only focus.

2.3 Program Management

• What are the key tenets for feature success?
• Do we have a crisp definition of metrics?
• Do the features have an attach with overall org metrics?
• How does the feature success attach with dollars?

Excellent teams have a great story around converting customer need to dollars. They use this virtuous cycle to buy more independence for the team to experiment and innovate.

⚠ Stay away if there is a marked difference of opinions between the business owner and product owner. If one cannot influence the other to be on same page, how will they influence the other parts of org together?

⚠ Stay away if you hear, we are leveraging team X’s expertise to understand customers and do market research (but we don’t know the real answer).

⚠ Stay away if you see multiple instances of opinions changing without substantial customer data after execution has started.

2.4 Support

• What are the areas with tons of support cases?
• How do we resolve the cases?
• What are the metrics to measure success in customer support?
• Do we root cause the issues? What are the patterns?
• Are the root cause patterns related to architectural decisions?
• In the product team, how many fixes have we taken in past sprint to fix recurring support cases?
• How is support handled? If there’s a separate team, do they feel hopeful about improvements?

Good teams use support as a feedback loop into architecture and feature definitions. This reflects often in rationale for future feature proposals.

⚠ Usually support ends up to be a case of accountability without a clear responsibility to fix things. See if there are metrics to ensure support issues make their way to product improvements.

3. People

3.1 Composition

• How diverse is the set of our colleagues?
• Is there a specific trait or skill that influences the group?
• How many people do we respect and deeply trust?
• Do we have colleagues to look upto as role model?
• Do we see ourselves in the position of leaders over next 5 years?
• If you were a leader in the group, what decisions would you take differently?

Bias towards diversity, respect and trust. Be among people you’d like to be one day. Systemic thrust can act as a buoyant force to lift you up ;)

⚠ Stay away if you find a lot of similarity with your current team. You’re probably going after comfort instead of learning.

3.2 Culture

• What excites us as a team?
• Growth mindset: what are the top 3 mistakes we learnt in past quarter?
• What are the top 3 risks we are taking? What are our bets?
• How inclusive are we as a team? Do we hear each other?
• Do we celebrate success? And failure?
• How many times do we hear yes to ideas? How many ideas shipped?
• Do we have time to step back and think holistically?
• Are we data driven?

Embrace a culture where failure is celebrated. Push towards learning as an outcome of every activity.

⚠ Stay away from a team which doesn’t setup high bars or never makes mistakes.
⚠ Stay away if the college hires in the team cannot explain how their work influences customers.
⚠ Stay away if the first word you hear often is no.
⚠ Stay away from teams where grapevine believes in anecdotal data; and members never question the perceived truth.
⚠ Stay away if people talk in terms of solutions instead of problems. It just indicates they don’t trust you or they lack a growth mindset.
⚠ Stay away if you see teams fight for a piece of software. Trust me there are better battles to fight in life.

End of discourse. Thanks for reading so far!