As software developers, “technical lead” sounds like a role we’re supposed to want. How can we decide whether we should want it? What exactly is a tech lead, and what does it take to be good at it?
What isn’t a tech lead?
We know by Schmonz’s Theorem that there necessarily exist other roles similar to, yet different from, “tech lead”. By inspection, some such similar roles appear to be:
- Senior developer
- System administrator
- Line manager
Line manager?!? Sort of. Both line managers and tech leads are better positioned to make certain types of decisions.
Sysadmin? Sort of. Sysadmins and tech leads are better positioned to understand the costs of technology decisions.
Developer? For sure. A tech lead who hasn’t been a developer faces an uphill climb to credibility, even if they somehow manage to make good decisions.
Senior developer? Depending on the context-specific meaning of the title, it could be nearly identical with my conception of a tech lead, or quite some distance away. In my experience, usually the latter.
Architect? Again, depends on the architect and the situation, but in my experience, it’s difficult for architects to do what tech leads can do.
What do tech leads do?
They help technical decisions get made.
What do good tech leads do?
They help good technical decisions get made by the team, consistently, at every level of the decision tree.
How do good tech leads do it?
Their knowledge is wide, such that given any technical problem, they know enough to guess well about potential solutions. Their knowledge is a bit deeper in the codebases they live near, so they don’t have to guess as often. And their desire to see teammates make informed decisions is wide and deep, such that they can await the delayed gratification of someone else making the “right” decision, or even tolerate the discomfort of someone making the “wrong” decision when it’s not too irreversibly wrong, if that’s what it takes for them to make a better decision next time.
What makes a great tech lead?
A great tech lead has impeccable judgment with which to make every last technical decision — and instead seeks, above all else, to share that power with teammates. A great tech lead is one who doesn’t think of themselves as “leading”, won’t be seen doing any such thing, and might appear harmless to remove from their team. Don’t go removing them! But if you do, and it turns out to be harmless, that might be because they’ve just finished doing a terrific job.
When is being “technical lead” a good decision?
When you could be an architect, but are afraid to drift from your team and your code; when you could be a senior developer, but are afraid you won’t get to share everything you’ve learned; when you could be a manager, but are afraid folks won’t get to manage themselves; when you’ve got the chops to be “technical lead”, but don’t want anyone thinking of you that way.
It’s a tough job. If you do it well, then (just like a sysadmin) you might not hear appreciation for your work until years later. Until that day comes, for what it’s worth, you’ve got mine.
I’ll be presenting Bring Your Whole Self To Work (In 15 Years Or Less)! at Self.conference. Here’s the abstract:
A few weeks into my latest gig, it became clear that what folks needed most from me was to come in every day and be myself. Cool, I was gonna do that anyway — except at every other job I’ve had, that’s never totally worked out. What makes me so sure it’s different this time? What’s changed in this new role? What’s changed about me, and why, and how?
Come hear a tale full of embarrassments, disappointments, and learnings, of mild reductions of obliviousness, of gradual improvements in efficiency, of partially mitigated personal weaknesses, and of matching who I am to where I belong.
How can I help?
If our lives have ever crossed paths (in any way, at any time), tell me the one thing you remember most vividly about our time together. Maybe something along these lines:
- What were we trying to do?
- What was I struggling with?
- What was it like to interact with me?
- What was important to me?
- What did it seem like maybe I was starting to figure out?
- What could you see about me and/or my situation that I wasn’t seeing?
- What hilariously dumb thing(s) did I do that everyone who was there will remember forever?
…or anything else that’s coming to mind. Then please yes right now email it to me.
P.S. Even if it’s been a while — especially if it’s been a while — I’ll be very happy to hear from you.
P.P.S. Even if you’re not entirely sure I’d be happy to hear from you, I promise you, I will be!
The kata’s README specifies the system’s current behavior, constraints on changing it, and a desired new behavior. Since the spec wasn’t executable, I couldn’t trust its accuracy; since no executable spec existed, I couldn’t verify its accuracy; and since the code was carefully written to be opaque, I didn’t think it was worth making an effort to convince myself I understood it. At this point, I knew only two things:
- Not going anywhere without some characterization tests
- Disallowing something makes me really, really motivated to carry out its nearest permissible approximation
After writing enough characterization tests to load the domain lingo into my head and support (mostly) my reading of the spec, I looked again at the system and at the desired new behavior. Not seeing an obvious place to put it, I instead took the opportunity — afforded by my new tests — to perform some obvious refactorings until I spotted an opening just big enough to test-drive through. And then I chopped up the concerns scattered throughout the characterization tests and reconstituted them, filtered through my newfound understanding of the system, as the one-new-thing-at-a-time unit tests I probably would’ve written to begin with.
None of this is original or special. Anyone who’s danced with legacy code knows the ungainly rhythm of this dance. And while Gilded Rose is a very nicely designed exercise, it doesn’t compare in scope or risk to a real production system. What might be interesting, since it was just an exercise, is how I decided when to stop.
Given the state of my code, I don’t love:
- The stupid not-allowed-to-get-rid-of-or-change-in-any-way
- The Primitive Obsession that remains
- The hardcoded names of items with special behaviors
- The domain concepts (like “legendary” or “conjured”) not yet explicitly represented in tests or code
And I’m happy with:
- The small size of each step I took
- The utility of my tests as they existed at each step
- The increase in my work speed (partly from tests, partly from plain old practice with the IDE)
- The new feature as safely delivered
- The unit tests as they now stand
- The likelihood that, given some new desired behavior, I or someone else could quickly and safely implement it
Remember, the assignment was to implement a new behavior. All that other stuff I did was enzymatic, enabling the assignment to be digested by my limited arrangement of brain cells. See how mixed that metaphor got? That’s why.
Anyway, I not only implemented the new behavior, but I did it in a way that felt safe throughout and that, were there a next developer, would afford them safety too. If this were a real production system, nothing in the “I don’t love” list would make me want to keep the new behavior out of people’s hands.
So that’s where I stopped. Because software development is always an exercise. We pick a point when we’ve learned enough to produce enough value, a point where more learning isn’t worth more cost, and we stop there. Every product and project leaves value on the table. I won’t pretend my “I don’t love” list doesn’t concern me (it does) or that it doesn’t matter (it does), but I’ll admit it doesn’t concern me or matter enough to be worth more cost. Every chance I get to make that decision wisely is worth practicing.
A year ago, with several aspects of my life in heavy ferment, many goals bubbled up and filtered through. How’d I do?
Said I’d make significant lifestyle changes. Did. Moved away from New York and quit my high-stress job. Got a dog and walked him lots. Biked to Cowork a few times per week. In November, underwent corrective nose and sinus surgery, producing a huge functional improvement (though post-op maintenance is still more of a hobby than I’d like). Weight feels more like myself, but not completely. New work routine affords a regular exercise routine. Will start next week.
Vowed to write at least 26 articles. Wrote only 15. Compensated, somewhat, by moving this site to a more comfortable environment (see “Ikiwiki” below), making writing more likely to occur.
Claimed that NetBSD was my top priority for the year. Did some long overdue maintenance on my pkgsrc packages, attended BSDCan for the first time, and spoke at pkgsrcCon for the umpteenth. Didn’t accomplish much for Board. Term ends soon. If lucky, I may get another chance to apply what I’ve learned for the good of the project.
Sad to have missed Kilmer. Made many bad-poetry-like sounds while home recovering from nose surgery, but none where the judges could hear. Reelected to Board. Have been attempting to enlist the active members of the Society in helping refresh their ikiwiki-backed website’s design and innards.
Committed to spend more of my time with people who care about what I care about. Got involved with RubySteps and did lots of mob programming, including with Alistair Cockburn and J. B. Rainsberger. Now I work alongside people who share my values.
Needed to feel greater appreciation for my work. Was willing to identify and deliver more valuable work in order to get it. Determined that helping teams make better decisions about software development would be highly valuable. Did some Agile coaching for my employer, and was going to change roles to do more. When that plan was impeded, I left. Now I’m a “Software Craftsmanship Coach” with a software consultancy that shares my values.
Got a place in Bloomington together. Got a very nice dog. Got good at living together. Got engaged. Not bad!
Always knew when that job ended I’d take some months off. Did. Needed the time to relearn to hear and attend to my own needs, to get right with myself before the next thing — all the more so because the next thing really did turn out to be coaching.
35-year-old me nailed it when he wrote “More than ever I know who I am, who’s for me, and who I’m for.” 36-year-old me could not possibly agree more.