Inside Out

Choosing a team

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

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

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

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

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

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

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

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

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

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!