We are all Engineering Managers Now

Several interviews and talks have been making the rounds lately. This one with Lex Fridman and Peter Steinberger and this Config Management conference talk from Adam Jacob both struck me as related as we all adjust to working with AI.

Jacob’s call out that “Ops velocity always follows dev velocity” was certainly proven true by the migration to the cloud and the subsequent DevOps movement. It will certainly be true again as developers harness AI and the capability to churn out code at breakneck pace.

Both call out the shift from IDE to environments that are not an editor (claude code, codex, gemini cli, etc) and the increase in frontier model capability as being pivotal moments staging us for what is next.

Meanwhile engineers are struggling. The engineer’s struggle however, is different from getting used to Waymo or other AI changes, such as those faced by musicians.

Engineers fighting through achieving productivity without directly engaging with the code, as depicted by the curve below, represents a monumental change. This shift impacts not only development velocity but also engineers’ self-perception and requires leaning into new skills.

Engineers are now engineering managers. They could be great engineering managers if you help them get there! Everyone on this journey struggles through the transition from individual contributor to leader. Some are getting tripped up in thinking it is a tech problem. They wonder about using a different model, or different billing plan, or a different agentic coding tool. They still plan to review all the code.

Thinking of people, process, technology, the reality is that it’s less about the tech and more about the people and the process.

The same attributes that make great engineering managers will make engineers great at agentic coding. Viewing your role in agentic development as a player/coach, writing specs, reviewing quality checks is a mindset shift from lovingly crafting artisanal code and only calling on AI to write tests or troubleshoot a bug.

It’s also a mindset shift to not focus on the tools like the IDE, IDE extensions, your dotfiles or the terminal or the workflow, but instead on how to set the agents up for success and help them combat their own limitations like context size or lack of memory. These are the same things great engineering managers focus on: how to unblock, prioritize, set boundaries and free up technical folks to do technical things. “Catch derailment” Jacob says in his talk, you can’t read the code as it goes by too fast as velocity increases.

Ask it to make a plan, then review the plan, modify the plan then go! This requires trust and letting go. One of the first things people struggle with in delegation is the realization that you need to let people fail to fully delegate. If you hang on to the outcome of a task or the method used, you haven’t delegated. It’s the same here.

The shift will require all of us to get comfortable with the new process.

How does it feel? Taking it for a spin

My career has largely been focused on information security. While security is changing because of AI, it is not yet as drastic as the shift for engineers. To better understand how it feels, I decided to take agentic development for a spin.

Recently I was introduced to Crush from CharmBracelet. It is a terminal-based agentic AI development tool along the lines of Claude Code that focuses on user choice and lets you pick and choose your LLMs, your tools, your workflows and works on every operating system.

It features its own event driven version of the Ralph Wiggum loop without requiring plugins and picks up on existing patterns like AGENTS.md, etc.

I was also introduced to ticket, a git-native ticket tracking tool purpose built for AI agents using only bash. Simply adding “This project uses a CLI ticket system for task management. Run `tk help` when you need to use it.” to AGENTS.md is enough guidance for an agent.

These two together felt like the minimum viable tooling that required very little setup, no subscriptions, etc. I installed crush and ticket, then hooked crush up to my google cloud environment using vertex AI to access gemini 3 (pro/flash) in thinking mode and set out to start.

The first job of a software architect is to write specifications for what you’d like to have the team build. This feels much different than cracking open a new github repo, picking a name and iterating your way into a functioning project.

I picked a toy project management utility as the goal, with an architecture that I know well enough to tell if the agents are going off the rails. Python, Shiny UI and GCP container services expressed in this agent file:

# Agent Guide

This documentation describes how to work with the **brainsheet** project.

## Project Overview

A Python-based web application acting as a work-alike for smartsheet
- **Language**: Python 3.11+
- **Package Manager**: [uv](https://github.com/astral-sh/uv)
- **Web UI**: [shiny](https://shiny.posit.co/py/api/core/)

## Core features
The project should allow the user to:
- Create a project
- Use a spreadsheet like interface
- Create milestones
- Assign subtasks to milestones
- Set ‘depends on’ references between subtasks or milestones

## Project Structure

TBD

## Setup & Execution

The project uses `uv` for dependency management and execution.

### Prerequisites
- Python 3.11+
- `uv` installed

### Ticketing, TODOs, task management

This project uses a CLI ticket system for development related task management. `tk` is already installed. Run `tk help` when you need to use it.

## Code Patterns & Conventions
- Follow standard python development practices
- Use Shiny core instead of express
- Shiny should follow the module pattern: https://shiny.posit.co/py/docs/modules.html

## Architecture
### Web UI
- The web ui (shiny) should be containerized such that it can run in Google Cloud’s Cloud Run
- The web ui need not concern itself with authentication at the moment, we will use the identity aware proxy to establish identity.

### Data Storage
- All data should live in GCP’s firebase database offering

I manually added a ticket:
``` tk create “Plan out architecture” -d “plan architecture for cloudrun hosted, serverless web interface using firebase for storage” -t epic ```

And prompted crush: “can you describe to me how you would go about planning to work on the first task in the tracker listed in AGENT.md ?”

It did this:

I prompted it: “ok, you are free to start working on this plan”

It set off to create the architecture:

and one by one check off the tasks it had created for itself

It finished after about 7 minutes by giving me commands to run it locally without having to deploy to GCP.

And I had a working but primitive task tracker in ~10 minutes.

It wasn’t great. Initially milestones didn’t work at all, there was no way to attach tasks to milestones, edit buttons didn’t work, etc. But adding tickets for what needed to be done and prompting to simply ‘work on existing tickets’ was enough to get it functioning.

All of this cost ~$3. (The crush UI cost estimator is a bit off).

Is it a great software product? No. Was it fun to create? Yes. Was it a different experience? Absolutely. Were there bugs? Yes.

What made it different was the mindset shift away from creating and caring about the code. The focus was instead on the outcome, the architecture and ensuring access to working tooling. I imagine this is quite easier in a greenfield environment than retrofitting markdown descriptions of architecture into existing repositories.

Regardless, it undoubtedly did a better job in less time and for less money than I could have done. But it could not have done it without the ten thousand hours it took me to understand what makes software architecture work, what doesn’t and how to coach technical teams through challenges.

As your teams adjust, lean into the sympathy someone undoubtedly gave you the first time you had to design, or delegate. Remember that impatience is not a virtue and the goal shouldn’t be ‘faster, cheaper, lonelier’. Just as humans still play chess even though machines can easily win, we will still code. Humans play a crucial role in curating the skills necessary in this transition. If you’ve ever viewed your job as ‘making more senior engineers’, congratulations your time is now!

The ‘Undiscovered Country’

It feels like there are rich areas to explore in this new relationship to technology such as:

• How does this new pattern affect interpersonal team dynamics? Is AI a new team member?
• How to give constructive criticism to human team members (who are acting as “EMs” to the AI).
• How to manage conflict between the various parties? AI, Engineers as EMs, Engineering Leadership, etc.
• How do you solidify this new way of thinking and working into a playbook of when to use it, when to avoid it?
• How to build in the psychological safety necessary for teams to take this leap?
• Long-term technical strategy and vision vs short term bursts of AI-powered hyper development.
• How to prevent behaviors used to manage AI from bleeding into non-AI relationships with actual humans (teammates, family members, friends, etc).

Where are you and your team on this journey? Comment on Linked in: https://www.linkedin.com/pulse/we-all-engineering-managers-now-jeff-bryner-fwxxc