How to Manage Software Development Teams

Managing software teams isn’t your typical management gig. In fact, it’s so different from most management gigs that I’m almost tempted to say ‘throw out everything you know’ right off the bat.

But before I get too hasty, I want to explain why managing software teams can be such an a-typical management experience. And that all starts with the nature of software development itself.

HOW SOFTWARE DEVELOPMENT AFFECTS MANAGEMENT

You’ve probably heard people refer to software development as building. 

‘We’re building a new app.’

‘I’m super excited about this new feature we’re building.’

‘We’ve been building it for 3 months!’

This makes you understand software development as an act of building. It’s logical. There are set processes. You’ve got the blueprints, you follow them, and BAM - you’ve got an app. 

Except it doesn’t work that way. In reality, you don’t build software, you grow it. 

Each project comes with its own unique difficulties and will evolve in ways you cannot predict. As you work on it, your idea of what the final product should be will change as you learn more about the features, the code, and everything else that goes into it.

There are no blueprints. There’s just the work, and watching it evolve as it grows.

This essential difference lies at the heart of why software teams are so often mismanaged. When managers fail to understand the nature of software development as growth, they make management decisions that constrict their teams and stifle their projects.

You may even be doing this right now - and you’ve never realized it.

So with that in mind - how do you take this perspective and apply it to managing teams?

Well, in terms of raw goals, you’ll always start with two:

1. Maintain a healthy cost-benefit ratio.

This should be the no. 1 priority for non-technical managers. It involves keeping the development speed consistent and managing costs (i.e. salaries). 

2. Manage risk

This is more easily overlooked by non-technical managers but is incredibly important. Why? You might end up having to rebuild the software from scratch. Or even worse, suffer a catastrophic security attack that causes you to lose everything.

Now, these two goals do imply that you’re going to want some kind of control over your project. A desire that doesn’t (seem) to lend itself to growing software as much as it does to building it. So how do you marry the two?

In order to address that I need to think about these two questions.

QUESTION 1 - DO YOU KNOW HOW TO HANDLE YOUR SINGLE BIGGEST POINT OF FAILURE?

Software engineers have a seriously tough job. They spend a lot of time alone, independently managing their time, dedicating hours to complex intellectual problems.

If that’s not a recipe for burnout I don’t know what is.

But not only that, but they’re also the single largest point of failure for the entire project. It doesn’t matter how good your idea is or how well you’ve planned - if your engineer sucks then your code will suck and your software will suck.

This is because Tech companies are less like systematized companies like say, Ford, and more like a private equity firm like JP Morgan. Ford’s systems are so strong that poor-performing mechanics scarcely affect the end product. But at JP Morgan, if the financial consultant sucks, then there’s going to be a very poor return on investment and the business will suffer.

It’s the same with software engineers. You can’t systematize your way to success, you can only rely on their individual skill. 

This might flag a few management alarms in your head. You want your engineer to avoid burnout, and you also want to make sure they don’t suck - as both will tank your project. But what can you do?

We’re going to get to that answer in a second, for now, I just want you to think about it. 

QUESTION 2 - HAVE YOU MANAGED YOUR EXPECTATIONS?

Everyone knows the legends of software development. Snapchat was built by a couple of Stanford kids in a month. Facebook was made in a Harvard dorm room. Tinder was built at a Hackathon. 

Most of these apps took no time at all and very little experience to make. And they “feel” the same today as they did back when they first released - so how hard can it be for you to make a breakout app with a simple development process?

While this sounds like it makes sense. The reality is that this line of logic is kinda like the bad guy from Iron Man.

Easy development stories like Snapchat, Tinder, and Facebook aren’t the rule. They’re the exception. 

A simple software engineering process isn't a guarantee. A complicated process pretty much is. This is because, in the tech field, things that seem similar may be very difficult to achieve when you actually do the research. 

In development, you see this mistake happening all the time. Managers think that because a program was built on C++ that it can also be built the exact same way on Python. But in reality, what seems like a minor change (C++ to Python) equates to a huge difference and a much, much longer development time.

To illustrate this point, think about it this way: traveling 10,000 miles sideways on the Earth costs you only a plane ticket. Traveling 10,000 miles upwards from the Earth requires you to build NASA. Amputating a limb is easy. Locating and removing a single cancer cell is next to impossible. The list goes on and on.

It’s the same way with software. This is why you can’t impose expectations on a project. Especially ones based on anecdotal evidence. You have to do your research, and you have to be realistic about what you want to achieve.

In software development, it’s never simple.

When you aren’t managing your expectations, it’s easy to become hyper-focused on deadlines, and following pre-established ‘plans’ of how long the software should take to develop. But for reasons I’ll get into later, you don’t want to do that.

So what can you do?

Answer: manage yourself first

These two questions should lead you to one conclusion:

Before you even think about how you’re going to manage your employees, you must manage yourself first.

As the manager,you have to empathize with the reality of the engineer and find ways to help them thrive. More often than not, this comes down to hiring well and trusting their ability. Stifling your employees with micromanagement is never a good idea, but certainly not with your engineers.

Likewise, as the manager, youhave to manage your expectations. Software isn’t built, it’s grown, so it’s very difficult to pre-plan all the unique problems you’ll have to solve and force all the different directions the project is going to go in. All you can do is help to guide it as it goes along.

But once you’ve managed yourself, there are some key approaches you should employ.

HOW TO MANAGE SOFTWARE DEVELOPMENT TEAMS

The aphorism ‘a rising tide lifts all boats’ is a pretty apt description of the Tech industry right now. Because of the industry's growth, even poor players are going to see some level of success. This might sound like a good thing, but not necessarily. As the wave of growth is very good at hiding flaws.

In management, these flaws generally orbit around two core mistakes: poor communication with mismanaged inefficiencies, and a focus on control. 

Which leads me to the two key management rules you’ve got to get right:

1. Focus on communication. It gives you a competitive edge. 

Communication is the most important thing you can get right as a manager. Why? Because most software development teams do not communicate well. Which creates massive problems.

But … It’s also an opportunity to secure a competitive advantage.

The problem comes from the fact that the less transparent your communications are the more that poor-performing engineers will be concealed from you. Given that your engineers are your single largest point of failure, it is crucial that you understand how well they’re performing. 

Furthermore, most software development teams have awful communication. That includes your competitors. So even if you’re operating at 50% efficient communications, your competitors might be floating around 40%. The more you improve, the wider that gulf becomes.

This is why one of your key focuses should be moving the needle on communications as close to 100% as possible. This will make everything as transparent end to end as possible. This means even if you don’t have the greatest developers on your team, your strength in communication will keep you performing.

However, this doesn’t mean you shouldn’t accept some inefficiency. You and your team are only human after all, and it’s unlikely any development team will reach 100% - but you should always be looking for ways to improve so that your work is as transparent as possible.

As the closer you get to transparency, the more you’ll leave your competitors in your wake.

2. To Succeed, Trust is More Important than Control. 

A lot of C-suite executives, especially those from manufacturing backgrounds, think that more rules equal more control. They want every aspect of each project documented. They want to know what the engineer is doing at all times - so that they can control the minutia to ensure a positive result. 

To reiterate what I said earlier - a tech business is not a manufacturing business like Ford. It’s more like a private equity firm. At JP Morgan they don’t stifle their employees with endless systems and controls - they hire the smartest investors they can and move out of their way so they can make smart decisions with money. 

This is what you have to be like in software development. 

Your job isn’t to control. Your job is simply to ensure communications are effective enough that you can understand how well the engineer is performing or not. Other than that you move out of their way.

Provided you’ve hired well, and you can understand how well they’re performing - your job is to trust them to execute on the job they’ve been hired to do.

Anything more than that and you’re going to be facilitating burnout … which is never a good idea.

HOW TO STRUCTURE YOUR SOFTWARE DEVELOPMENT TEAM

By now you should be seeing a running theme: 

Successful software development management is about relinquishing control in the right way.

But how does that apply to team structures?

Well, you choose a development style that reflects this theme, and then a team structure that logically follows. 

As it stands, there are three development styles: 

1. Waterfall, where the development process follows sequentially towards an outcome. This process relies heavily on documentation.

2. Agile, where the development process is iterative, and solutions evolve through self-organizing teams. This approach has a heavy focus on prototyping.

3. Hybrid, a mix of the above.

Naturally, as the running theme of this article implies - I would aim for as close to an agile process as possible. This won’t be possible for every business, especially if you’re already following a hardline waterfall approach, but you’re going to be much more effective the closer to agile you get.

You then want to establish a team structure that is designed to help your team thrive, and produce a favorable outcome within an agile (or agile-esque) development style.

I recommend a structure like this:

The client team sees if what is being built is capable of being sold in the market. The development team makes the product. The research team saves the development team time by researching problems, pain points, and solutions.

This structure is built around individuals performing roles to a high degree that they are trusted to perform. Provided that communication and thereby transparency is maximized, this structure will help you ensure the best result as you go through the process of growing software.

However, I would like to stress the importance of both the test engineer and the research team.

I have seen countless c-suite executives disregard the need for testing. The logic being that ‘if the engineering work has been done properly, why would you need to test?’. Answer: because humans have blind spots, and you do the work properly by identifying. Testing is crucial for everything from creating bug-free code to aligning product-market fit.

Likewise, research is essential because problems are going to be encountered by the engineering team. These problems are going to eat time and money. By investing in R&D you help sidestep these problems before they happen by funneling effective solutions to your engineers.

WRAP UP

If you want to manage a healthy cost-benefit ratio, while also managing the risk that your product will be a dud, then it is crucial you follow a development style that reflects the nature of growing software … while also utilizing a team structure that gives you the elements of control you need.

When you can combine that with a focus on improving communications, you will create a transparent working environment where your engineers are performing and you can support them to avoid burnout.