Anti-Technical Bias

An evergreen topic it seems.

A broken clock is right twice a day, and some of my old blog posts come around every few years. I’m in various technical leader chats, forums and face-to-face meetups, and one idea seems to come up over and over again. Whether it’s said over a pint or from a stage by a speaker, there’s this perennially popular idea that to succeed in tech leadership, you don’t need to be technical.¹

Let me be absolutely clear: this is only ever true if, and only if² the leader in question has independently developed the same gut feeling and reasoning that the apprenticeship path of software engineering tends to develop in most competent engineers.

And what is that reasoning? The goal of technical leadership is systematization.³

I wrote in several posts about the apprenticeship pattern of ‘software engineering’ described by Adewale Oshineye and Dave Hoover in Apprenticeship Patterns,⁴ and I think that an important result of taking this approach to a technical career is necessarily that your analytical and problem-solving skill, as well as your simple gut instinct become highly trained.⁵

That training (in my experience) tends to express itself as pattern recognition. Knowing the detail, it is possible to then interrogate whether a pattern you have identified (or intuited) has any basis in reality. This is where the ability to switch back into the detail matters.⁶

The logical fallacy is that because systematization is independent of deep technical knowledge, it is somehow mututally exclusive. This is not the case.

In essence, you have to be very senior before having no grasp of the detail is describable as anything other than a weakness. I’d use the analogy of me trying to explain the benefit of functional-core, imperative-shell (pick your code organisation habit of choice here) to an entry-level developer.⁷

Without experience of at least one large, production project experiencing growing or maintenance pains, not only does that developer not have any context for understanding the deeper implications of the argument (or perhaps even the foundational need for change or improvement at all), they also have no experience of it on either a hands-on level, or perhaps, more importantly, on an emotional level.⁸

There’s always a risk of over-priviledging your painful failures like the character on the Five of Cups,⁹ but it is through systematizing these lessons that truly exceptional individuals self-actualize (to use a dreadful term).

The counter-argument is of course clear at this point. The goal of technical leadership is systematization, and that is independent of deep technical knowledge.

This means, surely, that tech leaders don’t need to be technical.

Obviously, I can’t disagree with this point—I can merely restate that yes, of course not all engineers will be able to contextualise and systematize their successes and failures, but they empirically have much more opportunity to do so than those that are non-technical. They will encounter these situations daily, monthly, yearly over the course of a ten or fifteen-year track into management. That is an observable, testable, quantative fact.

The fallacy, I think, being played into is that because systematization is independent of deep technical knowledge, it is somehow mututally exclusive. This is not the case.

Moreover, technical leaders do not exist in a vacuum, and they will have talented non-technical colleagues, likely in product, design, delivery, and other disciplines, to collaborate with. Again, ability to collaborate is independent of deep technical knowledge, but it is not mututally exclusive.

So if you’re an effective technical leader from a non-technical path—celebrate yourself, and know that I’m not getting at you in this post. I’ve worked with many excellent non-technical CIOs and CTOs. No doubt I will work with many more in future.

However, if you want to be a technical leader, doing it the easy way definitely means doing the long yards in a technical role and reflecting on your work as you go. The really harmful thing about this debate is the same thing I identified in my old post (nearly eight years ago!)—that the advice that they did not need to pursue a technical track was being given to folks in their early career. In the general case, this is objectively not correct.¹⁰

1. The even hotter take you often hear is that being technical is actually a drawback. With the current AI hype cycle at fever pitch, it’s not surprising the idea that you don’t need to be technical to be a tech leader is doing the rounds again—with the added side that perhaps you don’t need to even understand code in order to ship it to production as an IC. The latter is obviously a spicier take—here I’m going to dicuss leadership.

2. iff, one of my favourite shorthands.

3. Just as, I suppose, it is the goal of big ‘S’ Science, or Scientific Research in particular.

4. Which feels sadly out-of-touch to recommend to young developers now. I’m not sure with a straight face I can tell them that investing in mastery is worth it in an age where that is systematically undervalued by organisations and structurally undermined by AI. It’s telling that most young technical people I’ve met—even if they have excellent promise as engineers—are looking to instead get into consultancy or product, two areas they (perhaps) see as harder for AI to replace.

5. If you are solving problems with stakeholders, end users et cetera, anyway. I can see that maybe if you’re a driver engineer or work on kernels, or parsers, then perhaps you will have to spend less time on the people side of the job. That said, for open-source projects, I imagine it’s more that it’s different in appearance but similar in reality. This was certainly the case when I worked on smart contracts and blockchains. It felt eerily familiar to enterprise work. As an aside, the importance of developing and maintaining this intuition is an issue with over-reliance on LLMs (AI tooling) as either (a) this skill may not develop, or (b) you may deskill and lose the intuition you did have.

6. And believe me, I’ve had to defend a suggestion of ‘isomorphic typescript’ that was deep in a report at a C-level meeting before. I’m not making this stuff up, though perhaps the people in that meeting didn’t need to dig that deep in the detail. That’s sort of the job of the technical leader in the room.

7. Possibly even one only familiar with a different paradigm—I’m thinking here of students familiar with Java that join a Rust project, say—there’s a lot of context to absorb.

8. If you’re thinking “what exactly is he on about here?” I may just have successfully nerd sniped you.

9. Satirized, of course, at the start of this post. No, I don’t know why the engineer is wearing a frock coat either.

10. Armed with two-plus years of arguing academic points, I finally feel like I can make this argument as precisely as I wanted to back in the day.