Andrew Fisher in conversation with Sarah Taraporewalla, Geoffrey Huntley and Dave Lemphers

AF: So with us to continue this conversation - so thank you for that, Geoff, that was great - we've also got another AI pioneer in here as well.

Dave Lemphers, come up, join us, please. So Dave is co-founder and a researcher at a company called Maincode, which if you don't know it, is doing a lot of pioneering research on this particular topic. You're in Melbourne, aren't you? Yes, here in Melbourne. So, yeah, so great to have him join with us. So, look, there's some great questions that have been popped up in the chat. So we'll kind of get into some of that, but some really thought-provoking different perspectives, as we've just kind of seen from these two talks.

You know, we're really sort of at that crossroads, I think, in a lot of ways about how do we as technologists and engineering leaders particularly start to shape the way our teams are going to be working and how do they feel about this transition as well? So certainly a lot of the conversation that was popping up in the chat was very much around that topic, particularly around people and managing them and stuff like that.

So I thought I'll just kind of start by asking a question to the group, which is that: how do we feel that the - are we likely to see large-scale reductions in the size of our teams do you think as we start to to play this out? Are we now moving from teams of 10, 15, 20 to teams of two or three? So, Dave, why don't you start? Because you're fresh to the stage. DL: Can everyone hear me? Yeah.

Yeah, I think the size of a team isn't necessarily dependent on the tools. And I don't think that AI tools are going to change the dynamic significantly.

I think what we're going to find is actually teams will still continue to ebb and flow based on people's ability to adopt technology and be early adopters of good technology.

I think what we'll actually see is just more productivity and more functions, more features, more backlog taken care of. I also think that we will probably see more interdisciplinary development happen. I think with coding agents and LLMs in the SDLC, we have a better chance of experimenting in ways that we didn't before. You can cut a dev branch, you can explore something like neuromorphic computing, you can throw it away, and you can learn something as you go. So I think if organizations and teams look at the AI agent loop as a trainer and an educator and a way to fast track learning, you know, in areas that they possibly wouldn't have before, then their teams are just going to produce better. And those that can't stay with that, just like today, folks who can't keep up with containerization or, you know, cloud, the same thing happened, right?

AF: Yeah, absolutely. I mean, definitely I think about this as kind of how much more through the backlog can you get, you know, especially for enterprise customers, and I know Sarah, you've been working with both startups and enterprise, which is very similar to me. And, you know, there's this notion of the sort of two tracks that these organizations are on. And I'd be curious about your experience with that and seeing how they're kind of attacking that both sides, but also this sense of, you know, what does the team start to look like as a result in those different organizations? ST: Yeah, hard questions right from the bat. I love it. So firstly, you know, if we - people who tell you they know what the future actually will look like are lying to you. Like, no one actually does know that. But I think we are, as tech leaders, we're actually in quite a better driving position than the most at the moment.

What I'm seeing in the startup game, especially startups that are happening now and today, so not ones that have been running for the last couple of years, they're still kind of in the enterprise boat. But if you want to, if you have an idea today, you can get that idea to market very quickly and very easily. And this isn't even a conversation that's happening within that space because they just get on and do it.

Within the rest of us that have got well-established teams, there is a human sacrifice to play if you want to play that game right now.

I believe that humans will continue to play a very important role augmented with the tools, but I'm not going to - i'm not naive enough to think that bean counters won't look at - to these tools as opportunities to reduce a large portion of their CapEx costs, which is human capital. So I'm not going to say no redundancies - it won't mean redundancies throughout the organization. I think that we are in a better position to steer organizations through shifting towards doing more with what we have rather than doing what we have today with fewer folks. AF: Yeah, I mean, a lot of organizations that are not pure tech organizations don't necessarily have very deep pools of expertise that they're drawing from anyway. So, you might have a tech team of 10, 15 people for an organization that might be several thousand in size. And so that whole notion that you're gonna start taking chops to that is probably fairly low. In other types of organizations, maybe where they're a bit more tech forward or kind of tech oriented, maybe there's a little bit more space to play in there. I mean, I'd be curious, Jeff, as someone who has been working recently at a large tech company, what your observations of that are. And I mean, now you're going to a startup that's kind of very small and your expectations around how that might scale from a kind of team perspective as well.

GH: Yeah. My website has a blog post called 'Dear student, you're screwed.' Straight up and down, like dad honesty, if it was my own son explaining it. ThePrimeagen, which is equivalent of CutiePi in the software industry, did a critical review on it, saw pretty eye to eye to it. I encourage you to read that.

Short term, I think companies will, because in this economic climate and pressures, they'll make a silly decision to cut costs and reduce headcount. To back Sarah's talk, some of the biggest efficiencies you can get in AI is not in AI.

It's eliminating processes and waste that's holding your organization back from execution. Now, for companies that cut workforce, I think it's not gonna be a cut of workforce based upon, 'we wanna reduce X headcount.' What it's gonna be, it's gonna be that 2024, 2025, is making sure you got the right people in the right seats who understand - who can navigate this that are investing in themselves.

Now, if companies cut - well, the history shows what happens. The last tech boom happened because in the year 2000, we had the dot-com bust. And in the dot-com bust, what happened was not enough juniors were manufactured, which created another boom. And then we saw salary, we saw, at least here in Australia, we saw a huge amount of Australians leave Australia because you're 22-23, you get your first job and you're already earning $230,000 Australian a year just by leaving the country. And that's the entry price for salaries.

If you've never seen levels.fyi and seen the career salary game, it has been wild. And the result, that came because there wasn't enough seniors produced, or - because in the dot com crash, they wasn't produced. So to complete a very long thing off here, who produces the juniors going forward? And we will see a repeat.

ST: I would be interested in challenging the notion that juniors aren't needed. I am seeing more and more rhetoric around seniors not being needed because you can get people coming out of the university that are actually a lot more AI literate and a lot more AI native.

So if you've got someone who comes out of university, maybe without a whole bunch of experience, but they can get the job done easily using different tool sets that you've got compared to the cost of training people that you've got to factor in - bringing them on the journey - that dynamic sort of also needs to play a part. So I'm not sure that the future of all junior developers is that they're not needed. But also equally, I don't think the future of senior developers is that we don't need them. I think we need the mix. And we've always needed that mix because we need bright, fresh ideas and thinking and we need to couple that with the experience and the know-how and the battle scars. Someone told me when I was a junior, I needed more battle scars. So I appreciate what that means now, because you need to know what happens when code bases go wily and you don't have enough documentation or tests, you know, around it, get craft through the system. You need to have experience of the failures in there mixed with a bright thinking of the future.

AF: Yeah, there's definitely a mix change potentially that might unfold as a result of this. I think the point of - we're still going to need juniors, but we're also still going to need seniors is very well made. And historically, we've been in a situation where you know, orgs have been a little reticent to kind of bring juniors in because they're like, oh, this is just going to drag my seniors down in terms of the time that they have to spend to mentor and support and kind of all this sort of stuff. And it's almost been seen in some ways as a tax on delivery. It's kind of, you know, like, I want to be more thinking about having, you know, competent mid-level and kind of senior devs who can just roll up their sleeves and smash the keyboard and kind of get stuff done. And so, you know, maybe we'll just bring one junior in over the next 12 months because we need six other people to support them and stuff like that. And you get, yeah.. DL: You know, I think what's also really valid here is that some of this is theater. And so as a software engineer, I can't remember the last time I looked at the documentation to write code. So, you know, at some point, Stack Overflow was the go-to, you know, I was just kind of like autopilot, you know, cutting and pasting, 'copy pasta,' refactor, get the job done, TrueUp everything in the stack. And what actually made me effective as a software engineer was automating and having my iteration time and that loop to resolve bugs and TrueUp being the quickest. And I think that this idea that we've moved so significantly far from just Stack Overflow- led development is really, I think, the biggest part of the theater. And I think that for a lot of folks, It's actually just a psychological aversion to losing control.

And I think as engineers, we struggle with this idea that we're going to lose control where the skills that we have that differentiate us and keep our jobs is going to go away and someone else is going to have that capability. But the reality is that if you look at the progression of any kind of advancement in tooling, you didn't lose the craftsperson, you just made them more efficient. So just like today, people don't hand drive nails all the time, just like they don't, cast those nails, you know, like a blacksmith did, you still need someone who knows their way around the challenge and the problem and the domain.

So I think it's actually, and this is my own experience, is it's largely psychological. And there's some folks who are just like, I don't want to use a tool that diminishes my control and my skill capability in my job. And I think as people start to realize that's not what's happening. And in fact, it's yeah, and I challenge anyone who hasn't done it today, but just go and zip your Git repo, you know, pull out everything that's, you know, not in the Git ignore.

Go upload that to Gemini and just ask it a basic question, right? Like, here's a great prompt: "Generate me a linear like ticket to improve one part of this code base from a performance perspective," and just see how powerful that workflow ends up being. It's such a really safe way to do it. And I think by doing that in a really slow way, people are gonna be able to acclimate quicker than just either scaring the hell out of them, right? GH: Yeah, I'm a very strong - like this is the deliberate intentional play - like deliberately approaching a problem space as if like not trying to achieve a task, what can it do? And then building that muscle, kind of like lifting plates, like just continually lifting those plates.

To back Sarah - yeah, I think it's a critical mistake for any engineering leader to say they're not needing juniors, because it's kind of like when Google Docs entered the workspace.

Previously, the workforce was emailing Microsoft Word documents backwards and forwards. They bought in the change at G-Suite and they introduced new changes of work. The younger generation are cracked. They're automating parts of their life right now with AI, and that's gonna be the skills you need. But in the short term, I'm seeing people close, and I disagree with that. DL: Yeah. I mean, there's other things that this whole workflow chain is opening up. Like, I think if you look at how much research made its way into day-to-day coding, very little back in the day, like to do literature review, to actually understand what a paper was talking about, to implement that in code was a lot of work. And you can look at people today with their workflow from Perplexity, you know, through an LLM, you know, "present me a prototypical code to this paper," you know, "now show me how I can stitch it into my existing code base" is a brand new workflow that just didn't exist before. So I think to that point, for the folks that actually get it, they're not only going to be able to work through the backlog quicker, they're going to be able to advance the capability of that backlog in ways that they couldn't before. GH: Yeah, yeah. ST: Oh, I was just going to say, to touch on something you were just talking about. I think the notion of what a team is will shift. And what I'm excited about the shift being is that we can certainly start to get really cross-functional teams happening and diversity of teams happening because we don't just need to pull from software engineering pool of people, we can pull from the domain - directly from the domain experts. So the domain experts armed with some of these tools can be actually productive within our software delivery. So our cross-functional teams, the thing that we've always been trying to advocate for Agile has usually just meant we have BAs and QAs and product people joining the developers in the team. But now it's actually business units can be a cross-function of the software delivery team itself, where we've got lots of people contributing to that value add.

AF: 100%. I mean, I led a big change several years ago now that was rolling out low and no code type applications across a big enterprise, and that ability to empower parts of the organization that had historically felt very disempowered in that whole process, where it was like, okay, you come to us and we will tell you what you want, which is typically the way that kind of, you know, technology in most enterprises works. You know, it totally changed on its head that whole dynamic and being able to, you know, federate out that ability across the organization for those domain experts to show their expertise and then have technology enable them to get on and do their jobs. And, you know, starting to kind of like really get through that backlog of tasks that would never have got a business case because, you know, oh, you're not going to throw a team of 10 and kind of, you know, a couple of million dollars at that task for the supply chain team, you know, because they're just not worth it, you know, that was definitely the mindset. And so I see a lot of parallels with how these types of tools might be able to kind of permeate back out to the organization and then bring people back in into that multidisciplinary squad that's a lot more kind of robust in terms of its makeup well and truly.

ST: Yeah. And so then the role of the tech leader or the CTO on the organization needs to care about how to democratize this as a thing that can enable the business in a safe and secure way.

So I'm working with lots of - a couple of key clients right now creating an AI workbench for their teams so that their teams are enabled to choose the different LLMs, to choose the different coding assistance that they want, to choose the way that it's sort of strung together and the different agentic systems that they want to use. But doing so in a safe guardrailed way that enables that innovation, but not - what I'm seeing that is actually coming rapidly with a really rapidly increasing total cost of ownership.

So yeah, I think the role of a tech leader now is to think about what - if we think about DevX platforms, what's the next version from an AI devX platform. GH: Sarah, I've seen some weird stuff. Like in Australia, there's this notion that if you're down at the pub playing a game of pool and the opponent sinks all the balls before, you have to do a lap around, you get pantsed. And I'm like - the best way to, like, it's always been a thing in software engineering - to get a software engineer to, like, engage, just say something's wrong, like, and like they will engage or like, that's the thing. And I've seen BDM, sales, product managers, they're raising PRs with these tools and they're wrong. And software engineers, the software engineers love to prove that, like, no, it's wrong, this is how it's wrong.

It's like, thank you for listening. Like, we're actually seeing reverse nerd snipes across organizations now to get stuff done. May not be right, but it's completely changing that the process of like, where parts of the organization haven't been listened to. AF: Excellent. So we've only got a couple of minutes left. So there was a thread of conversation that's been happening on the Q&A here, which really sort of, you know, to distill it down is really about overwhelm as leaders and, you know, how to cut through with that.

So I just want to do a quick, you know, pass along here, which - if you had one thing to kind of like convey to this great group of people here about one area that someone could focus in on, particularly if they're sort of, you know, a mid to senior level, you know, leader, where would you suggest they focus their attention and where to start? Dave, we'll start with you.

DL: I mean, I think create that emotional safety for people to explore and experiment with AI, and that's just not AI in their DevX and their tool chain, but be open to this idea of moving to more of like probabilistic thinking, right? I think the more we can experiment with actually putting models in our software, finding really easy applications to train or fine-tune existing models, it's gotten to the point now where in 30, 40 lines of code, you can actually achieve a pretty simple model, you know, to do a classification task, for example. So I think making it fun and safe to use AI across all parts of the process, I think is exactly where leaders need to be.

ST: AI for software delivery champions.

So setting up, it is overwhelming and there is so much information and it's sometimes really difficult to cut through the hype. But In your organization, you could set up a group of people who are really invested and exploring this on their own time anyway. Harness that power, pull them together, give them structure for what you want to do, what you want to explore, and what you want to sort of drive through the organization. But then let them experiment and give them that safe space to work in, and spread those lessons sort of across the organization.

GH: If you're an engineering leader, the most concrete thing you can do as you head back into the office is get people to build an agent. Just concretely. That will get people to understand that everyone is selling magic beans and it won't feel so tiring when they hear a new thing come to market market. Understand that it's three or four concepts running in a while true loop of 500 lines of code. That way, people will be able to know like the difference between a hatchback sedan and a 40 series, right? And then they would start going, oh, it's just the same loop with a different prompt on top, and then it won't feel so overwhelming. Like that's the most concrete thing you can do as an engineer.

On the people side. My God, it is scary. You need to get people through that deer in the headlights phase and understand that people, as they play with it, will regress. And to Sarah's point about basically organizational change and planning, it's pretty important as a people leader to start a program through that.

And I guess if you implement an agent, then you will feel a little bit less strained when it comes to "let's evaluate everything that every employer is doing right now." AF: Brilliant, great spot to end on. So, you know, as leaders all here, you know, so much of what we do is the combination of technology as well as people and systems and really sort of bringing that all together. And I think as we've sort of explored this topic both collectively and previously with Sarah and Geoff kind of doing their talks, I think that's really starting to come out in the heart of this. It's not just a technology solution to this stuff.

You know, people and systems are kind of like equally kind of prominent within that as well. So I'd like to thank our speakers and panelists, you know, for our session. I think we're about to go for lunch or is John gonna talk? John's gonna talk. So I'll hand over back to him. But thank you to our team. JA: Thanks, Andrew, as well. Thank you.