Transcript
Hannah Foxwell: My name is Hannah Foxwell. I'm here to talk about the reinvention of the dev team. Let's start by talking about velocity, because as a profession we have been obsessed with velocity. A reliable, responsive, high-performing engineering team was the goal for so many of our organizations, but they were really scarce, and we always felt like we were late. We always felt like we were too slow, that we were always behind, that velocity was hard to find. We got better over the years. The first software development team I was a part of, we shipped twice a year. It was a mainframe team, so it was a little bit different, but we shipped twice a year. I then moved into a more modern e-commerce operation, and we were doing well if we shipped four times a year. Through the course of my career, we've got better at that velocity thing.
Agile came along, and for a lot of people it was absolutely mind-blowing that we might even try to deliver once a sprint, like once every two weeks. Then we went through the cloud transformation, infrastructure was on demand, we could ship to an on-demand environment, that unlocked another level of velocity. Then with DevOps and continuous delivery, we got even better at it. It is not unheard of, and I'm sure it is common with people here that you're shipping multiple times a day to your products and to your platforms.
We Are All on a Journey
Yet, even just a couple of years ago, you would have come to a conference like this, and people were talking about developer productivity, people were talking about developer experience, people were talking about platform engineering as a way to unlock even more velocity. I feel like maybe that velocity has arrived. We're not quite sure what to do with it yet. This is the eight stages of agentic coding that was proposed by Steve Yegge when he announced Gastown, which is an agentic coding orchestration platform. This format of it has been publicized by HelixML, who are building an agent orchestration platform. It's absolutely bonkers to me to watch these teams work with their fleets of agents. I don't know whether you're working in that way yet. Give me a wave if you've tried Gastown or you've tried working with a fleet of agents. For the most part, for most people, this is theory still.
This is a frightening new reality of like, I'm not actually going to go into an IDE and prompt my way to code. I'm going to be driving it through specs, through tickets. The agents are going to be breaking down the weight. The agents are going to be delivering the software. The agents are going to be writing the tests. The agents are going to be deploying to production. The agents are going to be monitoring. This is a little glimmer of what the future might look like for all of us. It might be coming faster than we realize. Earlier this year, there was an inflection point in Cursor, the popular agentic coding platform Cursor, one of the first ones. They called it a third era of coding because now within Cursor itself, there are more agent requests than there are tab accepts. Agent-driven development is the majority of the work that's happening in Cursor. That's happened very quickly, you can see by that graph. That's because the capability of these agents keeps increasing and the reliability of them keeps increasing.
Thesis
What I am going to talk about today is not the agents at all. This is a talk about AI, but I'm not going to talk about the agents at all. I'm going to propose that they are coming, that they are here. I'm going to talk about the humans and what we do as teams to adjust to this massive change that is happening in our industry, the velocity that has finally arrived. If you do want to learn about the state of the art with agentic engineering practices, context engineering, and getting the best reliability out of your agents, go to Patrick's talk. This is the talk that you come to if you want to know what that means for me as a human. First of all, I want to reassure you, don't worry. This is really bleeding-edge stuff. Most organizations aren't ready to consider that a dev team with a fleet of agents is going to be shipping to production.
I think most of us should definitely consider playing with this, because the opportunity to unlock the value of software for our companies is enormous. There will be pressure, top down, to try this stuff. Having a play and getting an understanding of what works and what doesn't work, that's a really good idea. For this talk today, I am going to try and ground my vision of the future in three things, my three anchors that I believe are going to remain true no matter what technology we use or how fast we get. The first one is that we must build something worth building. We must deliver some value with the software that we ship. The second is that speed requires safety. The third one, I hope, is obvious, people matter.
Anchor 1 - Build Something Worth Building
What does it mean to build something worth building? Code is the how, it's not the what. We deliver solutions to problems. The solutions to those problems require software. To deliver that, we need to write code. Code is the how, it's not the what. What we're delivering is a solution to a problem. I simplify the feedback loop in this way. We have users with problems. We usually have a product manager whose job is to really understand those problems. We have a team of developers, usually six to eight in a normal organization, who then devise solutions to those problems and ship those as a software product. The users use it and they go, yes, no, that wasn't quite what I wanted. Or they go, wait, take my money. The feedback loop continues. The users have needs. The product manager filters those needs. The developers deliver solutions to those problems using software.
For a lot of development teams, they don't really speak to their users very much because the product manager does that on their behalf. For a development team, they have a lot of feedback loops. It's usually about how the system is working. It's not a user expressing their pain. I think that's pretty normal for a lot of the teams that I work with, the developers are not engaging with their users. They are not talking to them about their pain. There's a proxy for the user that is the interface, and that is the product manager. What happens in a typical organization is there are lots of user needs. There needs to be a filtering and a prioritization process. I've worked in product. I was always very considerate to my engineering team. I didn't overwhelm them with too many ideas. I was filtering out the ideas. I was deciding what was good and what was bad. I was prioritizing ruthlessly, I would say, prioritizing what they should focus on, because developer productivity requires focus. That was something that I believed to be true. I organized my teams around that. Focus on one thing at a time, no distractions.
What does that look like with agentic coding? What if we can 10x the speed? What if the amount of changes and new features that we can push to our product increases dramatically? That is happening for so many teams at the moment. What I've seen happen is backpressure on product. There isn't enough work in the funnel for some of these teams to keep those engineers who have unlocked this new velocity busy. I said a couple of years ago on a podcast, I was like, "I've got a three-year roadmap. My team are never going to run out of backlog." Actually, I've seen it happen now. I've seen it happen in the real world where dev teams don't have enough well-qualified work to keep them busy because of this velocity that they've unlocked. That is a new problem that I have never experienced in my career. What do you do?
Do you just say yes to everything? Every nice idea that you might smash into your product? No. Normally, that's not a really good product strategy. Enshitification is a thing. That's the word that was coined for when a platform gets too bloated with features. It doesn't do just one thing. It does many things, and maybe it does all of them quite poorly. That doesn't feel like the right answer either. We don't just build every single little thing that we could possibly think of, never qualifying it with our users.
There is a silver lining here, which is that the cost to test your ideas is collapsed. In the past, when we built out our roadmap, we had this confirmation bias. We were like, this is the roadmap. This is what will deliver success for our business. This will help our users. We didn't have the engineering capacity to really go and try and experiment. We were like, we'll just build it. If we build it, they will come. Whereas I think a much more healthy way of delivering product and delighting users is to try something, to build a prototype, to test it with them, to iterate before you commit that as a thing that you want your product to do. Because when it is a thing that you want your product to do, you have to support that for eternity or until you decommission it. What we've seen is the emergence of the vibe coding PM.
Anyone work with a vibe coding PM? Is anyone a vibe coding PM? Give me a wave if you're a vibe coding PM. Because this is a new breed of PM. I quite like it. It's not the product manager who's like, I'm shipping production code. It's the one who's like, I really need to test my ideas before I commit them to the product. How important is that? How powerful is that? That's a practice that I'm seeing emerge that I'm actually really excited about. Let's test our ideas before we commit them to the product. Another thing that you might want to do is you might want to pair a developer with a PM to build those prototypes if they are beyond the realms of the vibe coding. You get this feedback loop between your users, product and development so that everything that goes into the dev team is well-qualified work, well-understood.
You have tested it with your users. You haven't just put it into your product and hoped for the best. That is going to get you a better product at the end of the day. Another pattern that I've seen in the real world is the forward deployed engineer. Who's heard of that one? The forward deployed engineer, the FDE, is an engineer that is embedded in the customer and empowered to solve their problems. This is not necessarily an implementation or a professional services engineer. This is an empowered engineer that's going, yes, let's shorten that feedback loop as much as possible. Like, here's a real-world scenario that we didn't think about that we haven't built into the product, but now we can build it. You end up with a roadmap of long-term features and a very short feedback loop of small tactical changes that are going to delight your customers. I really love this pattern, and I'm excited to see how organizations evolve around this.
Another pattern that I've seen is the product engineer. The product engineer works really well in software companies that serve developers, so dev tooling. Basically, everybody who's outside in the sponsor area should be thinking about product engineers, because a product engineer is an engineer that's empowered to improve the product because they are the user. If they are the user, they know what they need and they know what they don't need. I was talking to the team at incident.io, and they are very keen on hiring product engineers, not just software engineers, product engineers, because they are building a product for themselves, and so they are empowered to make decisions. Another thing that they have is they have direct access to their users. There's no asking for permission to go and ask a user what they think of a new feature. It's a very open channel of communication.
There will be people sat here who are going like, "No, I do not want to be talking to customers. Please, someone do that for me." Then there will be other people here that will be like, "Brilliant, let me at it." I think you will all know which bucket you are most aligned to, and you will know which of your colleagues are. A product engineer, especially if you're building products for people like yourself, is a really powerful pattern, and it really reduces the feedback loop. What we're really talking about is building a valuable product at the end of the day. We want to solve real world problems for real users.
The backpressure that is created by the unlocked velocity of agentic coding has led some teams to challenge what the ratio of product to developers might look like. The two-pizza team, like the six to eight developers and one product manager, that's been standard in our industry for quite a while. I've seen teams now experimenting with two developers to one product manager, almost like a micro team. NBIM are running this experiment at the moment, and I will be really interested to see how this goes. In several of our AI projects, development now moves faster than the business can keep up. The problem isn't development capacity, it's lack of clear specs, fast decisions, and tight feedback loops. They're running this experiment to really compress the team down to the bare minimum, because a product manager can't keep six to eight developers busy. I think that's a really interesting experiment.
Andrew Ng, who is an entrepreneur and a bit of an influencer in the AI space, has proposed that it's actually the opposite ratio, that it should be two product managers to a single developer. Can you imagine that? Because that developer, you assume, has got like a fleet of agents and can orchestrate the development across multiple product lines simultaneously. This is the thing that companies are probably experimenting with. It's absolutely fascinating what a bonkers time to work in software development. It's a real period of change. I'm not here to advocate for any one of these. I'm here to show you what other people are experimenting with, so that when you start seeing this unlocked velocity, you have some ideas and some inspiration of what you might try next. I had a chat with a consultancy, because that's a really interesting space to chat about agentic coding.
They're selling developer time to their clients. How is it changing their world? Interestingly, of all of the companies they work with, so they work across 200 companies. I think they've got about 3,000 developers deployed to those 200 companies. They've only seen two or three so far reduce their team size. The rest are expecting more output. I think if you project that expectation of more output a little further, maybe you start to think about, maybe the domain that a team takes care of has to expand, because there won't be enough well-qualified work in their current domain to keep them busy. I think that will be incredibly fascinating.
I also want to advocate for design and UX. Doing user research and being data-driven and user-focused is going to be a differentiator in a world where writing software is quick and fast. Are you going to delight your users with what you've built? I don't think the craft of user experience design is dead. I think it is more important than ever. The challenge is accelerating it to the speed of software development. The challenge is making sure that we have good design that's thought through, that we make time for user research and usability testing. Things that I've seen organizations do that don't work and that probably are practices that will diminish over time is one thing that I call the ship and switch. The ship and switch is, basically, we have so much on our backlog that the first iteration of a product or a feature becomes the end thing.
We never go back and improve it. We never go and ask our users about it. It's like, ok, one box is ticked and we go on to the next thing. We ship it and we switch context and we go and solve another problem. Actually, the best products and the best product managers know that you have to go and work with your users after you ship it. Is this the right thing? Could it be more valuable to you? How is the usability of it? You just don't ship it and then switch your context. I know so many teams that have been operating in that ship and switch mode for so many years. It's a really difficult habit to unlearn. The other two are obvious, but saying yes to every single customer request and every single idea is not going to land you with a really successful product either. Then, HIPPO, the highest paid person's opinion, prioritization should have gone away a long time ago, yet it still is prevalent in a lot of organizations. Let's just stop doing that, the HIPPO prioritization. Let's really get data-driven and user-focused to make sure that we're building something worth building.
What am I keeping? What am I trashing? What am I trying in this new world of agentic software development? I'm keeping empowered product teams that can make decisions and help their users without asking permission. I'm keeping fast feedback loop with actual real humans, real users. I'm doing usability research. I'm doing UX research because those things are going to differentiate my product from every other vibe-coded platform. I'm trashing the two-pizza team of six to eight developers. I've seen multiple times now that that isn't necessarily the right ratio for success in a lot of businesses. We were talking about it in the pub and we proposed that it's more like a tapas team than a two-pizza team, like some small plates maybe. Yes, the tapas team might become a thing. I'm also trashing my six-month roadmap, not because planning isn't useful, but because actually deciding what you're going to build in six months' time is no longer a valuable exercise.
If you want to build such a thing, let's figure out how we can do it now. How can we parallelize? How can we get it done? If it's important enough, get it done and get it done at the speed that you can get it done at. New things that I want to try. The forward deployed engineer, the engineer that's empowered and sitting alongside a customer to solve their problems. I'm absolutely wanting to reduce that feedback loop to almost zero. Let's go and solve real-world problems. Let's be very customer-focused. Product engineers, absolutely. An engineer who has a strong opinion about what should and shouldn't go in the product is going to be such an asset. You don't want necessarily to be surrounded by teammates who just want to pick tasks off a backlog, because if an engineer can pick a task off a backlog, then, unfortunately, so can an agent in the future world. Definitely want to do prototype before product. I definitely would want to experiment with much smaller team sizes than we are currently used to. Smaller team sizes or an expanded domain of responsibility for teams so that you don't get that backpressure, and so that you don't end up building things that aren't worth building.
Anchor 2 - Speed Requires Safety
I'm going to go on to my second anchor now, and this one is that speed requires safety. On the path to production, we need to validate that the software that we've built does what it's supposed to do and hasn't broken anything that's important. These are basics. The path to production in a lot of organizations can have manual steps. There can be gaps in test coverage, which can make it very scary to ship at an increased velocity, because if you can't ship at that increased velocity, you're going to end up with pile-ups on the path to production. If code generation outstrips your ability to get that through a pipeline and into the hands of your users, then you're going to have a pile-up somewhere, and that's going to create backpressure in other places. Again, what we end up with is we end up with developers able to produce so much more work and the downstream process not being able to keep up.
High confidence requires testing, and I believe high speed requires automation. You need both. You need incredibly fast, good coverage with your automated testing. I think as people start to adapt to this unlocked velocity that we have now, those will be some of the first pain points to reveal themselves in your organization. Have a think about what you can start doing now to start closing those gaps and making the path to production as smooth and automated and fast as possible. I really enjoyed this article, and it's from AWS, about how they managed to get 10x throughput from their development team by adopting agentic coding practices. The summary is that they had to completely rethink testing, deployment, and coordination practices. They couldn't just bolt on the speed of AI to what they were doing at the moment. They had to re-engineer that path to production for velocity.
While we might find ourselves with a dev team who have run out of backlog and feature work from their product manager, I'm like, what can we do with that bit of capacity that we've got? Let's go and attack this problem. Let's go and attack the throughput problem. Let's make sure that we can unlock that velocity when the time comes.
Another thing that caught my eye was about how JPMorgan are using AI agents to drive their continuous component testing. Again, I'm like, this is a happy coincidence, really. I'm here saying like you have to have continuous testing. It has to be fast. Here we are with tools at our disposal that can go and write the tests for you. I thought it was really interesting that they chose to tackle this as a first priority, but it's actually very human-centric. Michele Willis says, virtually no developer likes testing. It's the toil part of the work. Developers want to spend time solving problems and understanding the code. Testing is something that can be tedious. Great. Let's give that to an agent to do. This is the sort of work that humans don't love, so why not give that to the AI agent, and in doing so, improve the automation of the quality gates that you need to unlock the velocity that you want on the path to production.
Another thing that I believe is true is that the cost of day 2, actually running that software in production, will always be greater than day 1. You can build something, but actually, the amount of time you have to maintain it, support it, patch it, improve it, is always going to be greater in the long run. I also believe strongly that, even though they don't ask for it explicitly most of the time, users really care about security and reliability, and right now, these topics are hitting the news, like the mainstream news. Reliability of Amazon made the news, and I think this has been talked about in many other sessions. This is mainstream newsworthy stuff when a website goes down. Claude went down the other week as well. GitHub's reliability figures are particularly bad at the moment as well. Reliability is newsworthy stuff, and it will damage your product reputation, so investing in that is so important.
I think that is fundamental. You cannot have velocity at the expense of reliability, nor can you have velocity at the expense of security, although apparently, if you're a Moltbook user or you've attached your OpenClaw to Moltbook, you don't really care. Good security is often invisible. It's invisible right up until the moment that it's not, so investing in a secure foundation. Your users are never, ever going to give you explicit instructions to that. They're just going to expect it all the time. They expect you to protect their data. With all of this velocity that we want to unlock, we cannot do that at the expense of reliability and security.
We also don't want to disrupt our users too much with new features or half-finished work. Progressive delivery, like feature flags, A/B testing, blue-green deployments, another way that we can actually create the sense of a reliable service while we are churning through a lot of change, more change than ever. We already have practices that help us to reason about this. The SRE book introduced us to the concepts of SLI, service level indicators, user-centric service level indicators. SLOs, what is the promise that we're making to our users in terms of reliability, and error budgets, what is the amount of acceptable failure? There's one tool in particular that I really want to talk to you about, which is the error budget policy. The error budget policy is more important than ever, because the error budget policy tells you what you will do as an organization when you break your promise, what happens when you don't meet your SLO.
What are you going to do differently if the promise you've made of reliability hasn't been achieved? Because I think it can be tempting to think that velocity is the only goal. If your product is unreliable, if your product is insecure, you are going to suffer commercially for that. Someone will come along and they will do a better job and they will serve your customers better than you are. Your error budget policy writes down what the SLO is, and what you are going to do in the event that you break that SLO. Maybe you slow down your releases. Maybe you need to invest in reliability. Maybe you need to invest in resiliency, but it is a written document that says, here is the promise that we're making to our users, and we're not going to break that promise. If you don't have an error budget policy at the moment, now might be the time to write one.
Because one of the unintended consequences of pushing more releases, and more code, and more change to production is potentially a degradation in reliability. Measure it and agree as a team what you're going to do if that should happen. If you should push so much change so quickly that you impact reliability to the point where it is intolerable for your users.
Some of the patterns that I think are going to be even more important and influential than ever are, building internal development platforms, and site reliability engineering, as I just said. A platform engineer provides paved roads. They can help you smooth that path to production. They can provide environments on demand. They can make sure that everything is secure by default, make the secure thing the easy thing to do, and then your development teams don't have to worry about it. SRE teams as well. When Google published the SRE book, and that is years ago now, I thought it was a little bit of an antipattern that you would have site reliability engineering separate in its own organization. I'm now thinking about that again, and I'm thinking that actually an internal consulting function that are experts in building resilient systems could be a massive benefit to a lot of teams who are finding that their reliability suffers due to the increase of velocity of change.
I'm reconsidering the idea. I'm not here to stamp my foot and say like, this is the right thing to do. I'm here to reconsider the idea, that I think that could be a really interesting pattern as teams start to move faster. An internal consulting organization, an SRE organization that could provide expert advice on how to make sure that your reliability does not suffer. I think the SRE team may be about to make a comeback.
The interesting question here is, what's the ratio? What's our team composition? Because what we see at the moment is even if you have an SRE, they're massively outnumbered by the number of developers. If you have a platform team, they are massively outnumbered by the number of developers. If you have a security team, then it gets even worse. There's even smaller number of people there. Actually, I think these functions unlock that developer velocity. We might find that different ratios are needed to be successful. I'm ready to challenge that. I'm ready to say that actually, a platform organization that makes it safe and fast for a developer with a swarm of AI agents to ship a lot of change to production safely and securely, that's huge value for my organization. That's a humongous benefit that's unlocked right there. The ratios that we are currently used to in our organizations are probably going to change.
I think that's a good thing. Another thing that can cause friction on the path to production is tech debt. Again, like I said, go and get your test coverage up to scratch by using agents. Agents are also really good at migrations, getting off old out-of-date platforms, old end-of-life platforms, refactoring codebases. These are today problems, and they need not be tomorrow problems if you can use the speed and the iteration that these agents and these processes can go through to get you off those platforms. That's something else that I'm going to say. If you end up in that situation where your product manager can't get enough work into the team that's well-qualified, it's like, ok, that engineering backlog that you used to have, the tech debt backlog that you had to fight to get any time and attention paid to, let's just go and smash through that. Because now is the moment, especially with these agentic coding platforms being so super cheap. That may not last forever. Now is the moment to go and smash through all of that engineering backlog and that tech debt that you have struggled to get time to prioritize.
My second anchor that speed requires safety, what am I keeping? What am I trashing? What am I trying? I'm keeping the error budget policy, because I care about reliability and because I know that my users care about reliability. I'm absolutely keeping progressive delivery, and if I'm not doing it at the moment, then I'm investing in that. I'm doing gradual releases of new features. I'm testing in production to make sure it's good before it reaches all of my users. I'm absolutely keeping internal platforms that help provide a paved road, a secure road, a path to production. I'm trashing basically anything manual, anything on the path to production that involves manual testing, manual release stages, manual anything. There is no space for that in the new world. It's too slow. That is where the pileup will happen. If you're looking at your path to production and you have manual steps along that, go and tackle those now because otherwise those will be the bottlenecks of the future. Things that I'm trying. I want to use AI to improve my test coverage. I want to use AI to tackle my tech debt backlog. I'm definitely considering bringing back the SRE team as an internal consulting function to help teams improve their reliability.
Anchor 3 - People Matter
Now we're on to anchor three, people matter. It's obvious really, like we want jobs that are fulfilling. We want to go to work and work on interesting problems. Unfortunately, reviewing code that was spat up by an AI agent is not fun. When we think about the future and what we might want the future of our roles to look like, how do we reconcile this? Like reviewing AI-generated code is just simply not fun, especially when there is so much of it created so quickly. I really liked this article by Joseph Ruscio about write-only code. His hypothesis is that actually not all code is going to be ever read by a human. Right now, most code is read by a human, almost all of it. Unless you're a vibe coder, almost all of it will be read by a human. His proposal is that actually that's going to flip.
Most code will run and it will never have been read by a human. If we state that that is our goal, what does our software development life cycle need to look like to make sure that that's not an absolute nightmare? I think that's a really interesting thought experiment. Another thing that I found interesting is the shift left of the peer review. A lot of teams operate in a system where someone writes the code and another person reviews their pull request before it goes into the product. A type of peer review is a type of quality gate. It has been important. What I've seen some teams do is shift that left to before the code is created. Peer review, having a second opinion on what you're building and how you're building it is still super important. What they've done is they've shifted it left to before the code was created.
It's the review of the specs. It's the review of the tests. It's the review of the test strategy. It's the review of the architecture. It's still two minds coming together to go like, is this the right thing? Are we doing it in the right way? It's not reading through lines of code in a pull request. I think that is a really interesting new pattern as well.
Another thing that I think we all know to be true is that when you're holding the pager, supporting a fragile service is not fun at all. There is this minimum viable amount of humans that you need to support a service in production because nobody wants to be holding the pager all day, every day. You can't be on-call all day, every day. When you think about that as a constraint, what is the minimum viable team to support a service? Say you have one person who's on primary on-call and another person's secondary as like a fallback. Then if you were to say like, maybe it's ok to be primary one week out of every four and secondary one week out of every four. That basically means that you're on-call still 50% of the time, which for a lot of people, that still wouldn't be a very sustainable situation.
We really have to think about how we're going to support our services in production before we can even start to consider reducing our team size. A team size of one developer who's holding the pager all the time is absolutely not realistic and not sustainable. Again, this is why I think potentially the SRE team as a separate organization might make a comeback, because the original manifestation of the SRE team at Google was willing to hold the pager for certain services if they were built to the standards and the reliability expectations that the SRE team dictated. They would not support a service until it met their standards and then they would. I think that's potentially another benefit of bringing back the SRE team. As I said, what is the minimum viable human that you need to support a service in production? I had the minimum viable human slide on this stage last year, because I was talking about agents.
I keep coming back to it. It's like, we can't reduce our team size to the extreme where the work becomes completely unsustainable, where we're a single point of failure, where we can't go on holiday. This is no good. What is the minimum viable human to make the work sustainable? I think that's a really important question to ask ourselves.
When we talk about teams and how people collaborate, I think a lot of folks default to the agile ceremonies that we're all used to, daily stand-ups, sprint planning, backlog grooming. I'm not sure all of these work anymore. The first thing that I'm feeling and sensing is that a two-week sprint is too long at the moment, and that most teams are iterating faster and getting through their backlog faster. If you go from that point, if you say, actually, I think I feel that a two-week sprint is far too long, what is the correct iteration cycle? Is it one week? Is it a day? How often do we want to be making decisions like that and who needs to be in the room? How might we experiment with our practices around how we collaborate as teams so that we don't accidentally introduce processes that are just too heavy, that are just far heavier than they need to be?
Because planning and replanning isn't necessary anymore. Another thing that I want to talk about is actually the skills that we need in this profession. If we assume that agents are going to get so good at coding that they're going to write most of the code for us and that actually this idea of write-only code that is never, ever read by a human might become a reality for some teams, what skills do we, as people in software development, need? It was at QCon last year that Sophie Weston gave a talk about her journey to becoming a principal engineer, and she introduced the idea of the broken comb. The broken comb was the idea that actually, rather than being like a T-shaped person or a Pi-shaped person with maybe one or two areas of specialism, that what we need to develop is a broad knowledge across a lot of different domains in software development.
Then we need to be able to go deep in a few. I really like this analogy of the broken comb, because I don't think being a specialist in a single domain will necessarily serve us very well in our profession going forward. I think developing a broader range of skills and being able to work on a different range of problems is going to set us up for success. I'm very keen on the idea of the broken comb. If any of you in here are managers, it's worth thinking about that with your teams when you go back. It's like, how can we develop breadth in our team by giving people different areas of specialism, challenging them to learn something new? As I've talked about in this talk already, there is a need in a lot of organizations for engineers who are willing to work side-by-side with customers and to develop product management skills and product thinking skills.
That is one area where you might ask your team to go deeper. There's also going to be a need for more specialism in reliability for release engineering. These are all areas where someone who has previously not just been a developer, but has been a developer who has been delivering against a backlog of coding tasks might want to start to diversify. That is something that I want to encourage everybody to think about for themselves and for the people around them, that diversifying of your skills to make you a bit of a lethal weapon when it comes to agentic coding.
Around my third anchor, what am I keeping? What am I trashing? What am I trying? I'm absolutely keeping sustainable on-call practices. I'm not going to have a single human be on-call all of the time, or even 50% of the time. I'm going to figure out a way to make a team successful without having to do that. I've mentioned it before, I will mention it again. An error budget policy makes it unambiguous what you're going to do if your service availability is suffering. I'm going to do career planning because we were doing that already, weren't we? I'm going to do career planning, but for today's reality, not for yesterday's reality. I'm going to rethink all of my career frameworks. I'm going to encourage everybody to become a broken comb, a generalist with some deep specialisms. I'm absolutely trashing heavy planning processes. They don't add much value.
Backlog shuffling, backlog grooming, all of that stuff. You can potentially say yes to everything and it becomes more important what is on that backlog than what you're going to say yes to or say no to. Two-week sprints, they feel too long to me right now. They feel too long. I'm trashing that as a standard. I'm also trashing mandatory code review. Peer review is important. Mandatory code review on every single line of code I don't believe is a sustainable practice for the humans in software development going forwards. That might be a controversial statement, but I don't think it's sustainable and it's not joyful. No one's going to want to do that job. Things that I'm trying, shifting left peer review to before the code is written. Talking through how you're thinking about your solution, how you're designing it. Talking through your specification if you're doing spec-driven development.
Definitely adopting spec-driven development. Deciding how you want your system to behave gives your agent a much better chance of success. I'm going to encourage everybody to become a broken comb. I probably won't shut up about that because I think all of us want to be set up for careers that are successful in this new age where we're working with these agentic coding platforms. What does it take for us as humans to succeed? We need more areas of specialism. We need to diversify our skills, and we need to start that now.
Summary
I'm going to go back to anchor one, which is, build something worth building. I'm going to tell my story of a product that I've built recently, because it's easier than ever to build a product. This is the story of BIMP. BIMP stands for Base Image Management Platform, because it's a platform that manages your container-based images for you, basically. It's a problem that I understand well because of my background in platform engineering and security. I was like, I can't see anybody out there who's trying to build a single solution for base image management. We did. Two people spent two weeks trying to build a platform to solve a user need. Yes, we ran out of work very quickly. We gave ourselves two weeks and we sat down on the morning of the first day. We said, what's our goal for today? We smashed that goal by lunchtime.
We were like, we're going to have another planning meeting at lunchtime to figure out what we're going to do in the evening. That continued. That continued until I unlearned and we unlearned the practice of ruthless prioritization, and we got more demanding and higher expectations of ourselves. It's like instead of trying to build one or two features in a day, we were trying to scope four or five in quite an intensive planning meeting in the morning, but then we would go and we would smash through it. Even then we would smash through it before the end of the day. This is not like a two-week sprint where we were pulling all-nighters. It was like, what's next to build? What's next to build? What's a nice to have? What will our users want? I would never ever in my previous job as a product manager have gone like, yes, in week one, we're going to do some management dashboards.
Never. That's what we were doing because functionally the platform was operating, and we wanted that extra level of visibility. We absolutely felt all of the pain of that backpressure in a very short space of time. I managed to get a product shipped within two weeks. Refactoring that codebase took hours with Cursor in agentic mode. The documentation was automated through AI, and it took minutes to build the documentation. You can scan the QR code. You can go and have a look at our homepage. What I want to go and say is that building is so much fun right now. If you go and have a look at our homepage, you'll see that there's a 3D blimp that soars across it. A 3D blimp should never, ever be in your MVP but it is in ours because building things is fun. We didn't stop building and we've kept going.
This is a bit of an exclusive for you all because we haven't even launched the product yet. By the time this is streamed online, we will have. The experience of building a product at the speed of AI has been incredibly insightful. I experienced all of these problems and then some, but it did make me way more ambitious about what I might build in future. Another thing that I want to say is like, we are all on a journey. Not everyone is at level 8, orchestrating a fleet of autonomous agents. Many of us will be prompting our way to solutions. Even that is going to unlock velocity. I do think we are all on a journey. I do think this is not necessarily a destination. I think there is a correct methodology for the problem space and the task that you're actually working on at the time.
Final Thought on The Three Anchors
I will leave you with this thought. Building has never been so easy or so much fun. We are going through an awful lot of change. Today I didn't want to give you a strong opinion about what I think the future will look like. Hopefully I've given you some ideas of some things that you might try when you start to unlock this velocity and when that starts to create new problems for your teams. More than anything, I want us all to feel confident about the roles we have in the future. I want us to feel like that we have a place in this world of agents. I want us to feel ready to embrace this change.
See more presentations with transcripts
