You're all CTO now

Years ago I moved from being one of the developers of Podia to being the CTO. I went from spending ~100% of my time writing code to maybe 70% as more time was taken up managing people and projects. Over the years, that percentage has continued to drop and drop. and now I’m doing very little consistent coding—I ship small changes, occasional bug fixes, upgrades etc but I’m no longer on the critical feature path.

This, is many ways, really suited me. I was never particularly interested in the code itself, and I don’t miss trying to solve some daft dependency problem that didn’t advance the feature. Instead, I was always more interested in the product and the systems and being CTO let’s me operate that that level without getting too bogged down into why this particular method call is not behaving as expected. And managing people let’s me scale my impact far beyond the features I could have shipped myself—assuming I can convince them to do what I want, how I want it done.

But here’s the thing: all that comes with a significant reduction in dopamine satisfaction. I wrote about the the manager’s unbearable lack of endorphins before and I think that’s something which many more developers are going to encounter in the age of AI.

You’re a manager now

Everyone is a manager of AI-coding agents now which brings some benefits and some downsides. Yes, you can get it to automate the drudgery and have it iterate until postgres 17.5 finally builds on your machine (last night’s problem). You can have it build out a feature according to the high-level plan you had, and implement the architecture which only exist in your imagination. You’re operating at a higher level now!

You can write more code faster than before or run these agents in parallel for the real juggling-plates management experience. Look at you scaling your output!

But how are you going to feel about this? Because you are not an AI agent and your feelings, your motivation, and your job satisfaction are going to matter over the long term.

Initially, you are going to feel amazing. How can you accomplish so much, with so little effort?! This is like swimming downstream, running with a tailwind, or when that caffeine finally kicks in. You’re flying! Who knew it could be so easy?

But then what?

Let that sink in for a while. Read it again, and again. Internalise it.

What are the proudest moments of your life? What are the things you’ve accomplished in your professional career that you’re most proud of? Did they come easy? Were they handed to you tied up with a bow, or fell into your lap through luck? I bet not. I bet you had to fight for it, you worked hard, got sooooo frustrated, and pushed and pushed through that problem. I bet you were exhausted when you finally cracked it.

Those accomplishments probably didn’t just involve explaining a concept or asking a question that changed the result of a project from a failure to a success. It wasn’t just making a decision that put the right people on the right project, or arguing for a cut in the scope, or highlighting a critical flaw in the system so someone else could fix it. It wasn’t just a well-crafted prompt to a colleague (AI, or human).

Because that’s what managers do and now, as a manager of AI agents, that’s what you will do.

Show me the dopamine!

How are you going to feel that dopamine rush now? How are you going to feel that same sense of job satisfaction?

There is a popular argument that a software developer’s job is not write software but to solve a user’s problem. Bullshit. By the time it gets to a developer’s desk, the solution should always be to write (or fix, or reuse) some software—otherwise why give it to an engineer? The product manager’s job is to solve the user’s problem. The business’s job is to solve the user’s problem. And yes, at a high-level the purpose of your job is to solve a user’s problem but your day-to-day function is to write and fix software.

Being a product manager or a business owner is probably not the reason you got into the tech industry in the first place.

Being able to satisfy a user need by spending a few minutes writing a prompt probably isn’t going to bring you the same satisfaction as the endless conveyor belt of interesting logic problems you are used to solving. So what’s going to keep you in this industry? Why will you still be here in 5 years?

I don’t know and I can’t answer that for you but maybe it’s something to consider. I think it might change the types of people that the industry attracts and retains. For one thing, it seems likely that those with ADHD are going to become less satisfied in an environment where it’s hard to achieve “flow” and doesn’t reward that sort of hyper-focus.

I don’t think AI-agents are going to work as perfectly as I’ve assumed above. There will still be room for some intense problem-solving at the code level by experienced humans. Emergency developers will be standing by, ready to dive in and rescue a project when the AI’s and less-technical people fail—the parajumpers of software development. Though you might not build the feature, you might now be dropped into the unfamiliar terrain of AI-generated code and asked to fix it: a much harder and more stressful task than working to fix something you have built up a mental model of and have some familiarity with.

Out with the old, in with the new

As you start to use AI agents more frequently, you’ll get better at explaining the tasks to them. You’ll get better at breaking down the work into suitable chunks, emphasising certain attributes you want over others, and understanding their limitations. You might get better at training them and giving them the resources they need. Hint: just like managing people.

And with those new skills, your old skills will start to atrophy. I am not as familiar with Rails code as I used to be. I have not kept up with all the changes in Ruby syntax even. I understand only enough of Turbo to be able to suggest it’s appropriate or inappropriate uses but I’d need to fish out some tutorials and documentation to write it myself.

The skills you use are the skills you maintain. Sure, you’ll have the muscle-memory—once a developer always a developer, just like former athletes can still have good form—but you won’t be as proficient as you were when you were writing everything yourself.

That alone is what’s going to make that “parajumper” role particularly hard. It’s one of the things that makes even being a CTO hard because, almost by definition, all the problems that get to me are hard problems, with code I’m unfamiliar with, and skills I’m not keeping sharp.

Welcome to your new role. I hope you’ll be happy here 😅