Wednesday, February 6, 2013

What you shouldn't do as a boss: Complaints from the trenches

Today's post is adapted from a talk I gave to managers in training.  Even if you're not a manager, I hope that you too can pick up basic principles and help implement them in your organization.  If you're interested in hosting me for a talk, you can find me via email or @RecodingBlog.

My first job was with a small IT-turned-web-development company that accidentally developed a software division.  Most of the people there were playing at their jobs, using congratulatory back-patting to reinforce the idea of how "great" they were, instead of acknowledging weak points and moving to reinforce them.

They had an excellent market position but were slowly losing it thanks to the above reasons.  There's a life lesson here: If you are not pushing you and your team to excel, someone else will and you'll find that your customers don't have nearly as much loyalty as you thought they did.

Management has the biggest impact on the velocity of a team, software or not.  Here are five simple "don'ts" that can have a huge impact on team productivity:

Don't ignore workers


There was a very flat management structure at my old job.  Virtually all of the ~20 people reported directly to the CEO.  This made it very difficult to find direction.  While flat management styles seem to be all the rage nowadays, the studies show that managers should have no more than 8 people reporting to them or else chaos will ensue.  Even if you've got less than eight people reporting to you, make sure that you stay in contact.  I strongly recommend a weekly one-on-one meeting just to check up.  An employee that feels that they are heard is happy.

Don't demand perfection


Scope creep is a very real danger to any software project.  Yes, there are many cool features that your product can have, but there's a limited time.  In most industries, you're racing against your competitors.  The (unwritten) spec of my project was subject to the whim of the CEO and all changes must be implemented before we release 1.0.  The project has been going on for over 1.5 years and still is in development
"If you are not embarrassed by the first version of your product, you’ve launched too late." -Reid Hoffman, Founder, LinkedIn

Don't keep information away


We woke up one infamous morning to discover that the CEO had announced that we'd be developing a mobile version of our product.  Now, he announced it to our customers, and us employees were CC'd in.  Ouch.  How "the boss" communicates with employees says a lot about their attitude toward them.  Instead of CCing, become an information conduit.  Remember those one-on-one meetings?  Use them to bring relevant information.  Make sure you don't assume that an employee doesn't want to know something.  Asking only takes ten seconds.

Don't make status reports anything significant


I once got three requests for project status on the same day.  I don't know what management expected to change over my lunch break.  Status reports only slow progress, as the employee has to put time aside to write the reports.  Instead, use that one-on-one meeting (aren't these handy?) to find out what's going on.  Need more information?  Chances are, your team is generating a lot of data through commits, bug trackers and other useful tech.

Finally, don't let bored people quit.


The tech world brings about an incredible amount of mobility.  It has become incredibly important to nurture professionals.  I don't mean pampering them, but rather ensuring that they have the ability to gain new skills.  I've moved on from my first job and settled into a place using cutting-edge technology developing a product that's never been made before.  Needless to say, it's much more exciting.  An important, but oft-overlooked point here is to respect free/learning time.  It's very easy to override this as it doesn't produce anything short-term.

No comments:

Post a Comment