I remember being a technical lead, believing that it was my job to make sure everything was doing correctly and as quickly as possible. The result was predictable: I made myself a bottleneck because I was afraid to delegate important tasks to other people, for fear that they’d do it poorly and have to redo it, or even simply because it would take me less time to do it than to explain to someone else how to do it. I know now that letting myself be a bottleneck is a bad idea, but I wasn’t able to explain why very well until just a moment ago when a long-awaited neural connection finally happened. I almost felt the crackle in my brain at the point of impact.
Tim Ottinger wrote about Sooner, Not Faster, which I describe to people frequently in my work as a consultant. My goal in teaching test-driven development is not to help programmers write code more quickly, but rather to help them deliver solid code sooner. The time-saving techniques include being clear about what to build before trying to build it (write a failing test first), building only what you need (write just enough code to pass the test), stopping when you’ve built enough (continue until you can’t think of more failing tests to write), and keeping the code clean as you go to avoid building up inventory of uncompleted necessary work (“clean the kitchen” refactoring). Not all these techniques involve thinking or typing more quickly. Some involve thinking more to type less and knowing what’s enough then stopping. In general, I help teams by focusing on how to deliver a satisfactory result sooner, no matter how fast or slow the individual tasks are completed.
Now I wish I’d thought that way as a technical lead. If I have a backlog of 10 tasks that take a total of 4 weeks to complete, but I could delegate some of those tasks to others, then even if they take 5 times as long as I do to complete those tasks, I could delegate any task up to 3 days in length and, as a group, we could be done in 3 weeks, even if we spend more total time working. The alternative is to keep those tasks for myself, then have the others do busywork to avoid looking idle. You might think this is a false alternative, but how many people on your team are working on its top three priorities, and how many are working on other things? The other things are busywork!
Had I thought this way, I could have benefited dramatically. More important work would have been completed, I’d have learned how to delegate effectively, and I would have felt (and probably now feel) less stress.