You're a Bad Manager. Embrace It.
You manage developers and you'd like to think you're a good manager... but look at the evidence. Most, if not all, of your projects are late. Your team often delivers products riddled with bugs. Quite a few never ship at all. How can you be a good manager if you constantly fail? Isn't getting the job done a big part of being a good manager? Let's look at this situation.
Let's look at a few of your character traits.
When your team gives you an estimate for how long they think work will take, you always reduce it. By dropping 25 to 50 percent of the time, you like to think you're pushing your team to do their best. We all work better under a deadline, right? And sure enough, your team puts in enormous amounts of unpaid overtime... they work nights, they work weekends. You don't, but they do. In the end, if you bothered to measure it, you'd find they often spend just as many hours as they originally asked for with their first estimate.
Unfortunately, instead of writing code for all those hours when they were alert and rested, they're writing code when they're exhausted, tired, and burned out. Look around. How many of your team quit in the last five years? How much time has your company spent on retraining people? This isn't ditch digging... it's usually a very complicated product. Tired developers write really interesting bugs... and by interesting I mean difficult to find and time consuming to remove. How much of that last schedule overage was spent fixing bugs and "hardening" the system?
And on that theme, when your team delivers what you ask for in record time, what do you remember? What does the customer remember? That product was junk. It crashed. The data was wrong. It ran slow. We all remember the bad results. Try to remember all the shortcuts that were taken. Those were the shortcuts you asked for, no... demanded. The team told you how long it would take to do it right. You gave them enough time to write a junk product, and they did. Then you blamed them for it. Is that a good manager? They followed the leader, then the leader punished them for following.
To be fair, you didn't realize what you were asking though. Or is that fair? Many managers have never written code. If it's been more than 10 years, then you haven't written code in anything resembling a modern architecture either. I know you think COBOL and Ruby are similar... you're wrong.
Have you invested the time to try and understand what your team does? Do you sit in on team meetings and just listen? Only listen.
How about your team's desktop computers? Do you fight to get them the latest hardware? Why not? Let me make two things very plain. The first is that developers spend a great deal of time compiling their code and debugging their code. This process is directly related to the speed of the desktop. If your developers need 10 minutes to compile the entire system and they compile 5 to 10 times a day, you lose 50 to 100 minutes a day per developer. On a 10 man team, that's 500 to 1,000 minutes a day that you pay them to sit and watch the computer work. A week has five days... a year has 52 weeks... so at 500 to 1,000 minutes a day * 5 days * 52 weeks is 130,000 to 260,000 minutes a year. That's more than 2,000 to 4,000 hours a year. That's the equivalent of one to two additional developers on your team.
A typical developer, after you factor in benefits and the overall cost of employment, costs you from 150,000 to 200,000 dollars a year. If you have a ten person team, you can buy them extremely high end workstations for around $3,000 each. That's $30,000 a year to save two man years. Does that sound like a good investment?
Have you ever seen a team whose manager gets them this type of hardware on a regular basis? This is single biggest moral builder you do for a team of dedicated developers. These people literally live inside these machines. Make them fly and they'll love you.
By the way, how much did the company spend on last year's Christmas party? Ask the developers if they'd rather have a very nice party or a new desktops. The answer might surprise you.
When your last project tanked, who did you blame? Yourself? I doubt it. You probably let your team take the blame. It's always their fault, right? Good developers always get the work done on time, even if they don't get enough time to do the work. It's just typing, right? (That's a quote from a bad manager I once worked for.)
How about training and conferences? Do you send your teams? There are many local and regional conferences these days. Can your team members attend local conferences on company time? No? Then don't complain if they're not up to date on the latest technologies and innovations. When another company across town gets to market before you by using the latest new programming tools, it's not because your team is lazy or dumb. It's because you didn't invest in them.
Are you worried about them getting training so they can leave? Here's a secret... not many companies invest in their people. Find a way to get your team training every year and they'll never leave. Developers love attending conferences and spending time surrounded by other smart people who also want to learn. They love learning... provide an environment where they can learn and they won't leave.
Speaking of rewards, like most bad managers you reward your developers individually. You provide bonuses and raises to the top performers, and less for the middle, and none for the "low performers". Then you stand back and wonder why they don't perform as a team. Why they refuse to help each other and compete with each other.
Why don't they work together? Because you're financially motivating them to not work together! If I can make myself look good while making someone else look bad, I'm more likely to get a raise. And I don't even have to make someone else look bad. I just have to stand back and let them make mistake after mistake. I'll only smile on the inside... you'll never know I could've helped them.
Try this for the next quarter. Tell your team that everybody gets the same bonus and every gets the same raise. Tell them that if that if a team member gets left behind, no one gets anything. Financial reward your entire team when they work together and make each other successful. I think you'll be pleasantly surprised at what happens once they realize you're serious about this one.
Do you get that you're not a great manager? Don't feel too bad... there aren't many good technical managers. They're worth their weight in gold. I know managers whose teams follow them from company to company. How valuable are those managers to their companys? Do you want to be that kind of manager? In addition to the tips above, here are a few other ideas you can try.
Ask your team what they need to get a job done. Then trust them. Assume your team wants to succeed as much as you do and will move heaven and earth to win. If they say they need three months, don't budge. Get them three months. If outside influences (other managers or customers) insist on a shorter deadline, then you insist that some features have to come out of the release. If you fight to get your team the time they need to deliver great software, they'll rise to meet your expectation.
As an aside, if you want to gut your team's morale, ask for their opinions, then ignore it. Asking isn't team building. Listening and acting is team building. Be the manager that gets things done when your team brings them to your attention.
Tell your team that you want a solid product. Ask yourself if you'd rather have a product with 10 rock solid features or 20 flaky ones. Most people want to deliver solid software, but push their team into tight deadlines that require shortcuts. There are many solid engineering techniques, like test automation, continuous integration, peer code reviews, and more, that build great software. But most teams get pushed into such tight deadlines that they feel they have to cut out all the practices that build solid products. If you want solid software, insist that your team do the right things, then make sure they get the time do them.
When your team delivers late, find a way to take the blame. See if you could've done a better job of solidifying requirements, or of getting a sane timeline. Could you have gotten the customer involved sooner to see what the team was building? Could you have bought pizza once or twice a week? Did you do a good enough of a job of keeping interruptions from the team? What could you have done?
Stand up and find a way you could do a better job instead of throwing the team under the bus. That kind of loyalty is rewarded by your team and your managers.
At the end of the day, you're probably a bad manager. Most managers are. If you cling to the fantasy that you're good, you'll be much less likely to reach out and try to improve. If you're already good, then why bother?
But if you realize that you're bad... if you accept it, and embrace it, then you have two choices.
You can continue to live a life of mediocrity. It's not so bad... you've gotten this far, right? Or you could take a look at a few of these tips, and dig out a few more on your own, and see what you can do to help your team succeed.
Assume your team is a group of smart, hard-working developers who desperately want to succeed. They want their software to be great, on time, and used by customers. You, as their leader, just have to find a way to clear a few road blocks out of their way so they can do it.
Are you up for the challenge?
This article is paired with You're a Bad Developer. Embrace It. Feel free to print them both out and put them on the bulletin board at work.