You work in the managerial staff – as a Project Manager or a Project Director, for example – and you want to know how to lead software development teams? Well, you already did something right – you’re reading this article, looking for knowledge on the topic. This means you want to know how to communicate with your more IT-oriented team members, or with an outside vendor who works on a project for you. That’s a step in the right direction. Here are a couple of other things you can do.

Find the right people for your development team

There’ll always be people in your team that just can’t grasp the tech-speak and intricacies of the software. There’ll also always be some folks who just want to be left alone and code – so-called stereotypical “code monkeys”. Most of your staff probably won’t be in any of these two camps on the fringes, but it’s important to ensure that every team member, including the outliers, is on the same page and can understand the rest. You should get to know your people (whether it’s your company’s internal development team or the folks the outsourced vendor assigned to your project). Learn who’s good at communicating and who prefers to be left alone.

You can also achieve a lot by investing in “special forces” – Lead Developers, Team Project Leaders, Delivery Managers, Business Analysts. You need people that not only are software developers but also have good leadership and soft skills which allow them to talk with other members of your staff about the things they currently work on and then translate their technical jargon into something the less technical part of the team (including you) can wrap their heads around.

There’s also something you can do yourself – try to talk issues through with particular software developers, whenever you can. Of course, you won’t understand everything, especially at first, but at least try to get their perspective. Sometimes a few minutes of conversation can save you a lot of time and money down the line. If you can fit it into your calendar, you can also attend IT webinars and conferences for beginners – to learn stuff that will allow you to better understand the problems your IT-minded employees or partners might be running into.

In the end, though, there’s probably nothing that will fit every team and circumstance – you should adjust your communication style to the people you work with.

Involve software developers early and don’t overpromise

Another good practice is involving software developers in a project early, so they can consult and help define the scale and features right from the get-go. It’s logical and should be quite obvious – people who are supposed to work on something can tell you a lot about what’s possible, what works, and what doesn’t. Some managers decide to exclude IT people from the design process in the early stages, only to find out – in the middle of the development process – that doing things the way it was initially planned isn’t necessarily the most optimal way (if it’s possible at all).

And, if – for one reason or another – developers aren’t part of the early planning, try not to overcommit or make false promises on their behalf to your business partners. That’s true for later stages of the project too. Don’t assume something can be done without consulting people who know whether it can. And if you promised something, don’t take it out on employees when it turns out that your promises can’t be fulfilled.

If something was already promised or you have to make a decision like that because of business reasons, try to be as clear and forthcoming about it with your dev team as you can. Don’t tell them “you have to do that, because I told them it would be done” – you can be sure that such a line directed towards any of the team members will not end well. You might even find a rare team member who’ll miss a deadline later out of spite (or design some other way to irritate you). Instead, inform them that it’s important for the company and ask them what can be done to achieve the goal (or at least part of it), despite the circumstances.

And once again – know your team and know how to communicate with them, or find the right people to carry the bad news. You should also make sure your people know that while you’re the one communicating with the client, you’re still part of the team and they can count on you – taking responsibility for difficult situations can help with that.

Introduce responsible project management and don’t change things on the flow

People often say “change is good”. They probably don’t work in software development. While some aspects of change – live evolving technology, for example – are indeed very good, others can be a huge issue. The biggest problem is probably specifications and expectations that change on a whim, because someone, somewhere said something during a business meeting, saw a feature in an ad, or heard of a rival company’s software.

It’s not that they can’t implement changes – they can and will. Just don’t tell them they need to change something, because they did it badly (unless they really did, of course). It’s usually better to finish open tasks/epics and then introduce updates – not the other way around.

And, finally, if you do decide to change something, at least try to explain your reasoning with arguments better than “it has to be done” or “the company wants it”. Developers work better when they really understand the business goals of the project. Frequent communication helps and often allows you to anticipate problems before they actually happen. In tough situations, you can also explain to the developer that while what he created is fine from the technical standpoint, it doesn’t fit the client’s needs – and in the end, that’s what matters. Someone the coder trusts – a PM, or maybe an analyst – should explain the problem to the coder, step by step.

Keep in mind that bugs are inevitable in software engineering

Let’s deal with the elephant in the room – every piece of software has some bugs. You can’t avoid it, there’s no point in getting angry about it, and especially in venting that anger on the team members. We’re all people and people will always make mistakes – that’s equally true for writing, gardening, production, gastronomy, and software development.

The main issues you should concentrate on are the number of bugs, their seriousness, whether they can get fixed in a reasonable time, and whether they come back once they’ve been dealt with – not the fact that they exist at all. It’s also worth noting that not everything that looks like a bug is one, and properly conducted software testing can help a lot.

Instead of looking for someone to blame, try to understand how you can help your team. Talk things through with them during a daily meeting, brainstorm ideas. Sometimes a bug really is their fault, but often it actually isn’t. Maybe they didn’t have access to the right testing environment or data? If so, provide them with what you can – it’ll often help you avoid problems like that in the future. Or maybe the client changed the specification so heavily, it pretty much turned the project on its head?

Whatever is the case, always make sure your software developers know they’re a part of a well-functioning team. An analyst can help them better understand what the client requires, a tester can check a piece of software they currently work on and point out problems before they really start complicating things, a Project Manager can help them arrange a meeting to help clear things out. Your team members should always know they’re not alone in this.

Simplify the development process

A streamlined development process helps both sides – management and employees – and there are several steps you can take to make the process more effective. For example, try to limit the number of status reports, emails to write, or Excel spreadsheets to fill out. Some of them are a necessary evil, of course – you need to know how the project progresses – but remember that each hour your developer spends on doing this stuff is an hour he’s not coding, and therefore an hour longer your app will take to be made. Frequent yet short status meetings – often used in the Agile model – are a good way to keep track of the project.

And since we’re on Agile and status meetings already, consider adopting at least some Agile methods in your workplace. They are more optimized for software development than the more traditional Waterfall model, often allowing developers to deliver working products faster and with fewer problems. It’s a bit of an oversimplification, but Agile is like working on smaller pieces of something bigger, one by one, instead of trying to tackle the whole thing all at once – it gives you more room to breathe and react when something goes wrong.

Agile isn’t the bane of project management. You don’t need to fear it, it doesn’t mean your project will be made indefinitely and devour an infinite amount of money, especially if you hire the right people, who can cooperate and get involved on a deep enough level. That’s not to say they’ll fit every situation, however. In general, the model should be adjusted to whatever job there is to be done.

At Pretius, some of our biggest clients prefer to set very specific deadlines and budgets. Working in the fixed-price model usually means going 100% Waterfall but we always, even in such cases, try to introduce some of the best Agile practices. We make sure to conduct an initial business analysis together with the client, we hold daily Scrum meetings, and we provide new versions of software on a regular basis for testing – both by us and by the client’s internal development team. And you know what? It works great.

Remember that software developers know how to do their job

Do you like it when someone tells you how to do your job? I’m assuming you don’t because pretty much no one does – including software developers. In fact, because of the complexity of the technology, it’s often even more irritating for the devs than for other people. Keeping that in mind is a good idea because mutual respect and appreciation go a long way in a workplace (and generally in life, to be honest).

One good strategy is to give people 100% of your trust right from the start, and only micromanage them when it turns out it’s actually needed. It not only helps you build good relationships with your employees but also saves you some much-needed time. In some cases it’s even better to deliver a slightly flawed product created without micromanagement than to strive for the perfect piece of software by micromanaging like crazy – this way the software developers get to learn through their mistakes and grow (and don’t hate you for constantly holding their hands).

Try to give your developers as much autonomy as you can. Don’t tell them how to carry out their tasks – only what job there is to be done.

Channel your team’s passion – people work better on stuff they like

According to the 2020 Developer Survey by Stack Overflow, 78% of software developers admit they code outside of work – they treat it as a hobby and it’s often one they’re pretty passionate about. Of course, that doesn’t mean they’ll like every task you throw at them, but it gives you a clue. People work better on stuff they love and if you can tap into that feeling, you can do some truly great things.

Just like Bartosz Zacharuk and Bartłomiej Jakowski wrote in their article on hiring software developers, it’s often a good idea to allow your employees to spend some time on side projects. When their main job can’t move forward because of reasons that are outside their control, you can give your developers something else to work on (especially if it’s your in-house team; remote vendors will take care of the devs’ free time on their own). Of course, it’s good when these projects are something you can later monetize. Also, don’t try to entertain your development team at all costs. Sometimes there’s a job that is menial, repetitive, and boring but just has to be done. Developers understand that and will do the work. But if there’s a chance for a couple of more creative tasks to do – go for it! Your development team will love you.

Don’t forget that time estimates are just that – estimates

Designing and creating software is not like putting plastic pens together. It’s a hugely complicated task in which solutions to some problems often create ten other issues no one anticipated. Because of this, you can’t always judge precisely how much time a project will take. You probably shouldn’t be too angry about that and it doesn’t necessarily mean your software developers are incompetent. Try to be understanding, at least when the delays aren’t too long, and especially when they were caused by a change in the specification that was outside the coder’s control.

You should always leave yourself some breathing room when it comes to deadlines – for example, if your developers tell you they can do something by the 6th, tell the client it can be done by the 10th. If push comes to shove, you’ll have four days to fix whatever requires it (and if not, you’ll have additional time for testing or to summarize the project with your team). A buffer like that can be a lifesaver. It’s pretty much project management 101, but nonetheless worth mentioning. If the client really needs you to meet a certain deadline, tell that to your people honestly and explain why it has to be done.

How to make sure delays will be as short and as rare as possible? By working with people who did projects like yours in the past. Do you work in finances and you want to outsource the development to a remote team? Look for someone who made software for banks or insurance companies before. Do you want a custom CRM system (for example Real Estate CRM)? Find a vendor that specializes in stuff like that. The more past experience a company has with projects like the one you want to do, the bigger is the chance that they’ll be able to assess and estimate things correctly.

A lot is possible in software development, but there are limits – know them

Managing expectations/business alignment is one of the biggest challenges in the IT industry – 13% of respondents mentioned it as the single biggest leadership challenge in the 2017 Tech Forecast Study. To put it bluntly, it’s good to understand your possibilities, but it’s equally important to know your limits.

Some of these limits come from budget constraints. If you outsource, you can avoid the biggest pitfalls by choosing your partner well and constructing the contract in a way that sets a clear budget limit – that’ll help you with one possible headache. (Also, make sure that the remote vendor will report to you regularly and inform you every time that there’s a possibility of exceeding the budget). With an in-house team, the situation can be more complicated, because often it’s actually harder to keep projects and budgets in check. Good analysis and planning beforehand are paramount here.

Other problems stem from lack of time or insufficient understanding of technology, which is why some other points in this article are so important. The main thing to take away from all of this, however, is that sometimes you just won’t be able to achieve everything you want to with a given piece of software – it may be outside the bounds of current technology or require time, money, or people you may not necessarily have in that particular moment.

Leading a software development team: Handy tips for a non-tech manager

Leading a software development team isn’t an easy task in any circumstances, but it gets a lot harder when you’re not a technical person yourself. However, as you can see, there definitely are some ideas, practices, and tools that can help you manage both the project and your team’s morale. Here’s a quick summary:

1. Invest in a good team and don’t lose your mind because of bugs – they’ll happen.
2. Get to know your software development team and find people with good soft skills and leadership skills, who can help you lead and make in-team communication more seamless.
3. Involve software developers early in the project and don’t promise your business peers something that your dev team can’t keep – that’s not good leadership nor project management
4. Avoid surprising your team members with sudden changes in the project specification. When it’s necessary, explain tough decisions honestly and using the right arguments
5. Streamline the development process, consider working in the Agile methodology or using some Agile methods
6. Don’t micromanage your team members when it’s not needed – software developers don’t like handholding
7. Set deadlines right – always find room for some margin of error
8. Channel the passion of your team members – whenever it’s possible, let them work on things they like
9. Know your limits in terms of time, workforce, and especially the budget. Don’t expect your project to be done fast, cheap and perfect at the same time.
10. A good manager should always consider the morale of his team. Build relationships with your people, find time to get to know them. It has a positive effect on the entire team and can help a lot, especially with the more introverted employees.

Do you need help with an IT project?

Development teams at Pretius are always supported by experienced project managers, and we’ve worked on projects for big companies in several different fields. Write to us at hello@pretius.com (or use the contact form below) and tell us what you need. We’ll check whether we did projects similar to yours and get back to you in 48 hours.