I guess we're all engineering managers now

In starting a new job as an engineer after 5 years as a sales engineer, I expected the tech stack to be different, but not the shape of the work itself … even having been at the leading edge of AI in cybersecurity and software development! Thriving with extra AI “help” seems to be unrelated to personal technical ability. Getting work done means leveraging more of the “management skillset” than building systems used to.

After a few months of this, I can’t escape the feeling that we’re all engineering managers now.

This post is some patterns and a few changes on “popular engineering culture” that have helped me personally. It’s not a “tools” or “look at my stack” post. There are lots of those and maybe I’ll write one later too, once “my stack” stops changing every week. 😅

Systems are more important than code

This is more or less how I approach “ask mode” of an AI agent. 🙈

It’s easy to shame engineers for not writing and understanding every single line of code, even though many feel that business is pushing us to move so fast as to not be able to.

On a healthy engineering team, it’s impossible for a tech lead to have the ability to make decisions on every single line of code or feature or design that ships. There’s simply too many choices to be made and a single human decision-maker becomes a bottleneck. Having a manager who can’t let go sucks for the humans on the team (no agency to do their work as tasked), and for the human responsible for more than they’ll delegate. It should be genuinely difficult to micromanage each small part of a task and every decision being made. Making all the choices isn’t the job.

Many teams don’t have the systems around their codebase to withstand a 10x increase in code volume or pull requests without an equal increase in time/judgement of the humans building it.

I saw this selling application security tools all the time. Systems for code quality, build speed and increased build volumes, and security all require domain expertise in their own right. A team would buy a tool and then not invest time in configuring it or using it. A thousand alerts no one responds to is perhaps even less valuable than ten alerts that no one responds to. Now tell that same team to multiply their output, giving them lots of “agents” and no time to build the paved paths to support that.

Human time and judgement still don’t scale. Building systems to not only endure the increased volume, but find increased value in it, is still difficult.

Measuring progress is still difficult

Vanity metrics have always been part of engineering. It’s easier than ever to game these “easy metrics” like lines of code written, pull requests opened/reviewed, or Arbitrary Jira Story Points can be done in X timeframe. For approximately $15 USD in tokens, I started and finished a feature in this PR.

+5500 lines before my first mug of coffee is finished … what could possibly go wrong?

This net +5,548 line, 43 file pull request is ✨ downright rude ✨ to ask a human being to review. Large change sets are difficult to follow and review thoroughly. Yet, this was done before my first mug of coffee was even cold. It wasn’t even bad. Each check for security, quality, maintainability, and more found something. For the most part, I was pretty uninvolved in the fixing.

Roughly 30k lines of code across a few features shipped that day, something I could never accomplish as an individual developer. It also was nowhere near that number of code lines versus specifications, decision records, comments, and citations across the codebase for behavior elsewhere.

I read and review a hell of a lot more code now than I’ve ever done in any prior role as an engineer. Keeping the bots in line and moving in the right direction isn’t writing software, but it is building something.

Automation, AI and not, handling as much as possible is the only way to scale humans-to-code. These checks include static analysis and composition analysis checks for code security, linting to keep it all consistent, and unit/integration tests. Keeping AI reviews constrained by brevity and “only focus on the important problems” prevents me from getting bogged down.

Making code understandable is still the hardest problem

This guy was the scourge of codebases everywhere with their single-letter variable names, no comments, and obfuscated or inconsistent logic. These problems are weirdly easy to point a coding agent at to have them consistently rename functions or variables, add comments, and make other quality of life improvements. With strict direction to not change the logic, but instead only rename things, AI rips through this problem quickly and reliably now. The “scumbag dev” of my first run through engineering isn’t the same problem anymore.

The new “problem teammate” is (by themself or with AI agents) constantly switching conventions in the codebase, shipping abstractions upon abstractions, or repeating functionality across different files or classes. These bad habits are enabled by

• not writing the code
• not reviewing the code
• not explaining the code to another human being
• merging code without any of the above

AI’s propensity for verbosity and abstractions makes it hard to engineer in different ways. Writing a ton of code/comments/documentation changes the problem in quantity more than quality. The hardest problem remains factoring the code correctly and breaking the problem down with human-understandable abstractions.

Talking to real humans is still my favorite tactic to keep this challenge in check. Social debugging unblocks me, but also keeps the solution in line the team’s needs. Likewise, if I can’t do an “elevator pitch” on why my pull request matters, is it worth asking someone to spend time on reviewing it?

Constant context switching changes the joy of building

I don’t find myself “in the flow” naturally anymore. Wrestling a single problem on my own isn’t my normal anymore. Instead, this pic is my typical flow by mid-morning.

around five agents is about my sweet spot for tasks I can directly supervise

Five separate AI agents running five different loosely-related tasks, mostly working independently. Each needing me to unblock and give direction every so often means I don’t get “focus time” of my own. I’ve felt this before, transitioning from an engineer into a team lead. When my job changed from completing a task to making sure multiple other people complete theirs, I was following a path well-worn by other engineers before me.

We’re all figuring out how to make use of this new technology. There’s lots of “this works for me, YMMV” and less studied and proven effective practices. It seems the industry expects engineers to ✨ just adopt it ✨ as a tool and not a career change.

Breaking down a problem, succinctly writing out the approach to take, and documenting the interfaces of how each agent’s task interacts with others is the most important parts of making progress. In other words, I’m functionally more “tech lead” or “engineering manager” than an individual contributor.

At no point did anyone say “leadership”

This new quasi-management role lacks a lot of the joys of management. I don’t think about which problem should be engaging or fun for each of my AI agents, or what work will help them get to where they want to be. There’s no joy of mentoring another human being, learning from them, or sharing the delight in finding a novel approach to a problem.

I delegate tasks that I’ve broken down in exceptional detail to what feels like very smart, enthusiastic juniors that have encyclopedic (mostly correct) technical knowledge of common frameworks. Their common sense seems to be improving, yet with no real input on my part. It’s not like I’m growing as a leader while wrangling bots either.

Many of the management skills helpful to herding the bots still don’t translate to the human skills for mentoring, persuasion, and building a business.

Am I building the right thing?

the timeless tire swing comic, posted at every construction field office, and remixed for decades

This classic construction picture was posted in my field office, textbooks, and so much more. It’s been remixed over the years for various industries, with the core lesson on communication staying the same.

The cost of generating code (and the materials for a tire swing) has collapsed. I’m ripping through backlog items and experimenting faster than it was economically possible a few years ago. The cost of being wrong has plummeted, so long as the system around my experiments won’t let me catastrophically fail.

Getting to wrong faster isn’t valuable and humans remain the only metric that matters. The delight of building is still here, even if I had to look for it. 🥰