Showing Initiative vs Being a Cowboy

A few weeks ago, I fixed a bug without being asked to do so. Shortly afterwards, I was asked “Why did you fix that bug? Who told you to do it?”  The question arrived in email, so I couldn’t be certain about the tone-of-voice, but I’m sure you read this sentence with the same tone-of-voice that I did.  You are imagining someone giving you a sour-look or maybe even a scowl.

If you were a smart-aleck, you could respond like you didn’t know it was a rhetorical question “I fixed the bug because it was a bug. That is what I do when I find a bug. I fix it. I’m pretty sure you don’t want me to do the opposite of that.” However, since you and I are very professional, I wouldn’t say something like that. Right?

When I’m asked a question like this, it does bother me a little. Mostly, because I know my own motivations. I am not a loose cannon and I don’t go around looking for trouble.  I also don’t typically invent assignments for myself.  So, when I find a problem and I fix it without being told, I know I am being proactive, a.k.a. “showing initiative”.  I don’t expect a pat-on-the-back, but I certainly don’t expect some reprimand or questioned about my reasoning or motivation.  This was some kind of misunderstanding, and it just needed to be worked-out.

Cowboy “Fixes”

I have worked with a few cowboys in my day. Those guys can be fun to work-with, but they can also cause some interesting problems.  Therefore, many companies have processes in-place to limit the damage that a cowboy could cause.  Most notably is controlling the dev and release process, to monitor and control what gets worked-on and included in any release.

Now don’t get me wrong. Not every action from a cowboy is a dangerous one.  A cowboy mostly does good work.  It is the dangerous stuff that really draws consternation and earns the cowboy his dubious title.  So how does a person tell when an action is “cowboy-ish” or not?

Here are the conditions when the action of a developer is cowboy-ish (or generally, overstepping a boundary, or outright dangerous):

  • Security reasons – an IT department needs a check-and-balance, especially when it comes to security. It is not appropriate for anyone to modify security settings/configs, without regulation.
  • Stability – it only takes once or twice, where you trusted someone to apply a fix, and they broke your production servers. After that, you tend to not trust anyone as much. If you are responsible for the system, then be proactive and assess any changes, before they are applied.
  • Cost/scheduling – Let’s face it, everything takes time, and time equals money. Developers shouldn’t approve their own schedules, or purchases, beyond a reasonable limit.
  • Control – Management is there for a reason. They need to be informed about what is going-on. There needs to be a way to track this. Whatever you do to track your work, it needs to contain enough detail to keep everyone honest. People make mistakes. Everyone needs to stand behind their work and own their successes and failures equally.

It is pretty common to put processes in-place to limit people from fiddling with any of these topics. Only your most trusted people should have permission to work in these circles.  Even then, your most trusted people still have to follow a process and have some reasonable limits and checks in-place.

Cowboy Detectors / Monitors

Placing limitations or verbal measures in-front-of the cowboy is usually not effective.  A cowboy is inclined to get around boundaries and hurdles without notice (sometimes, just for the challenge).  The only safe way to enforce your process is to steadily assume that the cowboy will periodically test the boundaries.  The real defense here, is to monitor and test, often.

Lets just assume for a minute, that not-all developers are cowboys. In that case, when is it right to make a change/fix without being prompted?

  • Trust smart people – face it, if you trust your developers to modify code, then you should also trust their judgment elsewhere. If you can’t trust them, then review their work periodically.  Find the line between management and micromanagement so you have control, without getting wasteful. After all, the programmers may be some of the smartest people you know. Certainly they must be trainable. So train them, and trust them a little. If you need more communication, then focus on that, rather than pulling the rope tighter.
  • Bureaucracy becomes too restrictive – This is why the agile manifesto was written. Sometimes well-meaning people get carried away with creating processes to protect the company and people.  Sometimes you need a fix ASAP.  Define a process for doing something quickly.  Of course it should be the exception. So define rules for when it is acceptable.
  • For the right reasons – back to my initial statement: a bug is a bug. Once you’ve found a bug, it usually takes seconds to fix it. However, it could take minutes or even hours, to log and track a bug and its fix. A team needs to find an efficient balance between regulation and waste.

In the end, I worked it out with my supervisor.  She just wanted to be informed about every bug that I find and the nature of the bug. That way, she could track the testing of the bug and add it to the statistics that went to management.  It was a very reasonable request and I was glad to contribute to the improvement of our process.


About Tim Golisch

I'm a geek. I do geeky things.
This entry was posted in IT Psychology, Professionalism and tagged , , , . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s