I was reading an article on nightmare bosses when my mind started drifting towards days gone by.  I was working for a large software company, but in a small division.  At one point I worked for a couple of tough bosses in a row.  The first was tough, but the second one was incompetent.  As I thought about my own performance and behavior during that time, I remembered my lack of motivation.  Then my thoughts travelled farther back in time to when I was a manager.

At one point, I was the development manager for a product group.  I was managing eleven people and we had successfully worked together to produce one product and were working on a second one.  Being a former developer and peer, I was pretty easy to work with and for.  I understood software development and developers and knew to give them a lot of rope for creativity and self-guidance.  On the other hand, I had two employees in particular who were slowing things down on a very tight schedule.  My feet were being held to the fire and I tried to insulate my developers from the pressure as much as possible.

I should have been a little tougher.  Not a nightmare boss, but a boss.  There are many degrees of management and these can apply differently to the different people that you have responsibility for.  Unfortunately, applying the same style to every developer is a mistake that I’ve come to realize only many years later.  Maybe this advice will help you avoid the same mistake.

There are common and different things that make developers work well.  Common items usually include positive feedback, a feeling of appreciation for their work, comfortable and quiet work environment, freedom to choose work-hours, lack of interruptions, good equipment, etc.  These are generalizations, but most people respond well to the above.  Developers respond differently, however, to the amount of supervision, freedom to choose projects, and tightness of specifications.  For example, some developers work very well when unsupervised and with a very loose set of requirements.  Others perform horribly under the same circumstances.  Others still can be easily distracted or have other things going on in their lives that either distract them or that they choose to work on during work hours.

For people who fall into the latter category, a certain amount of babysitting (pardon the use of the word) is in order.  This can be done respectfully, however, and if you’re good, it can be well disguised.  One developer, I discovered later, simply wasn’t doing much work at work.  He needed closer supervision and to understand the importance of what he was (or more accurately wasn’t) doing.  This should have started with a frank discussion of the nature of the situation:

  • We needed his code.
  • It wasn’t just what he was or wasn’t doing, but what would happen to the group if he wasn’t focused.
  • It wasn’t just his reputation, but mine as well.

Then, I should have worked out a plan to cope with him.

  • Get a good understanding of his areas of responsibility and what others were expecting from his code.
  • Formulate a design of the code and a plan and schedule to complete it.
  • Checking in with him every day, going over a goal for the day and progress made.
  • If there was any doubt, sit with him for an hour or two each day to ensure progress.  This could be done under the guise of wanting to understand this area of the system better.

You may be asking yourself, why there wasn’t already a schedule and a design, and in fact there was.  However, these things change over time and if someone is already off track, then it’s time to evaluate things in detail, even if you simply discover that initial designs are still good.

If you’re the manager of a group, remember that as the manager, it’s your job to see that everyone is doing their job to the best of their ability.  This doesn’t need to be a micromanagement activity, but it may need to be for some of your employees.  The best way to find out what’s going on with every member of your group is to visit with them often.  A bi-weekly one-on-one meeting for half an hour is often insufficient for this.  Stopping at everyone’s desk for five minutes every day to two will help you understand what everyone is up to, what roadblocks they may be facing, and what interconnections you can make between team members, who may be duplicating efforts.  Customizing your management style for each developer is simply providing the same kind of flexibility you like to have over the software that you use.  The equivalent of each developer having their own options menu on how they should be managed.  The end result is a smoother way to work.