I enjoyed this recent article from Tanya Reilly about Having impact in engineering by supporting other people’s ideas. Her post contains a lot of good advice, and I wanted to expand on the section, But it’s not how I would have done it, where Tanya highlights the importance of being open to different ways of achieving the same goal. It brought to mind the challenges I had around delegation in my early years as a team leader, and some related ideas that I’ve found helpful over time.
Being clear on what versus how
Whenever you’re delegating something, it’s important to be clear on the difference between what you want the person to achieve, and how they could go about achieving it.
Let’s imagine you’ve asked an engineer in your team to manage the team’s latest project, and one of your expectations is that project stakeholders are kept informed of progress throughout. As someone who has managed multiple projects in the past, you know exactly how you would do this — the format, the cadence, the style, etc — and no doubt these choices have been, at least in some way, effective. That doesn’t mean that this is the only way to be effective, nor does it mean that this particular project doesn’t warrant something slightly different.
There may be aspects of your approach that you think are particularly important — for example, you always send a status update every 2 weeks, even if little has changed — but if you’re going to insist on specifics like this, you should have strong justification for them that ties them back to the what. In this case you might argue that the regularity of the update helps create a sense of continuity and momentum, which stakeholders appreciate.
In much the same way as in programming, with interfaces (what) and implementation (how), it’s more important to define the right interface (to be clear on what you are trying to achieve, and any expectations on the outcomes), and be less attached to the exact implementation. This is the same mentality that if you’re managing team leaders, is vital to enable each team to have its own unique culture and sense of autonomy.
Being comfortable with good enough
Just because the how is less important than the what, doesn’t mean that all approaches are equally effective — depending on the context, some will produce better results than others. As a team leader you are accountable for the quality of the work the team produces. I remember feeling the weight of this responsibility, and wanting to feel in control similarly to how I’d been in control of the quality of my own work as an engineer. I found this (apparent) dichotomy uncomfortable: being answerable for quality, while at the same time recognising a need to delegate and not micro-manage how people do things. To overcome this, I had to get comfortable with what “good enough” feels like.
I like to explain “good enough” through the analogy of grading a test. Let’s say for simplicity, you would rate your own ability to do something (run a project, present a tech review, facilitate a retro) as an A. This is based on your repeated experience, positive feedback, and success in the past. Now try to think back to the first time you did this activity — what grade do you think you got then? Maybe you got a C+, or even a B. Hopefully you received feedback about what worked, and what could have been better, and you were able to put that into practice then next time around — that is how you improved, and how you became an A-grade practitioner.
Though it’s obvious, it’s easy to forget that people don’t just know how to do things — for example, no-one was born knowing how to manage a project — all skills need to be learnt. If someone hasn’t done something before, been shown what great looks like, or had any constructive feedback, it is unrealistic to expect them to be good at it. Every person is a work in progress, and achieving mastery does not happen overnight. The difference between an imperfect, good enough result, versus an A or A+ result that you micromanaged to guarantee, is often not a trade-off worth making. Whilst the outcome of that task may be better, the missed opportunities for learning, the reduction in autonomy and motivation, and the damage to the relationship is overall a net loss. Don’t deprive the individual (or yourself) of a learning opportunity of a different way of doing things.
Deciding whether to intervene
What good enough looks like is subjective, and depends a lot on context. One of the hardest questions you wrestle with as a leader is when to intervene and course correct if you perceive that things are going wrong, and when to stand back and let it play out (for the learning experience), even if you know the outcome won’t be as desired. We can learn a lot when we fail, and if you as a TL are constantly steering for others, not only will you have no time for anything else, but you’re also removing important opportunities to learn.
When thinking about whether to intervene or not, I ask myself two questions:
- What is the impact if I don’t intervene? For example, will this delay the release of a feature by a week, a month, or longer, and how much does this matter? How will this impact the complexity of the final system, and our ability to maintain it? What is the “blast radius” of damage — is it contained within our team, or will it have knock-on implications for others?
- How reversible is this decision in the future? If we start in a particular direction, and realise it’s not right, can we turn back and change our minds? What is the cost of doing so?
If the decision is low impact, or easy to reverse, I will try to give the benefit of the doubt to the individual and not intervene. If it’s high impact or hard to reverse, I will pay more attention to it, ask more questions, and discuss how we might be able to de-risk it. Tanya talks about some great ways of doing this in her article, through prototypes, interim milestones, or gathering more data.
By focusing less on how something is done, and more on articulating what needs to be achieved, the why behind it, and the expectations of what success looks like, leaders can scale themselves, and help grow the people they support. By optimising for autonomy, and making careful judgements over when to intervene, you can maximise the learning experiences of your team, and increase your impact.
Thanks to Melanie Harries for reading drafts of this.
