Welcome to the first episode of my podcast ‘Unlearning’. My guest today is Danny Barnett, Vice President of Emerging Technology Engineering at IBM Research. In his previous role, Danny was VP - Sales & Marketing Technology at IBM CIO, leading a team of 2000 software developers globally, building sales and marketing applications on every platform from IBM’s System z mainframe to Software as a Service, in an agile way. He was a Product Owner and an Architect in his earlier roles, and over his 25+ year career in tech, has seen software development from up close.
We discuss evolution of software development leadership role in today’s context. Skills needed to be effective in the role, preparation to be ready for the role, importance of delegation, ways to build capabilities to deliver successful enterprise programs at scale, and more.
Enjoy this great discussion with Danny Barnett.
Also available on Spotify & Amazon Music Podcasts
Show Notes:
[00:02:10] - [First question] - How do you define s/w development leader role in today’s context?
[00:04:41] - Top five skills a software development leader must have.
[00:09:30] - Preparation to take up Software Development leader role for the first time.
[00:13:41] - I am a techie. Is software development manager / leader role really for me?
[00:17:50] - Limited agile and technical knowledge. How can such a leader adapt?
[00:23:51] - Delegation Vs micro-management? Ways to find balance.
[00:29:36] - Managing and executing programs at enterprise scale.
[00:37:03] - How do I stay up-to-date? Resources for continuous learning.
[00:40:16] - Reading and managing against constant digital distractions.
[00:44:58] - Ideas on networking if it doesn’t come naturally to you.
Transcript:
Introduction
[00:00:05]: Jayesh: Hello all, I am Jayesh Kadam. This is my podcast called Unlearning. We are going to be talking on a diverse set of topics, like agile, software development, tech leadership. I'm very happy to welcome first guest on this podcast. Welcome, Danny. Shall we start with a brief introduction of yours, Danny?
[00:00:33]: Danny: Sure, yeah. Very happy. Well, I am honored to be the inaugural guest, the commencement speaker, if you like, of the podcast. So, hopefully it's all upwards from here on.
I am Danny Barnett. I look after, I look after the computing environment for the IBM research division. So it's something that I've been doing since the beginning of this year and it's a, it's a new venture for me. It's a new team and it's new set of challenges. I've got a long background in application development.
Last year we rolled out Salesforce, for example, to the whole of IBM. This year, it's more about building high performance computing environments, commissioning data centers, secure networking. It's it's a very different set of challenges, and I'm enjoying it enormously. So, um, but, I still retain interest in how work gets done. And, that's an enduring thing for me over the past 10 years, I would say, is this interest in how things get done. And, I think that's why we're talking.
Evolution of Software Development Leader Role
[00:01:41]: Jayesh: Thanks, thanks a lot Danny. So, today's topic, um, is very close to me, and I'm pretty sure to you as well.
The evolving nature of technical leadership, or, the software development manager or leader role, that we have in in software development or product teams. How is this evolving in today's world?
So, that's the topic, we are going to be talking about, and my first question to you is, “we are seeing, the software development world, you know, evolving at an unprecedented pace. The demand for new talent is at an all time high, and the great resignation is at a full swing. So, in this context, how how do you define the software development leader role?”
[00:02:36]: Danny: Yeah, I mean, I think it is, it is evolving. I think, uh, you know, in the past, you had kind of I mean, I've been in IT for the best part of 25 years now, and so it has been, it has kind of oscillated, I think, between people who were technical in background, and came up through the technical ranks, and then kind of almost by, you know, default, better, they kind of evolved into management and leadership, through the era when I think people thought of management as a separate profession, and so managers rather like project managers could project manage anything, managers can manage any kind of team.
Didn't necessarily have to have the same life history as the people that they were managing in terms of skills and things. I think now, um, the technical side of things is much much more back in focus and I think, you know, a good technical manager these days is a blend of a deep connection with people.
A good understanding of the business environment in which they're operating, and, a good background in the technical issues that can be brought to bear on those business, on those business problems. I think that's that's what you're looking for, in a, in a great technical leader.
And, you know, I think we have to distinguish between technical leaders who are people who might lead technical challenges, like, building an open source library. And then leaders of technical people, who, I think increasingly also had to have a technical background. But maybe don't need to do the coding any longer, but they need to have an understanding of what the issues are in technology and software, in order to do that job well.
[00:04:27]: Jayesh: Yeah, so Danny, you touched two key points there - the technical skills to understand, um, what the team could be doing, and the business understanding. So, my, my next question is, “as a Software development manager, if I have to list top five skills that the leader must have, right, to be effective leader of software development teams, what would be those five skills be?”
[00:04:59]: Danny: Well, when we, instituted agile in IBM CIO, um, back in 2015, we actually defined six skills, and I'll see if I can remember all of them.
Let's give it a go. So, the first one was to distribute work, you know, how many teams do you need, and what are they gonna do? Um, what's the constitution of those teams? The, how do you form teams themselves? Um, how do you develop the people that are in those teams? So how do you recruit, develop best talent.
Um, how do you influence and impact both the people within the teams and outside the teams, and then how do you listen, leverage, and learn from others? And I've forgotten one, which will come back to me, but you asked for five, so I remembered five, and I'll come back to the sixth, when it comes back to me.
[00:05:53]: Jayesh: Yeah.
[00:05:54]: Danny: Yeah, I think those, you know, the important thing about this is the, you know, is the distributing work, forming teams, you know, and sending them on the right path to be a successful. And, that has changed a lot.
I think, um, uh, you know, you hear a lot from people, who don't know a lot about software engineering. You hear a number of analogies that are not quite right. So you'll hear a lot of focus on individuals. Um, you know, this person is really great, is the person we have to go to get this problem solved, etc. Good software engineering is done in teams. Yes, it may have some very bright individuals in it, but the team will always outsmart the smartest person.
Um, the other thing I think is, that you have to be very focused on outcomes. Um, what is it that you're trying to achieve and really being, uh, you know, masterful about that. Um, and then, you know, the distribution of work, I think there's a lot of literature that started coming out recently. That's building on, you know, come with, which says that software is a reflection of the organization that builds it.
And so, the notion, so how you form teams, is absolutely an act of software design. I think it's not that obvious to people, that, that's the case.
But, hey, if you build a team full of developers, you'll get software that works. I'm sure of that. But, it probably won't look that good. It probably ‘d be quite buggy. Um, and it may be misaligned to, what business actually needs.
If you fill a team entirely by the user researchers and UI designers, and maybe only one developer you get software that looks beautiful, but it's probably not very, um, you know, high performance and stuff like that. Probably fine for a prototype. You need a good blend of skills, I think, in order to be able to build a good team, that's going to produce great work.
So, kind of key skills I would look at.
[00:08:16]: Jayesh: Yeah, that's quite insightful Danny. Like, I was reading somewhere, that if you want to trace back any problem, uh, that you want to see with, or, explore with a software development team, check how the team is set up. Right? And that could give a lot of insights into some of the root causes of the problems, you'll see.
[00:08:39]: Danny: Right, right. You know, increasingly we're trying to build teams, you know, we pay lip service to cross-functional teams. You know, we, that's been an agile mantra is that you have cross-functional, end-to-end teams, and things like that very clearly.
And, even when I was running a software team, so at scale, very rarely do we have truly cross-functional, end-to-end teams. That you're trying to minimize hand-offs partly. So, that the teams can work quickly, and you can get flow through the teams. But, mostly, you're trying to do it so that you've got a good diverse set of skills.
Eyes looking at the problem from different backgrounds and different trainings. Um, that's going to give you a much better answer than, you know, everybody in the same discipline.
Preparation to take up S/w Development Leader role
[00:09:27]: Jayesh: Sure, so so my next question is, and this I get from several, uh, experienced software developers. They have had say, close to 10 years of experience. They have been in various software roles. They've grown into say, a technical lead role. May have even performed a scrum master role in today's agile way of working. Yeah. And now are looking at a potential software development manager or leader role um, and the question they have is, how do I be better prepared to take up a role?
[00:10:06]: Danny: Right. So I spent a lot of time thinking about the art of management, because I'm starting a new role, and so, it's a chance to reset because not everything that worked in your last job is going to work in a new job.
And there were always things that you could have done better in your last job that, you know, it's like, joining a new school, you know, it's like, nobody knows that you were the naughty boy in the last call, and you can now be a good scholar in the new school and stuff.
So I spend a lot of time actually over, you know, during the change of we're thinking about this and I think, it's the part of delegation, I think it's the idea of delegation, even as a technical leader. If you're really in a leadership position, it's about developing other people.
At least a part of it is about developing other people and leadership is about achieving through other people. Um, so bringing out the best in other people to be able to achieve a goal and that involves, I think, one of the things that people miss about delegation is that they think it's just handing off work. So, here I am, I've got a task that needs to be done.
“Hey, Jayesh, this would be a great thing for you to, you know, the growth opportunity for you, or I know you're capable of this but, you know, can you go? Here's the stuff. I think what we have to remember about delegation is that it's an act of trust. Most of us just hand off the work, and then come back and see whether it's been done properly, and then come back, and see whether it's been done properly. And then come back and see whether it's been … properly, and then complain that it's not done yet.”
You have to hand-off the task, and the accountability, and the responsibility when you delegate work, and trust that, it will be done. Well, you know, obviously you want to check in on progress. But mostly what you should be checking in on is whether anything is blocking the team. So if you are not good at delegating, you are not gonna be a great manager and you can be a manager in name, but you won't be a leader. In fact, if you're not delegating and really thinking hard about what it means to delegate.
And it does mean, you know, it's trusting people to make their own mistakes, but they'll make their own peculiar interesting mistakes that you wouldn't have made yourself, because you've made your own interesting, peculiar mistakes in your past career.
But unless you're good at this, both as a technical leader, and as a leader of technical teams or technical people, you will really struggle, I think. So, if you're thinking about how you're preparing, yes, you may not be in the leadership role, right? At the moment. But are you mentoring the right people? Are you giving them the right tasks as you break down a particular project? Are you letting people make mistakes and then celebrating, you know, sometimes the mistakes, because you learn more from mistakes than you do from success. There's another of those truisms that you hear. But, what we don't say, when we say, oh, you know, you learn more from mistakes than than than you do from from success. We don't say well, that entails that you better make a lot of mistakes. So, most people are not happy with that half of the equation.
I am a techie. Is S/w Development Manager role for me?
[00:13:38]: Jayesh: Yes, that's, uh, quite true. Danny. Um, another question that I get a lot is, um, I am a techie, and I'm not sure if this software development leader or manager role is for me. Would I lose my technical skills?
I don't, I may not have people skills to take up that role. So, how do, how does one answer that question?
[00:14:08]: Danny: Well, I think if you love what you do, you should strive to do more of of that, I think. Sometimes, I think we, in large technical companies, one, at a company like IBM, for example, one of the big advantages there is, is that you can be technical from the day you join to the day you retire. Um, you know, you can have long, very successful, technical career with lots of change, and lots of challenges that are different across different areas.
And, there are many technical companies that will allow you to do that. And if that's what you really enjoy, and you ‘re happy doing that, then you should stick at it, and just get better at it. That's what I would give people as career advice. I think you need to look at your motivations.
If you don't have much people management experience that is a, it's a skill. It's a skill like knowing how to code Python or, you know, configure a Linux server. It's a skill that you acquire through practice. Um, and because the practice involves people, a lot of it is very frustrating, and painful, can be joyful too.
But, you need to be sure, that you're going to get the same kind of, amount of joy out of seeing somebody get promoted, or get their next job, or whatever it is, that you would get from debugging a particularly gnarly python problem. So, if you think you have that motivation, then people management is a career in which you could thrive.
Now, when you use your technical skills, you'll lose some of them. You'll lose some of them. Because, if you were coding for 40 hours a week, and now, even if you say, coding for 20 hours a week, and you're coaching people for 20 hours a week, and you, you should be coaching people for more than that, yes, you're going to lose some skills.
You're not going to be on top of the nitty gritty of, you know, how to build a software engineering package, but you're gaining other skills and you will also, as you elevate in the organization, you get more, you get more information flows from a higher level.
And, that's important because it puts, it gives you a broader context in which to make decisions. And some of those decisions will be technical decisions. And, so you will see that the team toiling away, building their own library is not probably the best thing to do when when you talk to your colleagues at high level in the organization, you can find that there's actually a library that's already been built, maybe they should be using that, and so on.
So you will lose, you will lose some technical skills. I think what you will gain is, is your gain a more architectural view, which is technical in itself, but you're getting a more architectural view of how the team operates, and how the output that they produce fits into a, larger technical strategy. So, yeah, but I think, really understanding why you want to become a manager is important, and I think some people get pushed into it because, you know, manager leaves oh, who's the next person on the ...
Yeah, Danny looks like he's, everybody gets on with Danny. Let's put him in that position. That's not a good reason. That's not a good recruitment. And it might be that Danny was perfectly happy being, you know, a programmer or an architect, or a business analyst, or a user interface person.
Limited agile and technical knowledge. How can such a leader adapt?
[00:17:48]: Jayesh: Yeah, so Danny, the next part is, um, talking about experienced software development managers or leaders. Now, this is the generation, you know, 20+years of experience, uh, some of it as, uh, software developers, but largely managers, when the manager role kind of came to them, as you said, by default, uh, and, uh, quite a few of them I see have an approach where, um, they are not technical completely. And, then their job mainly is of coordination, a bit of HR or people management, um, and they may not be in touch with how the role is evolving. Um, how can they adapt given the changing demands of the role?
[00:18:48]: Danny: Uh, well, I think, we we saw this a lot with the adoption of agile. I think we had a lot of, um, software engineering leaders who had worked in different environments, much more kind of waterfall type approaches. And, um, they've done those kind of waterfall approach is when they were developers or project managers or whatever they did beforehand.
But, um, having your team changed to being, you know, uh, agile and you not having any experience of that, um, is a bad situation to be. I mean, if you change, if your team changed completely, uh, the technology platform that they were working on, and you had no idea what it was I think these, you would struggle. I would say to you, go back, and, go back and learn what it is that your team is doing. You need to understand what your team is doing because ultimately you're accountable for the output from that team. If you can't understand what they're doing. It's a complete black box here.
You were an accountant, and now you're in charge of a software engineering team. That's not gonna work in the modern world. That's not going to work. You could have got away with it 10 years ago. I don't think you can get away with it any longer. Um, and I think the same thing applies to how the team works. So, if you've not worked in an agile environment, and most of when we introduced agile to IBM, most, you know, we had about 2000 managers, or something like.
None of whom had really worked in that environment, and so they had not, had the experience of what a fully empowered, end-to-end, cross-functional team really can achieve, and the joy of actually working in that environment. And, I think one of the things that we did do very consciously in the area that you and I worked in was, was to try to get those people into an environment where were applying agile principles, the work, the output was not necessary software, but the output might be, you know, some managerial artifact, like a salary plan or, um, uh, or a training program for agile. If you remember the ‘Brilliant at the basics’ program that we had.
That was, I think the looking back on that, I think, you know, had strengths, and it had weaknesses. But the biggest strength that it had was that it forced all of our leaders to practice in an agile way. We set it up in scrums. You know, we had backlogs, we have people, you know, as product owners leading those backlogs.
The leaders themselves had to teach many of the practices that they were asking their teams to follow. And that was an enormous, uh, that was an enormous learning exercise for them. But it was structured in a way that mirrored the agile software development processes that you see in an agile team, and you can do that.
I did that very rigorously with my previous team, is that, I had two-week backlogs. We would define a backlog. We had a capacity. It wasn't very sophisticated. You know, our capacity was on in general, we got seven or eight things done every two weeks.
And, so we didn’t bother story pointing or anything like that but we just said, you know, on average, we would have seven or eight things that we could get done. You know, there might be, uh, you know, the salary round, or there might be performance report appraisals, or something like that. And we worked our way through it, you know, we set up a backlog for the whole of the year.
Um, every, every quarter or so, and revised it. Um, and it, it was a good way of managers in really very managerial roles to to practice agile techniques. And we rotated the role of the scrum master. We had a JIRA board. Um, you know, we do, we didn't.
There were no, we actually assessed ourselves against all of the other practices that the software engineering teams were doing as well. So, how well did we do a retrospective and well, did we do you know, Sprint planning, etc.? Answer was not terribly, but, you know, we were making the effort and trying to live in that environment. And I think that was quite differentiating for, for many of us.
You have to do the stuff, you have to do the stuff that your team is doing. If you are very distant from that, then I think you are going to suffer. People who are very distant from what their teams do would not agree with me but, you know, you're asking my opinion.
[00:23:28]: Jayesh: No, I, I agree with you Danny. Like the, if teams are following agile way of working, and if they are software engineering teams, then a leader, uh, must have a better understanding of what does it really mean to be an agile team? And how do we really inculcate the engineering culture in the team.
[00:23:50]: Danny: Right, right. Exactly.
Delegation Vs micro-management? Ways to find balance.
[00:23:52]: Jayesh: Coming back to the topic of delegation, because that's a topic that, you know, comes up a lot. Um, in many of the org set-ups, the accountability kind of is pushed to the software development manager or leader, that if something goes wrong, you know, then the person to catch neck of, is this software development manager.
Now, uh, we have seen two sides of it. There are managers who delegate everything to their teams, and at times struggle, and then, there are managers because they have this accountability overhang, um, on their head, micro manage. Um, so, so how do you, build a balance between delegation and micro-management?
[00:24:45]: Danny: Well, I mean, it it is situational. So, so, if you, um, you know, there's quite a lot of management literature on this. I mean, if you have a very young team you're going to have to, be very in the weeds with them. If you have a new team, you're going to have to spend time with them, in order to kind of establish the roles and the expectations and things like that.
So, I think you'd have to look at the situation, but I would say, um, on reflection, the more you can delegate, the more people will grow, and the more space you will have to grow.
I mean, I've, I've told this story a couple of times, but I think it's, I think it's kind of revealing. I rang up my old boss. Couple of friends and I were kind of like laughing, that, you know, we rang up our old boss now, and he was always free.
And, um, we used to say, you've got a very senior job. You know, don’t you have more things to do than just answer the phone when we ring.
And he said, look at my level in the organization, you know, the decisions that I make are big decisions, and I can only make maybe two of those a week. Um, and it takes me about five to ten hours of preparation for each of those decisions. And so I'm in meetings for that.
So, you know, that sounds like, you know, for most of that sounds like, oh, you know, that four hour work week. That's kind of, there's a book about a four hour work week. Um, but the rest of the time, actually, he is working. But what he's doing is, he's talking to people. So, when I pick up the phone and we talk about what's going on and all the rest of it, what he's doing is, he's gathering intelligence. He's getting the information from, and he has a huge network of people across the whole of the industry, and across the whole of the world. So, he's getting information and intelligence that allows him to make decisions in the right context. So, and as a result of that, he, in order to free up that time, he has to push everything down.
So, what you find is, is that each of his leaders underneath him is also extremely capable, because they are taking on a part of his role, because he's pushing that down so that he can play this much more strategic, thoughtful role at the top of the organization, but because, you know, we all copy what's successful in our in, you know, in our immediate examples, and so they push things down as well, so their teams are growing.
So the more it's hard to do, and the situations will pull against it, but you have to push things to the next level. So you have to push work that you that you might feel inclined because of experience or skill, or whatever it is, um, to hold on to, especially when you're newly promoted manager, it's very easy to hold on to the things that got you. That, you know, I was a great developer I should do all the code reviews, it's like, no, that's not your job any longer.
You need to let go of what got you there and develop the skills that will get you to the next level. And, so I'm more and more of the opinion that if you are in the weeds of micromanaging, if you are talking about the work, and you're not delegating it, you're doing the wrong thing and maybe the right thing in the situation. But, but, the long term, it's the wrong thing, and you need to be thinking about how you change the current situation. So you can get it back to the right model.
And I think, I think, that goes for technical leadership. I think it goes for people leadership and I think it gives everybody a chance to grow.
[00:28:41]: Jayesh: Okay, thanks Danny. About, uh, the delegation is an art at end of the day. It needs to be practiced, uh, to really become better at it.
[00:28:51]: Danny: Right, yes, but delegation is not abrogation of responsibility.
When things go… we used to have this joke that, you know, praise rises up and blame goes down. But it, but that's a very bad organization, that operates like that. What you really want is, is the praise goes down and blame comes up. You know, when something goes wrong in one of the teams, I'm on the hook for that, and I should be the one, on bent knee, apologizing, not the teams themselves. They can apologize to me, but but from an outside point of the organization, that's my failure.
Managing and executing programs at enterprise scale
[00:29:35]: Jayesh: True. Um, now, coming to another challenge that I see with software development leaders. As the responsibility increases, at times, and the way organizations are structured, you know, this, there are matrix structures, there are large enterprise programs in almost all organizations and, uh, the software development managers kind of struggle to scale, and think at enterprise level when they're running their programs. Um, this is even more critical when you have multiple teams working on the same product, or platform, or program. And, if those teams are from different departments, then it becomes even more challenging. So, how do leaders prepare themselves to get better at managing such a scale.
[00:30:31]: Danny: Well, it is a hard problem, and it's a problem that the industry is spending a lot of time and energy, and paper writing about it. So, um, that's quite a good joke that Jonathan Smart makes, which is, you know, how to scale agile? The answer is - don't.
And actually, that's the heart of a lot of these, you know, scaled agile methodologies is actually what you're trying to do is, you're trying to break the work down. And, so this is why distributing work is one of the key arts of, uh, a technology leader is being able to break it down into parts that are kind of meaningful for the teams themselves, meaningful in terms of outcomes.
So that, they're not just, you know, some kind of, uh, technical, nice to have, if you like sitting in a corner, you know, kind of clockwork toy. That's great. But, then has the outcomes that are measurable? And, the team can be accountable to real users of those pieces of, uh, those products of their work.
It's hard to do and you have to keep at it. And most programs that I've seen, have not really thought about that terribly hard. They've not really thought about. If they've thought about the things that they need to get done, and they tend to put organizational structures in place, program management offices and all the rest of it, and things but they don't think about the charter for each individual team. Um, and how those component pieces will then reassembled back into, um, something that's more meaningful at the enterprise level.
And it is tough, because for all the methodologies and all the consulting groups in all the world, um, each of those projects is different. You know, the Salesforce that we deployed in IBM last year is very different from the Salesforce PWC delivered, you know, the year before that. And it is very different from the Salesforce themselves use. Um, every context is different. Every.
You know, we did a CRM SaaS rollout just 18 months before we did the full Salesforce rollout, and that was different again. The context was different. The people were different, the goals of the organization were different. So, every one of these large projects is different, and there is not a cookie cutter.
Um, so not spending the time doing the hard work thinking about it, is, you're gonna be doing the hard work thinking about what went wrong, rather than the hard work about how you can, how you can build this out in a way that's kind of meaningful for people, but all levels in the organization, that is fine for people at all levels in the organization, that delivers real outcomes for the business itself. Um, and I think because most of us only get to do five or six of these really major projects, um, over the course of, uh, you know, parts of our career, we don't get terribly good at it.
Um, it is the honest answer. We don't get terribly good at it. So each of them has the challenges. Um, a lot of the luck that we had with the Salesforce rollout was, was that we were very time-constrained. So, there was less time for people to really get into the gnarly problems. And, we were kind of focused on the kind of a boarding exercise, which is, which is fine. I mean, I think we achieved the goal of what what we wanted to do for the organization, where we've delivered some significant benefits. At the same time, to the organization, we drove a lot of simplification, which was again if you have enough time, you'll end up with a simpler solution.
[00:34:40]: Jayesh: Yes.
[00:34:41]: Danny: That's one of the key things here, is, you can drive simplification by shortening the time-frames. Um, but you had to do that in a humane way, shorten the time-frames, expect the teams to deliver still complicated solutions, and expect to keep people.
But, um, yeah, I think the truth is, is that that you have to spend some time up front thinking about this, and that is kind of a little bit anti-agile, because agile has a very strong bias for action. Let's get in and see what happens. Big programs do need a period of reflection and thought before you get going on.
Like, you know, people will often make comparisons with software startups. Um, but what people see from the software startups is, is they see the, you know, huge amount of energy and the many iterations that are coming out, and the pivots, and all the rest of it, and things, but what they forget is that there was a long period before.
That when people were having the idea about what the startup would do, who they would need to have on the team, what would be successful how long they would, you know, how much cash they needed in order to make it through the next six months and things like that. Now, they may not have spent years and years and years doing it. Like, some enterprises would do, but they did spend, you know, 2 or 3 months at least doing that.
Big enterprise programs, you know, deserve the same type of reflection as that. Um, yeah, so, you know, Slack, I think took kind of over eighteen months or something to, to pivot into being Slack before, or whatever it was before that.
[00:36:21]: Jayesh: Yes.You you mentioned a key point, Danny. Like, ability to think ahead and ability to, uh, bring all the different components together as an outcome for for the business, is a key part of managing programs at scale.
[00:36:23]: Danny: Yeah, yeah, I think so. Yeah, but there is no magic sauce to this. And, as I say, recognizing that each one of these will be different is important. I think we tend to look at consultancy kind of patterns and methodologies and think that they provide answers. My experience is they don't.
How do I stay up-to-date? Resources for continuous learning.
[00:37:03]: Jayesh: Now, coming towards, a bit of a self development of software development leaders. Right? So, uh, one question that I get from some of the new software development managers is, um, how do I stay up-to-date? How do I, um, stay on, um, the journey of continuous learning? So, what could be some of those resources for continuous learning?
[00:37:33]: Danny: Well, I think you have to be out in the world, and talking to people outside your immediate team. I think it's a bit. I'm not a terribly sporty person. I know you love cricket and things, but, um, but I'm not a terribly sporty person. But, the more I look at what coaches do for sports teams, um, the more I think that's analogous to the role that the software manager does.
And, coaches don't play the game. They observe the game. They don't run on the pitch or, you know, and, tell people to hold the bat straight or, you know, bowl from this particular angle, or whatever it is.
And things they don't do, that they watch the game, they observe, and then they watch their competitors. That's a big part of what they do. Um, and they talk to other coaches they talk to the field, they talked about teams, they talk to other people, and they, they gain intelligence from a broader spectrum as possible. And so, um, that's that's a key part of of the role. So, talking to people is the most useful way of doing this, because you can ask questions.
Second, most useful. What is there for me personally? I go to lots of meetups. Um, I like getting out, and they serve free beer and pizza, but I like free beer and pizza. Um, but I also, like, just listening to other people talking about their experiences, and I get to ask a few questions, and I get to meet other people who are practitioners in the field and those things.
I think that's, we've lost a little bit of that. I think, in the last two years, ‘cause none of us could do that, and the digital forums that replaced in-person meet-ups where we're a poor facsimile I think, of that experience still got information flowing, but it's not the same.
I think go to industry events, go to conferences, um, read books. I think reading reading is, um, very under-rated as a management discipline. Um, a lot of people don't seem to read books, which I find odd. Books, online articles, whatever it is, but they don't talk about the stuff that they've read, which I find odd.
Um, but, you know, maybe that's just a generational thing. Um, yeah, I think you just have to, but, but make a conscious decision to look outside.
I think make a conscious decision to look outside. It's, it's, easy to pull the nearest book on the shelf. It's harder to go to the library and find. A, another book on a different topic.
[00:40:16]: Jayesh: So, so, uh, on that topic, Danny, like, what are you reading nowadays? And, another question I have is, about reading, um, is this constant distraction due to the digital world we are in, right? A notification on your phone, or an email, or a slack message. How do you manage your attention span, given all these digital distractions?
[00:40:43]: Danny: Well, I don't, that is the simple answer. I get distracted just as much as everybody else. Um, in terms of reading I do, I do read, um, and I do enjoy reading so I've got 3 books, uh, that I'm kind of digesting at the moment.
One is Team Topologies, um, which has been kind of going the rounds at the moment. It, um, seems to be in vogue. And it's around, you know, what how do you form teams and what are the teams for, which is, you know, very germane to what I'm doing at the moment.
The other one is the Jonathan Smart book, which is about better, safer, happier. Uh, it's very difficult title to remember, but it's focused on what are the outcomes you are trying to achieve, which is very germane to what I'm trying to do in terms of reorienting my own focus in terms of management style.
And then the other one is the Nexus, um, scaled scrum framework. I think what I get from that book, is not so much the practices that they talk about, for kind of rolling up scrum teams work and things like that. It's just the general wisdom that's encapsulated in the book, which is lots of really useful little bits.
Information about how people behave, and why teams work in some places, and they don't work. So well, and others and things I think it's a lot of distilled, um, usefulness in that book, in terms of, you know, and planning, and things like that.
So, those are the three that I've been looking at, as the start of this year, as I've been kicking off with my new team.
And then I tried to read something that's completely different, like fiction, and I'm a member of a book club. So, I am a member of a gay man’s book club. So, every month we read a book, that's different or, you know, it's not work. Let's put it that way, and we get together and it's actually a very, it's a good book club, in the things, that the people who have read the book, and they have lots of interesting things to say about it all of which I think oh, yeah. It didn't really get that.
I think the thing about fiction is that it's about life, isn't it? So, you can't have all that, you can, you can watch, you can't go and climb a mountain and dive to the bottom of the sea and, you know, write the next great symphony, or whatever it is. You have to live some of that precariously. Fiction has a great way to live other people's lives precariously, and, you know, get experience that way. Gives you, gives you a little bit more intuition into people, I think.
[00:43:27]: Jayesh:Yeah, I, I also love fiction like, that is my go to genre. Of writing or reading, uh, to get away from, from thinking about work. So I try at least an hour to just focus on something, which is beyond work. So, you know, fiction gives you that insight a lot.
[00:43:53]: Danny: And, I think, there’s a lot of switching of context. I mean, uh, you know, I'm in a new office now, and I've discovered there's a, there's a library that's that's.. When I was doing my MBA thesis, I deliberately went to libraries, because it was kind of quiet and I would have to get on with it, and I wasn't allowed to have the phone ringing and that sort of stuff and things, and it was just a very kind of peace.
Environment, I mean, sometimes boring reading, boring management text and stuff. Um, but I found this little place that's a, there's a library in the building that I'm in, and you can sit up there and it's very quiet. It's, it's very sunlight and it has this beautiful view. So, I do get distracted, but I get distracted by, you know…
I might be writing a blog paper, or I might be writing it some instructions, and then I can look out the window and I can look at a distance. So, that thing, that opticians tell you to do, which is to look close and then look far to rest your eyes. That works for the soul as well.
Ideas on networking if it doesn’t come naturally to you.
[00:44:55]: Jayesh: Um, so, lastly, Danny, one thing, you know, that, um, many managers are kind of struggling with, especially if you are, like, an introvert kind of person outside of work, is building networks. Right? And, as as you grow in your career, it become really key in enabling right opportunities, um, having, uh, potentially even career growth opportunities. So, what are some of the steps we can recommend to uh, the, the team members, to look at building networks as a skill?
[00:45:40]: Danny: I'm terrible at this. So, so, you know, I'm, I'm really not very good at this. And, um, but I think and I have to work at it. So, I have to set aside time when I do my LinkedIn updates. I have to set aside time after I go to a conference to follow.
Go up and make connections with people. Um, but I am not a master networker by, by any means. Um, some people are just really good at it. And I think, I think for those of us, that are not good at it. You need to put time on the calendar when you say, oh, I'm going to follow up with Jayesh about, you know, how did the podcast go? Did you get any feedback on it, etc.
Anybody who wanted to talk about it. You need to think of these as tasks. I think is the is the way to do it. So, I have a to do list, and it has a series of things that I should be doing in terms of building networks on it. And, um, you know, every so often I'll pick it up and go.
Not yet and because it's not natural for me. Um, I have to make lists. Some people just very good at it but, as you say, those are probably not the introverts. So, I think for something that you don't like doing, like a chore or…
Everybody has parts of their job that they're not terribly good at. You have to a good technique for that is to put time on your calendar to say this is important, or you will keep deferring. I'm a terrible procrastinator. You'll keep deferring it unless you put time on your calendar to actually get it done.
Yep, but yes, if you're asking me, what would I prefer to do, which is, you know, take an afternoon nap or spend some time doing some networking. I would rather take an afternoon nap.
Thank you
[00:47:38]: Jayesh: Um, so, Danny, that was, uh, a set of discussion points that I had in my mind about, um, software leadership as such, and, and, um, you know, the discussion really gave a lot of insights into, not just the, the role, but, um, the mindset and thinking that needs to go in, you know, to be successful in that role.
Thanks a lot for your time. A conversation with you is, uh, in an immense source of learning for me. Um, and I'm sure through this podcast, it will be for several other people who ‘d listen to the podcast. Thanks.
[00:48:20]: Danny: Well, thank you for having me. It's been a pleasure. I really appreciate it.
[00:48:25]: Jayesh: Thank you.
Huge thanks to Aishwarya for helping with edits.
