Hands-on Again?

I recently wrote a couple of articles on how Engineering Leadership is changing, and what are the new skills required by the role. Is regularly producing software also one of these skills? I’ve been thinking about this recently since we started seeing companies mandating a larger part of Engineering divisions (including management and senior management) to produce code on a daily basis, and even hear of CEOs writing 10,000 lines of code a day. Not to mention, I’ve been producing more code (“writing” at this point would be a clear overstatement) in the past month than in my last 10 years combined.

For a long time the answer has been consistent: leaders should stay out of the codebase, delegate and trust the team, scale through people. That has been my advice for the past 10 years, because the only way a manager could improve delivery speed or quality was through the engineers doing the work. Mentoring, clarifying requirements and priorities, reviewing architectures, removing waste from the development process, and removing obstacles that get in the way of team deliveries were the main focus.

That hasn’t changed, it is still the goal. We are still measured on whether the organisation ships faster and with fewer defects. What has changed is that AI now lets a leader affect productivity and quality directly, with their own hands, for the first time in years.

Production code is still the wrong place to start

The wrong answer is (still) to pick up some Jira tickets and commit production code. A leader’s day is full of interruptions, and unexpected changes, and it would be irresponsible to be on the critical path for important system updates. The leader should never be the bottleneck the whole team waits on.

But there are many hands-on, coding tasks that can be chosen that will survive interruptions. Prototypes, tooling, monitoring can be picked up and put down without a release depending on them. That is how I would frame it: build the system the team works in, and do not take the team’s work.

Working ahead of the team

Prototyping ahead of the team is a very consequential place to start. AI lets you take an architectural idea or a business question and test it to a level never available before. What happens if I build a UI on top of existing data storage? What if I build an MCP over an API? You can verify if an idea has legs before any engineers are committed to it, and all that in a few hours. A working prototype built in hours is still the most powerful way to prove if an idea is worth pursuing or not.

Doing this personally also has positive side effects. The most obvious is that it keeps you close to the codebase, or at least part of it. Not as close as a developer would be, but at least it keeps you digging into it to learn (or remind yourself) of its architecture and API. It also allows you to deepen your understanding of AI coding tools, learn which frameworks, patterns and prompts produce code that holds up to scrutiny of full-time developers.

Strengthen the “system”

The larger and more durable work is building and maintaining the tooling the whole team uses every day.

Documentation is one clear case. The hard problem of keeping documentation correct as the code changes is easier to solve with AI automation. A leader can now build a system that enforces this, rather than leaving it at the bottom of a backlog. The same applies to keeping test coverage complete as the code moves, and to keeping the description of the architecture true as the system evolves.

Small tooling and utilities are quick-win opportunities: dedicate some time to automate routine tasks (setting up environments, automating production investigations, …) with your favourite AI coding tool.

Finally, testing is the other obvious area. Analysing automatically flaky tests, discovering untested areas and improving coverage, producing a wider set of test data, automatically ingesting and parsing test logs to find new bugs; the possibilities are really endless.

Agents that monitor the organisation

The internet is on fire recently with the concept Loop Engineering for good reasons. Building agents that monitor the organisation continuously and act, rather than dashboards that require a person to remember to look, represents a further step forward in AI adoption. This is continuous organisational improvement, the ultimate goal of Engineering leaders.

Agents that read the logs each day and open issues for new or recurring errors; others watching the metrics and raising anomalous values. Agents monitoring how long pull requests wait for review, how long they take to merge, and how many comments they draw. All of these are examples of creating a self-improving organisation.

What to monitor, how to do it, how to activate self improvement loops, none of that is clearly defined and documented yet, and it’s again up to leaders’ creativity to imagine how to shape the organisation to capitalise on that.

Conclusion

Should Engineering leaders take a more hands-on approach now that AI coding tools have accelerated software development? My answer is yes, 100%, following the examples above or others taken from your personal experience.

Anything that increases productivity and quality is worth pursuing. Especially if it’s something that fits well with managers’ and leaders’ agenda, something where you can make significant progress in the little time between meetings and other management tasks.