wandercoding.com

Although I have been unable to locate it, I remember an old Doonesbury cartoon that went something like this: Mike had a friend, Roger, visiting from MIT and was introducing him to B.D. or someone else.  When Roger spoke, all that came out was, “Bleep Bleep.”  I must admit that working around techies all day that’s what some people sound like and I’m sure that I’m no different at times.  I remember a few times when someone would come over to my desk and tell me about something they were working on in terms that were unfamiliar to me.  I would simply respond with, “Bleep Bleep.”

This came up again a couple of weeks ago at judo practice.  One of my students is a Ph.D. graduating from Cornell.  I told him that I wanted to hear his 30 second elevator description of what his work was about.  We got to talking and I mentioned how it was very important to be able to speak to people with different levels of understanding.  Not everyone in your company will have the same technical background that you do, so the ability to communicate effectively with others at their level is crucial.  You’ll often find that salesmen, marketing people, and even CEOs will use terminology incorrectly.  Additionally, they’ll often have a much less thorough background in the field than you do and yet be responsible for presenting your work to the outside world intelligently.

For example, your CEO may have to speak at a shareholders meeting.  He (or she) will need to relate the latest functionality of your software to people who want to invest in it, but have no idea how to use it.  The CEO will have to explain the technology using analogies or simpler terms that investors and analysts can understand and get excited about.  While you may be excited about the implementation, they’re only interested in the UI and general functionality.

On the other end of the spectrum, your ability to converse with your peers and other colleagues in the trenches is equally important.  You must be able to describe complex functionality in a simple way to your documentation people, who then have to help your end users understand things.  Your peers on the other hand probably will know more of your terminology, so they will be happy to use jargon that can shortcut a conversation to the point.

Knowing your audience and speaking or writing at the correct level can have a great impact on your effectiveness and your image.

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.