I once joined a team with an unusual history. The area recognised the engineers as brilliant – inspiring, even – yet the group had a poor reputation with senior management and key stakeholders.
The team is supportive to the surrounding teams and people. At least one external team is completely reliant on this team to solve production issues. The team is innovative in terms of product. They propose exciting ideas, several of which have been successful. The team ships quickly. Features fly out the door. And no need for data analyst support – the team members themselves are able to prove business value and justify their investments. The team invests in infrastructure, creating new frameworks and marketing these internally. The team volunteers for ownership, and owned, for example, a critical page in the checkout funnel, and key deployment tooling.
The team ought to be high-performing. But a closer inspection revealed all was not what it seemed. Like a double-sided coin, each apparent virtue belied a hidden threat.
Supporting other teams – without helping them learn
The good: The team supported surrounding teams.
The bad: It meant those teams started to view critical issues as ‘not my problem’. They had stopped planning to address them, and stopped building up knowledge in their core domains.
“The systems are too complex and we don’t have the knowledge to fix them,” complained the sister team, while having their problems solved for them.
Suggestion: Put the pain where it belongs. The sister team needs to principally solve its own problems if it ever hopes to have sufficient mastery of its domain to deliver for the customer. Illustrating the impact on the roadmap and deliverables could help motivate for more independence. Maybe a staff rebalance is required, a training programme from team A to team B, or a formal agreement for support e.g., X time per week until the team is sufficiently onboarded.
Product innovation – in random directions
The good: The team was innovating on the product.
The bad: Product improvements were not aligned to strategy. Delivery on company goals was good luck at best, post-hoc rationalisation at worst. Evaluating the success of its own work could not help but position the team at risk of bias.
“We don’t understand this team’s prioritisation. We think the team could have more impact,” challenged the product and engineering directors.
Suggestion: Challenge the team’s prioritisation. Where does this work originate (requirements tracing)? We are a data-driven company – what signals are we seeing that leads us to believe we should continue on this path?
High velocity – at the expense of quality
The good: The team shipped quickly.
The bad: You guessed it – quality issues. A steady stream of product features was resulting in accumulating tech debt, an increasing volume of bug inbound, and replication of existing systems.
Product features were also fixing bugs resulting from the previous shipping of product features that were also supposed to fix bugs …
Suggestion: Focus on resolving bugs and production issues first. Pause product development until what already exists works properly for customers. Set the expectation that it is not okay to break existing functionality for the customer.
Technical innovation – ignoring the tech strategy
The good: The team invested in creating libraries and frameworks, and promoted these to adjacent areas.
The bad: The approach was at odds with the company’s tech strategy. One library in particular was strewn throughout the codebase and would take years of untangling to resolve.
“Why did you take this approach when we have been trying to work with you for years on the reference architecture?” – an exhausted principal engineer
Suggestion: Enlist architects and principal engineers to support the team, and make sure the team benefits from this arrangement, too – make it a 2-way street.
Volunteering for ownership – without a plan
The good: The team was proactive in volunteering for ownership.
The bad: The team did not have the resources to own the variety and quantity of items it had signed up for. The scope of ownership was not cohesive. In the end, balls were dropped because things were owned but not monitored.
“I only said we’d own it because someone was asking for volunteers“
Suggestion: Define an ownership strategy, stack-rank the ownables according to agreed decision criteria, and work proactively to define a mitigation approach or hand-over plan for prioritised ownables.
How did we get here?
- The product manager grew reluctant to challenge the team because they had been burned by bad behaviour from team mates. “So will I be fired if I don’t do this?”
- The team’s people manager had an entirely different role in the company and participated primary in annual ceremonies rather than the day-to-day
- Leadership disagreements over the philosophical approach of managing a team as well as leadership turning over masked the above two issues.
- The team was aware that something was wrong but was unable to self-reflect – they felt the issue was with everyone else around them.
Restoring focus
I thanked the team for their extensive support of the external teams, and set an initiative to help that team move to a new phase of independence and autonomy, by onboarding them to own their own systems operationally, within a time-box – with dedicated support each week, pair-programming, and training, that would sun-set in the near future.
I involved the team deeper in the company strategy, injecting it into the team’s planning processes and objective setting, raising awareness on the team of where they were already highly-aligned, or alternatively had more opportunity to support, big-picture goals at the departmental level.
I challenged long-running initiatives on the team, raising the data around investment versus the rewards that had not yet materialised despite an extended time duration, and combined with the above, it helped the team to realise how they could free bandwidth to re-focus on high-impact projects which would support the department as a whole, and yield more customer benefit.
I reset expectations on the team regarding quality and bugs, and the need to ensure that we were not breaking existing functionality for customers. This included the quality of experimentation, including setting meaningful hypotheses and adhering to full-on criteria that were established at the start.
I worked with the team through a series of team-buildings that revisited the team’s purpose and scope of ownership, creating mutual standards and accountability, and clarifying the different roles, especially around decision-making and prioritisation. I created a strategy and decision framework, working with team leadership, to define the target scope of ownership, and stack-ranking ownables falling lower on the queue for hand-over or maintenance mode, ensuring business continuity.
I met extensively one-on-one with the senior developers on the team, explaining the ‘why’ of the tech strategy, and inviting them to collaborate and contribute to it, rather than veering off script. During this time, two developers felt that the changes I was introducing on the team meant the team was no longer a fit for them, and while I was sad to see them go, I’m glad they made the decision which was best for them.
A team transformed
This was a story not about punishment or judgement, but rebirth: helping a talented and independent group of people unlock their abilities and rise to their potential they already knew they had. A deep understanding of team dynamics and shadow beliefs was necessary to peer behind the curtain of the many team aspects which looked good on paper. A methodical and human approach of working through the issues – clear communication, strategic alignment, and expectation setting – combined with empathy and resolve, turned the challenges of the past into a robust foundation for the team which emerged stronger, more cohesive, and much more effective than ever before.
