How to manage a software development team

You may be an amazing developer, but as soon as you take on a managing position in a  software development team, you also take on countless other duties that extend far beyond coding.

Becoming an excellent manager takes time, practice, and a lot of effort. This is particularly true if you’ve spent most of your career doing technical work. 

Now, in a managerial role, you’ll have to learn a new set of skills and perform new tasks. 

To help you with the whole process, in this article, we’ll share some tips on how to effectively manage your software development team.

If there’s one thing developers value, it’s being able to do their job—to code. Therefore, it’s in your best interest as their manager to remove any obstacles that prevent them from doing so.

For example, meetings are a common hindrance. 

Coding is immersive, individual work, and it can take time for developers to get into the flow of things, which can be disrupted by having to participate in meetings.

Imagine your developers have been building a new feature for an hour, and just as they’re about to solve a pesky stakeholder requirement, a surprise 10 AM session with the boss and the rest of the team yanks them away from their IDE. 

Paul Graham explains how frustrating those situations can be:

As soon as there’s a scheduled meeting, developers are often less inclined to start any complex tasks, as they’re aware they will be taken away from their work. 

As such, it’s recommended to keep all meetings with developers scheduled for one single weekday. 

That way, you provide your developers with the calm, quiet environment they work best in. 

In the same vein, try to handle everything that isn’t connected to coding—all the non-technical tasks. 

After all, your developers are great at coding, it’d be a shame for them to waste their time performing administrative tasks and writing status reports.

Those are all duties you can take on, which frees up time for your developers to focus on the coding itself. One Reddit user appreciates this type of manager, as described below:

Manager A is clearly the favored persona. 

Not only does he protect his developers from meetings, but he also trusts his developers to do the technical work and assists by handling the non-technical tasks.

That being said, there are some technical obstacles as well—bugs. 

They can severely impact the software and halt progress, which is why it’s important to report them as soon as possible, while developers still have a fresh memory of the code. 

Shake is a tool that helps remove bugs quickly. After noticing a bug, users can just shake their device, and a comprehensive bug report will be sent to the developers. Below is an example:

The bug report can contain screenshots, screen recordings, steps to reproduce, app version, logs, and more. A high level of detail helps swiftly remove any obstacles within the software.

When delegating tasks, it’s good practice to provide as much context as possible. 

By communicating the why and the what to your developers, you allow them to work much more effectively. 

For example, there might be some details you’re aware of (due to your coordination with other departments) but your developers don’t know about. This can easily lead to errors.

Let’s say management wants a chatbox that automatically translates all tickets into English. 

However, this chatbox is only available for website visitors that are already customers. In that situation, context is critical. 

Without clarifying that this feature is aimed only at existing customers, developers could notice that it doesn’t appear for some users, label it a bug, and ‘fix’ the issue so that the chat box now appears to everyone. 

Only then would they tackle the translation issue. 

Not only is this not what the stakeholder asked for, but it also wastes the developers’ time unnecessarily.

Moz software developer Maura Hubbell also touched upon this:

As a team leader, it’s vital to fully brief your team members about the project’s broader scope.

One easy way to do this is to choose a standard use case template that describes the context systematically. 

There are many use case templates available online, and there’s an example below:

This type of document defines all possible features and the wider scope. Without filling one out, developers might misunderstand the exact requirements. 

In fact, unclear requirements are among the most common reasons for extensive software reworking, and they are a direct result of a poor UX to Development transition. 

The graph below illustrates this, with the red cells representing the negative consequences of a poorly managed transition.

A quality UX to Development transition is paramount for clarifying requirements. 

It’s not enough to just send some written specifications—developers should truly understand the customers’ pain points and how the solution is supposed to solve them.

To ensure that developers have a clear understanding of what they’re supposed to achieve, it’s a good idea to organize a kickoff meeting for each new feature. 

That way, everyone will be on the same page, developers can envision the final product, ask any questions they might have, and product owners can answer them.

Your software developers will appreciate it if you behave consistently. If you promise to accomplish something by a particular deadline, your team members will count on that task being done. 

Consistency is predictable behavior, and team members appreciate knowing you can be counted on.

For example, if you decide on daily stand-up meetings—make sure the stand-ups do happen every single day. 

Emily Nicole, who is a developer, explained why she appreciates these daily meetings:

With these stand-ups, team members know there’s a set time for them to ask questions and present their progress. 

They are aware they always have a dedicated time slot to ask for help and report findings and don’t have to worry about when to communicate with their team.

What would happen if those meetings weren’t consistent? Employees might find it more challenging to give status updates, as there would be no real opportunities for it. 

Furthermore, receiving assistance would be difficult since employees wouldn’t be able to consult the entire team but would have to contact co-workers individually. 

The worst practice, however, is barging in on your team members unannounced. They won’t have time to prepare and will probably be too frazzled by your presence to explain their findings. 

A Reddit developer commented on his negative experience with this: 

Having no consistent plan for team coordination can heavily impact your developers’ productivity, as that would mean working with no clear guidelines.

It is also advisable to decide how you will use communication channels. In other words, define what type of channel warrants which type of communication.

A common practice is using instant messaging such as Slack for urgent requests, whereas e-mails are better suited for less urgent, more complicated inquiries. 

Then, if that’s what’s decided, stick to those practices. Don’t contact them asking for their PTO plans. That type of information is sensitive and requires coordination between the entire team. 

Instead, be consistent. Stick to your guidelines and only send instant messages about urgent matters. The more complicated issues should be outlined via email.

However, if you’re unsure what warrants an email and what an instant message, you can use this flowchart as a guide:

This chart helps you stay on track, and use each communication channel in accordance with what was previously decided with your team.

As part of your consistent managing style, implementing regular one-on-one meetings is not a bad idea. 

These types of meetings—between yourself and one single employee—are an easy method to connect with a team member, as you can devote your full attention to them. 

Team meetings don’t offer you the same opportunity, as you have to juggle everyone’s different requests.

A one-on-one atmosphere should be much more personal than a team meeting. Your employee should feel comfortable enough to speak up if something is bothering them. 

At that point, it’s your job to work together with them to devise a solution. One-on-one meetings facilitate frank conversations and problem-solving—and the numbers prove that. Take a look:

One-on-ones are also an excellent tactic for gathering progress reports. As a software development team leader, you’re also probably serving as a project manager. 

As such, one-on-ones are a great time to see how old tasks are coming along and what work is next on the agenda. 

By speaking with each employee individually, you’ll collect all the data you need and be able to plan out the next steps of the project in an organized fashion.

A recent Quora thread touched on this issue as well, and one software engineer highlighted how these meetings help remove information silos:

Talking to each team member individually is a great way of spotting information silos before they become a problem. 

You’ll then be able to ensure afterward that absolutely everyone on your team is fully brought up to speed, ensuring the most productive collaboration possible.

Regarding how often to host your one-on-ones, just ensure that you choose a set, pre-determined time. Whatever you do, don’t make your one-on-ones impromptu, unscheduled affairs, as that will ruin your developer’s deep work. 

Scheduled meetings, on the other hand, have the opposite effect, as developers expect them and can work around them. 

We suggest organizing a brief, 30-minute one-on-one once a week, perhaps right after a lunch break. These won’t be disruptive to your developers, as they’ll be at lunch beforehand anyway. 

These meetings will stop your team members from being overworked, and you can monitor their general task advancement. 

In addition to that, a weekly meeting could provide extra motivation for the employee.

If you need advice on how to structure the one-on-one meeting, there are plenty of templates online to guide you. Here’s one example below:

With this one-on-one template, you can construct a productive weekly meeting outline for yourself and your team members.

Another excellent practice for managing a software development team is promoting open communication and discussions. Realistically, conflict-free teams are near-nonexistent. 

And if your team is fairly complacent, ask yourself: are they all agreeing because they all have the same opinion, or is that just the path of least resistance?

Constantly saying yes isn’t actually the best idea, as it stifles constructive criticism and amicable debate. 

Therefore, there’s seldom any innovation, and employees never challenge one another. Instead, they go along with the most popular option.

Therefore, try emphasizing that team members can disagree with one another and have differing opinions. In fact, tell them they’re even allowed to clash heads with you. 

These are all good things, encouraging new ideas and quality brainstorming sessions.

A Zartis employee describes an ideal working environment:

When even the CEO is available to approach, you’ve fully developed the type of open discussion that can help software developers thrive.

To encourage this type of unrestricted communication, try hosting a regular AMA (Ask Me Anything) session. 

This is an opportunity for interested parties to ask questions about, well, anything. 

By answering company-wide questions, employees should realize that their manager is approachable and that they can always begin a discussion with you.

An example of one such executive AMA can be seen below:

By inviting such discussions, you’ll truly encourage your team to express themselves.

Finally, don’t forget that productive discussion doesn’t have to take place in real time. Quality discussions can happen asynchronously as well.

The problem with real-time communication is the working hours. 

Since most team members are only online between 9 and 5, it’s natural for employees to feel pressured to answer in that time frame, even if they haven’t fully worked out their answer.

Asynchronous communication removes that pressure. Since there’s no sense of urgency, team members can take their time and give an informed answer. 

Sahil Lavingia also recognizes the benefits of asynchronicity:

Make sure to impart to your team that you don’t need an answer to a complicated question that very day. 

Elucidate that you’d rather receive a thought-out, comprehensive opinion in two days as opposed to a split-second “Yeah, that sounds good!”

Your developers deal with tasks on the micro-level—they mostly write code. However, as their manager, you can’t limit your perspective to that narrow scope. 

You need to coordinate with your entire team, other departments, and C-level management. As such, you need to stay focused on the macro level to complete the project. 

In other words, rely on your developers to deal with the coding. Do not critique their function use or rewrite their code—trust them to do the job you’ve hired them for. 

Micromanaging their every step will only lead to resentment and frustration, as this Quora thread proves:

This user also brings up another important point. If you interfere with their work on the micro level, your developers won’t be able to make decisions without you, while you’ll be bogged down in the details your developers should be able to handle.

There are several methods for keeping the big picture in mind. Story mapping is particularly popular. 

Story mapping essentially outlines user stories in a specific chronology and then, underneath each user story, lists the individual tasks for accomplishing it. The visual explains it well:

With this type of story map, you’ll have a clear overview of the big picture and what steps will accomplish that goal.  

Furthermore, a story map provides you with a roadmap you can present to stakeholders so that everyone is fully informed about how the project is structured.

Objectives and key results—or OKRs—are another big-picture framework. 

With this system, leaders first define their team’s objectives, then determine what changes they anticipate that could quantify if these objectives are being met. 

These OKRs are a superb method for keeping track of the big picture, as you always keep your goal in mind. Jeff Gothelf is also a fan and explains their usefulness below.

With OKRs in mind, it becomes easier to align different strategies and roadmaps to ultimately work towards high-level objectives, providing a clear roadmap to achieving the company’s vision. 

As a manager, it’s essential to facilitate your team’s work as much as possible, thus increasing their productivity. 

There are several ways to do this. For example, removing blockers to your developers’ tasks while upholding consistent behavior creates a comfortable working environment.

It’s also vital to encourage open discussions among your team and organize regular one-on-ones to hear how your developers are doing. 

Finally, give them as much context as possible and continually remind them of the big picture – that’s the magic recipe for achieving project success.

Hopefully, these tips will help you become a great software development manager!