This deep dive is based on the ARC 2026 session on engineering leadership in the age of AI led by Packt author Michelle Brenner, and has been edited in her own words.
When Packt reached out to me to give a talk on engineering leadership and AI, I was excited, because this is the giant elephant squeezing every other thought out of the room. I was also concerned. There is so much information out there that I wasn’t sure I had anything new to say.
After pondering some more, I realized the problem isn’t the data. It’s the analysis. Like DNS and time zones, it’s one of the bigger problems in modern software that we just haven’t truly solved. Your phone tracks everywhere you go and everything you search, and you still mostly get ads built for a generalized version of you. AI is going through the same thing, with so many headlines pulling in so much data that they create confusion and chaos instead of comprehension.
So I set two goals. The first is to align AI goals between engineers and leadership. When peers are in conflict, it’s usually because their goals are in conflict, not because they’re terrible people, and it’s the job of leaders to spot those systemic problems and get everyone into alignment. The second is to decrease fear to make space for innovation. People don’t do their best work when they’re scared. It’s like that common advice about gambling, that you can’t win if you’re afraid to lose, and right now many of us are afraid to lose the AI race.
Here are the slides from the session.
Four personas want four different things
I can’t address every kind of leader in one piece, so I’m treating this like a product problem and creating personas. I based them on research for the talk and on the leaders and engineers I work with and meet across the tech community. The idea is that you’ll see yourself, or someone you work with, in one of them.
Executive leadership means the nontechnical executives, your CEOs and CFOs, and their voices are the loudest in the room. The leaders of the AI labs talk about curing disease and building superintelligence, and you can’t fault them for that, because putting out moonshots is their job. Outside tech, the message is different. Walmart’s then CEO Doug McMillon and Ford’s Jim Farley both told audiences that AI would change or replace enormous numbers of jobs, and they’re both really big fans of “literally.” Accenture’s Julie Sweet described exiting people on a compressed timeline, and Standard Chartered’s Bill Winters talked about replacing what he called lower-value human capital. The focus is almost universally labor reduction, specifically replacing the back office with AI. Their AI goal is to reduce cost and headcount.
None of those quotes talk about return on investment or profit. For everyone at a for-profit company, the North Star is profit, and profit comes from increasing revenue as much as from cutting cost. That’s the first friction point.
Technical leadership, meaning the CTOs and CIOs, gets told to implement AI as fast as possible so the company is more efficient and can then do layoffs. But technical leaders know AI isn’t magic, no matter how cool the demos look. Complex components used by many departments are hard to modify, and what AI is doing exactly is hard to track. Somebody has to own the outcome when an AI does something wrong. In an atmosphere of fear, people skip the critical steps, like acceptable use policies, human-in-the-loop checks, audit trails, and data and security controls. That’s why my goal around safety is really about risk management.
The versatility of AI makes it useful in almost every business workflow, and that’s exactly what makes it harder to use, because people don’t know what to do with it. It isn’t an upgrade to a tool they already know. They’re not one hour-long workshop away from proficiency, and they need time to practice and integrate what they’ve learned. So technical leaders want AI safely integrated into business workflows.
Accountants already went through this
Technology changes, but how people react to it follows patterns. In 1979, an accountant at a Fortune 500 company copied every transaction by hand into journals and then into large general ledgers. Catching mistakes was the hard part, and a single change could take all day. Then in 1983 Lotus 1-2-3 shipped on the IBM PC, which finance departments already owned, and that’s what drove adoption. Change one number and everything updated, so the job shifted from computing numbers to building and interrogating models.
Data entry and checking stayed part of the job, though. Today AI drafts the reconciliation, categorizes transactions and flags anomalies, while the accountant validates the work and uses the time saved to advise clients. First the math was automated, then data entry, then error checking. None of it eliminated the accountant. The day just shifted from producing to reviewing and supervising.
As an engineer, the slowness of that surprises me, because I would rather take three hours automating something than fifteen minutes doing it. But as an engineer who has tried to drive adoption of tools, it doesn’t surprise me at all. Change is slow. Change is uneven. Change is not automatic. People have to get in there and force every single workflow change.
Managers and engineers feel the cuts
The engineering manager’s AI goal is to hit leadership’s goals while upleveling their engineers. Learning new technology has always been part of the job, and engineers like to learn, so this is an extension of that. When a manager has a solid team of high performers, they want to keep them, and they do it by pointing engineers in the right direction.
The pressure on them is real. According to Challenger, Gray & Christmas, technology companies announced 139,156 job cuts in the first half of 2026, up 83% on the same period last year and nearly a third of all US cuts. AI was the most cited reason for cutting jobs, named in about 23% of all cuts through June. Those cuts are affecting real people in our community, and some of them could be reading this. The long-term view looks like spreadsheets, with more productive workers rather than fewer. What we don’t know yet is how long that takes and what the new jobs will look like. In the meantime, leaders have to work out how to shift the conversation toward productivity, and with the right direction and strategy, our engineers can produce the gains that make that case.
Editor’s note: Michelle’s slides cite 22%, from Challenger’s May report. We’ve used 23% from the June report, the latest available when she gave this talk in July.
Senior engineers are the final persona. I’m currently writing The Software Engineer’s Library, a career guide for senior software engineers coming later this year from Packt, which also publishes Deep Engineering, and I’ve interviewed a diverse set of engineers all over the world for it. AI was obviously top of mind. Engineers want to ship good work while keeping their jobs and learning the new technology, and what they’re doing instead is the next friction point. Every engineer is running their own R&D to figure out the best way to use AI, which is inefficient and creates bottlenecks. Many now pass their days pressing yes every time the coding assistant asks them something. They’re still very task focused, so they get a ticket, have the AI do the work and deploy it.
More code means more reviews
In the talk I played the I Love Lucy scene where Lucy and Ethel wrap chocolates on a conveyor belt that keeps speeding up, and the more they try to keep up, the worse it gets. The development pipeline is doing the same thing. More code means more reviews. You can automate the reviews, but then engineers stop keeping up with changes, and support requests take longer because nobody knows what’s going on.
Adding chat support helps with the simple stuff, but that leaves only the hard problems. I’ve used AI to help diagnose issues, and it can’t figure out what it doesn’t know. Most of us work on big legacy systems with many touch points, so it’s never as easy as reading one repo and explaining it. In the 1960s, people said COBOL was so easy that companies could fire their programmers and let the bankers do the work. Today the few people who can still maintain it are paid a lot of money because of it. If humans will always be in the loop, let’s make the most of them, solving big technical problems and pointing AI in the right direction instead of burning out on support.
Only 6% redesigned the work
Put the four goals side by side and each persona is optimizing for something different. Executives want lower cost and headcount, technical leaders want safe workflow integration, managers want to keep their team delivering on product goals, and engineers want to keep their jobs while learning new tech. With work, they can all be aligned around what’s best for the organization.
McKinsey’s State of AI survey, published in November 2025, covered about 2,000 organizations in 105 countries. AI use rose from 78% in 2024 to 88% in 2025. But only 39% could attribute any EBIT impact to it, and most of those put the figure below 5%. Just 6% reported significant value. Those companies didn’t add AI to one component, like writing code, and create their own I Love Lucy situation. They went back to basics and redesigned entire workflows. Of all the factors McKinsey tested, fundamental workflow redesign was the one most strongly linked to profit.
Editor’s note: McKinsey’s 2026 survey, published in August, found the same pattern, with nearly three-quarters of high performers fundamentally redesigning workflows against a quarter of other respondents.
Workflow redesign gives all four personas what they want. Executives get reduced costs, technical leaders get a full picture of how AI is used, managers get productivity gains, and engineers get to focus on the work they’re best suited for. That’s the alignment I promised at the start.
Map the workflow before you fix it
For the how, I’m borrowing from the nineties. Consultants have used Six Sigma and Lean for decades, and the approach has a bad reputation because it often comes with layoffs, but its basis is actually the scientific method. The process is DMAIC, which stands for define, measure, analyze, improve and control, and it’s designed to find bottlenecks and smooth them out. It was traditionally aimed at slow bureaucracy. We’re going to aim it at tedious tasks and let AI absorb them.
You start with process mapping, which means going through every single step of a workflow and documenting it. It’s like the developer workflow, but instead of the code-to-deploy cycle, you get into the minutiae. I did this for myself. I kept a document open, and every time I did anything, I wrote it down.
My workday actually starts the night before, when I check tomorrow’s calendar for early meetings and anything I need to prep for or flag to my team. In the morning I check email for updates and GitHub comments, go back to the calendar, and then move over to Slack for thread updates and anything urgent. Only then do I get to my IDE, where I address comments and reviews first and pick up my pull requests one at a time, using drafts to track what still needs features or documentation. After that I check my docs folder for comments and turn feedback into tickets. Throughout the day I cycle through all of it and try not to forget anything.
It was honestly painful to write out. But this is a no-judgment zone. If you judge a workflow before you understand it, you can’t fix it, so be objective and don’t fix as you go. Define and measure the whole workflow before you start to analyze and improve.
One digest instead of five inboxes
The challenge with my workflow is that it touches many applications. Luckily, most of them are in Google Workspace, so I can connect my AI agent to them directly. I’d be wary of doing that with my personal email for privacy reasons, but this is work, and I shouldn’t expect privacy there. Use the internal AI models your company provides, and don’t send your work data to external ones.
Then I set up a recurring task that checks all of those places and gives me one digest, on my schedule, surfacing what changed when it matters. No more checking five different locations and interrupting my work constantly. That takes care of my communication work.
Documentation written for the reader
Engineers used to learn what was happening in the code by doing reviews, and code is always the best source of truth. But if code is written and reviewed automatically, people have to read documentation instead, and writing and maintaining docs is a chore engineers tend to skip.
AI can help in two ways. You can ask it to summarize how a system works and what recently changed, but that requires engineers to know there’s something to ask about. With complex systems, it helps to know what’s going on before the support request comes in. So I go with the second way, which is having AI generate comprehensive, custom documentation and keep it current with every change. Since nobody has to write it all by hand, it can be written separately for users, engineers, DevOps, product managers and designers. It can also answer the questions people actually have, like what you need to know when you’re on call or what a backend engineer needs to know about a frontend repo.
My favorite example is a project I inherited when the person who owned it retired halfway through. There was literally no documentation. I worked with AI, reviewed every part of the code and the system, and kept writing documentation until everything was clear and easy to test, and it went much faster than doing it completely by myself.
Checklists that enforce themselves
Keeping all that documentation current is the hard part. I have never told engineers to keep docs current and had them just do it. Everyone is focused on getting their work done, and there are psychological reasons people skip things that don’t seem important in the moment.
Surgeons faced a version of this. The World Health Organization’s surgical safety checklist has 19 items across three phases, before anesthesia, before the first incision and before the patient leaves the operating room. Operating theaters demand rapid life-or-death decisions and working memory is limited, so the checklist externalizes the critical steps. Experts also fall into complacency and skip steps because nothing has gone wrong before. But a low chance is not a zero chance, and the checklist makes sure the checks happen whether or not the surgeon finds them useful.
We can add a checklist for engineers, but without a life-or-death scenario, the tedium wears down the desire to follow it. AI-driven automation closes that gap. Instead of reminding engineers to write documentation, we can integrate skills that notice a change and propose the matching documentation update. These are simple changes that make a huge difference. I’ve used this idea for almost my entire career, starting with my first job in support engineering, where things got lost between the morning, day and evening shifts, just like in a hospital, except we were making movies.
Front-load the thinking
Letting AI increase velocity can also introduce risky code. One trend I’ve already seen starting is engineers putting more time into planning up front instead of letting the agent race ahead. That planning should include reviewing multiple solutions, creating a risk assessment and designing the tests, and then the crucial step, socializing the plan to get feedback before any work is committed. It’s like writing a design memo, but thorough enough that the agent isn’t making decisions after it’s done. It is simply implementing.
Evaluate judgment when AI writes the code
When AI writes the code, what you’re evaluating in an engineer is judgment. I’ve always looked at what changed in the real world after the code went out, because a good resume and a good peer review both show impact. It takes more time in design and planning, working closely with product managers on what we want to accomplish and what we can demo, and then checking afterwards that the work did what it needed to do. I don’t deal with style comments at all anymore. If someone leaves one, I tell them to tell the AI, because tabs, spaces and semicolons belong in the skills and harnesses we use, and people should focus on what we can do for customers.
The most common mistake I see is fear, the go-go-go feeling that you’ll be fired if you don’t become an AI engineer overnight. A new tool appears every day, and it’s almost impossible to tell whether one model is better than another for what you actually need. When someone told me Cursor does all of this, I looked at what I was doing in Claude and decided it was pretty close and doing what I needed. Once a quarter is often enough to look at the new tools and what might be missing. You don’t have to try every tool the day it comes out.
Safety is the strategy
Used this way, DMAIC lets leaders offload the tedious work so engineers can focus on complex, multisystem technical problems. Engineers were already skipping documentation when they could get away with it, and now it’s always done. I’ve been on teams where engineers were already their own product managers, project managers and SREs, and now they can do those roles better, because they can learn and automate.
At the start, I said none of us do our best work when we’re scared. When you get back to work on Monday, focus on what you can do to help your team feel safe. Give them direction, and put them to work learning and improving, so your organization knows how invaluable everyone really is.
Editorial note: This article is adapted from Michelle Brenner’s ARC 2026 session, Engineering Leadership in the Age of AI. The session recording and slides were condensed and reordered for print, and the statistics were checked against their primary sources. You can find Michelle on LinkedIn.
