How To Lead Through Transformation in Tech • Hannah Foxwell & Charles Humble • GOTO 2025

How To Lead Through Transformation in Tech • Hannah Foxwell & Charles Humble • GOTO 2025

Show Video

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. Thank you for having me.  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?  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. 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. 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. 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? 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? 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. 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. 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. 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.  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.  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. 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.  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. 

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.   You started talking about that transition with  the three-teams model. So, can you maybe talk   a little bit about that for our listeners? 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? 

Yes. 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. I think that's really good advice, actually.  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? 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. 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.  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.  Right. Yes. 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.

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? 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. 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.  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. I think that's really good advice, actually. 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. 

It's very divisive, isn't it? 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?  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. 

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. 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? Yes, absolutely. 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?  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. 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. Thank you for having me.

2025-01-17 04:13

Show Video

Other news

Ep. 60 - Proactive vs. Reactive IT: Mastering Strategy for Success 2025-02-11 16:46
How Infrastructure is Powering the Age of AI 2025-02-09 20:43
TECH TALK: RETRO LONGBOARDS 2025-02-09 21:56