Escape the Coding Cave: Unlock Your Team’s Potential
I. Visualization
Let’s put ourselves into a particular headspace.
We’ve just finished being the technical lead on a big project, code name: Cadence. We put together the technical specs, spent many hours in product meetings hammering out the details of the UX, and did much of the actual implementation ourselves. Finally, launch day arrives, and it’s shipped! The usual bugs here and there, a little tightening and polishing in the days and weeks to come, but overall Cadence was a success.
Only… a feeling begins gnawing inside. The sensation that things could have gone, well, better. As project retrospectives get scheduled and pats on the back ensue, we can’t help but notice the unease about Cadence growing into lasting frustration. And not the usual “time to give up” annoyance we feel about things like time zones and date math. This frustration is pointed inward, we could have been better, done more to make this project run more smoothly. But what?
This is the kind of introspection I went through at the close of my own Project Cadence. Noticing that I was Confused, I took this niggling self-doubt as a sign to engage in some more thorough meta-cognition. Doing this in my usual way, by talking RJ’s ear off during our weekly 1-on-1, I found that my frustration was rooted in feeling like I had been the bottleneck of the project.
I’d settle into a “coding cave”…while blockers stacked up in the world outside.
II. Retrospective
As the technical lead, it was my job to know from stem to stern the details and constraints of Cadence. I had the most complete mental model of the many complexities of time zones, date math, form localization, and the way those elements interacted with the project. Since most of these details were to happen primarily on the server side, at the start of each week I would find myself breaking off a nice, big chunk of GraphQL implementation and testing.
However, as the week wore on I found that the other threads of Cadence — the ones that I wasn’t actively working on — began to decelerate. Miscommunication about the behavior of a component might have become a blocker. The API that I had merged last week might be missing a detail we hadn’t known we needed. Whatever the problem was, I would put it on hold until I could power through the work I was already in the middle of. Never a great multi-tasker, I’d settle into a “coding cave”, implementing and testing the constraints only I knew well while blockers stacked up in the world outside.
Finally, I’d post a pull request and get back to tackling the blockers. The amount of work that would suddenly get moved over the line was amazing. When the rest of my team could draw on the understanding of the project previously locked up in my mind, tickets flew across the kanban board. I would spend 3 days in my cave banging together fiddly date math end-to-end tests, and then for the last two days of the week I would spend most of my time pairing, mobbing, answering questions, and putting up 3–4 small quality-of-life PR’s to help smooth the work my teammates were completing.
I had heard the phrase “high-leverage work” before, but I had never thought of it beyond a vague notion of “work smarter, not harder”. But as I was reprocessing my experiences during Cadence, I felt a shift. The lightning bolt of epiphany. I finally grasped in a visceral way what it meant to focus on high-leverage work.
Take everything you know about the work at hand and write it down.
III. High Leverage Work
Yes, “work smarter, not harder” directs your energy in the right direction. I was used to applying this mantra to my work as an individual contributor on a project: automating boring tasks, DRY-ing up code as I went along, making things work before I tried to make them right — all the programming truisms. But where I had fallen down was that as a tech lead, my end goal had shifted from getting through my own work as quickly as possible.
High-leverage work as a technical leader means being a force multiplier for everyone else. Your responsibility is no longer to simply move individual tickets across the finish line, it’s to keep the entire project in motion. You’re not necessarily slamming home runs, you’re lining up the at-bats to get folks on base and scoring.
The time and energy you have to do real quality work is limited, making it more important than ever to spend time on the work that will make everyone most effective.
So how do we go about finding where we’re most needed?
First, slow down and take a breath. The first thing human brains tend to do is conflate importance with urgency. The quality of your decisions are the currency of leadership, so take all the time you need to make the right decision.
Next, take everything you know about the work at hand and write it down. When you’re leading a project from vision to delivery, you alone see the intimate details of how it will all come together. Your number one goal should be to democratize the knowledge locked up in your head. The easiest way to become the bottleneck is to ensure that everyone has to wait for you to have an opening to answer questions, attend a meeting, or pair up on a ticket. You won’t completely shed the responsibility of being the point-of-contact for the project, but you can give folks a place to go when they don’t have access to you.
Keep track of the work you’re doing, including how much time each thing is taking you. Meta-cognition benefits from having real facts to turn to when your memory is hazy. You won’t need exacting notes — general terms should do: an hour or two writing docs, two hours in meetings, half an hour pairing, and so forth until you’ve accounted for your time.
Something that often helps me is to take note of sentiment throughout the lifecycle of the project. I want to be able to answer questions like, “What am I spending my time doing when I feel least energized about the project?” and “What activities am I dropping the ball on when people start feeling unsure about how the project is going?”.
Then, set aside some time for retrospection. Look back over your notes and break your tasks into sub-lists labeled A, B, and C.
- A — Things only you could have done. These are tasks that required your unique understanding and perspective on the project. It might be attending high-level strategy meetings, writing specs, documentation, and test plans, or leading a mob session. Many of these are going to be your higher-leverage tasks right off the bat. Confirmation can come from your sentiment notes — the really high-leverage tasks are the ones you were doing more of when you notice sentiment improving.
- B — Things anybody could have done, even if not to the same level you would bring to it. These are tasks you should probably delegate. This work might be some of the more important work of the project, such as implementing key modules, ripping out some nasty prerequisite tech debt, or even some of the things that might otherwise appear on your A-list. Although they might benefit from your enhanced understanding of the context, delegating that work to someone else is a great way to force you into democratizing that context. As a bonus, many of your B-list tasks are great career-advancing opportunities for your other teammates.
- C — Things that other people could have done better than you could. These are tasks you should almost always delegate. There’s no sense in inserting yourself into tasks that not only use up your limited time and energy, but would have benefited most if you were not the one doing them. These could be tasks that might appear on someone else’s A-list, where they have the superior context and knowledge. Or it might be tasks on the border of your expertise, where you would have to spend precious time catching up. This is often time better spent doing tasks on your A-list.
As you fill out these lists, you’ll come to a greater understanding of what work you do every day increases the productivity and happiness of everyone around you. Just remember to keep in mind your limited time. Odds are your A-list will have enough tasks for you to cut or delegate some of them on any given day. Keep in mind too that your teammates equally have limited energy and time. Sometimes the most leverage you can apply is to take a task off of somebody’s B-list so they can focus on their A-list work.
V. Conclusion
Here at Koan we make it a point to reflect on our work. Retrospective meta-cognition is one of our few superpowers as humans, and with it we have the ability to improve ourselves and our performance and happiness over time. I encourage you to take a look at your own work, seek out the tasks that allow you to become a force multiplier for your teammates, and cut the toil that helps nobody. Remove obstacles, make constant improvements to pain points, reduce noise and confusion, and create answers where there are none.
Thanks to Danielle Heberling, Daniel Kaczmarczyk, RJ Zaworski, and Matt Tucker for reviewing drafts of this post.
