From junior to Jedi - cracking the leverage code
Summary
Most tech companies want to run well-leveraged teams; i.e a few senior people and a bunch of junior people. But many of us lack the process discipline to do this well.
Frontline leaders, such as tech leads must have the time to coach junior colleagues.
Inexperienced team members should have the safety to fail and learn from their mistakes.
Team knowledge and best practice must be easy to access, in self-service mode.
There are many impediments to these three conditions. Facilitating such a team environment against the odds, is a function of effective team design.
I work in the IT consulting industry. It’s no secret that our business model is simple. We put talented people in front of clients and they pay us by the hour. The more people a client needs, the more money we make. In such service-oriented setups, a term we often speak of is “leverage”. Here’s what it means, in plain English.
“The ideal split of team members, by seniority and proficiency so that you can deliver your project at the highest possible profitability.”
With that definition in mind, let’s expand the jargon a bit more.
A team that has a few senior people and a lot of junior people is a “well-leveraged” one because it’s cheaper to run.
In contrast, if you have too many senior people and too few junior people, your team’s costly to run. Hence, you have “poor leverage”.
Well leveraged teams cost less to run and also leave room for people to grow
The exact ratio of what’s “well leveraged”, varies by company and business model. It’s fair to say though, that every software development team wants to keep its costs low while continuing to achieve its objectives. It doesn’t matter whether you’re a services firm or a product company or a non-profit.
There’s also an intangible value to bringing inexperienced people into our teams. As Shunryu Suzuki famously said, “In the beginner's mind there are many possibilities, but in the expert's mind there are few.” Newcomers bring fresh perspectives to teams. While some of us have the battle scars of experience, newcomers are unscathed by the past. If your team can help junior people be productive with little or no stress, you may see the payoff in fresh ideas for the products you build.
If doing more with less is indeed so important, it’s worth reflecting on how we achieve this goal. So, in today’s post, I want to take a team-centric view of what it takes to achieve healthy leverage.
How does a team create leverage?
All of us have been “junior” in the early days of our careers. You and I know what it takes for someone to become proficient at their job. They need on-job support because no amount of training can ever prepare you for the real world. People need the space to fail, and to learn from their mistakes because that’s at the heart of deliberate practice and a growth mindset. And finally, people need ways to self-service - i.e. to find things out by themselves and get answers to their “dumb questions”. Let’s be honest - this is true not just for junior people, but even for “senior” people who may start something new in their careers.
On a team of engineers, this translates to a few conditions.
Team leads must have the time to coach others on their team.
The team environment must provide space for new team members to try things out and to learn from their mistakes when they fail.
All team knowledge must be easy to access. This is the notion of a shared, objective reality.
That sounds simple, doesn’t it? Yet, achieving healthy leverage is a struggle for many companies. To find the solutions, we must examine our experience of software teams, from a closer perspective. What stops us from fulfilling these conditions? How can we get better and create a resilient team that welcomes relatively inexperienced people?
The crisis of overburdened leaders
One criticism of the agile manifesto is that it doesn’t pay enough attention to “leadership”. It says that if you build projects around motivated individuals, they’ll self-organise and get the job done. Cast me out of the church if you will, but I find this overly simplistic. Effective leadership is essential to a functioning team.
The trouble with this lack of focus on leadership is that even when people carry the designation of a team lead, they’re diffident about their authority and responsibilities. It doesn’t help that companies tip-toe around the idea of leadership by throwing out nonsensical ideas of a “flat culture”. As a result, team leads become reluctant leaders. They spend most of their time coding. This isn’t a bad thing, unless it happens at the cost of “team leading”!
The other anti-pattern I’ve noticed is that team leads have too many direct reports. In such cases, even the most well-intentioned and empowered tech lead cannot be effective.
What should happen instead? Here’s what I suggest.
Team leads should make coaching one of their primary responsibilities towards the team. Pair programming is a great way to stay close to one’s craft, while also helping junior people learn. One-on-one meetings, code reviews and design reviews can help tech-leads offer guidance, even when they’re not coding.
No one becomes an effective coach overnight. Companies must train their first-level leaders to become effective coaches. Practising radical candour must be a non-negotiable skill for people in such roles. At Thoughtworks, we expect people in lead roles to be proficient at exchanging feedback and coaching.
Maintain a lead-to-direct report ratio of 1:5, or less. It’s unfair to expect a manager to support any more people. This gives the lead enough time to pair with others rotationally and to conduct weekly check-ins. Weekly check-ins are also a fabulous way to revisit people’s expectations, share feedback and to nudge them to learn and try new things.
All this said, even if you set your team leads up for success, your team environment may be too chaotic to include junior people.
When everything gets crazy at work
I’m amazed at how normal it is for people to say “It’s crazy at work”. On software teams, this manifests itself in what we call a “death march”. For those unfamiliar with the term; “death march" describes a high-risk project with unrealistic expectations and tight deadlines. This leads to overwork, exhaustion, and a high likelihood of failure.
One would think that agile projects can’t become death marches, but they often do. The word “agile” invariably leads business stakeholders to think of the word “fast”. I wouldn’t fault them, but that misconception leads to unrealistic plans. When you’re behind the eight ball with your plans, two things happen.
There’s an “all hands on deck” approach to developing software. Even if your team leads commit to coaching and have less than five direct reports, they have no option but to code all day. When they don’t code, the team falls behind even more.
To add to the chaos, there’s no room for error. Guess what? Junior people who aren’t getting on job support and coaching will inevitably stuff up somewhere. This isn’t necessarily a bad thing; it’s just the nature of learning a craft. You don’t learn to do a backflip, without landing on your backside a few times. But when a team is under pressure, every minor mistake adds up. Before you know it, the team leads ask for more experienced people on the team, to fix the problem.
Let’s first admit that this is a wicked problem to solve. If you have an unrelenting business stakeholder, you’ll also have a poorly leveraged team. That’s the law of nature! It’s up to you to decide if this is a problem you can live with.
But if your stakeholders are amenable to reasoning, then it helps to take a step back and reflect on the state of your project. While I don’t have quick fixes for you, I have a few things for you to consider.
“8 hours for work, 8 hours for life, 8 hours of sleep. That’s a fair formula.”
How sustainable is your pace? As 37Signals says, “8 hours for work, 8 hours for life, 8 hours of sleep. That’s a fair formula.” Think about revisiting your plans with that balance in mind.
Many stakeholders are happy to negotiate scope, as long as you don’t mess with the delivery timeline. If you deliver the highest-priority features early, you can reason with stakeholders to deliver some low-priority items at a later time. If you do continuous delivery, this can be an easier conversation.
We’re all prone to the planning fallacy. We underestimate the time to complete certain tasks, regardless of our previous experience with them. Account for this optimism bias in your planning process. In an earlier post, I described how to decouple time and size in your estimates. Check out my estimation and planning masterclass to learn how you can build contingency into your plan to negate optimism biases.
Resist the one-month-birth fallacy! As you know, a woman can give birth to a child in nine months, but nine women can’t give birth to a child in a month. There’s a point beyond which adding more people to a project won’t make it go faster. It may, in fact, increase communication churn on the project and slow you down further.
Working with your stakeholders to create a calm project environment is an essential pre-condition to achieving healthy leverage. At the risk of sounding like a broken record, this needs “leadership” as well.
Then again, it isn’t enough to stave off business pressures. The safest team environments cannot function effectively when they become noisy.
Losing our battle with the hyperactive hive mind
A recent paper on developer productivity details three key dimensions of a productive developer experience - a.k.a DevEx.
Fast feedback loops. The sooner we get actionable feedback, the better our ability to act on it. This comes from setting up efficient development environments, optimising build and test processes and reducing wait times from manual hand-offs.
A flow state. We achieve this joyful state of work when we can perform our tasks without interruptions. Too many meetings and chat messages, and there goes your flow state.
Reduced cognitive load. It’s unproductive to keep heaps of knowledge in our working memories. The lower the cognitive load, the easier it is for any technologist to build software. We lower this cognitive load by making information easy to access and by organising teams, code and documentation such that it feels intuitive to the team.
The three core dimensions of DevEx
Now imagine a rookie developer in a team that hasn’t paid attention to these aspects of productivity. You’ll notice many symptoms of such negligence.
People end up waiting for a long time waiting for a test suite to run before they learn about the impact of their changes. This discourages frequent commits, which in turn hinders their learning.
Manual processes such as kick-offs, desk checks and code reviews impede flow and fast feedback loops. People spend inordinate amounts of time waiting for others.
Information isn’t available in a self-service mode. Large parts of the day go into meetings and chat conversations, to ensure that people have the information they need for their jobs.
Without a well-designed, and well-understood process, people reimagine the process for every challenge they face. This leads to communication churn. Constant interruptions in the name of “collaboration” hinder our flow.
Since inexperienced developers have the least sophisticated mental models to engage with the project, they create much of the communication overhead. Before you know it, senior team members feel frustrated by the collaboration tax they pay and they ask for more experienced hands on the team.
If I haven’t made my point about leadership already, let me make it one more time. Just so it’s clear. Designing the developer experience is a leadership responsibility. You’ll want to avoid the hyperactive hive-mind effect that I described above. Here’s what you must do if you want to include less experienced people on your team.
Document everything. Anything that anyone knows, everyone should know. Create a team handbook. Follow the DEEP mnemonic to remind everyone about their documentation hygiene.
Reduce FOMO by documenting meeting minutes and decisions. That way if anyone has a question about how you got to the current state of your project, you’ll have artefacts to point them to.
Streamline your onboarding process. Protect people’s “dumb questions budget” by maintaining a project FAQ. Every code repository should have a README explaining how you’ve structured the code. People should be able to self-service themselves through the onboarding process, using a simple checklist. Optimise your process to where people can commit code on day one.
NEO - Thoughtworks’ award winning developer portal
Extend the philosophy of self-service to developer documentation. Document your internal APIs and make software templates and assets available using a developer portal. This’ll not just simplify communication in the team, but it’ll also help you make good practices visible.
Leave nothing to guesswork. Document your ways of working and communication protocols. For example, a consent-based decision-making process can avoid a lot of back and forth and can help you train new hires to adopt effective decision hygiene. Be clear about your team’s focus hours so everyone enjoys a flow state for part of the day while being available for meetings at a later time.
Structuring your teams effectively can help simplify communication and reduce cognitive loads as well. Matt Skelton and Manuel Pais’ work on Team Topologies, can help you revisit how you organise yourselves. In addition, writing a Team API will clarify how you interact with other teams. The time you free up through such reorganisation can go towards supporting less experienced people on your team.
If you’re a leader, you scale yourself by not having to solve the same problem twice. Once you uncover a pattern to solving a problem, share the pattern through templates, frameworks, documentation, learning materials or other mechanisms. Your junior colleagues can then reuse these patterns and benefit from your experience. When you practise such metawork, your work works for you, even when you’re asleep.
Indeed, you achieve a truly calm work environment when you avoid the hyperactive hive-mind phenomenon. All the time and capacity you save from this chaos can go into supporting junior colleagues on the team. That’s how you can improve your team’s leverage.
The more I think about these business challenges, the more I’m convinced that team design must be a first-class competency in distributed organisations. It’s no longer a question about where we work. It’s about how we work. Healthy leverage stems from healthy work practices and a calm team environment. That doesn’t happen by accident. It’s a conscious act of design. What do you think? How are you helping your junior colleagues become Jedis? I’d love to hear about your experiences.