This is the last blog from interviews for a while now. I think up to this level is enough for us to ascertain the different jobs available, and what they involve. in the development of software engineering projects. Next week I will be moving back on to electronics and focusing on some more technical articles again. But for now, here is a worthy perspective, the software manager (SM).
ME : Well, I suppose there are many facets to your position, why not start by giving us an overview of what your job entails ?
SM: You’re right, there are many tasks I perform on a daily basis, but when looking at the position it quite often doesn’t align with those. From a top level perspective, my main responsibilities are nurturing the team, delivering product and reporting progress and road blocks, I help the team achieve their directives, and I set the directives.
ME: So why doesn’t that translate very much to what you’re doing each day then ?
SM: Well everything works on the cycle of the development, when something is being planned the tasks are very different to when a product is being finalized. So if you look at the stage we are at right now, I am micro managing key members of the team to make sure we can deliver a highly valuable product on time, and to the right level of reliability. This has been going on now for about a month, and we have another month like this. So I am not really spending any time nurturing the team, or planning the future, I guess you could say we are on the front line at the moment. This will change though, and there will be a planning phase before we start the next big development. During this time I can spend some time making sure my team is ready for the next project.
ME: So how do you cope with not being able to achieve everything you need to do all the time ?
SM: There isn’t much any manager can do to achieve perfection, you are simply dealing with what resources you have. This is always the key point in any project, how many experienced engineers do you have, and how competent are they. Not just competence as engineers actually, but also the ability to report to me accurately. Communication with the team is critical. If I know about something that is failing or needs effort applying to it, then I can target it, if it doesn’t get reported to me until it’s too late then there is very little I can do, except of course move the delivery dates, and that is something that is really a failure, unless of course things in the team have changed to cause that.
ME: So let’s take a step back here. Talk us through how a project begins and how it comes to being delivered.
SM: It’s a tried and tested model. We are given a request from our business division, they will talk to marketing who in turn study the actual market. They are looking for trends, or gaps where we can produce products and profit from those for the business. Ultimately at the company level we are reporting to shareholders, and they want to see things improving on the bottom line. So we are looking at keeping costs low, and selling products and services at high margins, simple business economics really. That comes through to me as a request for a new product for example. If it is new product I look for any resource that might have relevant experience, this will become my first line, a collection of team leads. I expect those people to really understand the objectives, and to highlight to me quickly if we are going to deviate, or not deliver any key targets. Once we have the requirements for the new product, and these could be generated internally, or they could be driven by an external customer. Then we plan what needs to be done in the first delivery. We plan it out, trimming off things we don’t really need, and then decide how much resource we need. Once it is a viable project we begin planning everything starting with the large stories or epics. Like most software development teams we follow a pragmatic agile style, tailored to our context, we are not purely Agile. As we project plan we make sure we record required effort, dependencies between tasks, potential risks etc. But as we all know, no plan survives the first contact, so we have to be capable of responding and reacting well. I really look for team leaders who can bounce back if there is a problem, and people who can think their way around problems, using unconventional means if necessary.
ME: So once the project is running, is it fun, or stressful ?
SM: It’s a challenge, and that’s why most people do this job. If you enjoy using resources in a clever organizational way, then you’ll like this job. If you see changes as bad, or unplanned events as scary then obviously this would be a nightmare for you !
ME: What kind of qualities make a good manager ?
SM: There isn’t any one size fits all here. It can depend on what you are managing. Some managers need to rule with an iron rod, they need to get quick releases out, others are trying to encourage creativity, they need unique features to beat the product competition, and yet others are trying to produce top quality, as lives may depend on it. So if you take those contexts out of it, being a good manager requires being a good listener, someone who doesn’t react, but will consider all options, someone who is versatile, hates risk, most of us are going for the boring reproducible top quality on time product, so we like things to be predictable. But deeper than that, you also need to like people I believe. This is what people do for a large proportion of their day, week and even life. You want people to come here and have some fun, sometimes. You also want to show your team you care, and make sure they are getting training. Often in the software industry training is seen as a rarity. Good managers will always prepare there staff for new technology if they expect them to be proficient in it. So I always see that as a beneficial thing for the company and also the individual.
ME: Does it help to be from a technical background ?
SM: Yes it can do, there are many engineers who really try and pull the wool over managers eyes, so it can help to understand the difference between a bad check in to a repository, and an untested, un-reviewed piece of code. We have a lot of software merges in our repository, sometimes these explode and break the build for example, and sometimes it’s the result of a bad merge, two delivered pieces that are incompatible. But sometimes it’s people breaking from the process and trying to circumvent the rules that are there to protect us all. So knowing how things work in terms of the tools your team is using can be a good thing. Likewise with the language you might be using, C++ for example has problems with memory management and leaks, C# and Java have garbage collectors. Knowing about details like that can help you understand when problems arise. But it’s not generally my job to go into details such as those.
ME: What about firing people ? Do you think it’s always a failure to have to fire someone ?
SM: That is sometimes necessary, but can also be a failure on the part of the management. When you have to let someone go, you ask yourself did you give them tasks that they couldn’t complete, did you ask too much of them etc. But quite often it’s due to a bad attitude about work in general. Some people are not willing to learn from mistakes, and some people don’t want to get out of bed, it’s life. You have to expect all your staff to go through some bad times, and you have to be patient with them, people are not machines. But if they don’t respect you or their place of work, they have to go. A bad member of staff will cause a lot of rot to spread.
ME: What about when there is a high turnover of staff, what often causes that ?
SM: Bad moral is devastating for a project, sometimes these should just be shelved and forgotten about, but often they simply can not. So if a project is late, or lots of bugs, quality issues, or the tools and process are frustrating, people leave. Bad planning is also a big cause, expecting people to work overtime and weekends when you haven’t worked out the right level of effort is a big cause for people getting fed up and leaving.When you have a sinking ship you need a lot of support from above to fix it. Most of the time, let the people go who won’t change the way they are and help out. Then keep the ones who are up for a challenge, incentivize them with some kind of reward, and get stuck in with them. This is one of those situations where living with the team will help. You have to catch all the small frustrations early on, and get them out of the way quickly, this means more work for someone in my position. But again that can be very rewarding, where everyone else has failed on a project and you walk in and you succeed.
ME: Do bonus and other incentives work ?
SM: The bonus schemes are often really a way of retaining staff who you want to keep. They do not incentivize people on a daily basis, but of course they stop key people leaving or looking for alternative employment. In most teams you have succession planning, making sure if key people leave it doesn’t cripple the project. But you try to avoid letting key people leave, and a good way to do that is to lock them in to long term investments, targets, share offers, pension contributions are all ways to attract new staff and to retain key staff.
ME: Tell us a funny anecdote about someone who worked for you.
SM: I had a DBA who spent all day sleeping at work, then worked all night at home. I felt it was bad for him long term, but the amount of trouble he got us out of when fixing issues with our high availability web services meant it it worked for him and us, so I let him get on with it. Of course we had another two DBAs with him who eventually balanced out the work, and a test plan that reduced incidents, but sometimes when things are going wrong, if it works, use it.
ME: What’s next for you ?
SM: I am really looking forward in my career, next for me would be a departmental position. I am attempting to climb my way gradually to the top. I am a true believer in people being promoted to the point where they are no longer showing signs of competence ! In other words people are promoted for doing a good job, once they stop doing that they stay at that level. You get promoted when you are doing a good job, then stay at the level you are when you are making a mess of things, so like a shark I’ve got to keep swimming. In fact that is the Peter principle (1969), people rise to the level of their incompetence. The Delbert principle on the other hand dictates that the useless continue to be promoted until they re out of harms way. I’m on the fence about which I think is more accurate of those two principles !
ME: In my experience management is like every other position, you get your star players, but mostly they are people trying to hide the fact they don’t know what they are doing. Most managers are promoted with very little training, and they tend to follow tried and tested paths, very few are real mavericks.
SM: That could be a good thing, a managers position is not really geared towards mavericks, mostly it is making sure the dull processes are followed, and the product does what it should, so straying to far from the path is a distraction.
ME: We see a lot of diversity and gender equality targets being advertised from many big industry players. Do they work ?
SM: Yes, they focus recruiters and managers on choosing a well balanced staff mix. I don’t think it helps productivity directly but it creates a more healthy, pleasant working environment. Our societies now are much more diverse, and gender and other forms of inequality are an awful and restrictive medieval mindset. Meritocracy is what should really matter, and allowing everyone to have the opportunity to prove themselves, irrespective of any differences to the people who might be running the show. So yes it is working, and yes everyone thinks it’s a positive, welcoming concept.
ME:OK thanks for that, it was very interesting. Good luck with your project.
SM: Hah, if I have to rely on luck, then I’ll be out on my ear soon, we have had zero luck on this project since it started ! But thanks for the well wishes.