In this episode I provide a recap of the episodes since the last recap show (episode #25). This episode is both a recap of the series since episode #25 and a good entry point for new listeners. During this episode, I'll be summarising the key takeaways - and which episodes to listen to if you want more.
Or listen at:
Published: Wed, 29 Jul 2020 14:33:34 GMT
Transcript
[00:00:38] Hello and welcome to the 50th episode of The Better ROI from Software Development podcast. In this episode, like the 25th episode, I want to recap the past 25 episodes. I want to give a brief introduction of what each episode was about and to give some common themes.
[00:00:58] In this podcast, I'm going to try something slightly different, I would usually work directly from a script. However, I feel that sometimes I come across feeling a bit flat and rehearsed. So this time I'm going to try and do it without the full script. Hopefully it improves the tone of the podcast and makes it feel more conversational. Please let me know if you've got any feedback as to whether or not the new approach works. Thank you.
[00:01:28] OK, so looking back at the last 25 episodes, a good chunk of those, the first 11 were entirely devoted to recruitment. And there's a reason for that, recruitment is probably one of the most important jobs we can do - at all, not just software development, but any part of our business. Recruitment is so crucial to get right and it's something, unfortunately, I find that so many people will actually just treat as a side task, as a a box ticking exercise. However, that individual that you're bringing into your organization could change your organization significantly. You want someone that can come in and really change your organization for the better, making a much stronger, much more competitive business in your marketplace.
[00:02:22] In the same way, recruiting the wrong person can be hugely damaging to your organization, and I've certainly seen instances of both. However, more often than not, what we end up doing is we spend a lot of money, a lot of time, a lot of effort bringing in mediocre. We bring in someone that ticks the box, "yep they do, they'll fill that seat". And that isn't what we should be doing in recruitment and certainly not in software development recruitment.
[00:02:52] Think about how much that individual could potentially change your business, and I've equated it in those episodes to thinking about how important a new potential client is - if you bring on a new customer. How important could that be to your business? And I really do think that bringing on additional staff should be thought about in the same vein. Are they going to make that materially massive difference to your business? Because they can if you get the right person. So I do spend a lot of episodes on that. There's actually nine episodes initially. Episode 26 actually gives a fair recap of those episodes - I did that before writing them. So it gives an idea of what's coming up over that series. And then there's a further two episodes at the end, episodes 35 and 36, which are bonus episodes. And I'll come back to those in a second.
[00:03:44] Given that episode 26 covers what I was going to discuss in most of those episodes ahead of time, I want recap them again here because its so much easier to go back and listen to that episode. However, what I did want to pull out was some of the key characteristics, maybe two or three from that whole series. The first one is obviously the importance, and I've already touched on that. But I also want to talk about how during the whole process, you want to be thinking about your own organizational brand. What do the development community think of you as a brand, as an organization to work for? Now, you might not think that's important, but as I go through in so many episodes, it's crucial to make sure that your company is somewhere that developers want to work. That way, you can attract the best. And it comes back to the important thing. You want to be able to attract the best. Now, if your organization is not known for being a really good employer, if it's not known for being friendly to open thinking in terms of IT, in terms of software development, that's not going to help you with your brand. That's not going to help you bring in those people. So you then have to think about, OK, what is it you would want to do, do your current staff feel as if you're the brand that they're working for? The organization is a good one to work for. And to be honest, only way you are going to do that is to ask them and find out. Now, some of that may be rather shocking to listen to, you may find that your current staff actually don't value your brand, they don't value your organization. They turn up, they do the work, they take the money. Maybe they don't feel engaged.
[00:05:33] They don't feel that they're doing the right things. They don't feel that the business is allowing them to express themselves correctly. But that's great, because if you can find that sort of information, you can address it. You can make it better, you can improve it. And it all comes back again to a culture of change. And so many of my episodes talk about an ability for the organization to change where it is, to change what it's been doing, to understand that sometimes it has to move to be better, to improve.
[00:06:04] As part of that recruitment section, there were two additional bonus episodes not originally planned. The first one; Best hire, I gave advice on the best high you could make, and that's quite simply in this day and age, when all businesses are technology businesses, it's bringing someone that has that good technology knowledge to the top table. While it's great that the entire top table educate themselves on technology, make themselves more technologically savvy. It really does help if you've got someone that's native technology driven within that organization, whether that be a CIO or CTO, but definitely someone that can be bringing those technology initiatives, be able to understand the value of that technology and why it's so important. And it really now needs to be at that top table.
[00:06:59] The second bonus episode was on feedback. And I've touched very briefly when I talked here about the organizational branding and how you're perceived in the marketplace, if you can get feedback from any source on what your organization looks like, feels like how it behaves, how it's interpreted outside of your business. That's great. Use that feedback. Use that to improve who you are, what you want, how you think about it as a marketing campaign, you're marketing to potential candidates. These hopefully are really good developers that will take your business forward and really, really make your business shine. So how do you market to those? And that's where you're looking at the feedback, you could be getting feedback from recruitment agencies, from your existing staff, from employees that come in for interview, employees that don't come in for interview, use all that information to understand why.
[00:07:53] Ok. So that covers episode 26 to 36.
[00:07:59] I had one episode then, episode 37, on over-focus on the short term, I looked at how companies have a tendency sometimes to focus on the immediate and I see this all the time, to be honest. It's not uncommon. We have short term targets. We want to hit those. We want to get those. We want to get those out the door. But we lose sight of the longer term, the longer term value. I referenced in there "The Alchemy of Growth" by the consultancy McKinsey and Company. And they talk about how you need to be looking, not just the immediate term, but also across longer term boundaries.
[00:08:35] I equated it back also to the technical debt analogy I've talked about previously, where you may choose to do something in the short term, incur a technical debt for a view that you're going to take that debt over a longer term. So you get the benefit initially, but a long term debt. However, again, the danger is here as a lot of companies are going in taking a debt without realizing it's happening or realizing why it's being done.
[00:09:04] Episode 38. This was the Covid-19 episode.
[00:09:10] It was basically just a call out to look at your remote workers. Look at your staff. Understand that suddenly a lot of people who wouldn't normally be outside the office are suddenly working from home. They could have any number of problems, whether it's just the basic technical ones in terms of not having a good desk chair, not having good Internet, not having a laptop, all those fun things to much more serious problems in terms of concerns and anxiety over their job. So I talked about making sure that we look to engage psychological safety in terms of trying to make our staff and our team and our people feel safe about where they are. I don't dispute that there's some unpalatable things you may have had to do as leaders during this time, and that includes redundancy, includes reduced hours. But keep communicating, over communicate. If anything, make sure that your people know as best they can do where you are, what you're thinking, where you're going. It alleviates so much of that stress and that worry, rather than small bits coming out from HR or from the CEO saying, "OK, we're going to do this action here". Without the descriptive narrative around that action, it's so easy for people to make up their own narrative, and that can be much more dangerous than the actual narrative that was there in the first place.
[00:10:35] So if people are making things up, the danger is that before you know it, you've got an entire business that feels the they're being put upon you, that you're sweating the workforce or that the business just is not viable.
[00:10:51] Episode 39, I talked about predictability, predictability in software development. For me, it's it's a false idol. Very often I get into conversation with project managers wanting to know exactly how long a software change will take. The honest answer is, most of the time you don't know. But they feel as if they need to provide an answer back to whoever requested the change. So you get into a guessing game, you get into a "Oh, I think it might be about this". And this isn't an uncommon thing. This is something that's been part of software development ever since I joined it 20 odd years ago. But you then get a game happening where the software developer will think of a number. The project manager will then take that number and then goes "Wow, I'll then adjust that number based on what I think". And then they get to the original stakeholder who asked for it and goes "Well, normally when I ask for a number, it's this far out. So I assume it's that". It's very difficult then for anyone to have trust or reliability in that.
[00:11:56] However, should that predictability still be important to you. The thing that's important to understanding is how quickly a team achieve things. It's a product of the team. It's not a question of just getting them to work harder, just telling them it has to be done by X. And to just get on with it doesn't necessarily make it happen. If anything, it generally makes it worse. So what I advise is break down the work, make it into small chunks, ideally give the teams less until such point as you understand exactly how much they can actually do as their natural velocity in terms of how much change they can actually do of a number of similar size changes. Say, for example, a day size change, how many of those they can achieve within a given period, say, for example, two weeks from that, you start to get an idea of how much work they could potentially get done within a longer period. And that's a known concept. The idea of building a velocity to understand how much work of a known size can get done within a known period. Again, a lot of it is going to be based on averages. This is not a perfect science and it's certainly something I actually recommend people think about strongly before they get too excited and force a lot of work that way.
[00:13:15] I then moved on to four episodes, episodes, 40 to 43, looking at hot technologies. I looked at containers, Docker, Kubernetes and Serverless and the technology that underpins them all - virtualization. These are technologies that your development team, if they're not using now, should certainly be talking to you about it in the future in terms of using some of these technologies to be able to move quicker, adapt faster and be able to give you advantages within the market.
[00:13:49] So many people are moving to these sorts of technologies that to not look at these technologies, will actually put you at a competitive disadvantage because of how slow it makes you in comparison. They really are helping teams to move faster and deliver better, and without them, you can't really expect your organization to keep pace again. Some of these things will come down to how your organizations do things. So it isn't as simple as saying "Right, start using that technology". Now you have to think about the wider impact. But certainly those four episodes are great ones. If you just want to get a feel for what those technologies are, what Container, Docker, Kubernetes and Serverless are, what they might mean to the team, how they might help the team and how they then fit into things like cloud and where they'll be going in the future.
[00:14:44] Episode 44 to 47 then touched on learning. I think most of you realize by now that learning is very important to me. I spend a considerable amount of my time making sure I keep abreast of technical changes. There's a lot of stuff happening in technology and it keeps happening. If anything, it just gets faster. It doesn't slow down. So for me, learning is one of the most critical skills a developer can have or any IT professional, for that matter, can have. Again, some of that was actually touched on in the recruitment section. So learning is important and that's important to me and I believe is important to IT. And one of the key characteristics I see for that good software developer is the ability to learn and to apply that learning. So I looked at organizational learning, I looked to individual learning, and I looked at some deliberate practices to help team learning.
[00:15:40] So at the organizational level, I come back to things like a learning culture, making sure that the organization is thinking beyond just that immediate piece. We often equate our organizations to mechanical devices, things that do things repetitively and follow a predefined pattern. It's not really true, they're closer to being living organisms. The bigger an organization gets, actually even small organizations, have so many variables in how they operate in a day to day basis that the idea of a living biological organization is so much more appropriate to how it operates.
[00:16:23] As such, thinking about an organization and making it into a learning culture organization makes so much more sense. Think about how evolution works for an organism. It will learn based on what works best. That's how evolution happens, certain traits will happen. Certain abilities will propagate because they are better for the adoption and the survival of the organism.
[00:16:51] Whereas if you compare a learning culture to a traditional blame based culture. You can soon see that one will stifle any form of growth, one will stifle any form of innovation, one will actively make people scared to engage. Whereas the other, asks people to come forward, it is allowed people to just go "Yeah, that that went wrong" and to do it properly - rather than just going after you broke it "you're fired", which doesn't help anyone.
[00:17:22] So I talked about a couple of specific meeting types within organizational learning. I talked about the Retrospective that's used in many of the agile practices, which allows a team to go back and look at what's worked well over the past period. So whether that be the last two weeks, last month, what they want to improve going forward, a series of experiments. Again, this comes back to my minimum viable product type strategy of having a hypothesis, the minimum to test it, look at the result, repeat. I also talked about the blameless postmortem, and this really does come back to when something goes wrong, you want everybody as open, as honest and capable of having real feedback and real engagement as to how do we make that better next time rather than trying to find someone to blame. We're not on a witch hunt. We're trying to find the real reason why it went wrong and how to resolve it.
[00:18:23] In terms of individual learning, I gave some advice on how to help your individuals learn. It's very much a case of; you can lead a horse to water, but you can't make it drink. You have to create the correct environment where they feel it's appropriate to learn and they've got the tools to do it and the time.
[00:18:44] So certainly for individuals, there's a lot of work there to make it learning available to them. It's then up to them if they choose to use it.
[00:18:54] I also touched on some team aspects with some deliberate practices, I talked about Code Katas, where the team can learn various practices in a safe, controlled manner, learning how to do things before they actually get there. I equate this to firefighters' the world over who will drill on how to fight a fire. They need to know how to use their equipment. They need to know how to put out fires. They need to know how to work as a team before they turn up to your burning building.
[00:19:22] I also talked about Game Days. A way of rehearsing what would happen if something goes wrong, what would happen if something broke in the middle of the night? Do you have the support processes in the people, the knowledge and the systems in place to allow someone to fix it three in the morning?
[00:19:42] It's sitting down and do an almost role play exercise to actually see how you'd cope with it, to think outside the basics of "turn it off and turn it back on again". Excellent ways of learning.
[00:19:56] In episode 48, I talked about building things right, not just building the right thing. I'm very keen on making sure that IT and software development is aligned with the business and understands the business to the point where they are the business. There isn't a blurring the lines. And I'm very much a strong believer that. However, if you look at the "Avoiding the Alignment Trap in IT" by Bain and company, they put forward strong evidence to make sure that your IT is both aligned, and effective. If it is only aligned, but not effective, then you actually fall into quite a dangerous category by their analysis. They put any company within that category of both being aligned but being ineffective as having 14 percent less growth, as having 13 percent more cost. Really not a great place to be. So certainly what you want to be thinking about is not just the alignment, but also making sure that you're using best practice. You're using good, technical, efficient ways of using IT. And again, that comes back again to that learning. It comes back to that learning culture. It comes back to an environment where it's seen as important.
[00:21:26] Episode 49, I talked about another's intent. I wanted to look at the dangers of trying to assign an individual an intent based on their actions. I'd seen this crop up in a number of places and I talk about two books specifically within the episode. We cause ourselves quite considerable damage and danger to our organizations in our conversations and our daily conversations where we are assuming the other party we are talking to has an intent based on how we've seen them behave, how we've seen them behave previously, or even if we just expect them to behave in that way. It's very much in the same category of stereotyping. It's very much assuming you know how that individual is thinking. And to be honest, very few of us do. We're not mind readers. So if you're going into a conversation and you believe that you understand what the intent of the other party is and you are making assumptions, then you are making active interactions based on that assumption, if that assumption is wrong - how much damage are you doing to both your relationship with that individual, that conversation at the time and the organization as a whole?
[00:22:39] Ok, and that brings us up to date, so what's next?
[00:22:45] In the next few episodes, I'd like to look at professionalism. IT and software development in particular don't really have proper professional qualifications in the same way, as say, a doctor or the legal profession does, or even a building architect. We could be responsible for developing quite considerably dangerous systems if we mistakenly get things wrong. And this has been a call, I think that's been going out for a while now, as to whether there should be more professionalism within specifically software development.
[00:23:19] One thing I want to look at is the Programmers Oath by "Uncle" Bob Martin. I'll use that Programmers Oath as a template to talk about what important things are. Good software developers should be thinking about how they should behave and how they should be interacting with both the end client of the work, on their teammates and everyone else that's involved in the software development process.
[00:23:49] OK, well, thank you very much for listening to Episode 50. I hope this new format worked. Certainly I won't know until I edit it down just how clean it is, but any feedback you can give me is greatly appreciated. Thank you very much. And I look forward to speaking to you again next week.