Agile Zone is brought to you in partnership with:

Jared Richardson works at Logos Technologies As a recognized expert in the software industry, Jared has worked with both start-ups and software giants. He's been involved with various open source projects, with roles from contributor to founder. Jared co-authored the best selling book Ship It! and Career 2.0, and founded the Agile RTP user group as a local outlet for the agile community in North Carolina. His personal blog is Agile Artisans Jared has posted 52 posts at DZone. You can read more from them at their website. View Full User Profile

You're a Bad Manager. Embrace It.

10.06.2010
| 29115 views |
  • submit to reddit

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. 

 

Published at DZone with permission of its author, Jared Richardson.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Tags:

Comments

Yannick Menager replied on Thu, 2010/10/07 - 2:19am

Good article, too bad it's published on a development-related website, meaning the odds of a manager reading it are close to non-existent :-)

George Kokkinos replied on Thu, 2010/10/07 - 3:45am in response to: Yannick Menager

Maybe the developers who actually read it, can send this link to their managers!! :-)

Alex Scott replied on Thu, 2010/10/07 - 6:03am

Good article. Unfortunately I agree with the above comments - very few IT managers will read it (mores the pity).

Roger Parkinson replied on Thu, 2010/10/07 - 6:37am

Good stuff and, unfortunately, so true. Re the hardware upgrades: it doesn't even have to be new hardware. I got sick of slow compiles on Windows and unilaterally 'upgraded' my ageing laptop to Ubuntu. Build time went from 7 mins to just under 1. That's for free, and it's also cooler. Of course new hardware would also be nice but since my compiles are faster than anyone else's right now I can't make a case for it.

Jared Richardson replied on Thu, 2010/10/07 - 8:20am in response to: Yannick Menager

The article I published last week, You're a Bad Programmer, was very popular... over 32,000 views so far. It was on the front page of several other news sites, etc. One of the recurring themes in the comments was managerial responsibility, and I agree with it.

 

I'm hoping that the same army of readers that embraced last week's article will take this one and share it with their tech leads and managers in the same way. I suspect if they send both links to the entire team (Your'e a Bad Manager ~and~ You're a Bad Developer) it wouldn't be taken as badly as if they just sent this one to their manager. :)

 

Can you help me spread the word? 

Jared Richardson replied on Thu, 2010/10/07 - 8:49am in response to: Roger Parkinson

Hi Roger,

I've seen a few shops that have moved to SSDs instead of a new machine. Most builds are reading and writing constantly to disk, so that single upgrade makes a huge difference. It's much less money and it's an upgrade you can carry forward to your next machine.

I don't know if that's a possibility for your team, but maybe it's an idea you can use to get people thinking.

Tony Siciliani replied on Fri, 2010/10/08 - 4:15am

I would still make a dinstinction between lower-level managers & the upper hierarchy.

The reason is, I've often seen good PMs having no choice but to implement bad decisions from up the command chain. And that, independently of how well they argumented against such decisions.

 

 


 

 

Jared Richardson replied on Fri, 2010/10/08 - 9:12am

Good point Tony.

I'm hoping to help motivate those lower level managers who feel forced into bad decisions... how creative can they get? Is there another way to share the real compromises they're being asked to make? I'd like to hear more stories about managers who work as hard, or get as creative, as a the dev team that works 100 hour weeks, moving heaven and earth, to make things work.

But you're right... it's often executing on a bad strategy from higher ups. How can we educate that level of leadership?

srini kamisetty replied on Fri, 2010/10/08 - 2:06pm

Right on. Luckily, most of the managers, I have worked so far in my career are great except one or two.

Jared Richardson replied on Fri, 2010/10/08 - 2:41pm in response to: srini kamisetty

Thanks Srini. Do you have any other tips about some of the managers you worked with? What things did they do?

Jay Johnson replied on Fri, 2010/10/08 - 9:19pm

I like your essay.  I've written at least two that were very similar to yours --  the first was over 20 years ago.  Funny how things never change much for the better, even though technology changes drastically every 3 years. 

I know a guy who was a manager.  He could code Java as well as his best developer.  He did everything he could for his people... the latest tools, training, and methodologies.  He created, with his team, an excellent technology stack and a great agile process.  He reviewed their code, wrote his share, and worked late nights and weekends.  His developers were good, some were even great.

BUT here is the reality.  Here is the ultimatum he always got from HIS managers: Complete the project, including constant requirements changes, in this unreasonably short time or we will begin outsourcing full projects, starting with this one.   Finally he called their bluffs, stood his ground.    Stress put him in the  hospital.  The whole department was outsourced. Did I mention he WAS a manager?

Face facts:  The world is flat.

 

Steve Ciske replied on Fri, 2010/10/08 - 10:14pm

Great article. My response here: http://www.steveciske.com/post/2010/10/08/Insights-of-Youre-a-Bad-Manager-Embrace-it.aspx looking forward to more of your posts!

Jared Richardson replied on Sun, 2010/10/10 - 8:53am

Face facts: The world is flat.

Should we give up? Should we just quit or keeping trying? Maybe I'm still too young and idealistic... ;) (I'm 40), but I still believe that most people really want to do the right thing. Most of the crazy things they do (like measuring lines of code) are an attempt to try to manage an effort they don't understand.

Many of the project management practices in the agile space (like scrum) are becoming recognized as very useful ways for the less technical managers to understand what's going on. If we can find ways to help the managers understand what we doing, and how they can effectively do their job, they'll welcome it with open arms.

And I recognize that some people just don't want to change. Their existing "process" has worked for them for decades (or at least kept them employed). These aren't the managers we'll reach. The ones who recognize that the status quo isn't working and are looking for something better... these are ones we hold out for and try to reach.

Carla Brian replied on Mon, 2012/06/25 - 6:53am

In order to be an efficient manager, you have to have a good relationship with your people. You should approach them that would not let them feel intimidated. Just be carefree as you are. - Mercy Ministries

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.