How To Lead Through Transformation in Tech

Charles Humble: Hello, and welcome to this episode of "GOTO Unscripted." I'm Charles Humble. I'm a freelance techie, editor, author, and consultant. And this is the eighth episode in a series of podcasts that I'm doing for GOTO, talking to software engineering leaders. Today, we're joined by Hannah Foxwell. With over a decade of DevOps behind us, Hannah continues to champion the human and cultural elements of technology transformation, shining a light on the engineering practices that make life better for the people involved. Hannah is  co-organizer for DevOps Days London and is an Open UK ambassador. She currently works as an independent advisor and writer at the intersection of platform engineering, security, and AI, and is the founder of the AI for the Rest of Us Conference and Community. Hannah, welcome to the show.

Hannah Foxwell: Thank you for having me.

Charles Humble: Absolute pleasure. Thank you for being here. So, as I said in the intro, you're very well-known in the DevOps community, so I thought perhaps we could start there. So, why did you get interested in DevOps and continuous delivery in the first place?

Hannah Foxwell: Well, DevOps for me was the solution or potential solution to a problem that I was feeling every day in my working life. So, I was a release manager for a large enterprise retailer in the UK. And so, my job was literally to sit at that intersection between development teams and operation teams. And so, I saw that sort of conflict and those misaligned objectives. I saw the impact of the introduction of agile processes and the increased frequency and velocity of delivery we were trying to bring into the world of software development. And I saw the impact that that had on my colleagues in operations. And so, when I first got involved in the DevOps community, it was super early days, but I understood the problem. Do you know what I mean? Like, nobody really had concrete answers at that time, but I really understood the problem that needed to be solved. And so, that's already what I've been doing ever since. And it's crazy to think it's been over a decade now, but I've been really looking for ways to, like, create that harmony and create that sort of one-team mentality in software delivery where we are so accustomed to silos and quite often conflict in our organizations, which isn't good for anyone.

Charles Humble: Right. Yes, it's interesting you were a release manager because that was one of the few roles that I very kind of studiously and intentionally avoided. Because it was such a difficult thing to do, you know, sort of 10, 15 years ago. It was a sort of famously hard and fairly thankless often.

Hannah Foxwell: Yes, oh my God, I can imagine. I remember very vividly, like, the types of methodologies that we would use. And it was like, we do like three months of development work and then we would create like the bronze build and everybody has to check in their changes. And we'd create this version that was due to go to like this higher up controlled test environment. And of course, like hundreds of people all checking in their changes furiously, it never worked. And, you know, like all of those things that I like as the person who was like the face of these processes, I was like, "Why? Well, why doesn't it work?" And so then, you know, you start to read about continuous delivery and continuous integration and shipping small changes rapidly and pushing small changes to production, how that reduces risk. And it was intuitively true for me because I'd seen my team do that on things like bug fixes and things. But as soon as we started to pile in on a major release, that's when things went really wrong.

Recommended talk: Re-engineering Inclusion • Jill Wetzler • GOTO 2019

Balancing Agile Practices with Inclusivity and Flexibility

Charles Humble: It's really interesting because so I had a vaguely similar experience. I was at QCon. I think it was QCon San Francisco. And there was somebody from Amazon talking about the fact that they were deploying to production, I forget what the number is, sort of 15 times a day or something like that at the time. And I think we were deploying to production three, maybe four times a year. And we thought we were pretty cutting edge, you know, like it was just, it was like night and day. And I sat in this talk for 40 minutes and came out of it thinking like, "That is very clearly a much better way to do this than what we're doing." But it's interesting because I think there is a sort of counterintuitive thing. It's interesting you said that you got it straight away because I'm not sure that I did. The idea that, if you were moving quicker, that somehow that was less risky. I think that took me a little bit of time to kind of figure that out. And interestingly enough, I think a lot of agile practices can feel a bit counterintuitive. I mean, pair programming is one that I still see people kind of going, "Well, you've just got two people doing one job. How can that possibly be better?" Which, you know, like you sort of see it logically. Actually, do you have any recommendations for how you make those sorts of things appealing to sort of managers and leaders who aren't familiar with them?

Hannah Foxwell: I think one of the best ways to advocate for a change is to demonstrate the benefits of it. And so you can waft slides at your leadership team allyou like, but what's very powerful is just running an experiment and saying, "If it works, great, we'll keep doing it because it's an improvement. And if it doesn't work, you know what? We'll go back to the old way. No one's lost anything." And I think framing it in that way, when you're trying to introduce practices like that is sort of like a good way to navigate change. It's like, "Well, if it works, obviously, we'll do it. And if it doesn't work, then we won't." And so with pair programming, one of the things when I was working at Pivotal, that was one of our really core practices. We understood that, you know, you build quality in from the beginning and that is, that saves you time and waste further down the process. And the two brains are more likely to get to the right answer quicker than one. 

There's also the element of sort of accountability or less likely to sort of rabbit hole on something.If you're with someone and you can talk through the problems out loud or you intentionally take a break from a problem because you're not getting anywhere, there's all kinds of benefits to pair programming. But, yeah, we introduce pair programming and XP practices to many, many organizations. And, you know, it was under the umbrella of a sort of consulting engagement. It was like, "Okay, well, we're here to teach you things. And so why wouldn't you want to sit side by side with us doing it with us?" And so that was actually very natural. And it was very embedded in our culture. But I think, you know, that sort of time-boxed, evidence-based approach is something that anybody could do. And maybe your engineers are also, you know, a little bit nervous about pair programming because it's quite a different way of working and, you know, frame it as an experiment and agree like how you're measuring the success or failure of that experiment. And suddenly it's less like a mandate from management. You know what I mean? No one likes a mandate from management, do they?

Charles Humble: I have a kind of interesting relationship with some of the agile practices and pair programming is a good example. Because, although it isn't true for me personally, I feel like our industry is one of actually a fairly small number of industries that's attractive to people who are, for example, autistic or neurodiverse in certain ways. And it's also quite an attractive area for introverts. I mean, so much so that it's kind of a cliche. But it's a cliche for a reason, right? Because it's one of those areas where writing code, working with a computer is something that's quite attractive to a certain group of people. And I worry that the various practices that we've promoted that make-up what we might call a sort of agile, real agile, or something like that, are yes, they're helpful for neurotypical people. But I worry that they are somewhere between completely exhausting for introverts and utterly impossible for many other people who might be extremely good at their jobs if only we can learn how to accommodate them. And I'm curious if you've sort of got any advice on how to find a healthy balance there.

Hannah Foxwell: It's interesting because I've got lots of friends who are neurodiverse. I've had lots of colleagues, I've had team members who sit in all kinds of places on the spectrum. And I think it's difficult to generalize. I think you have to be open to accommodating people's needs. You have to make it safe for people to advocate for what they need to be successful. But a lot of folks who sit somewhere on the spectrum or would cast themselves as an introvert, aren't sort of fundamentally against teamwork. It's just that you have to realize that it has a different impact on them. And so I'm like, it's not a scientific analogy, but I like the analogy where extroverts gain energy from all of that social interaction, and introverts are sort of depleted by it. They need to recharge afterwards. And I think making sure that you create space for that recharge for people who need it. And also make sure you create engagement and collaboration for the people who need that. I'm probably more extroverted than I am introvert.

I'm not extremely at any one end of the spectrum. I need my alone time and I also need my social time. But for me, during COVID, I did miss people. I did. Like, I really did. And I don't know whether that was exclusively a feeling for the extroverts. So, I don't think there were introverts sitting at home going, "Brilliant, don't need to see another human for like six months." So, yeah, I think it's about small adjustments and making it okay to take breaks, making it okay to create that recharge time, selecting some tasks where you can solo or where you can work asynchronously or you can work more flexibly. I think having a sort of, again, I said like the management mandate, a management mandate of like, this is how you should work is not going to be successful. It's about adjusting to the group of humans that you have collected together and figuring out what's right for them.

Recommended talk: Remote Working Approaches That Worked (And Some That Didn’t) • Charles Humble • GOTO 2023

Navigating Remote Work, Flexible Practices, and Organizational Transitions

Charles Humble: You and I have both advocated, I think, for both remote work and flexible working practices more generally. And again, I think pairing is one of those things that can make that more difficult. So, remote pairing now, I feel, is more or less a solved problem. I mean, there are technologies that allow you to do that fairly well remotely. But I'm yet to see pairing and flexible working work particularly well. I'm curious, again, if you've got any thoughts on that, if you have any sort of suggestions or advice.

Hannah Foxwell: Again, it's about the needs of your team, really, isn't it? And so, you know, there's flexible working in terms of a distributed team. And that's awesome because, you know, we can still collaborate virtually. The tools are there today and they weren't before. Then there's flexibility in terms of the hours I'm available and online. You know, some people... Like, I have different needs. I don't do the school run. Like, my sister's got kids, she does the school run. My friends do that. You know, they sort of down tools for like periods of the day where, you know, they have responsibilities at home, but then they're back later. And that works well. And I think being really open and having an environment where you can be open about, you know, life stuff now. I'll be offline for an hour and then I'm back. That's really good. Now, there's sort of a levels of this.

I'm now thinking about the teams that I've worked, and have been very globally distributed, where there's very little overlap in terms of time zones. I think that can be a more challenging one to navigate. I think you do have to build that muscle memory of asynchronous communication. I probably would never advise you to have like a single team member who is on their own in a completely disconnected time zone. I think it would be really intentional about how you build your team, because if you have a hub of people, for example, in the U.S. or a hub of people in India, and a hub of people in Europe, you know, they still have the opportunity to pair program and collaborate and have that sort of sense of belonging. Whereas if you have a single person who's out on their own, I would worry about that person feeling connected to the team.

Charles Humble: Yes. I actually did a whole keynote on this at GOTO Aarhus I think a couple of years ago. And one of the things I say is that basically you can get away with about five hours of time zone difference. So, from, like, England where we both are now to New York is okay. England to San Francisco is more of a problem. And one of the reasons it's a problem is because basically what happens is, basically all of your meetings end up at the start of the day for the people in San Francisco and the end of the day for the people in Europe. And then over time, those meetings get earlier and earlier and earlier for the people in San Francisco and later and later and later for the people in Europe. And it just doesn't really work. But I think up to about five hours is okay.

Hannah Foxwell: Yeah. One of my colleagues was the only team member who was in San Francisco. And it was a brutal schedule that he was waking up at sort of 4:00 or 5:00 a.m. every day. And I mean I'm not a morning person. So, I was like, "Hell no. That's never going to be me." But, yeah, like he did it. But then it was sort of, it was one of those things that you probably wouldn't have planned for if you were hiring. But it was a person who joined through an acquisition who was an expert in their field and he was willing to make that sacrifice. But I think still if you were being intentional about your org design and your sort of distribution, putting a single person out in a completely different time zone with very little overlap with their colleagues is not setting that individual up for success very easily.

Charles Humble: I think there's another sort of interesting thing there, which is if you start imposing practices or introducing practices that weren't there when people signed up. So, for example, the sort of you build it, you run it idea, that came out of Netflix and Amazon and people like that originally, you know, sounds like a really great idea. I remember hearing Sarah Wells talk about it when she was at the Financial Times and saying that, you know, "We had people who perhaps had young children or, you know, carers for elderly parents or something. And the idea of being on call just wasn't realistic and wasn't something they'd signed up for when they joined." Which again, I think is really interesting.

Hannah Foxwell: Yes. Well, that's a very difficult change to make because that's contractual. Usually, if you're going to be on call for your services, like, it's part of your employment contract. The expectation is set up front. You know, the additional payments that you'll receive as usually, you know, there's usually some financial benefit to taking an on-call shift and holding the pager and things like that. But changing from one to the other. I think it's like changing jobs. Isn't it? It needs to be done in consultation with the employees. And, yes, like, if at all possible, to accommodate people's needs. I think it's difficult because you don't... You know, there's like layoffs have become like a normal thing in tech. And it's so sad. But, you know, you wouldn't want anybody to feel like, "I have to do this and I have to change my life because otherwise I'm going to get laid off." I think navigating that change must be incredibly hard. I've never had to do that myself. Luckily, it's always been, you know, you're an engineer who holds a pager or you're a consultant who does not. But, yes, that must have been a very tricky transition.

Charles Humble: I think so. Part of my thinking for putting this series together for GOTO was to provide advice for people who are making that transition into management or leadership roles. Here are perhaps, you know, really, really good engineers and are suddenly being told, “right you're a manager now.” I've personally meant to quite a lot of people on that transition and I know you have as well. And I'm obviously aware that I think it's one of the most difficult transitions, actually. You gave a fantastic talk at QCon London recently called Being a Bad Influence, which we'll link to, I hope, in the show notes because I thought it was fantastic. 

Recommended talk: Work Anywhere: Managing Remote Engineering Teams at Airbnb • Jessica Tai • YOW! 2022

The Three-Teams Model for New Managers

Charles Humble: You started talking about that transition with the three-teams model. So, can you maybe talk a little bit about that for our listeners?

Hannah Foxwell: Yes. Similar to you, I feel very proud of the people I've helped to coach and mentor, and sponsor through that process of going from an individual contributor to their first management position because it's not easy. And so what I try to help people understand is, you know, there are three teams that you need to think about as a manager. And the first one is really easy and intuitive because it's the people who report to you. And this is going to be where a lot of people start and actually where a lot of people sort of think that the job ends as well, which is incorrect. And I'll go on to that. But this is the bit that is visible to you. Like, as an individual contributor, you see your interactions with your manager. What you don't see is your manager's interactions with everyone else in the organization, and how they're working, and how they're being successful to set you and your team up for success. So, most people, when they step up into their first management job, they dedicate, like, the vast majority of their time to those things that they understand as part of the manager job, the things that have been visible to them.

So whenever I'm coaching a new manager, I ask them to think about their other two teams. And so the other two teams that you need to think about are your leadership team. So, this is, so think about your boss. Like, so you're a manager, but you have a manager as well. Who are your peers? Who is your peer group in that? And how do you create a really cohesive leadership team there? There's a very strong likelihood that if you share a manager, that you will all have quite similar roles, quite similar responsibilities, quite similar challenges. And I always encourage people to collaborate at that level because you're better together. You can learn actually when you step up into a management role by watching what your peers are doing, watching what your teammates are doing, and working on sort of that next level up in the organization to solve common challenges, is really impactful.

That's what people want when they become a manager. They usually want to have more of an impact, have more influence to get things done. And so having a really cohesive leadership team around you, makes that so much more enjoyable, so much more fun. Like, you can really do some very effective teamwork as your leadership team. The other, the third team, which I think is often neglected by new managers, is your peer group. So, if you're an engineering manager, you probably work alongside people in product, people in design, people in support, people in infrastructure. And there's this peer group of people that you need to collaborate with to be successful. And quite often I see people approaching these folks as stakeholders to be managed. And I hate that.

This is a very personal opinion, but I hate it. These are your teammates. We're all on a shared mission here. And we need to work together. We need to collaborate. We need empathy for each other and our unique challenges. We need appreciation of what our peers outside of engineering bring to the table. And so I would always, always advocate for kind of identifying that peer group around you. And really trying to instigate more collaboration and more teamwork there if you can. Bring people into the fold, you know, create shared objectives, make sure your plans are aligned, make sure you don't take them by surprise with any of the changes that you're making. And I think that all becomes very natural if you take the teamwork ethos rather than the ethos of, "You are a stakeholder to me and I'm going to manage you." You know what I mean?

Charles Humble: Yes.

Hannah Foxwell: When you step up to be a manager, like, it's very, very easy to lean into like, "I am here and my purpose is to just look after the people who report to me." But that's not a manager's job. I would always encourage people to like to build those three teams. And to understand who's part of those three teams and you'll be a lot more successful.

Charles Humble: I think that's really good advice, actually. 

Recommended talk: Structures Shape Results: Software Insights • Elisabeth Hendrickson & Charles Humble • GOTO 2024

Inclusive Management: Tailoring Leadership to Individuals

Charles Humble: We've talked a little bit around, sort of inclusiveness in organizations already. And I know, again, it's a topic that you mentioned in the talk. What advice would you have for new managers on that subject?

Hannah Foxwell: You know, what? My number one piece of advice is that everyone is different, and therefore treating everyone the same is not a path to fairness. Like, it seems counterintuitive to say like, you're like, "I'm the manager and I'm going to treat everyone equally. I'm going to treat everyone the same and therefore everyone will have the same opportunities." And like that's not the real world. And that actually can have negative consequences. What you need to do as a manager is adapt yourself and your management style to each individual. You need to uncover what their strengths are, what their weaknesses are. You need to figure out, you know, what is the right next step. You know, do it with them for you or what the right next step is for their career. And then you need to help them get there. And that's going to look really different for every single individual. So, you have to be a bit of a chameleon as a manager.

The way you manage one person will be completely different to the way you manage another person. But it's really about taking the time to understand what success and what progress means to that individual, understanding how you can support them in the context of the work that you do. And then helping them take those steps towards that goal that they're working towards. You know, some people are very ambitious. Some people will be impatient. Some people will be very motivated by, you know, more challenging work, harder, technical challenges. Everybody is different and you need to understand those differences. Not everybody is pushing for a promotion. Some people just want really interesting work to do and some people want both. But, yes, understanding that for every individual in your team is absolutely fundamental. So, creating equal opportunities for success does not mean treating everybody equally if you're a manager.

Charles Humble: Yes. I think there's something else to sort of mention, which is that people aren't static. So, the way someone needs managing will change over time. And I have seen managers make this mistake of thinking, "Well, I know what that person wants." And they're not going and having that conversation again in a year or two years. So, maybe a bunch of things have changed. In your talk, you talk about this idea that, you know, sometimes people need a mentor and sometimes people need a coach, which I really liked.

Hannah Foxwell: Absolutely. And sometimes people need a sponsor. So, a mentor is someone who teaches you what they know. So, you know, it can be easy for people to think, "That's what I need to do as a manager. I need to teach you all of my amazing knowledge and experience and then you'll be fantastic." But actually, if you sort of rein yourself in from that and you think, "Well, actually, does this individual need to be told or do they need a little bit of space to figure out things on their own?" That's when sort of coaching methodologies come in. And I would encourage any manager if you haven't done any courses on, like, coaching and things like that, asking the right questions, helping people to help themselves, that is an incredibly powerful skill. I remember having a manager when I first started my career, who would, our one to ones, he wouldn't give me the answers. And I was like, "Sometimes I just want the answer," but he would coach me consistently so that I got to my own answers and that I figured it out myself. And it was brilliant, actually. It was brilliant. I learned so much. I gained so much more empathy as well by putting myself in other people's shoes, thinking through what their motivations were, learning about the business. And so, yeah, I experienced coaching very early in my career. And so I'm a big advocate for it.

Charles Humble: Right. Yes.

Hannah Foxwell: As I said, sponsorship is the other one, like, often neglected. Sponsorship is where your manager says, "I believe you can do a thing that you've never done before," and then creates an opportunity for you to do that thing that you've never done before. And that's a risk on both sides. It requires trust, but nobody progresses in their career unless they're allowed to do things that they haven't done before. And so this is what sponsorship really means. And I think one of the things I mentioned in my talk, or one of the things that, you know, I think makes sponsorship programs rather than mentoring or coaching programs very powerful is that there is a disparity between the amount of sponsorship that women receive in the workplace compared to their male peers. And it can... You know, there's been some studies that suggest that this is one of the reasons that women don't rise through the ranks of organizations as quickly because women are mentored and coached.

They are, you know, generally speaking, presumed to need help rather than being trusted to do something that they haven't done before. And so I think like when I had this awareness that this is something that happens and this is a pattern. Oh, my God, I saw it everywhere. My female colleagues having to fight, fight, fight for every promotion, for every new responsibility, for every new opportunity. And then some like and then like our male peers just getting a little tap on the shoulder, just like a little just, "This job's yours now." No, fighting, no discussion, no push from their side. Just a natural elevation to a higher level role. And so, yes, getting a bit passionate about this now, but once you start to see it, you see it everywhere. And as a woman I can see that it's impacted my career. You know, I've always been ambitious, I've always been quite a strong leader, I've always been quite opinionated. And it's amazing to look at my trajectory compared to, you know, like my male peers who started their career at the same time as me and so I want to be part of the solution.

There's no good me sat here complaining. I think the solution comes from awareness that this is a bias that impacts women and minorities in the workplace and actively pushing against that, putting things in place to ensure that, you know, women have opportunities to take and people and support and the framework to make sure that they can leverage those opportunities. And then for me as a manager, by making sure that I can be a sponsor to those folks in my team who maybe haven't received as much sponsorship in their career up until then. You know, you might have someone quite junior join your team. And once you get to know them, you think, "Well, why on earth are you at that level?" I've had this happen to me. Why are you at that level? You are so ready for the next thing.

But, you know, like you have to understand that they might not have been managed as effectively in the past, they might not have had the opportunities to prove themselves. And so then it's about, you know, correcting for the wrongs that have been done to them earlier in their career and making sure that you can create those opportunities. You know, they don't need to prove themselves all over again. When they join the team, you can go like, "Okay, I trust you go." Like, and really get out of their way. You know, if someone's more than ready for that step up, you know, as a manager, it's really about getting out of their way sometimes.

Recommended talk: Insights on Leadership & Innovation • Gene Kim & Charles Humble • GOTO 2024

Promotions and Acquisitions: Insights for Managers

Charles Humble: Yes. You have a great section in the talk, which is kind of in a related area, which is around sort of money, rewards, promotions, that sort of thing. When you're thinking about rewards and promotions, what is it that you look for?

Hannah Foxwell: So, I always think you can be an absolutely incredible individual contributor, you can be an absolute subject matter expert. But I think when you start to look at promotion within those individual contributor levels, what I look for as a manager is I look for impact. If you are a subject matter expert, and you do not share your knowledge, you do not collaborate, you do not support your teammates around you to improve, then really you're not ready to be a senior or staff engineer. You know, there's a certain level you get to where it's not about me, it's about we. And so I always say, you know, your domain knowledge is amazing. But what I need to see you is, I need to see you using it. I need to see you using it to have a greater impact. And I talk about your spheres of influence, and it might start with, "I'm mentoring a new junior member of the team, and I'm bringing that person up." And that extends your impact to more than just you and your contribution. It might be that you're sharing your knowledge within the context of your team. That's fabulous.

I want to see that as like table stakes from my senior engineers. And then it goes beyond that. It's like, "Have you experimented with new practices and technologies? And can you take that knowledge to the wider engineering organization? Can you teach what you've learned? Can you help more people on that journey?" And that's when you start to when you... Those are the conversations you need to have when you're talking about maybe staff or principal level, it's about that impact that you've had beyond yourself. And so that's what I would look for. And what I always communicate very openly to my team is, you know, this is what it looks like, to get to those high levels. It's not about me. It's about we. How do you have that impact across the organization and with your colleagues? But, you know, what, pay and promotions, it's a sensitive topic. And I think, you know, it doesn't matter, like outside of engineering, generally across any job in management ever. It's about setting expectations. There's absolutely nothing like that anybody wants more than having that conversation of like, "You didn't get promoted this time," and having somebody get really upset about it because they expected a promotion.

If somebody wants a promotion, that should be an ongoing conversation about how you're going to work together to get them there. And there should be no surprises when it comes to who got the promotion and who didn't get the promotion. When those letters go out and when those announcements are made, everybody should be aligned on their expectations about what you need to see to be able to champion that promotion. And whether or not they're on track to get there. So, yes, like, that's any management role ever, I would say. Communicate the timelines, communicate the expectations, communicate whether or not that employee is on track. And like it's a much easier process than you just don't end up with disappointment, you don't end up with people feeling under appreciated either. If people feel like they're on a path to where they want to go, then everyone's happier.

Charles Humble: Yes. I've been speaking to quite a few people recently who've been going through mergers and acquisitions and are feeling high levels of anxiety. And a lot of that I think stems from this idea that we'll lose something important as a result of the merger. And I was wondering whether you had any advice perhaps on the back of your experience of being at Pivotal when VMware acquired them.

Hannah Foxwell: Absolutely. It's a really hard thing. It may be, you know, acquisitions aren't necessarily a bad thing. It may be, like sort of, you know, a great goal to even work for if you're a small business, an acquisition. But I think for employees who like things as they are, if you have a happy team, like an acquisition and an acquirer, it can feel like a threat. Like, it could feel like this outside force that's going to take everything that you love about your job away and replace it with rubbish. It's like it's made up. You know, everybody catastrophizes in these scenarios, because during an acquisition there's so much unknown. You don't know what the acquiring company is like. You've never worked there. You don't know what the people are like. You don't know how it will influence your team and your work. There's a lot of unknowns and your manager won’t have the answers because nobody has the answers.

Acquisitions are about figuring out as you go and integrating those two companies in the best possible way. And I think the knee-jerk reaction from a lot of people is like, "I'm leaving." And what I said to my team because I genuinely felt it at the time when we were acquired, was the only way I guarantee losing all of the things that I love about my work right now is by walking away. You know, the highest chance I have of maintaining and continuing to be a part of this group of people and all of the things I love about it, is by staying. And especially if you're a smaller company acquired by a bigger one, there's really no such thing as a homogenous company culture. There's really no such thing. And there wasn't at Pivotal, there hasn't been at any company I've worked at. Like, teams they've built their own culture and their own values. And like as long as your team understands that nobody can actually take that away.

Nobody can take that away because you're still here as a group of people and your team's culture is what you make it, then I think people can feel a little bit easier. I mean, it's never easy like I said, because there's so much unknown and people have different levels of comfort with the unknown, don't they?Another thing that I do is I make space for people to voice those irrational concerns, make space for people to catastrophize a little bit, you know, help people become a little bit comfortable with like the worst case scenario as well. Like, if you write down, for me, this is the worst case scenario outcome of this acquisition. Maybe I get laid off, maybe I don't get laid off but my work changes. Like, whatever that worst case scenario is, just figure out what you would do. Like, write yourself like, "This is what I would do in that scenario."

It gives you just a little bit of a sense of control back in a situation that's outside of your control. So, yeah, those are the things I would recommend really, is just not jumping to conclusions but also like really acknowledging that your team will probably be worried, they'll probably catastrophize and helping them voice that. But also helping them, you know, make their own decisions about the benefits of staying or going, what they would do in the worst case scenarios. All of these things can add a little bit more comfort during times of uncertainty where you don't actually know what the outcome is going to be.

Charles Humble: I think that's really good advice, actually.

AI: Optimism, Realism, and Organizational Strategies

Charles Humble: I mentioned at the beginning that you've kind of recently changed focus to concentrate more on AI, which I guess is another of those things that's quite anxiety-inducing for some people, at least.

Hannah Foxwell: It's very divisive, isn't it?

Charles Humble: Absolutely. I think one of the things that's happened that's been kind of dramatic is the speed at which, from on the generative AI side of things, we've gone from having sort of nothing to having foundation models that have effectively already become commoditized and are already available to everyone or somewhere near commoditized. So, given that, and I expect this is a question you get a lot, but are you sort of more optimistic or pessimistic when it comes to thinking about AI?

Hannah Foxwell: You know what? I ask people this question as well. For me, I don't think I'm at either end of the spectrum. I like to think I'm a realist. You can't put the genie back in the bottle. These technologies and these tools are here. They're very accessible. They are not cost prohibitive. And so I'm like, I would say I am curious and a little bit excited about where we're going on this journey with generative AI right now. It feels a little bit like DevOps did maybe like, sort of 10 years ago where we sort of had these little glimpses of what the future might look like. There were some companies who were like, way ahead of the game, like real trailblazers, doing things that haven't been done before with this tech. And then there's the rest of us who are like, "Do I want that? How do I make it work in the real world? What does it mean for me?" And so like, I'm so here for the roller coaster that is going to be AI adoption. I don't think we've seen anywhere like... I don't think anyone who says that they know what the future looks like is being truthful.

I don't think any of us do. But I am looking for those little, those inspiring stories, those use cases where, you know, there's a very real problem, a problem for our businesses, a problem for our users, a problem for our people that can be solved with these technologies, which was impossible to solve, not in a cost effective way in the past. And so I'm kind of, I'm looking for those stories at the moment, and I'm looking forward to navigating this humongous change in our technology landscape as well. You know, it is, you mentioned cloud earlier. I think it is a little bit like when, you know, the big cloud providers came on the scene and everybody kind of understood that this is where the future was but didn't quite know how to get there. And I see exactly the same thing happening with AI today. It's like people are taking their current work, and they're rubbing a bit of AI on it. Like, people did with their servers in the cloud, it's like they lifted and shifted all of their data center processes and practices onto the cloud when actually, that wasn't the way to leverage the technology.

Don't send me a ticket and I'll get you a server in, like, a week's time if you have infrastructure on demand. Like, and I think we're at that stage now where people are lifting and shifting their current roles and business processes and rubbing a bit of AI on it. And I don't think that's the answer. I don't think that's where the benefits are going to be. I think it's, like, we're going to need new practices and processes to actually leverage this technology in the best way. Whether it be productivity tools or AI agents, or automation that we weren't able to do, insights that we'll be able to derive from very rapidly, you know, churning through like mountains of unstructured data. You know, these models are fantastic at that. Yeah, it was a simple question, wasn't it? Are you an optimist or a pessimist? And I'm like that, but I would say I'm a curious realist. And I'm absolutely here for this roller coaster we're about to go on.

Charles Humble: I think it's really interesting. Funny enough, I was on a webinar yesterday where we were talking about this from a sort of strategy angle. And one of the points I was making there was, and it's again, it's drawing on the sort of parallels between cloud and to some extent DevOps as well, is that in the early days of these things, there was a lot of experimentation. And so from an organizational point of view, one of the consequences of that is you have to be okay with experiments that don't work as a company. We talk a lot about psychological safety and IT as one of the aspects of that. But it's really understanding that, you know, the vast majority of experiments you run won't work or won't work in the way you think they will, but they might take you to another step.

I sort of feel with a lot of the AI stuff, we're kind of at that point where suddenly we're able to put... You know, historically, like if you went off and did a reinforcement learning project or something like that, you were talking about a multi million pound investment in multiple years to get to anything. Where, as now, you know, you've got tools that you can grab that are open source for three or for a small fee for one of the large providers. These are not the same thing, reinforcement learning and generative AI are not the same thing, but you've suddenly got the ability to put tools in people's hands. But then, from an organizational point of view, you have to be willing to let them experiment and try things out.

Hannah Foxwell: Yes. I think there's been a lot of high profile sort of AI whoopsies, haven't there? In the media where companies have rushed like gen AI solutions into production, into the hands of their users, and it's backfired. And I think, you know, actually, that experimentation and that iteration needs to be done with lots and lots of user feedback. You know, and you need to really look at whether or not you're solving the right problem for your users. And I think, you know, a lot of the hype around LLMs and things like that is, it's an exciting piece of technology, but organizations are talking about, "Where should we deploy them? Where should we do this?" It's a solution looking for a problem instead of the other way around, which is, what do our users actually want? And can we now approach... Like, can we attack some of these user problems that we weren't able to in the past? Or can we attack an old problem in a new way and make it better for our users? And I think that's a better conversation to have about generative AI and LLMs. It's, you know, how do we actually serve our customers better by using this technology?

Charles Humble: Yes, absolutely.

Recommended talk: Beyond the Hype: A Realistic Look at Large Language Models • Jodie Burchell • GOTO 2024

The Role of LLMs in Software Development and Enterprises

Charles Humble: I appreciate it's obviously very early days, but what do you think the impact of working with LLMs have in terms of the sort of shared understanding and other things that we take for granted in our sort of typical working environment as programmers?

Hannah Foxwell: I mean, there's so many dimensions to it. So, there's, I'm a software developer who's working on, like, a regular application, not an AI application. And so the influence that that will have on your career is probably one of productivity and velocity, actually. So, you know, as code generation tools become better and better and better, and they're improving all the time, your job changes a little bit. You know, the time it took you to get that first prototype working or the time it took you to do that little experiment becomes less and less and less. And I think that's exciting. It will change what your job looks like as a software developer. But, you know, I think we will really start to emphasize, I guess, you know, are we solving the right problem? Are we building the right thing?

And I think actually, that shifts a bit of pressure into the domain of product. How do we make sure we're building the right thing? Because building it, that's good. That's getting easier and easier. How do we make sure it's the right thing? And I think people who have really robust practices around product and data driven decision making, people who do A/B testing, people who are very good at user and usability testing, people who have strong UX muscles in their organizations will do well. And people who are, you know, a little bit less mature in those domains might be left behind because, you know, it doesn't matter how fast you code if you're not building the right thing. I think that's one aspect. The other aspect is the folks who are actually implementing AI, and those are new skill sets.

If you're an engineer building sort of, you know, a website, you might be expected to integrate one of these open LLMs into your solution. And so there's a whole new domain of technical skills and architectural patterns that need to evolve around that and doing it well. And I think that's for sure going to take people's careers in a different direction. Honestly, if I was... You know, it's like people who picked up and started learning Kubernetes, like five or six years ago, isn't it? Like, it did wonders for their CV, because there was a real shortage of skills. And so I think if I was looking for a way to differentiate myself in the job market right now, I'd get really good at deploying open LLMs and integrating them into your systems, because that's a skill that's going to be in very high demand.

Then there's the rest of us, like the users of the AI tools, and you don't don't necessarily have to be in a technical domain anymore to benefit from it. And I think that's a huge, huge opportunity. I would love to see... I've worked in so many enterprises that, oh my gosh, just the way the information and process traveled around the organization, across organizational silos and the amount of time it takes with all these handoffs to get things done. Easy, repeatable, like standardized tasks that I think there's definitely so much opportunity to reduce waste, especially in big organizations where there's handoffs all over the place, which could just be automated out of existence by, you know, a collection of AI agents. Like, with human supervision to make sure that they are doing the right thing and to make sure that any of the more complicated tasks are sort of bubbled up for intervention.

But that's also a huge opportunity. I don't think we've heard the last of AI agents from an enterprise perspective, to be honest. I think based on what I've seen in a lot of the big organizations I've worked with, there's enormous amounts of waste when it comes to processes that involve human handoffs. The humans and the integration layers in a lot of large organizations. And so when you put AI agents into the mix and you give them responsibility for the easy and repeatable tasks, that gets very exciting. Like, how much time is then freed up to do more important work.

Charles Humble: I think that's actually a fantastic place to wrap the conversation up. Hannah, thank you so much indeed for your time today. It's been lovely to chat to you.

Hannah Foxwell: Thank you for having me.