Most of the newsletter articles come from my own experience and mistakes. But for many challenges, I don’t have a great answer, and I enjoy bringing in EMs from other companies to share their perspective.
Previously, I shared takes from EMs at Amazon, Flo, Meta, and Weave.
For today’s topic, I talked with Hayden Waisanen, a Senior EM at Harvey (AI for the legal industry, valued at $15.5B). Before that, he was an engineer at Amazon and Netflix, and an EM at Roblox. It was the most interesting 30-minute conversation I've had in a while!
One of the questions I asked him is: “What would you do if a business stakeholder asked you to just use more AI and move faster?” As I shared in Explaining to business people why building software is still hard, it’s something I find myself dealing with quite often, and I was curious to hear other takes.
The article is a combination of my own thoughts and Hayden’s great insights.
The good old days
For 20 years, the conversation around moving faster and project timelines was pretty much the same.
We had the iron triangle to guide us:
You have scope, time, and cost. You couldn’t adjust just one of them - if you wanted more scope or tighter deadlines, you needed to compromise on something else.
Time
If you want an increased scope, with the same number of people, you can either delay the project, or ask everyone to work longer, grinding over the weekend (in both cases, adding time).
Obviously, that’s not a lever you want to pull often as a manager if you want to keep a healthy team, but it’s a possibility.
Cost
Another option is to add additional engineers to the project. This one rarely works (see Brook’s law: “Adding manpower to a late software project makes it later”), but for a long and ambitious project it might work.
Scope
The most sensible one, and then one I use most:
Finish at the same time, with the same team. You just prioritize together what you could cut. You want to turn that into a trade-off decision for the leader who wants to move faster, so they’ll feel in control.
Quality
The point of the triangle is that if you adjust one of the vertices, you need to adjust the others accordingly - and if you insist on not changing them, the quality will suffer.
In theory, quality can also be a lever, but I've never met anyone who told me to release shitty software to existing customers. It’s always kind of a given that you don't want to sacrifice quality.
“Just move faster”
Over the last 6 months, there has been a lot of pressure to move faster.
The first thing I start with is the basics and try to cut scope. Figure out how the business is going to be better because of the work we are doing? Which part is the least important for it? And come up with a suggestion for what we can postpone .
If that doesn’t work, and you are still told, ‘You just have Claude, can’t you finish all of it on time?’, here’s what I’d do (after taking a deep breath):
1. Talk to your team
I believe that as a software industry, we still have room for improvement in how we use the new tools to move faster. We are still in the phase of learning, even at Harvey, where products and features are shipped crazy fast.
So instead of being on the defensive, I’d start by talking to your team.
You can tell them: let’s do a thought experiment. Let's say we have an unlimited budget. What if we loaded up Codex/Claude, got Astra/Fable running on this problem, and had it do a first pass, do you think it can actually work? Do you think that it’ll help us in any way?
Of course you're going to get a lot of pushback, because people have different opinions about AI-generated code. You’ll probably hear some variation of: “No, it won’t work, and it will be a huge waste of time”.
Yes, you have a hard job, being the bridge between your engineers and the rest of the company in our crazy times.
You have to balance both sides. On one hand, as I mentioned, I’m sure there are still many ways we as engineers can improve. You have to dig deep and understand what exactly won’t work.
On the other hand, you have to really listen to what the engineers are saying and work hard to understand the limitations they talk about. For that, you need the next part:
2. Experience it yourself
You have to experience the current way of working yourself. There is no way around it - engineering leaders who just push their engineers to ‘use AI more’ are not effective. Get your own Codex/Claude account, write services, build stuff, understand what works and what doesn’t.
Even if your org doesn’t explicitly expect it from you. Even if you’ve been hands-off for years.
3. Answer accurately
Once you have the full context, both from your team and your own experience, you can provide an accurate and balanced answer. For example:
“I understand what you're saying about moving faster with AI here. We are already generating all our code using the frontier models. To move even faster, we would need to stop reviewing the code we produce. We tried that, but the result was a severe hit to quality, which we don’t want to affect our clients. We are working on a way to automatically detect which code is less risky, to reduce the review bottleneck”.
(The Iron Triangle anyone?)
That answer has 3 parts:
You show what you already do, and how LLMs let you move faster than before
You acknowledge the current gaps and limitations
You share a plan on how to address them
When you back the answer with real experiences and conversations with your team, there is a much higher chance your point will land, and the pressure reduced.
Final words
In my opinion, the most important thing here is to not be the shit umbrella for your team. It’s tempting to shield them from those conversations, but over the long run, it does more harm than good. Lay out the problem and listen to what they have to say.
What I enjoyed reading this week
I don't want the details. On what leadership really cares about in postmortems.
The Manager’s Path in the Age of AI. Superb article by Camille Fournier (author of The Manager’s Path book).
Inside OpenAI's agentic software factory. Gave me some interesting inspiration for my own team.
