Yasin: Welcome to Ctrl Alt Deliver. I'm your host, Yasin, and today we're going to be discussing AI and the potential impact it has on team structures and the software development cycle. AI is already writing code, testing features, and maybe even coming to our sprint meetings. But what does it really mean for how we build software teams and run the SDLC process? That's what we're unpacking today with our guest Ryan Greenhall.

Ryan is an engineering leader who has helped scale-ups like Uswitch and Gusto go from firefighting mode to billion-pound exits. He's known as the voice of reason when everything is on fire, and he's the one who shows up with the extinguisher and a plan that actually works. Ryan, welcome to Ctrl Alt Deliver.

Ryan: Thanks for having me on the show. It’s really great to be here this afternoon.

Yasin: OK, so, Ryan, before we dive in, why don't you tell us about yourself, your background, and what you're working on these days? And I'm particularly interested in hearing about your time at Gusto, when you were scaling the platform during COVID, while you were feeding the entire nation. It must have been a very interesting time.

Ryan: Of course, yes, so I'm a software engineer by education and practical industry experience. I studied it at university. I had about 10 years as an engineer. Then I moved into more sort of tech lead roles, and now I lead software organisations, so I’ve done the full spectrum of roles from engineer, tech lead, was product manager for a little bit and then went more into org leadership.

So this was really my first experience of remote work that was instigated through the pandemic. So, there I am, joining an organisation that is experiencing unprecedented growth and COVID-driven demand. It sort of shifted the scaling plans by about 2 or 3 years. And as you can imagine, the systems are starting to creak, the organisational structures are starting to creak.

There was no playbook, you know, no one had a leadership playbook for COVID, and it's like, not only do you have to think things through a business and organisational lens, we're in unprecedented territory where, you know, there was a, vast breadth of experiences where some people were living outside of London, in spacious homes, they had reliable internet, and things were quite comfortable for them.

And then on the other side of things, people who were living in houses, the internet was flaky, they were living, working from their bedrooms, and not a very healthy environment for those individuals. So it really had to lean into all of those things to make sure that people were cared for and we were adapting to people's needs whilst driving results in an unprecedented time of growth. So, yeah, lots of interesting experiences and lessons learnt. An exciting but challenging time, I think it's fair to describe it.

Yasin: Yeah, you mentioned, there was no playbook at that time, given it was COVID and everything changed, people working from home, there were a lot of social pressures as well, the way of working was changing, and then all the digital platforms. There was a lot of pressure on platforms like Gusto, where they had to scale in these conditions. So I'm glad things went well, and now we're in another era where the playbook does not exist. So instead of COVID, we have AI now.

There are no playbooks. There are no rules. There is no set workflow as to how everything is going to change, how it is changing, how it is evolving. And this brings us to our topic today, which is the entire world of AI and how it's going to be and probably already is changing. So the first question I wanted to ask you was around team structures. And I want to see what your take is on how you see AI reshaping software teams. Will we see smaller core engineering teams supported by AI, or will we see new roles like AI jugglers popping alongside our traditional devs?

Ryan: All fascinating questions. The first thing to lead with is that AI is not going to replace engineers anytime soon, in my view. Now, I know we see a lot of headlines that AI's coming for all the engineering jobs. Software engineering has always been hard, and we're often trying to solve what many call, or what has been known as, wicked problems, things that are novel, they've not been solved before, things that take a great balancing of creativity and judgement. Trade-offs and commercial sort of realities.

AI will change software development for sure, but my view at the moment is it's going to augment, not replace, engineers, and it's also going to result in the gap between the best software engineering teams in the world and the rest is going to continue to grow. If you haven't got the strong foundations in place. It's around being customer problem-focused, you haven't got cross-functional teams, you haven't got fast feedback loops, you can't get your software into production very easily. AI is gonna be your world's worst nightmare because it's gonna allow you to develop software, it's gonna allow you to build the wrong thing faster, the software's gonna be a nightmare to maintain, engineers won't know what's going on, and it's gonna be poor quality and it's not gonna drive the commercial outcomes that you seek, so that's the cautionary tale of AI and now let's flip to the optimism.

If you're an organisation and you do have those strong foundations in place, and you're delivering software, you know, every day of the week, your teams really understand deeply your customers, the domain that they're working in, and AI is going to allow you to do more, and this isn't about getting rid of engineers, we are gonna see a trend where, you know, turning the dial to 11 in those organisations is going to be a trend towards smaller teams that are augmented by AI and it's going to give rise to a what I'm calling sort of raw fluidity. I've seen some really great experiences recently where engineers who identified as being backend engineers were in a position where they had to start building UIs to service some of their internal customers, and they were using AI tools to essentially get over some of the initial fear around, well, hey, I'm not a front-end engineer, but they're able to sort of use those tools, get something up and running, and then build on it, so I think, from an engineering perspective, it's going to allow people to sort of broaden their skill sets.

So I think the key differentiator now for those teams and people in those teams is being a good designer or being a good PM or being a good engineer. I don't think it's going to be enough. It's going to be around; the differentiator now is, you know, Google were calling this back in the 2010s, like a smart creative. It's like thinking, yes, you have your primary skill that you're bringing to the team but your primary goal is whatever the team's goal is, and you'll roll up your sleeves and you'll use AI to augment yourself to support the team, in any way you can, so that might be a designer prototyping, that might be a product manager who is coding up acceptance tests, so it's a tale of two halves, really. There are going to be teams that are going to be applying this new technology without solid foundations, and it's just going to magnify the chaos. AI is going to be like an amplifier or a mirror that will show your imperfections.

Yasin: So Ryan, you've touched upon quite a few different points, and let's hone in on one aspect about development. People who are actually coding at the moment with tools like Replit, Cursor and others in the market it has added a lot of productivity. There's a certain part where tools like Cursor are very good at. And we keep hearing that the junior developers on the team, the need for them might reduce over time.

And I'm specifically talking about kids who are graduating these days, or who graduated 6 months ago, a year ago. Because the cursor has increased productivity for the developers, especially for the senior developers. People will be able to do more, but doing more means that there is efficiency gain. Is there 10%, 15%, 20% in your view?

And would that eventually lead to smaller teams, and then a certain segment of the teams, maybe the most junior developers who were tasked by the senior developers to do portions of the code, are they going to become redundant?

Ryan: I don't think junior engineers are gonna become redundant. Junior engineers have always been a hedge for a company around growing future talent. It has been a very challenging market for junior engineers in recent years, but that's more macroeconomic forces rather than AI; there is some crossover. Speaking from my own experiences, you know, budgets have been much tighter than they have been in recent years, ambitions have been just as high or if not more, and so I've had to think very carefully as an engineering leader where do I spend my budget, and, a lot of that budget has gone on more experienced, senior engineers, but I've always been acutely aware that you can only do that for so long because you need to build up your talent pipeline and grow your future leaders.

Now, the role of a junior engineer is definitely going to be changed, so the days of a junior coming in, maybe writing some basic tests or writing the boring code, those roles are gonna be gone because they're the kind of things that can be safely farmed out to AI. So this is where differentiation and how people differentiate themselves in that new market and how we as engineering leaders lift up that new generation, and it's gonna be all around. We need to make sure that the new generation is well versed in the fundamentals, like algorithms, data structures, system design, good architecture, and layered on top of that, how to work within teams, like having good product sense, having empathy for the customer.

And being able to think critically about the code that is being generated by AI, so it's those periphery sort of skills around broader software engineering skills, around knowing how to operate software in production, how to work well as a team, as a teammate, how to work really well with products, and design. They're going to be the things now that make candidates stand out, and as I say, it's a two-way street, and I think there's a big onus on industry to grow these people, and it's a great opportunity to mould these people that have great potential, great enthusiasm into the culture of your organisation, and a lot of the best organisations have been doing this for years, and obviously a lot of companies have taken their foot off the pedal in recent years, but when it returns, and it has to return because seniors become seniors by helping juniors, guiding them, and if we take away that level, then in 5 years' time, where are all the engineers?

Yasin: Yeah, and the thing is that AI has to come to campus, as well, much sooner than universities think; the curricula have to evolve. They have to change. They have to keep AI in mind. My son just started university about a week ago, and in the first class, they told them, you know, I'm not going to name the university or the programme, but they said that AI is the worst thing that has happened to mankind since the atomic bomb. Stay away from it. I personally think that is the wrong message. You cannot avoid the AI revolution that's happening. Campuses and universities have to adopt it. They should realise that it is there to, like you mentioned, augment their intelligence, and it's the actual intelligence that will prevail in the end. You just need to be able to see how this artificial intelligence is going to help you with your work. These are very fluid times, I think, and let's see how things evolve with time.

That brings me to the next question: how do we see the SDLC evolution happening, because you've touched upon product management, requirement gathering, doing UI UX design, working with agencies, the different stages of AI, but you know, which stages of SDLC do you really think AI will meaningfully transform? Because if it's just writing unit test cases, I'm not sure if that would qualify as some sort of AI revolution.

The upfront task, like when you mentioned about discovery, doing visualisations, getting prototypes, demos, product managers are now very equipped, and they have this weapon called Lovable and Bolt and these tools where you can actually start doing a lot of stuff on your own. Where do you see AI being the most effective in the overall SDLC process?

Ryan: Great question. If we look at the end-to-end flow of value from someone has an idea for something that they believe is going to have commercial value to getting deployed into production. Coding is like a small component of that, and so requirements and discovery is gonna be an area that's gonna be hugely facilitated by AI and vibe coding, we've touched on it earlier in that, you know, a product manager and a designer now have the means to very rapidly prototype, and I think this is where we need to be really careful, because we spent the last 10 to 15 years trying to get the triumvirate of engineering and design, working really closely together, shared understanding around goals, and there's a risk, because now the technology affords it, that product and design might splinter off again and be, well, we don't need engineers in discovery now, we've got all these tools, and then all of a sudden the engineers are gonna get the classic da da, this is the thing we're building, can you just productionize this, this five coded thing, which completely removes the value of having engineers in discovery in the first place, where the designer is there to see, is what we've built usable and the customer's going to love it. Engineers are there, is what we're trying to do feasible from an engineering perspective, and then the product manager is there, you know, all these things combined, are we going to solve the customer problem in a way that works for the business?

Whilst it's going to accelerate and reduce the time to prototype and get feedback, there's a real risk that engineers will be left out of the loop, and so I think we really need to be careful to keep, even though there is the means to prototype without engineering. Engineers still have a valid role to play in discovery, but I think that's gonna be one of the key parts of the software development process that's going to improve, and it's going to help us identify what is the right thing to build, because if we don't get that right, then anything that happens downstream is just moot. So, I'm excited about that aspect.

In terms of the coding aspect, gone on this journey from, programming in just raw text editors, then people having fancy VimM or Emacs setups, the code just sort of magically appears, and then we had more fully fledged IDEs and so we've had this phase of AI where it feels like code complete on steroids, whereas I think the next leap is the move into autonomous agents where they can be given meaningful pieces of work to go off and do themselves. And now, let's assume for a moment that we get to a point where the technology does get to the point where you can have these autonomous agents that can code at a mid-level engineer level. Then what that essentially does is that it turns senior engineers into leaders and managers of agents, but then we've got this interesting dynamic in that they may not have the skills yet to successfully, delegate work to these agents, and that role becomes very much like a traditional tech lead role, or certain aspects of engineering management, so I think we are potentially on the brink of a tech leadership crisis that means that even if the technology gets to that level, we can't, we've always got this capability gap where most teams won't be able to get the most out of it because, engineers will be completely overwhelmed with these 10 agents that have gone off to do this work and they now need to reintegrate the work.

When I've spoken to some engineers experimenting with this, 3 things that came across was one of overwhelm, so this cognitive overload of managing all of this work that's going on, frustration that the work coming back isn't how they would have done it or wanted it, and then overall feeling of disappointment that, OK, I set all this work in motion, and it's come back and I don't have anything meaningful to show for it. So, we're in the world of rich prompting and guardrails, where these agents need to be fed. This is our coding standards, this is how you need to work in small increments, test-driven development, and I think what we're going to see is a revival of a lot of the XP practises.

We're in this world where the general sentiment is that LLMs aren't going to get that much better, as like ChatGPT5 wasn't a step change; it was a small increment, and so we're in this world where the AI age, we're going to need more technical leadership and better technical leadership. It's going to force the most experienced people in an org to really distil their knowledge and experience into a way that can be interpreted by AI tools to then get the kind of output that we're seeking. I think the organisations that can get that to work, my earlier point in the podcast around we're just going to see this ever-growing gulf between the best teams and the rest of the average teams.

So, if we're building on strong foundations, I think we will be surprised at the kind of the, the levels of performance that we can get out of some of this technology. But it's not going to come for free, there are no silver bullets, and it's the organisations that are already doing well that are going to benefit the most.

Yasin: Yeah, and you know, it's very interesting that you point out, and we actually see the same thing as well, that in a lot of the upstream activities, we see AI and the tools actually being very powerful, tools like Lovable and Bolt. We personally like Bolt a lot more, for certain reasons, and you're able to visualise, you're able to prototype, you're able to come to decisions much more easily and quickly and brainstorm ideas across teams. And then when you go on the coding side, development side, it is, the tools are also very powerful, but they're very dangerous as well at the same time. So, what we have done is that we have recently adopted Cursor after a lot of research on different tools. And before anyone could use it, our CTO and our VP of engineering, and other senior tech leaders within the company basically set out all the guardrails, all the rules, of how coding should be done. They have squeezed their 20-25 years of experience, from 8 or 10 different people, into this one document that the entire company would have to use by default because those are the rules that we have fed into Cursor, that our output needs to match to that.

I'm sure you realise that as well, it is a great time to be a very senior engineering leader and a CTO because, you know, everyone needs them more than ever before, because if you set the guidance right, that's what will propagate down to the junior members of the team as well.

So that brings me to the next question: how do we prepare our engineering teams that we have today? How should you prepare your teams for this shift? Do you retain existing devs, hire new skill sets, or rethink what good engineering even looks like? When AI is part of the mix, we have not struggled, but we have tried to navigate our way through. We see that the younger developers are a lot quicker in adopting AI, learning AI, because it's science that you have to learn, and then upskilling existing developers is another task which we have had challenges with. How would you guide engineering teams and leaders as to how would they prepare their teams for this shift?

Ryan: So the most important step is a cultural one rather than a technical one. It's around creating a culture of safety and experimentation. So a lot of people when they hear about AI initiatives, immediately are thinking, what does this mean for me and my job, and we see the headlines, which prey on people's minds. And so I think the key thing is that where possible like depending on your context. It's like maybe significantly reducing headcount is the goal in your organisation so this will differ.

But for many organisations, this is about getting more from the people that they have and for those people to be able to do more and interesting jobs. So I think the key thing is to be as open as you can around the motivation and what the end state looks like.

And to have a culture around experimentation, these are new tools, and when people are using new tools, performance often goes down, and I think that's what we've seen with a lot of people using AI tools, people that have been, for 10-15 years reporting, actually the first couple of months, I was slower because I'm learning how to use these tools. So it's like having that sort of safety and that experimental mindset that we're not going to win first time and that leads us then into mindset in that technologies have always changed and new ways of working have come along and so people need to be curious, they need to have humility that that they're not gonna know everything. And that ability to learn is a sort of a non-negotiable really, in this day and age, and I think that will just continue to be ever more true.

I think there's one thing that, what we're seeing with AI is that previous records have been broken, like companies have gone from 0 to 100 ARR in 5 months or whatever. Like breaking records. But pilots are where I think where a lot of the hard work gets done in a safe way and in a way that embodies experimentation. So it's like carving out, say, a single team to say, OK, we're going to go into this team and we are going to start experimenting. Let's say you're able to significantly reduce the time from idea to software and production, then that will get people curious, and then you can go and you can tell stories about what was done, what the tools were, and then people will start most likely leaning into that and, we want some of that, and then you can rotate people around the organisation to actually roll out those things, and this is why I think, the concept of, whether it's called an AI champion or AI champions, that they're like bumblebees, they're going to go around all those different teams and they're going to share the knowledge, and that's how you get this reinforcing cycle. So a cultural safety experimentation, you know, be very clear about intentions, you know, mindset, and have those pilot projects that can then, you know, demonstrate where there are wins.

Yasin: Yeah, I think you said it right, Ryan, that it's all about experimentation. These are the early days, a lot of companies have not even adopted AI. It will all start with experimentation, learning. Things will be slower in the beginning, and then you will find your way through, and find where it makes more sense to your organisation.

On my next question, you've already alluded to what your vision is, but you know, let's say fast forward even just one year, Ryan, in this ever evolving age we're going through. How do you see teams after a year with this AI driven environment? And how do you think it would be different from today?

Ryan: If we look at a year out and we spoke at the beginning about that two spectrums, so this is from the basis of, it's already a strong team, they've got lots of strong foundations in place, so let's say a year out, we're going to see even tighter integration of, product design and engineering, and we're gonna be rapidly experimenting with new ideas on a daily basis, and testing a new idea is not gonna feel like something's scary and it's not gonna take 2 weeks, it's gonna be done in hours, and we're not just talking about showing some prototypes to a working group or a cross section of users, it's gonna be working software in production, you know, it may not be production grade because it's being built to throw away, but it's in production, it's being used for a small subset of customers, and we're getting valuable feedback around what are customers engaging with and finding value, and then that's going to be followed up with execution, that is, teams that are maybe 2 to 3 engineers, you know, they're using AI tools with strong context, project dependent prompting and guidance, so there's all the guardrails, the usage policies, the coding standards, and those teams would have really identified the kind of tasks that can be delegated to agents, and so those engineers are starting to operate more like tech leads.

They're thinking more about the system design, breaking up work, delegating it out to agents, but against the backdrop of like super small batch sizes, solid suite of tests to ensure stability and having really good operational observability. So that's what I would expect from these pilots. I would expect a year's time in the leading organisations, you've probably got a team of 3 to 4 people that are building products at pace and having significant impact.

Yasin: Yeah, and this is in line with Sam Altman said recently that there will be a lot more unicorns with very few people on the team, like I remember when WhatsApp was sold, it was what, 9 or 11 people, and they sold for $19 billion or something.

There'll be more and more of those with the advent of AI and all these tools. So, all right, Ryan, let's wrap up with a quickfire round, short answers only. I love this part. So, first, one AI buzzword you would happily ban forever?

Ryan: AI is going to replace engineers.

Yasin: Yes, good one. Especially for engineers, that's a very good message. OK, next one. An AI tool you absolutely trust?

Ryan: Well, that's a deep question because that data's going everywhere. But in terms of trust as would I trust the output, I think I've been a big fan of a lot of the transcription tools for meetings and calls like this. It's been really accurate, but what those companies are doing with the data behind the scenes.

Yasin: Yeah, a very good answer, Ryan. Very diplomatic answer as well because it's transcription service it has to be accurate. There's no judgement over there. Whatever people speak, they transcribe. Last one, you know, if AI gave you let's say 10 extra hours a week because of productivity increase, what would you really do with those 10 hours?

Ryan: So, I love running. I'd be doing lots of running. I've recently got a dog, so I'd do some walking of the dog. But, I think the interesting thing about that question is that, you know, as much time that AI saves, we'll find more things to use up that 10 hours. I don't see us entering a world where AI is enabling the 20 hour work week or the 10 hour work week, unfortunately.

Yasin: Yeah. Well, Ryan, thank you so much for your time. I really enjoyed our conversation. I know we have not spoken in the past, but there was a lot of common ground that I saw, in terms of your ideas and what we have been thinking about practising at GoodCore as well. Our viewers and listeners would learn quite a bit from this. Really appreciate the time, Ryan, with Ctrl Alt Deliver and hope to see you again, sometime.

Ryan: My pleasure, thanks for having me, Yasin.