How to Manage a Development Team Effectively?

Want to know how to manage a development team effectively? 

This is exactly what we will answer here.

Great software development team management is about setting clear goals and removing obstacles to success. Why, then, do so many software development managers do the opposite?

You know exactly what I am talking about. We‘ve all had jobs where our managers seemed dead-set on preventing any project progress.

I remember working as a personal assistant in NYC for a prominent multimillionaire businessman, not to be named here. He asked me if I knew how to build a website for his business, a new venture he‘d started a few years prior.

“Sure! Anything to help, boss.”

The next week consisted of me attempting to build a website with my admittedly less-than-stellar coding skills. He just needed a few pages with some photos, business info, and an email form. Hardly a difficult task even for a guy like me. Except…

“Coffee!” he hollers, slamming his hand on his desk.

“OK, just a few minutes. I‘m literally in the middle of a line of code.”

“No, now.”

“…ok.”

What proceeded was a week of desperation as I tried to finish the site. Every two minutes, the phone rang, or I‘d be sent out on a truly menial errand. This guy had millions of dollars, why not just get your lunch delivered? Nope, he has a personal assistant for that.

In the end, the website was forgotten. By the time I finished coding it, he barely remembered asking for it.

Hire expert software developers for your next project

Trusted by

Get started Now

This is an extreme scenario: I, a very unskilled programmer, while he being a truly micro-managing boss. But it‘s a great tale to start with because it demonstrates the four key components of ineffective management.

In short, here‘s the difference between great managers and terrible ones:

• Great managers remove obstacles, bad managers add them.
• Great managers get interrupted, and bad managers interrupt.
• Great managers try to be clear, bad managers try to be clever.
• Great managers focus on the macro, bad managers focus on the micro.

Developing a software application requires a deep understanding of different development frameworks, programming languages, cloud infrastructure, application security, backend integrations, etc.

If you don’t have a professional team with this relevant expertise to take on the task, then submit a request for a complimentary discovery call, and one of our tech account managers who managed similar projects will contact you shortly.

The remainder of this article will go in-depth on these four concepts. By the end, you‘ll be horrified by the idea of being a bad manager. You‘ll have the right project management software and the wisdom needed to manage a software development team effectively.

How to Manage a Development Team Effectively?

Go through the following points to manage your development team:

1. Great Managers Remove Obstacles

Developers want to write code. That‘s how they do their job.

Some people call this The Lean Startup methodology, invoking phrases like Minimum Viable Product and saying the word “Iterate” over and over.

I prefer the phrase: “Write code, test code. Repeat.” That‘s five words, and it makes sense. Why get clever about it?

It is truly unfortunate that some managers pester their devs to do all kinds of non-development work. Status reports, meetings, and keeping up with email threads. These things may have their place, but they are generally wastes of time.

You hire a talented developer for a bunch of money, then have her spend 50% of her time filling out QA forms and sitting in meetings? Really? What about cutting that down to 10% and letting the dev get to the work?

Sitting in a meeting, especially a large one is the opposite of writing and testing code.

How Do I Keep Track Of My Team?

If you think the above advice is impractical, you are in “bad manager” mode. Every single time you add an obstacle to your developer‘s workflow to make your job easier, you are being bad.

It may be necessary to do some of these things. Meetings are like cigars; great to enjoy a few times a year. But it should cause you intense mental anguish to even think about interfering with the true work of writing code and then testing it.

Of course, you need a great team to do this. Lackluster devs, left to their own devices, create lackluster products.

This brings up an important sub-principle of effective management: Being a great manager amplifies your team‘s natural tendencies. If your team is excellent, they‘ll do even better with the power of effective management.

However, subpar teams often expect subpar management. They get used to being micromanaged and love to waste half a day in meetings because they feel like they are being paid to sit around. These kinds of teams may get confused or grind to a halt when they‘re left alone, which brings us to the next point:

The Pareto Principle for Effective Dev Team Management

You can use the Pareto principle, aka the 80/20 rule, in order to manage a development team effectively. Hiring is the most crucial aspect of the job. Period.

If you are in charge of managing software development teams, but not hiring, I‘m really sorry. This is a crucial thing to get right. If you have to work with bad teams, I‘d honestly recommend that you start looking for a new job immediately.

The longer you work with bad teams, the more they drag you down into bad management practices. If you can‘t trust them to do the work, you have to micromanage, and it all goes downhill from there.

The skill of hiring great teams is beyond the scope of this article, but in short:

• Great Developers Almost Always Have a Large Portfolio of Great Work.
• Great Developers Have Good Social Skills (Ignore the myth of the rude savant).
• Great Developers Charge a High Price Because They‘re in High Demand.
• Great Developers Respect and Expect Great Management.

2. Great Managers Get Interrupted

The art of great management requires significant self-awareness. You need to look past your own needs in favor of the needs of every team member under your management.

Creators of all shades and stripes need access to long periods of uninterrupted time to get their best work done. They need to sit for hours without checking email or picking up the phone.

While researching this article, I saw several “gurus” opining about how pleasant it is to simply wander around the office. One article, which I‘m really resisting the urge to call out by name, suggested that you look for people whose “heads are up” and talk to them.

What a load of crap! As an employee, have you ever been happy to have your manager notice you while you stare off into space for a minute?

As a great manager, your job is to allow yourself to be interrupted while defending your team from interruptions at all costs.

Examples of Good and Bad Interruption Methods

The extreme example helps make this principle obvious: When my boss disrupted my coding work to get him a cup of coffee at my old NYC job, he was being the worst possible manager.

Hire expert software developers for your next project

62 Expert dev teams,
1,200 top developers

350+ Businesses trusted
us since 2016

Get started now

He saved himself a two-minute walk to the coffee shop at the expense of a finished website. There were a dozen apps that would send some underpaid teenager running to his door with a coffee, just the way you like it. Why interrupt me?

This problem persists in less extreme scenarios. For example, imagine that you get a call from a client. They need to speak with the developer to clarify one of the coding requirements, and they ask you to give them his phone number.

The bad manager gives it to them, or worse yet, hollers for the developer to come to his office while the client is still on the phone. “Come over here right now! No, it can‘t wait!”

A more reasonable manager might give the client the dev‘s email, then let the developer know to keep an eye out for it.

You, the great manager, should say this: “I‘m sorry, but he‘s not available right now. No, even if it‘s important, I‘m afraid I can‘t get an immediate answer. What I can do is personally get back to you in the next 24 hours or so with an answer.”

That answer, even if it chafes the client a bit, defends the integrity of the developer‘s time. They can write code, test code, and repeat. You‘ll be able to find a non-interrupting time to discuss it with them, and they‘ll never even need to type an email. Instead, they‘ll type more code.

Are You Sure?

You might be thinking I‘m crazy right now. Why would you willingly take on all manner of interruptions instead of letting your employees handle them?

The truth is, being a great manager isn‘t about having fun. It is about getting the job done in whatever ethical way works best. Most of the time, that means being the person who has to deal with a bunch of BS.

There may be times when you truly need to interrupt a developer. If your client‘s website isn‘t working and they are losing $10,000 per minute of downtime, it‘s time to run screaming out of your office, “HELP!”

However, if such an extreme case happens often – more than once a year – you‘ve got some big problems. Whenever an interruption does arise, take time later on to rethink the situation. Look for what you could‘ve done earlier in the software development process to avoid the emergency.

In this way, you can move closer to the golden ideal of no interruptions.

3. Great Managers Try to Be Clear

Being clever is great fun. As a writer, I love nothing more than to wax poetic and show off my skills. Trust me, I‘m clever as hell. But that‘s not useful for management.

Use simple, direct language to speak your mind. I‘m not saying to be rude – don‘t be that guy who always finds a way to be “brutally honest” – but rather to focus on the listener‘s perspective while speaking.

The skill of clarity starts out by acting in a way that feels a little weird. It can come off as robotic when you‘re still learning how to do it. The idea is to say everything, including the stuff that you think is implied.

For example, when you say “I need [feature] done by first thing tomorrow morning,” what do you mean? Does the phrase “first thing” refer to 6 am or noon?

Once upon a time, I spent the time between midnight and 4 am every day practicing the drums. I‘d literally bash the drum set as hard and fast as I could for hours at my soundproof rehearsal space. In this situation, “first thing” would be 2 pm the next day when my bleary-eyed self finally got out of bed.

Besides, what about time zones? It‘s easy to see how a seemingly “simple” request can be remarkably unclear.

The Movie Method

In general, think about what would look cool in a movie. Then do the exact opposite of that.

In a movie, the manager starts yelling as soon as something goes wrong. “We need to do better,” she screams, slamming her fist into the table. This makes for great drama and for terrible management.

In the real world, the manager calmly explains what went wrong. The team briefly discusses how to move forward, then disperses. Later, they talk about what happened and devise a simple method to avoid letting it happen again.

In a movie, the manager says what he thinks and then hangs up without confirmation. “Hey, I‘m gonna need that new feature in the next two hours, no matter what.” Slam. The developer stares at her phone, befuddled.

In the real world, the manager offers a clear statement of what he needs, then waits to see if there are questions. This is the effective way.

Aspects of Clarity

There are a million ways that being clear can manifest in reality. Rather than running through more examples, let‘s think about this on a macro level. Always try to make explicit the following information:

• Time. When do you need it?;
• Metrics to be measured. How will you determine the success of the task?;
• Resources. What (and who) does the employee have at her disposal?;
• Requirements;
• Restrictions.

That may seem like a lot, but it‘s easier than it sounds. For example, pretend that you are approaching a deadline for an important new feature. You shoot a Slack message to your employee so that they can check it when it‘s most convenient:

“Hey, [feature] is due on Friday. Are you good for that? We‘ll be happy if it works, even if it doesn‘t look great yet. Kevin said he‘s available if you need some extra help. It is essential that the feature has [x] and [y] (let me know if there‘s a problem with either of those) – and please don‘t bother Melissa, who has her hands full as it is.”

It‘s surprisingly easy to be clear. This may seem slightly rude when expressed in text – but it‘s pretty easy to balance out clarity with being polite. If your team is made up of great developers, they‘ll be grateful for the great management.

4. Great Managers Focus on the Macro

Your developers are uniquely suited to do great work on the micro-level. It‘s their job to write the best possible code and build software from the ground up.

Hire expert software developers for your next project

Trusted by

Get started Now

Your vantage point is way worse for this task. You are managing a team, perhaps a few people, perhaps dozens. How could you do a better job of managing the micro-level needs of a piece of software?

The worst-case scenario for any developer is to have a manager walk up to them while coding and start offering micro-level input. “Hey, why are you using this function here? Haven‘t you heard of [clever BS]? I saw a great YouTube video about it, here let me show you.”

Hopefully, you’ve never been quite that bad about micromanaging, but it can happen in a variety of less obvious ways.

It could be as simple as pestering your developers to include more comments on the code or to work on features in a different order. Sure, these may be fine ideas. You may even be right about some of them.

However, the idea of giving micro-level input from your macro-level vantage point is rotten from the start.

Risks of Micromanagement

The most obvious risk of micromanagement is that you‘ll be wrong. You could be insisting that your developer do something that is not effective. How should you know? You‘re the manager, not the developer!

A less obvious risk is that you‘ll piss your team off. They may grow to resent your constant micromanaging.

I know I was not a fan of being told to go get coffee when I was trying to do important work as a personal assistant. I can‘t imagine what it feels like to be micromanaged at a higher-level job.

Even worse is what happens when your team accepts the micromanagement style. “Fine, you can micromanage,” they think. Now whenever a menial development decision has to happen, they wait for you to show up.

“Hey boss, should this text-entry box be green or blue? I remember you were still deciding about that.” Gross!

When you micromanage, you train your team to either resent you, to be terrible, or both. Don‘t make this mistake.

The Power of Trust

If you have a great team, you should trust them. You‘re probably paying quite a bit of money to work with top-notch developers. Why not let them do what they do best?

If the developer insists that her way is correct, she might just be right. Even if she‘s wrong and ends up doing it a little less efficiently, what‘s the big deal? All that matters is that the job is being done well enough.

Trying to be perfect is the enemy of getting anything done. You may very well have useful insights for micro-level decisions, but that does not justify your involvement. You get paid the manager‘s salary for a reason: to manage. Not to micro-manage.

Micromanagers earn micro salaries and create micro work. Enough said.

Ready to Manage a Development Team?

Being a great manager isn‘t about an Ivy League degree or a crazy IQ. Sure, it helps to be a genius or a socially gifted person, but you can make do with a lot less.

The key is to be aware of the real challenge of management: bravery. It‘s scary to let your team run wild, creating code that they believe will get the job done. You aren‘t there while important coding decisions are being made.

Hell, you might end up getting surprised at various points. You think the software will look one way, but instead, it‘s something else.

That feature you were excited about doesn‘t pan out quite as you‘d expected. It‘s tempting to blame the team and go back to the ineffective micro-managing ways.

Resist, resist, resist! If you hire a great team and use great management practices, you‘ll get great results almost all of the time. Of course, there will be exceptions, but these exceptions are few and far between.

To do that, you have to be brave. You‘ll have to have the courage to trust your technical team and stay in your lane. Are you up to the task?

If you need any help from experienced software developers or project managers following the best development practices, get in touch with DevTeam.Space via this quick product specification form.

Our vetted and field-expert software developers follow an AI-based agile approach while delivering market-competitive software solutions successfully. Discuss with one of our account managers in detail how your software project can be the next big hit in the user market.

Frequently Asked Questions on How to Manage a Development Team