Innovation through engineering practices

About Dr. Holly Cummins
Dr. Holly Cummins was the development practice lead for IBM Garage for Cloud, before becoming an innovation leader in IBM’s corporate strategy team. She drives innovation for companies in various industries, such as banking, catering, retail, or even nonprofit organization. She is also a Java Champion, a JavaOne Rockstar, a published author, and a regular and vivid speaker.

Read the whole episode "Driving innovation through engineering practices" (Transcript):

[Improve this transcript on Github.]

[00:00:00]
Michaela: Hello and welcome to the software engineering unlocked podcast. I’m your host, Dr. Mckayla and today I have the pleasure to talk to Dr. Holly Cummins. This episode is sponsored by IBM. IBM not only produces and sells hardware, middleware and software, but also offers hosting and consulting services. The part that is the most interesting to me, is that IBM is also an active research organization, and an enabler for innovation and transformation. One interesting business area is called the IBM garage - which focuses on accelerating digital transformation, by helping people generate innovative ideas while it also equips them with the practices, technologies and expertise needed to rapidly turn those ideas into business value.

Dr. Cummins was the development practice lead for IBM Garage for Cloud, before becoming an innovation leader in IBM’s corporate strategy team. She drives innovation for companies in various industries, such as banking, catering, retail or even nonprofit organization. She is also a Java Champion, a JavaOne Rockstar, a published author and a regular and vivid speaker. So what should I say? I'm super thrilled to have Dr. Holly Collins here with me today. Holly, welcome to the show. [00:00:56] Holly: Thank you so much. Yeah, I'm really looking forward to our chat. [00:01:00]
Michaela: Yeah, me too. I mean, your introduction was really, really long because yeah. You have so many accomplishments. It's really cool to talk with you. So how does that work? Driving innovations for organizations? Can even one person drive an innovation for a whole organization? Or do you need like, that everybody is on board. How do you. [00:01:21] Holly: I think one person can make a whole organization innovate, but one person can help create an environment where innovation flourishes. I think we've certainly all seen the opposite as well. One person, if they do it wrong, can really affect innovation across the whole organization. And I think with innovation, It's about making this sort of environment where ideas can grow and where there's the second, the logical safety for people to express ideas, but then also the organizational tolerance for risk too, to be able to invest in those ideas. But then also I think you need some methodology, or some rigor to try and manage your innovations, because I think a lot of us as well have seen innovation labs where there's all these amazing ideas and then none of them actually make it out to the door of the innovation lab. And that's fun for everybody, but it does not really move things forward. And really what you need is innovation that matters. [00:02:29]
Michaela: Yeah. . I'm currently working on a research project where we look at cultures, especially for development teams. How do they have their cultures? What makes them happy? What makes them productive? What makes them innovative and psychological safety and, you know, being able to speak up your mind. This is also important. And I conducted a couple of interviews. I also have worked in different organizations and it's just really tricky, right? I mean, it's really tricky to be in a work environment and being able to voice your opinion. And some people get really lucky, but a lot of people really struggle with that, I think. And I don't know if it's, if it's a bigger organization, I can't, can't even say like a bigger organization. It's more tricky than in, in smaller. I've been in startups. So you think, well, innovation should really flourish down. There were like brilliant people on the team, but they're are also. They take all the space, right. They're very dominant people. So then all the others conferee so much, then there are like larger organization where you can strive. Is there some recipe that you can recommend for people to, you know, follow to get more psychological safety or do you know, be, be more self-aware if others even can speak their mind or, you know, like, how does that work? [00:03:40] Holly: Yeah, that, that that's yeah. Super interesting about the startups. I I sometimes feel a disadvantage talking about culture because I've worked for IBM, my whole career. And IBM clearly is not a startup. It's about as opposite a startup as, as you can get in terms of its history. But one of the things that I like to talk about, which I think is probably quite related to your
research is the importance of fun in the workplace. And I deliberately talk about fun because it's a little bit provocative because we all have this sort of instinctive reaction that says work is a place for work. It's not a place to have fun. And so then. I think by sort of choosing something that seems counter-intuitive and then peeling away the layers to talk about why actually that fun environment is really closely correlated to a productive work environment. And I think as well, it's, it's quite closely correlated to psychological safety. And I think, you know, the psychological safety manual, certainly doesn't say let's have achieved psychological safety by, you know, installing. Ping-pong or, you know, that kind of thing, but, and it's, you know, and I think what I mean by fun as well, it's not those sort of that superficial layer of fun. It's that, that deeper thing where you feel the connection to your colleagues and you feel the work that gives you joy. [00:05:19]
Michaela: Yeah. I also saw that coming up in my own research, but also related research, right. That satisfaction, happiness and productivity. They are really concepts that are very intermingled. So engineers also having fun if they are feeling productive and productivity also means connectiveness. So a lot of developers that are interviewed, they talk about supportiveness and how they have to know that there is another person that I can just call or you know no call I know before we could walk up to them, but now we call them and they are there and they're helping us. If you're stuck, we don't feel siloed. Right. There's a friendship coming up as a concept. Right. People want friendship in their workplace and yeah. I can totally relate to that. I felt really lonely last year working as a solopreneur. And so that's also why I stepped a little bit away and was taking on more customer work again, because now I'm in teams and I'm feeling, you know, I'm talking to people more and this is really, I mean, it's also joy and yeah, so I can totally relate to that but how, how do you engage with organizations? So you are at IBM, but you got into different other organizations or is that all internally where you have like little labs that you, you know, that you try to get to flourish? [00:06:33] Holly: So my role at the moment it's somewhat internal and somewhat external. We're always working with clients, but sometimes I'm working with an IBM team who is working with a client, but in, in the garage we were, we were very outward facing client facing. And, and I think there's, there's lots of different answers for how do you engage with an organization? How do you change an organization? and the, the answer that we chose in the garage is really sort of support at the top and then making the change bottom up. So we would try and get buy-in from the senior stakeholder that the organization wanted to try working in a new way that it wanted to try bringing some of these, the psychological safety in the innovation. But then also some of the other things that we talk about a lot, like, I mean, agility is an overused word, but that, that ability to respond to change that, that tolerance for risk. But I think sometimes if if we try and make that change only at the top level, then it just ends up being as a lot of words on slides and so in. And, and there's a lot of resistance to these ideas as well because people work in the way they work for a good reason. It's not like everybody's sort of set out and said, I know we're going to make our organizational cult culture so that it, you know, crushes the spirit and destroys productivity. You know, the intention was always to, you know, to try and achieve something good. It's just that the side effects sometimes were not good. So then what we do is we work with a particular team on a particular project, and we say, we're going to, we're going to do this particular thing and we're gonna get a result and we're going to do it in this new way. And you can see that while we work in this way. Actually good things are happening, not bad things. And bringing in DevOps, for example, hasn't increased the, the odds of something bad happening. Look, we can show you it's reduced the odds of something bad happening, and look, it's actually made the process more rigorous, even though the process is also more seamless. And so if we can do it on this one project, that's maybe not super business critical, let's try and now expand it to the next project that maybe is a bit more business critical. That, that ripple I would affect because I mean, I think success is the best evidence. And so when you can do something and show the results, then that makes people much more keen to try it for themselves. [00:08:56]
Michaela: Yeah. So you are coming in and then you're working with one team. And is it only you, or is it you and the team that's working with that other team with that project? How does that work? [00:09:05] Holly: Usually we'd have a team. And I think the, sort of the, at that teamwork aspect is, is so important. I think going back a bit to what you were saying about the lockdown that even the most introverted developer, I think, you know, we, we get something out of the team and the, the effects are much better as well. So we try and have really diverse teams in terms of the skills and the disciplines of the people. So normally what we would have is we'd have a handful of developers. We'd have maybe some, some architecture support. But then we'd also have designers who are really making sure that we're focusing on. The humans using the technology rather than just look, it's a thing and it's shiny and I can install it and I can write code on it. And so I'm happy, you know, trying to sort of reel it back, but I'm glad you're having fun Holly, but how are we making life better for someone else? And, you know, what's good. You know, cause success for any software project. It's not just, I did code. Success is something better somewhere either at a business level or, you know, at a user level or that kind of thing. So on, on our side, we try and have this really diverse team, but then we also want to make sure that we're co-creating with the client. So our ideal is that they're bringing their developers along. They're bringing their architects along. They're bringing their designers along as well. And then they're bringing a product owner because they're the one who owns the vision for what we're trying to do. And then that means that as well as making the thing we're doing a skills transfer. And so I when I was first working in the garage, one of our, the the IBM sellers who we were working with got a bit grumpy because the, the sort of model that they had done was that we would do a thing and then they would sell training for the thing. And because we were co-creating that training just sort of happened on, on the job and it didn't slow anything down. So we would be pair programming and that knowledge transfer would happen. And it would happen in both ways as well. So we, we know things about the garage
method that we can share. We know things about test-driven development, DevOps, but then, you know, they're going to know things. Or organizational context to say, ah, yes. When you want to do this, you need to tell, talk to Bob on the second floor. And so having the person who knows that pairing with you means that you don't sort of have to go through this elaborate process of I'm stuck. Who do I talk to you? And then, you know, try and figure it out. And they know things about their, their business domain as well. And you know, the sort of the, some of these problems are really quite specific and niche. And, you know, you couldn't have just a general consultant go in and solve it without doing that co-creation. [00:11:48]
Michaela: Yeah. And how long are those engagements normally until there is some transformation and some knowledge transfer, how long does it take for the thing?
[00:11:56] Holly: I think the sweet spot is about six weeks, so that's, that's long enough to do something that's really meaningful to get an MVP, but it's short enough. That an organization will feel okay with the risk. Cause, you know, if we, if we sort of say, and, and, and as well, you want to make sure that at the end of it, those results are going out and are really visible. So having that short cycle and then say, okay, and if we've done it once and you like it now, let's do it again because. You saw that result and it wasn't this sort of really protracted process where it took 12 months to see any change.
[00:12:33]
Michaela: Yeah. So you were mentioning already a couple of development practices, like DevOps, test driven development, and you have been the development practice lead for IBM Garage. So. What do you think, what are some of the development practices that you recommend that really everybody should do? Is it like peer programming? You also mentioned that or code reviews. What about testing? Do you think this is crucial? Do they have to do it? Can we just do it a little bit? Or can we just skip some of those things? [00:13:04] Holly: Yeah. We sometimes have conversations about testing because. The there's a trade-off I think between doing something quickly and failing fast and getting that rapid feedback and not over-engineering while you're doing that and the enormous benefits of testing. So sometimes if we're doing something that we know is going to be throw away, and I think there's a lot of value in doing something that you know, is going to be throw away. That is that, you know, sort of lean startup methodology, maybe testing doesn't make sense. But I think in general, the, the benefits of testing are so great in terms of the quality of the code, but also automated testing is absolutely necessary to support DevOps and DevOps is really necessary now in order to support any kind of automation and efficiency and any, you know, that, that ability to do those repeated deployments and the ability to respond, to change and to manage risk. Sometimes, you know, you sort of hear these stories of something that goes wrong and then an organization doesn't have any way to make a change to fix the problem, except either to go through this lengthy process or to completely short circuit and bypass the process and, you know, have someone secure shell into the effected machine and then they change the things by hand, which is obviously not going to be particularly robust in terms of the repeatability or the safety or anything. So you sort of get this chain where you do DevOps, because I know it gives so much better results in order to do DevOps. I need to have automated testing. If I'm going to do automated testing, I want to do it with test driven development, because that gives so much better quality for the tests and it ensures the testability of the code and as well, I think one of the biggest benefits of test driven development is really to refine our understanding of the problem as well. Some people call it test driven design rather than test driven development because of that effect that when I sit down, I think we'll see, what am I really trying to do? How will I really know what I'm successful? Let me write a test for that. And usually what we look for with a test is something that we would have been looking for manually. Anyway, you know, I go to a web page and I see this, or it prints this. It's always, you know, we're always looking for some evidence. We just try and encode that, looking for the evidence in, code, which is efficient. Usually. [00:15:33]
Michaela: Yeah. So test driven development often is I see it a little bit synonym to also unit tests instead of integration tests. But now you also mentioned something like a UI test, for example. So do you have, like, do you make some distinction here and do you think one is better than the other? Do you see that there's a shift nowadays in industry? I see a shift and a little bit that, what is your perspective on that? [00:15:57] Holly: Yeah. I mean, I like to do test driven development at, at all levels. So I like to do test driven development for my integration tests. I like to do test driven development for my unit tests. I think sometimes you do get a little bit tangled where you can't have, you know, you sort of, you, you do your, you write your unit test and then it passes. And then in doing that, you've done enough that actually your integration tests is already passing. So then you're kind of catching up with your integration test a bit, but sometimes we do it the other way and we say, okay, I'm going to start with my integration tests. I'm going to get those integration test passing. And then I'm going to fill in a bit with the unit tests. But I think, like I don't think it's something that is just for one level. I think if it's an outcome that you care about and that you don't want to regress, then there should be an automated test on it. I mean, I, I'm a huge fan of contract tests as sort of an intermediate layer between the integration tests and the unit tests. Cause I think sometimes with unit tests, well, integration tests are really expensive to run in any kind of complex environment, especially once you've got 60 microservices. Good luck running the integration tests in any kind of regular way. But then with the unit tests, I think you can sometimes get the sort of abdication of responsibility where everybody owns their microservice and they run their unit tests and everything works great. And the system as a whole doesn't work. And so somebody has to care about that at some point, but then you sort of end up playing this sort of. Sort of pass the parcel of responsibility, where everybody goes more, my services working as designed. And so then an on all the problems happen at the seams. [00:17:37]
Michaela: Yeah, my PhD thesis was about plug and testing or plugging systems and how you test them. It was more or less also services, service oriented architectures at that point. Right. And it was pretty new. People were just jumping on that vegan and so on. And I said, well, you know, you were going to get a little bit into travel if you're, if it stayed the same with how we are doing testing and nowadays but you're also an expert for cloud computing. Would you say that in the cloud world, somehow testing or in general engineering practices change, is there, do we have an impact, do we? should we or can be developed in a different way, test, deploy everything. Why is it the same? [00:18:19] Holly: Yeah, I think it has to be different in order to take advantage of the cloud. So one of the things that you're almost certainly going to want to be doing on the cloud is, is that DevOps it's that more rapid deployment. And then if you are deploying rapidly and you don't actually know if your code works, then either you're going to have an enormous issue in production, or actually you're not going to be deploying rapidly, you know? So we still sometimes see these cycles where something is getting deployed to the cloud, but then there's a three week UAT phase before anything can be deployed and so then. You know, that just doesn't work. It's a waste of the cloudiness. It almost may as well be on-prem. So, so you sort of get this ripple back from, again from the dev ops, which you want to be doing to the testing to the TDD. [00:19:06]
Michaela: I also think like we had, we had very strict roles back then. Right. So we had, like operations. Yeah. The engineers, the software engineers or developers. And we had like the testers, then there was like a time. Now we have this DevOps for, you know, at one point for DevOps, I feel like every engineer was supposed to be a DevOps engineer. And and then we had like the full stack. So you're not a front-end or back-end, your full stack, your full stack from front-end to back into DevOps to everything. And now I feel people start to struggle with that concept again that if you know everything because there's so much to know that there's not a single person that can be like this end to end DevOps engineer to front-end you know, genius. You see dad, like is there, is there again do you see that there are more roles that are forming itself or a person is bringing more DevOp engineer and then more of back-end, more front-end, you know, cloud maybe, you know, even more concepts then we have here. [00:20:07] Holly: Yeah, that one's a really tough one. And I, yeah, I sometimes sort of, and I think I sometimes talk to people who, who say exactly the same as you, that, that there are too many expectations on me and actually trying to do all of these things means that not only will I not be quite as good in all of them, actually, I'm going to be pretty inadequate in all of them. And are you sure that's what you want? And so. I think there probably is, is a space for having those specialist roles. But I think part of the issue as well, sort of is there's an organizational decision about where do you, where do you put the boundaries? Because I think we probably still do want to be saying. That if you are too specialized, it creates organizational friction because it means that you risk becoming a bottleneck or, or the opposite as well that it, you know, it means that you risk not being deployed because all of a sudden, none of the projects our organization is working on, have a need for your skills. And since you only do this one thing really well. You're just going to be sat around and that's not great for us cause we're paying you and it's probably not great for you either because you're really bored. So let's try and have everybody at least be able to do a few things and let's have people really comfortable sharing their skills as well. Cause I think that comes back a bit to the pair programming and the multidisciplinary teams that maybe I'm pretty, pretty bad at front-end, but I know just enough front-end that if I'm collaborating with a front-end developer, I can bring my something else. And we're still going to do a better job than if that front-end developer was on their own. And we're going to do a way better job than if I was trying to be a front-end developer on my own. And so then you get these sort of complimentary skills in, in the pairs. [00:22:01]
Michaela: I think we are coming back again to the teams as well, or to the concept of a team. And that people are really strong as a team. Maybe they are. And there was like, I did an interview with a very senior engineer. And what he said is like, if you want to go fast, go alone. But if you want to go far, go with the team or with people. Right. And so this was indeed in one of the interviews about productivity and happiness and so on. And I think, I was also talking to Alex from FedEx and she was on my podcast. She's a testing expert. And she was also talking about these teams where you have like a person that has a strong expertise, but then this expertise somehow overlaps. Right? So you want to expand your expertise to other roles. Let's say you are a testing expert, but then you want also to understand development a little bit, then you want to understand maybe DevOps a little bit. Right? And so you're having this. These shapes that are overlapping. And then in the same team, you have a person that is very similar to what you said, right? They are front end expert. And so you're overlapping in your understanding each other quite a bit. Right. It's good. If you don't, if you're not solely responsible for everything and you can learn from each other, I think learning is also such an important concept for happiness. Do you see that, that people want to learn? [00:23:12] Holly: Yeah. A a hundred percent, I think it's, it is one of those things that motivates you at work. Isn't it? is, is that desire to learn and, and, you know, if you just do the same thing everyday, it, I mean, it's, it's awful. Isn't it? You sort of. There needs to be something coming in. And I think you're right. That, that does come back to that teaming that if you're working in a team and people have different skills than you, then you're, you're automatically going to be learning. And one of the things that I always said about pairing in particular is, you know, there's sometimes we put sort of a hierarchy on pairing doughy and we say, okay, so we've got the senior developer pairing with the junior developer and they're teaching everything they know. It always, it always goes in both ways. So as a senior developer, if I'm pairing with a junior developer, often they'll know a framework I've never heard of. And so then they'll teach me about that and they'll know keyboard shortcuts. I've never heard of. So they'll teach me about that. And so it's always that, that two way knowledge transfer in, you know, independent of your position in the hierarchy or how long you've been anywhere. [00:24:13]
Michaela: Yeah. So I hear you talk a lot about pair programming, so. I don't hear you talk about code reviews. What do you think about them? Do you do them, are they not that important? Do they compliment or do you don't need them, if you do pair programming, how do you see them? [00:24:28] Holly: So my, my, my personal take is that one of the great advantages of pair programming is that it eliminates the need for code reviews. And we sometimes talk about you know wait, isn't pair programming, more expensive. I've got two people doing the work of one person and, and, you know, there's all sorts of reasons why that's not true, but I think one of them is that otherwise you have, usually you will have a para-programming code review process at the end, otherwise, and that can be really expensive, so it can be expensive in terms of people's time, but then it can also be expensive in terms of the sort of the bottleneck and the blocker that it creates, and it can be expensive as well in terms of the, sort of the patterns that it encourages. Because if people know that when you put something in for code review, it takes three days to get it back and get it approved. You know, that's maybe a pathological case, but it's not that pathological. People aren't going to be putting things in every 10 minutes. You wait until you finished something and then you send it over and then you get this sort of spiral where the person who's doing the code review gets a mountain of code and they go, Ooh, I'm not, I'm not looking at that until I've got a bit of room in my schedule, which is three days later. And then as well, when they look at it, usually. I see a couple of things happen. One is that because it's so much work, if there's a really fundamental design problem, either it's sort of too late and they can't see it, or they do see it, but they think, oh man, you know, they've been working on this for three days. I can't go back and tell them they should have done something completely different or that they shouldn't even written any of this code. And so then the sort of the big problems don't get fixed and. But then you think, well, but I've got to show that I did the review. I've got to show that I've got some value in this process rather than just annoying them by waiting for three days. Let me find the position of the semi-colon on line 36. Let me comment on that. Then everybody knows I'm contributing. So you get this sort of bike shedding. And as you can tell, if I find the whole, the process frustrating, one of the patterns that I really encourage with the pair programming is that you rotate the pairs every day. So that gives you a much deeper code review. Cause I think otherwise you only, you get like one person's code review, but then you sort of end up where two people can be wrong just as easily as one person or two. Certainly, you know, two people can be wrong. So then on the second day, a third person comes in and then there's already sort of another built-in code review where they, in order to be able to contribute, they get walked through what was done the day before. And then they're able to say things like, oh, well, but why did we do this? And here, why don't we just try this? And it it's, you know, it's not a formal review. It's an interactive sort of getting them up to speed teaching experience, but then it means that there's this second chance to catch errors before they develop too much, but I think, I mean, I think you probably are. You're asking the question cause you, you probably have quite a lot of expertise on code reviews and you're gonna tell me all the patterns where it does work, which of course it can, then it can work well. [00:27:27]
Michaela: No, no, but I definitely recall and realize all the things that you said, because these are definitely really the common problems that I also see that teams have. Right. So this is also one of the things in my workshops, Teams come and they bring all really everything that you said, right? Like, and this whole chain of how it just doesn't work. Great. How the process doesn't work and where you, where you have this waiting time, where then the code reviews are too big, right. Or you're done, cannot understand them. You still have to do them. What do you do? Right. So this, there is definitely this, this loop that you are describing. Totally recall, because this is, you know, this is the, the problems that all the people are bringing on the table when they're coming in, when I'm working with it. Maybe what I see, I actually really like code reviews because of this asynchronous way. Right. So you can have them in a very lightweight way. I also see them complimentary a little bit to peer programming, but you definitely have to do them in a different way. Right. And I think what many organizations don't understand and why we are creating this loop of you know troublesome problems that we have, how we doing is that we don't understand the goal of why I'm doing this. Right. What do we want to get out of that? And then also, okay, what do I want to get out of that? And how can I shape the process in a way that I'm getting this out of that? Because I really see that they have all these painful drawbacks and definitely. But they also have like really wonderful benefits. So I think the most important is that you really understand. The pain points that you said very, very deeply, but then also, what can you, you know, what can you do to counteract them? How can you change your practice but, but I see, I see all the things that you say, and I'm actually a big fan of pairing as well. For me personally it's very draining to do it. Like I love it from time to time, right? Like it's the best where I feel like. You have your mentor there, or, you know, you have just this connection and the supportiveness with the people. So I totally enjoy it from time to time, but not too often. How often do you do pairing? [00:29:36] Holly: So what, what we used to do. In the, in the garage is, is we would do it pretty much all day, every day. And there was, there was a few advantages to that because I think one of the, sort of the hardest things of pairing is the logistics. And so then going back to the code reviews, you know, there's some circumstances under which pairing just will not work and makes no sense because it's, it's so synchronous and synchronous doesn't scale. So, you know, you need to have that kind of asynchronous process as well. And if you've got Particularly, you know, if it's something like Open Source where people are in different times zones and they're working different schedules and some of them are doing it in their own time, you know, something like pairing it, it, you know, it's almost off the table to, to begin with. But what we found is if we tried to be ad hoc with our pairing, which of course works quite well for a lot of teams. We sort of, we never end up doing it because it would be well let yes, let's pair today. Yeah. We definitely want a pair today. Okay. So, so maybe after lunch. Oh, I can't after lunch, I've got, you know, I've got a thing. Okay. Well we'll maybe, maybe at two o'clock. Oh, I can't. And then, you know, we, we settled that we're going to start pairing at three o'clock, but then something would come up and then somebody would be unavailable. So by sort of defaulting to pairing, we'd keep our calendars free. And it was great actually, because if we got invited to meeting. I'm afraid I can't attend this meeting. I'm pairing. So if you interrupt me, you're interrupting my hair as well and it was sort of, it was like this sort of intrusion , interruption, depend. we could block your time around that.
[00:31:00]
Michaela: We could block your time around that. A couple of organizations that we're working with and that we try something out and it looks really, really nice is that you're doing code reviews on a particular time. And then it's done by one engineer. Right. But they're doing all the others can go in and now everything is via suit, right. As are our teams and whatnot. Right. So by that video conference, and so they're doing this code review, right? Everybody that's interested can join. Right. And those sessions really, really particularly work well. I'm very surprised by that, but I really have good feedback from, from different organizations where you know, you have this casual thing where people know this is happening, right. One person really drives the review and the others can watch, ask questions, clarification questions, or, you know, other things maybe learn just have their awareness. Have you tried something like that? Is that ? [00:31:55] Holly: We've tried some similar things? Not, not exactly like that, but that, yeah, that seems, seems really good. So we did, I mean, one pattern of course is the sort of the mobbing pattern where we say, "We don't just want to do it with two people. We actually particularly for knowledge sharing, you know, we want to do it with six people.So let's all gather around the keyboard or let's all gather on the zoom", but as well, what we used to find was, again, it's that scaling, that the pattern I described, where you rotate the pairs every day in a big code base with a big team is still gonna be quite a while before you rotate round and so then you do need something else. So what we'd sometimes do is on a Friday, we'd do a show and tell session. So it was, it was very similar to what you described actually, but we'd sort of someone would say, okay, well, I've just done this particularly evil thing in this part of the code base. And nobody's gonna understand what I've done unless I talk them through it, or I've just discovered this really counter-intuitive behavior in this library. Let me show you all what it does. So you don't get called out the same way I did. So it was sort of partly a code review and then partly an education session, but it would just be really informal and just whoever had interesting code would show it and talk it through the rest of the team and then they'd ask questions and that kind of thing. [00:33:05]
Michaela: So maybe one last thing that I would like to talk a little bit with you about is because you. You actually transitioned a way, right? From, from being this development lead at the IBM Garage and now you're an innovation leader in the corporate strategy team. What does that mean? And what, what's your role there? What do you have to do? [00:33:25] Holly: So my role in corporate strategy, it's really interesting. It's because I'm sort of in the, you know, we're sort of a headquarters role, so I'm sort of in the, in the heart of IBM in, in the center of IBM and I sort of get to see a lot of what's going on and what we're trying to do is we're trying to really just be the, sort of like a free resource, both people and financial to try and when we see something amazing that can't quite happen because there's some sort of blocker or there's just, you know, it just needs a little bit of money to, to get over a starting line that we can sort of give it that, that push and then hopefully make something amazing happen so often it's where if we have a client team and you know, the client really wants to do something and we really want to do something, but just somehow it just needs a little bit of money just to demonstrate to you know the people you know, who have the large amounts of money that this is really worth doing. And, and one of the things that we do as well, because I think as an industry, we've, we've moved a lot now, too. Every, you know, we always want to be trying to do things by actually trying them out rather than doing slides. So that that's not, it was new when the team I'm part of was started. It's not, it's not new anymore, but still in a larger organization, you still sometimes get things that fall between the cracks where it doesn't quite fit in, in anybody's mission but that means it's actually extra important. So then, because, because we're sort of central, we can bridge those, those internal barriers. [00:34:59]
Michaela: And do you still have a lot to do with engineering? Do you still develop software or is it more really strategic and leading that you're doing right now? [00:35:08] Holly: It's a little bit of a mix, which I think going back to what you were talking about with the learning and the, and the variety, I think it is good. So it means that whatever, whatever seems most necessary. We'll do that. So sometimes it's actually let me go in and architect this, let me, let me go in and add a bit of code. Let me, you know, I'm not a data scientist, but some of my colleagues are data scientists and they'll okay. Let me fix your model for you. And then sometimes it's more strategic and more making those connections to say, actually, I can see that this is going on in one part of our organization and something complimentary is going on in another part of my org, let me connect those two, and then we're going to get a better outcome. [00:35:50]
Michaela: Oh, that sounds like you're really having a lot of hats. I really liked that when I was at Microsoft, also driving bit innovation there and having all these different hats, like you're, you're driving projects, but you're also doing the implementation. I was mainly prototyping at that time. But it also means that you, as you said, you have to learn a lot. Did it take it a little bit to get used to that role and know what you have to do? Do you have like mentors that help you or is it structure around some, formal mentorship program at IBM. How does that work? [00:36:23] Holly: I think, with that kind of role where, where you have a lot of hats. I think it comes back to, to the team again and the sort of the resiliency in the team. So what we tend to do, because we're doing challenging things and we don't know in advanced necessarily what skills will be required; is we, we do sort of go around in groups where there's more than one of us. And then that means that whatever hat ends up being needed, there's someone who has that hat and then someone else who can sort of shadow the hat. [00:36:53]
Michaela: Yeah. Yeah. That sounds really a great team to be in. Maybe the last thing, really the last thing and then I'll let you go is that I want to talk with you about is there's the same culture, eats, strategy for breakfast, right? So, and what it means is that: The culture is of utmost importance. But also it's a very vicious cycle that, you know, how do you get your culture to apply and how do you get your team members to, you know, like each other or at least respect each other, right. Especially if you have, so sometimes people have I also have that in my workshops when we are, you know, when we are working on these problems, that code reviews create right where we have, for example, very strong personalities in a team with very strong opinions. So it have problems, you know, like giving into. What did you hear? Do you have like do you have like some strategies for that? Do people do something to do, do some coaching or can you help can the team help itself? What's your experience with that? [00:37:53] Holly: It's, it's tricky culture, because in some ways, some things about culture, you, you can change because you can, you know, sort of start with your small changes and then success is the best evidence. And then you can roll it forward and you can make those little changes to encourage psychological safety. And you can have, if, if the leaders are bought in, then they can make some of those changes as well. But part of it then does still come down to the people in the team. And that is often the thing that is most challenging to, to change, but, but even, even people I think are, are changeable. And I think sometimes characteristics that we assume are just this person actually are the context in which we put them as an organization or habits that they'd learned that with the right environment can be unlearned. [00:38:47]
Michaela: Or team dynamics, maybe, right? One person creates or reacts, not onlyt only to that person, right, but to really the whole team (dynamics).

Are you are you a fan of like bonding sessions and you know, where people, where a team really can, you know, get to know each other, do you think thats important? [00:39:06] Holly: I really like them, but I think they, they need to be done sensitively because they do end up sometimes not being very inclusive if we ,if, if we choose something that half the team love, and then some people are sort of still there going, well, this isn't really what I wanted. So I think there sort of needs to be some, some pre-thought to, well, there's everybody in the team going to like going out to a noisy bar or does that actually not work. And I've seen I've had some good conversations with people actually, when I talk about fun, because sometimes we get these sort of bonding sessions that get put into a team and we say, right, we're going to have fun. Now we're going to, you know, do our bonding and we're going to go out to a bar and some people are going to know this, this isn't fun for me at all. But then there can be alternative. So some teams, for example, they'll play a board game at lunch. And so it means that people who need to rush home after school, you know, after work to get kids from school or that kind of thing. You know, they're, they're included and people who don't drink are included and it's in sort of at work. So then it feels like an extra nice treat. It doesn't feel like you're sort of being required as part of your job to go out and do things out of hours, which some people really object to. And so then, you know, and there's other things like, like that, or. This is a really old example because one of the other things that happened when I started talking about fun is lots of people told me about their workplaces and that the terrible unfun things that had happened. And there was a team and they were sort of there were a support organization, so they would work quite long hours and shifts. And it was a distributed team. So what they would do is after five thirty, they would all play quake or doom or something like that together. And it was sort of back in the day when broadband at home was a luxury. So you would take advantage of your office network and they were, you know, they were, it was completely you know, a bonding thing. And they were told by management, if you're in the office after five thirty, you have to be doing work, which I just thought was so incredibly short-sighted on the, on the part of the, that management to say, you know, your, your people are not on your time making the effort to get to know each other better and to work better as a team. And not only have you not, you know, encouraged this and, you know, put in money for cakes or something, you've actually told them they're not allowed to do it. [00:41:27]
Michaela: Yeah. Yeah. That's very, very shortsighted. Yeah. Terrible mistake. But sometimes I really like for management, sometimes I really ask myself. How can you make this decision, but you know, different story. Okay. Well, Holly I know we are on time, so thank you so much. I could have, you know, like talked with you another hour, but thank you so much that I could pick your brain about everything, about all your experience and you know, your knowledge that you have. Yeah. It was really wonderful that you have been on my show. Is there something that you want to share with my listeners? Did you think it's important for them maybe around culture, happiness, fun, productivity, maybe a little thing that they can start doing today? [00:42:09] Holly: I mean, I think, yeah, just to sort of think about those, those, those aspects of fun and, and think about how can I have more fun at work? How can I bring more joy, joy, and delight at work, but also how can I make sure those around me are also having more, more joy into life at work because otherwise it becomes a bit one-sided.
[00:42:29]
Michaela: Yeah, I think in general, after Corona, I call it now after COVID right. I just say after, because it's just nicer to say that but I think we really have to come back to thinking more about others. I think we haven't been thinking enough about others before, but I think, I don't know how it's in, in, you know, in the UK, but it, at least here, I feel people are more distance because of it. Right. And I really think we should think more about each other and you know, what brings others joy? How can we help others? How can we be nice to others? Right. Yeah. And I think this can bring joy again to yourself, right? If you maybe should think about how can I make the day, a little bit better for my colleague today? Or help somebody? I think this can be a cycle of positivity. I dunno. Like, yeah. [00:43:20] Holly: Yeah, absolutely. I think we realized one of the things that we realized with, with COVID is how, how much we need others and how it's, you know, it's not much fun without others. [00:43:30]
Michaela: Yeah. Yeah, exactly. I think so, too. So I hope you all can come back together and then really be nice to each other and care for each other. Yeah. Okay. So Holly, thank you so much for being on my show. Have a wonderful night and Yeah. I hope I talk to you soon again. [00:43:29] Holly: Yeah. Thank you so much. It was, it was great fun. [00:43:53] Michaela: Yeah. It was really fun. Bye, bye. [00:43:53] Holly: Bye. [00:43:54] Michaela: I hope you enjoyed another episode of the software engineering unlocked podcast. Don't forget to subscribe and I'll talk to you again in two weeks.