My take on the competency trap.

Many posts I've read on this topic tend to focus on the technical leader that struggles to let go of coding. They hold themselves back from engaging fully in the leadership role because they believe they're now just the most senior engineer - so continue to focus on the same things.

I think that's only half the story.

I think there's a second, harder, trap to escape. I'd argue that as we move up the leadership ladder, failing to backfill our own competency leaves us as the default answer whenever difficult problems arise.

Some pre-amble

Before we begin, I'm not advocating that technical leaders stop being technical. I think leaders who completely disconnect from the craft eventually become commentators rather than practitioners. The nature of your contribution should change as you progress, but that's a topic for another day.

The 1st competency trap

I want to focus on the 2nd trap, but it would be remiss of me not to tell you I also fell into the first trap for a while. As our company grew, as the team doubled, then tripled in size, I was trying to focus on being a decent CTO, but I made the usual mistake - I still wanted to be hands on, I still wanted to build features and the product we built was still "my baby" and there were things I wanted to build to make it feature complete to the original vision.

The feature that took two years

There was one particular feature I'd wanted to build for years - a major piece of functionality that had been on my wish-list since the beginning of the company and I'd given myself permission to build it. I still understood the entire codebase, still enjoyed building software, I was opinionated on how I wanted it to work. The problem wasn't ability, it was predictability.

I'd thought to myself though that it didn't matter - I could build the feature over an extended period of time, in any slow time, and ship when it was ready. That was naive though - once marketing and customer success knew the feature was in development, it was announced everywhere. We whipped up a marketing storm, posted everywhere about the feature "coming soon", it was a highlight of many a user group session and customers were chomping at the bit for the thing to be released.

And for a little while I was able to focus on it - I spent around 60-70% of my time on it for a solid month or two.

Then we grew - and we grew faster than we could have imagined. That's when I needed to let go of any engineering that was on the critical path - my focus needed to be on the business and on the team, but I still believed I could carve out enough time to get the feature finished.

That didn't play out - every time something happened in the business, the feature stopped. A customer issue, a production problem, a strategic discussion, hiring decision, board meeting - something else always took priority.

The result was a feature which probably represented six months of focussed design and engineering effort took me two years, at which point I finally handed over to a senior engineer to complete.

I couldn't finish it - not because it was difficult, but because my attention belonged to the company and my real "job" as CTO. I found myself parking the project for months on end - and customers started to refer to it as an urban legend that would never ship.

The 2nd competency trap

The first trap taught me that I couldn't reliably deliver product features while being CTO. The second taught me that even when I stopped trying, I could still accidentally become part of the delivery system.

Setting the trap

By the time we'd grown our business into something substantial, I knew what my job was - it wasn't spending days building features, it was focussed primarily on strategy, product, customers, hiring, architecture, outcomes, and helping steer the company through it's next stage of growth.

The challenge wasn't knowing what I should be doing, it was that whenever something genuinely difficult appeared, it eventually found it's way back to me. The buck stopped here.

One of the realities of being a long-serving CTO, especially when you co-found the startup, you're often the person with the most context. You've seen every generation of the product, probably wrote the first line of code, you know why decisions were made, remember the failed approaches and understand the strange edge cases that nobody has touched in years.

When a problem becomes sufficiently difficult, all of that context becomes valuable and as a result, those difficult problems naturally gravitate towards you. Not because anyone planned it, not because the team isn't capable, but simply because it feels like the fastest route to an answer.

Solving problems vs Understanding them.

One pattern I've noticed throughout my career is that when we find a plausible explanation for a problem, we naturally stop looking. Then the problem returns days or weeks later.

The first investigation would find a problem, the symptom would be fixed and everything would look healthy again, case closed. Until it happened again, then again. Then eventually it would arrive on my desk.

What made these issues difficult wasn't usually the technical complexity - it was knowing when to stop digging. More specifically, when to refuse to stop digging. The first answer is often plausible, the second is often better, the third starts to get to the root of the issue. Often the real cause is hidden three or four layers deeper than the original symptom and many of the hardest problems I worked on weren't solved because I was smarter than those that tried before me, they were solved because I was prepared to spend five days thoroughly gathering evidence and following the trail until I understood the entire chain of causality.

Authority over time

I had perhaps the broadest domain knowledge of the system, but I wasn't necessarily better equipped to solve these problems than anyone else. I was however better equipped to invest time in them. As CTO I had authority over my own calendar - if I decided a problem deserved five days of investigation, nobody was going to stop me. I didn't need to justify that decision, I could simply clear the decks and focus.

Thats a privilege many engineers don't feel they have - they have sprint commitments, project deadlines, competing priorities, and pressure to move on. In many cases the difference wasn't capability, it was permission.

Springing the trap

Every time a complex problem arrived on my desk and I solved it, something else happened - the organisation learned where difficult problems go. Completely unconsciously, without malice, but naturally the shortest path to a solution became "escalate it to Tony".

The more successful I was at solving these issues, the more that pattern was reinforced, the more problems came my way. I was solving the immediate problem whilst simultaneously reinforcing the long-term one.

As the business grew further, the drain on time dealing with all critical customer issues myself became quite significant. I'd helped scale the company, scale the team, but I hadn't scaled myself and I was still the default answer.

The lessons

Time becomes unpredictable

Both the first and second competency trap taught me the same lesson - the higher we move through an organisation, the less predictable our time becomes. That's why senior leaders often make terrible project resources - not because they lack capability but because they lack uninterrupted focus. An engineer with twenty focused days is often far more effective than a CTO with twenty interrupted ones.

Let go of the critical path

There comes a point where we absolutely can't be on the critical path for feature delivery. We have to let this go and focus on the business. We can keep our hand in by working not on features, but on prototypes, new ideas, new approaches, but once those things become concrete, especially when those things are being communicated to customers, hand off to the team where delivery can be more predictable.

Backfill competency, delegate authority, and force it

For me escaping the 2nd trap was harder than letting go of coding. When you've spent years solving difficult problems, it's tempting to keep doing it - it feels useful, it feels valuable, and responsible. But, that doesn't scale - it only scales when the problem is directed to the team, not an individual.

When we hire our teams we hire them because of their competency - when it comes to those complex problems that need five days to investigate thoroughly, we, as leadership aren't more qualified, more competent, but we do have the authority to invest our time. To avoid the 2nd trap, we need to ensure our team have the same authority to invest their time, and then we need to remove ourselves as the fastest path, forcing the team to take on that competency with us as support only, allowing that to scale out, and for us to scale upwards to the responsibilities of our real role - leadership.

Final words

Looking back, the competency trap wasn't believing I could solve difficult problems, it was proving it often enough that everyone else believed it too. Every time I stepped in, I solved an immediate issue, but also reinforced the idea that difficult problems should always find their way back to me.

That's the 2nd trap.

It's not that you become a hero, it's that the organisation quietly starts believing it needs one.