The Engineering Manager

Introduction

It’s been two months since I finished a sequence of LLM-based posts which were intended to think of unique ways that you could improve your leadership skills by leaning into AI as a coach, a contrarian thinker, and a way in which to expand and accelerate your decision-making.

If you’re interested in reviewing those posts, then you can find them here, in reverse chronological order:

Leadership co-processing with LLMs, which introduces a number of prompting and usage ideas that could help you develop your thinking.
A bag of worries: tackling overwhelm with LLMs, which is a technique I’ve been using to help me manage my own never-ending to-do list by offloading some of the cognitive load of prioritization to an LLM.
A weekly mind meld, which uses some LLM assistance to communicate weekly with my department.
LLMs: an operator’s view, the original post in this series, which covers some of the cultural change addressed in the first post in this list, and how code review and hiring are also changing.

Building on the leadership co-processing article, we’re going to go further this week and think about how we can expand our usage of a thinking partner into multiple thinking partners by using LLM agents to create your own councils that you can use to accelerate and supercharge your thinking and also simulate situations where many actors may not have default consensus on issues.

Inspiration

At work, I’ve mostly been using Claude Code as my go-to interface. Generally speaking, I like the Claude models, which have become particularly good since Sonnet 4.5 and Haiku 4.5 were released. However, I also enjoy the terminal interface, which I always keep open at the side of the screen as it is space efficient. I can mix regular prompting along with the generation of code, and it looks cool as well.

One neat feature of Claude Code, which is the backbone of this article, is that it makes it extremely easy to build agents that you can delegate to. For example, you just type /agents like below:

From here, you can create a new agent.

In order to create an agent, all you have to do is give a rough sketch of what the role of the agent is. For example, here is my initial prompt for a QA Engineer agent.

Claude Code is able to expand that into something far more detailed which you can edit and tweak however you wish.

If you’d like to see more examples of how a number of agents could be defined, then there’s a great public GitHub repository where people have been collecting together their examples. Each of the folders has a different type of agent (or agents) combined with a collection of commands that you can use in order to work with them.

This is especially useful when you’re programming since you can delegate specific types of work to these agents, such as refactoring, security testing, initial code reviews, and so on. Now, none of these are meant to be substitutions for the real thing, however, they become great partners when you’re coding because you can call upon specific functionality when you need it, which is especially useful when you know that you have blind spots. For example, a security engineer agent can continually make sure that you’re aware of these kinds of issues as you code.

One particularly interesting observation, highlighted in Simon Willison’s recent post, is that Claude Code could be considered a general purpose agent, rather than just a coding tool.

Following my own usage, I agree with this viewpoint. Claude Code is not just a tool for coding, but is also a tool to think. And agents let you get really creative with your thinking.

In previous posts, we looked at how we could use simple prompts to “pair think” with LLMs, from organising our time, to cross-checking decisions, to enabling mob sessions where architecture or code is designed together, and so on.

The more senior you get as a leader, the more nuanced and complex some of your decisions can be: not necessarily only because of the impact of those decisions, but also because of the challenge of finding consensus within large groups with differing opinions, biases, and experiences.

Sometimes the act of maintaining fast, synchronous connections with groups of people in order to debate, discuss, and forward your thinking can be blocked by others’ busyness or timezone. That’s where agents come in.

Council of agents

In the same way that there were examples above of how to use agents in Claude Code for specific technical functions (such as refactoring and testing), you can use agents to form specific thinking councils that you can use to accelerate your thinking faster than you could by working either on your own or by requiring synchronous time with others.

This is most easily shown by example, so we’ll go through two of them in this section. The first will be a technical council, and the second will be an executive council.

Creating a technical council

Now that we’ve seen how to build one agent, we can now think about building multiple agents that can make up a council that you can work with and think with. For this first example, let’s consider a technical council that can help you.

Firstly, you’ll need to think about which kind of roles you’d like to have in your technical council of agents. For example, you might want to have the following:

Principal Engineer, covering broad technical vision, architectural patterns, and cross-cutting concerns.
Platform Engineer, covering infrastructure, deployment pipelines, developer experience, and tooling.
Security Engineer, with an interest in threat modeling, secure architecture, compliance, and vulnerability management.
QA Lead, covering testing strategies, quality metrics, automation, and release confidence.
AI/ML Engineer, responsible for machine learning systems, model deployment, and intelligent feature design.

Your own mileage may vary on the above depending on what kind of role and company you’re in.

With a decision made about what kind of roles you want to have in your council of agents, you then create them using the same methodology as we did in the example above.

For each of those roles, you create an agent in Claude Code, and you use your initial prompt to outline what they’re responsible for. Then, Claude Code will expand those into more detailed role definitions for the agents, which you can edit if you wish. And then, you continue doing this until you’ve defined your whole council.

Once this is done, it means that you can then ask questions to your whole council of agents. Here’s an example of what that could look like.

Here’s the output that was achieved from that particular query.

For this example, I specified in the query that I wanted just one paragraph of output per agent. However, if you wanted it to generate a detailed report and use one of the more expensive thinking models to do so, and then output that to a file, then the choice is yours.

And that’s it: with a small upfront effort, you now have a model of a technical council at your fingertips that can help you quickly interrogate ideas and decisions taking into account the diverse strengths and biases of each of those particular roles. It’s an incredibly useful tool to have.

Creating an executive council

Here’s one that helps me a lot.

As a CTO, my team is probably the most multi-disciplinary of them all, given that everybody in my executive team runs one of the other functions of the business. I am the only engineer!

Therefore, in order to help with my own thinking, especially about company-wide issues, having an executive agent council is highly valuable, and improves the kinds of proposals and decisions that I can bring to the group. Essentially, I almost get one or two meetings of iteration on my ideas completely for free (token costs aside) by doing it locally with my agent council.

In order to create this executive council, I go through the exact same steps but change the role definitions. For example:

CEO, owning the overall company vision, board relations, strategic direction, and having final decision authority.
Chief Product Officer, covering product strategy, roadmap prioritization, user experience, and feature decisions.
Chief Operating Officer, responsible for operational execution, cross-functional coordination, process efficiency, and delivery.
Chief Revenue Officer, owning sales strategy, pipeline, revenue targets, and go-to-market execution.
Chief Marketing Officer, covering brand, demand generation, market positioning, and customer acquisition
Chief Customer Officer, responsible for customer success, retention, NPS, implementation, and the voice of customer.

Again, depending on what kind of company you work for and who you’d like to have in your executive council, you may want to switch these roles out for whatever is relevant for you.

Here’s an example of the kind of query that you could ask. Let’s assume that the chat functionality that we were previously thinking about with the technical council is now ready to launch: how do we bring it to market?

You can see in the query that I accidentally wrote “rollout” twice, which I guess proves to you that these articles are still written by a human.

What’s fascinating about our query this time is that Claude Code even asked for input from the user to model the company that we’re working at. I did not explicitly ask to be given these choices in the setup.

After thinking for a while, I received output that looks like this. There was far more output than could fit in the screenshot, but for each of the executive council members, there are at least three to five interesting points that I know that we need to think through when we discuss it as a real human team.

Try it yourself

I’ve been finding this council of agents approach really useful for thinking through larger, more strategic plans and also in helping me develop my ideas before I bring them to the human version of the groups they represent. They allow me to do much more asynchronously. And then, when I do connect with my team synchronously, I find that the discussion and ideas that I am bring are more nuanced, considered, and researched.

So why not try it yourself?

Experiment with creating your own councils of agents using Claude Code or other tools and frameworks that support them. Get creative and think about ways in which you could improve your programming, your thinking, and your strategic decision-making.

It’s also a whole lot of fun as well. What councils of agents will you create?

This week we are going to take a deep dive into constraints: one of the most powerful tools that you have as a leader to help your team deliver more with less.

Now, this isn’t the first time that we’ve written about constraints, so if you’re interested in some history:

We looked at Parkinson’s Law back in 2024, which is the classic anti-pattern that occurs when people are given too much time (or no deadline at all) when asked to do something. The result is that work — like gas — expands to fill the time available, and yes, we’ve all been there with our school assignments.

We covered the iron triangle of project management in 2017, which is the classic model of the three constraints that projects typically have: scope, resources, and time. The idea is that you can only ever optimize two of the three.

We more recently explored how scope could be reframed as thoroughness in 2024, since scope alone rarely tells the whole story about what is being delivered.

But this time we’re talking about constraints as tools. Tools that you wield and can use.

Discovering places where you can add constraints to your projects is a superpower: it unlocks unconventional thinking, forces people to prioritize ruthlessly, and leads to unexpected and surprising results.

Let’s go on a journey together to explore the beauty of constraints. We’ll start by examining their paradoxical nature.

The constraint paradox

The word “constraint” often has a negative connotation. If you asked an average person, being “constrained” in general would not be seen as a desirable state. One does not wish to wear a pair of trousers that make them feel constrained.

However, paradoxically, constraints in engineering can often lead to our best work. The longstanding meme of IT projects being over budget and late is often due to a lack of constraints.

This is because projects often begin with a forward-facing process of thinking about all of the requirements that a product should have, and then estimating how long it will take to deliver them.

But the problem is that estimation of large projects (and even small ones) is essentially guesswork. If no constraints are imposed, the result is a project that stumbles along with ambiguous, bloated requirements and timelines. Walking along a path purely defined by what we want, without any constraints, is where it all goes wrong.

That is because this manner of thinking about projects — where we think about what we want and then work out how long it will take to get there, then go — very rarely makes us challenge ourselves to work in unconventional ways. There’s a difference between traveling a road to explore it and experience it versus trying to deliver a package as quickly as possible.

And talking of packages, a classic Bezos quote comes to mind here. “Frugality drives innovation, just like other constraints do. One of the only ways to get out of a tight box is to invent your way out.”

Putting oneself in a tight box, paradoxically, will make one execute better. Constraints tend to bring out the best in people.

Innovation through constraints

This isn’t just hyperbole, either. There are many great examples of products that achieved innovation through constraints. Here’s some of my favorites.

The original Sony Walkman emerged from a focused set of constraints: power, cost and size for portable travel. It’s worth remembering that at the time, cassette players and home stereos were bulky, imposing hunks of machinery and plastic.

The engineers were tasked with creating a device that could play music whilst walking and on long flights, which meant innovation in miniaturization, motor efficiency and stability, and headphone design.

Additionally, the compact form factor constraints dramatically led to stripping back requirements that were standard on home stereos, such as recording capabilities.

Another example is Twitter, which began with a strict 140-character limit, similar to SMS. This constraint forced users to be concise and creative in their communication. Interestingly, when Twitter expanded the character limit to 280, only 5% of users utilized the additional space, demonstrating how constraints can shape behavior and innovation. Looking at X today, many messages are still short and to the point, showing how the original constraint has had a lasting impact.

My favourite constraint-driven design story is that of the Dyson dual cyclone vacuum cleaner. The constraint of a bagless vacuum led to the invention of cyclonic separation on a small scale. It took 5,127 prototypes in James Dyson’s garden outbuilding to achieve this over many years of toil and no income. However, these constraints brought the first real innovation to vacuum cleaners in decades. Now Dyson is a household name and billion-dollar company.

Types of constraints

Constraints typically fall into three categories, broadly categorized by the iron triangle of project management: scope, resources, and time. I wrote about this way back in the early days of this blog in 2017, although my thinking has evolved since then.

But how?

Whereas earlier in my career I would consider those three trade-offs typically whilst wearing a project manager hat, I now consider them as categories of constraints that can be purposefully applied to projects in order to encourage teams to deliver more with less.

So, looking at each corner of the iron triangle, let’s see along which vectors constraints can be applied:

Scope is the set of features and requirements that a project is trying to deliver. However, instead of just accepting scope for what it is, great leaders try to ruthlessly cut down scope to shrink a project to the bare essentials. We’ll look at an algorithm for doing this shortly.
Resources typically means the number of people working on a project, which you can deliberately limit in order to force tough prioritization choices. However, resources can also mean money or other technical constraints, such as cost of infrastructure, or choice of technology. Great leaders will ensure that resources are deliberately limited in order to drive innovation. For example, instead of standing up new search infrastructure, what could you do with a simple database query?
Time is straightforward: Parkinson’s Law tells us that work expands to fill the time available. Therefore, great leaders will encourage teams to set challenging deadlines and use them as forcing functions to keep scope and resources in check.

So the way that I encourage you to look at the iron triangle is not as an accepted set of trade-offs, but instead as a toolkit of constraints that are available to engineering leaders to help their teams deliver more with less.

At all stages of a project, from the beginning to the end, never accept the status quo. Always ask yourself: “Can we do this with less scope, less resources, or less time?”

So how can you start looking at your projects and seeing whether constraints can be applied?

Let’s look at a practical algorithm for doing that which is one of the most repeated themes in Walter Isaacson’s Elon Musk autobiography.

The 5-step algorithm

I watch this video at least once a month as a reminder to question everything that we’re doing. It’s a short (1 minute and 29 second) clip of Elon Musk explaining his 5-step algorithm for finding ways to strip projects back to their bare essentials.

This isn’t just useful at the beginning of projects. As we mentioned before, estimation is guesswork, and so as projects evolve, it’s important to continually re-evaluate whether the original constraints are still valid, and if not, change or delete them. Repeated and continual application of this algorithm will help you do that.

The algorithm touches on all three corners of the iron triangle, inviting you to insert constraints in scope, resources and time.

Here’s the algorithm:

Question the requirements. Musk says that the most common error of a smart engineer is to optimize things that shouldn’t exist in the first place. He stipulates that smart folk are trained to answer questions, but not to challenge the questions in the first place. So, the first step of the algorithm is to accept that some or all of the requirements are dumb, and they should especially be questioned if they come from a smart person! For each requirement, ensure that it is attributable to a specific person or user need. If not, challenge it ruthlessly. If you can’t justify a requirement, then it gets deleted with no remorse.
Remove unnecessary steps. Once the requirements have been stripped back to the essentials, look at all of the steps of the project or process to achieve them. Try very hard to delete every step or feature that isn’t absolutely necessary. In fact, a good rule of thumb is to remove steps until you are forced to put some back in. That’s when you know that you’ve found the bare minimum.
Optimize. Now you know that you’ve stripped the project back to its bare essentials, you can optimize each step. This is where you can apply your engineering skills to make each step as efficient as possible. That could be code optimization, process improvement, or tooling. But remember: the only things that get optimized are the bare essentials that remain.
Accelerate time-to-learning. Next, look at ways in which you can accelerate cycle time, specifically the amount of time that it takes to get something done that you can learn from so you can start your next iteration. What’s the fastest way to prototype, build, ship, measure and learn? The maxim is that if the timeline is long, it’s wrong.
Automate. Finally, look at ways of using automation to speed things up. Note that this is the last step. No time should be spent on automating things that shouldn’t exist in the first place. Musk tells the story of how he automated too early in his factories, resulting in expensive robots needing to be removed because the steps were unnecessary or could be done more efficiently by hand.

Try going through this algorithm with your team on your current project. You’ll often surprise yourself at how much you can simplify what you’re doing.

Your constraint toolkit

Constraints are tools, and as such, you should have a toolkit of constraints that you can use at any time. Below is a non-exhaustive list of tools categorized by scope, resources, and time.

Scope constraints

Use the 5-step algorithm above multiple times during a project to continually re-evaluate scope. Perhaps schedule it weekly or monthly to ensure that your project remains as lean as possible.
Use techniques such as the MoSCoW method (must have, should have, could have, won’t have) to further strip back requirements ruthlessly.
Explicitly specify a single-sentence “success condition” for a project or feature and work backwards from there to ensure that everything is aligned to that goal. Delete any requirements that don’t align. This increases your cycle time to learn.
Tightly constrain the number of features to cover the absolute minimum happy path for the first version. Defer all nice-to-haves and edge cases to future iterations: learning about the happy path is more important than building out the full feature set.
Remove configuration options. Lean heavily into sensible defaults that work for the majority of users and only add configuration options later if absolutely necessary. Configurability and optionality causes complexity.
Build and ship for one platform first. Don’t try to launch everywhere for everyone in the first version. Pick a single platform (web, iOS, Android, etc.) and ship that only to learn faster. Once you’ve learned that what you’ve built is valuable, you can expand to other platforms.

Resource constraints

Limit the size of teams deliberately. It’s an easy escape hatch for teams to always feel like they need more people. Instead, set the challenge of being resourceful with less. It’ll force scope constraints, prioritization, and new ways of thinking. Ironically needing to hire more people often makes projects take longer; not only because of the Mythical Man-Month effect, but it takes a long time to ramp up new people (see: the contribution curve).
Limit costs. If the scope of a project is going to incur high infrastructure costs, challenge the team to find ways of doing it with lower-cost alternatives. This will often lead to new and interesting ways of thinking about the problem than buying more RAM, CPU or instance hours.
Limit technology choices. Instead of always reaching for another new technology or service, challenge the team to use what they already have. A huge amount can be done with simple databases, queues, and caches if you think about the problem in the right way, and your existing technology stack already exists and doesn’t need provisioned or learned.

Time constraints

Set challenging deadlines. Instead of asking “How long will this take?” ask “What’s the fastest we can do this?” and then work backwards from there. This will often lead to new ways of thinking about the problem.
Continually ask “What would it take to do this in half the time?” You will be surprised at how many timelines can be dramatically shaved down just by asking this question.
Use sub-milestones as forcing functions. For example, having an expected cadence of shipping daily or demoing weekly will force teams to prioritize and shape their work in a different way.
Use time-boxed iterations. Instead of open-ended projects, use fixed-length sprints or iterations that yield shipped software or demos to create a sense of urgency and focus.

Now you try!

It’s over to you: you now have the tools, so give some of these techniques a go.

At the very least, do the following:

Apply the 5-step algorithm to one of your current projects. Do it as a team exercise and see what you can shave from the requirements.
Challenge one timeline by asking “What would it take to do this in half the time?” and see what happens.

There are so few leaders that do the above that you’ll not only be surprised at how much time you can save, but also how much your team will appreciate the challenge.

Trust me: constraints are your friend.