Team Goals Over Individual Goals

In a conversation with a senior engineer at a multi billion dollar successful Silicon Valley tech company, the likes of which we cite in case studies and conversations, I observed a major anti-pattern in how work happens on the team to meet business goals.

We were discussing a challenge this person was facing on their team. The team was under these circumstances:

• the team is a platform team
• mostly firefighting because they are understaffed (3 engineers)
• super experienced team with only staff level engineers
• the team does not have a dedicated engineering manager and the director is sort of managing the team with multiple other priorities
• responsible for a critical project (let's call it Project X) of de-risking a company-wide reliability risk; the project is operationally intensive, requires coordination and alignment of other teams for success

They had recently hired 2 junior engineers after struggling to hire for a few quarters. So this person was looking for advice on how their team should approach their work now, since their long running "bandwidth" problem seems to be getting better. While discussing possible options, we arrived at the point of managing firefighting. Here is how the conversation went (reworded):

Vaidik: So here is how you should think about work now. Firefighting is going to continue until you guys hire more developers because your team is heavily understaffed and you have to support other teams. Support work is not going to stop really. So budget some bandwidth for that. Then, obviously try to finish Project X first because it is already delayed and it is probably best for your team's morale and reputation to just get it over the line. If there is any bandwidth left, then perhaps use it for one of the new initiatives we discussed.

The Person: Yeah that makes sense. Project X is something that we really don't like talking about any more because everyone keeps asking us about it. And it's delayed big time. Honestly, the person on our team who is responsible for Project X is struggling with it. When we realised this, we decided to help him out with some of the tasks. We would do long calls for several days together to figure out ways to speed up progress. But then, he would get distracted by volunteering to do other work like writing postmortems for incidents that he was involved in but not primarily responsible for and that additional was totally avoidable.

Vaidik: Interesting. What happened then? Did this not get discussed any time? May be in 1-on-1s or team meetings?

I am assuming at this time that there is nobody to give regular feedback to that individual because there is no manager.

The Person: Not really.

Vaidik: Hmm. Do you guys do retrospectives as a team? Do you do any kind of planning on a regular basis? How does your colleague get the feedback to correct this behaviour?

The Person: No. We don't do that. And we just decided to help our colleague.

There are many companies out there where teams are nothing more than a functional grouping construct for management to get a certain kind of work done. But they hardly work like a team.

Here is how work happens in such settings:

• Goals are assigned to a "resource" on the team
• Of course, these are organisations that value "developer autonomy". So developers can also volunteer for a goal or suggest what they would like to work on.
• The team meets and talks, obviously or nothing will get done. But for the most part, every individual have their own goals to chase.
• Some goals are more challenging than others, obviously because the goals  are decided to solve business problems. Some problems can be more hairy than others.

What's the impact of this?

• Challenging projects have higher risk of not getting done on time or not meeting acceptable level of quality because there is just one person responsible for getting them done. So progress will be usually slower as compared to what the team collectively is capable of doing.
• When critical projects don't get done, the team as a group takes the blame because the team is more visible to the organisation than the individual.
• Developers on the team think in the box of their own capabilities and aspirations instead of working as a team to solve business problems. No bad intentions here. Their company have put them in this framework. This is just how things happen.
• Feedback is delayed. The team does not really work like a team that cares about the goals they want to achieve together. So there are no frequent plan-do-check cycles. There is no time to retrospect on how the team is progressing against their goals and what is not working - a strategy, tactic or even a behaviour or practice.
• People are nice. When they see someone struggle, they try to go out of their way to help. But that is a matter of chance. What if everyone is struggling? How does that change?

I recommended him to think from the perspective of a team and what is impacting them. If the team's external reputation is impacting the team, then they should work as a team to protect it and solve everything that comes in the way. There is nothing wrong with individual OKRs but business priorities should be a concern for the entire team and not an individual.

For the person I was talking to, it's a challenging situation to navigate, especially in absence of a dedicated manager and when the precedent has been set. The only way out is to raise this concern with the director with the intention to make changes in how the team works and take one step at a time.

How companies become successful despite following anti-patterns of how to run teams and organisations — a digression

Having witnessed both failed and successful companies from the outside, knowing how a few of them work internally, and further overlaying the best practices I have learnt from leaders in our industry, I often end up being confused about how some companies end up being successful even when they don't follow the best practices. It is quite frustrating honestly because things just don't add up. It's hard to make sense.

I guess there are a lot of factors that make a company successful:

• Problem Space, Market & Timing - the business is about something that is bound to grow, despite having poor systems, ways-of-working and organisational practices. Many examples come to my mind but to name a few problem spaces - e-commerce, payment wallets, edtech, to name a few. Basically, any new big wave is sort of resistant to a certain extent to bad practices if they get something right. If the company does a job of putting a useful product out there and there is enough demand for it (organic or due to external factors like demonetisation, regulations, a pandemic, etc.), the business still takes off and makes money.
• Founders - their intelligence, drive and determination sometimes outperforms the entire company. These companies are essentially founder run companies. Employees are mostly cogs in the machine.

In both the cases above, imagine what such companies could have done if they had a better organisation that harnesses the collective intelligence of their workforce and enables the employees to do more. But I understand that this is like saying "what if they had more money" or "better engineers". The realities of how businesses are built are often far from ideal. No company gets everything right. A lot of successful companies get a few things right - but may be not how to best run their teams.

While there is no one proven way to build a successful business and the importance of good practices can always be debated when you have many successful businesses that do the exact opposite and follow many anti-patterns, I would still argue that organisations that follow good organisational practices get to better outcomes faster with happy employees.

The quest to help build great teams and organisations should go on for all leaders, despite these contradictory cases.