Skip to content

A Challenge to IT Companies

Dear Reader,
[Note: This blog post should in no way reflect poorly on my current employer. I love my job and am not talking about any one company in particular but about IT companies in general.]

The Problem

Something has been bugging me for a while now. I’ve been a member of more IT companies than I care to remember. Outside of cube farms, one thing seems to remain constant throughout, a contract that was written in the 1800s. Most (not all) of the employment contracts I have been handed to sign have contained a clause that states something to the effect:

While you are working for us, if you invent something we like, we can claim ownership of it.

(more…)

Perception and Telecommuting

Dear Reader,

“You are responsible for how others perceive you.”
– Jim Turner

Jim Turner was an accountant for my parents right after I got married and was working for them. I’d like to say that Jim was one of the wise old ones but honestly, he was a working guy like you and me. However, the wisdom quoted above is the one thing that he taught me that has stuck with me. How others perceive me is my problem, not theirs.
(more…)

Remote Developers

Dear Reader,

This conversation takes place via email at least once a week for me

Headhunter: “I am looking for the best PHP programmer available. Do you know anyone?”
Me: “Yes, I know someone right now who is looking around and is awesome; however, they are not looking to relocate. Are you willing to consider a remote worker?”
Headhunter: “no.”
Me: “Sorry, your loss.”

(more…)

Good Boss…Bad Boss

Dear Reader,

Today I want to play a little game I call Good Boss…Bad Boss.

I’m going to list four personal experiences I’ve had with bosses and explain to you why I feel they are either a Good Boss or a Bad Boss. I will not say who the boss was at the time and I can confirm that none of these have anything to do with my current employer.

Bad Boss

I had a boss at a job one time who’s favorite saying was “I could teach a German Shepard to do your job.” He would pull this motivational bludgeon out once or twice a day. I can still hear him standing in my cubical saying:

“Jesus, Cal” he would say, “I could teach a German Shepard to do your job.”

Now, I will not argue the accuracy of the point because I realize it’s subjective. His ability to train a dog could have been far greater than mine and he may have been telling the truth. But this is a Bad Boss situation because he was trying to motivate me to work faster, better, more. The point I will argue is that he had mixed up the whole ‘Carrot and the Stick’ metaphor of motivation. Instead of holding the carrot out before me and occasionally smacking me with the stick. He was beating me over the head with the stick because he had already eaten the carrot.

He was a bad boss because he did not understand how to motivate his team. He didn’t take the time to understand each of us as individuals so he could not communicate with us his needs.

Good Boss

I had one boss pass me over for a promotion that we both knew I deserved. He only had one open billet at the higher level and it was a tight race between me and another guy. I didn’t get it. I acted like a spoiled child. I pouted, I grumped, I even went home early that day because I was mad. My boss didn’t say a word. He knew that even though I was wrong, it was best to let me blow off my steam. By letting me go home, he moved the problem off-site. The next day, I came in an apologized for my behavior. He smiled, thanked me and then we moved on to my project. He never mentioned it again, even on my quarterly review. He was a good boss because he knew that I was human, with faults but that he if just let me get it out of my system, that I would get back to normal. Had I come in the next day and continued to grouse, I have no doubt that he could have come down on me like a brick.

He was a good boss because he took the time to understand his team members beyond their obvious skill set.

Bad Boss

I had a boss at a company where I was in charge of 2 development teams. This boss, while a pillar of the business community, kept changing our company’s focus. As the head of all software development, every time we changed directions, I had to explain to the development teams why we were ‘re-focusing’ our efforts again today. There were times when it was a nightmare. Development teams (as most of you who are reading this know) do not turn on a dime and start off in a different direction. Almost monthly, we would have a new vision for the company. That usually meant the software we were developing was now no longer wanted and we were off to the races with the new software.

He was a bad boss because he didn’t understand software development even though he advertised it as one of the core competencies of the company. Software development, done right takes time and planning.

Good Boss

I was hired at one company to build and manage the development team. This team was pushed hard, we had some demanding clients and difficult projects, most of which involved processing money so they absolutely had to be correct, every time.

In November, my boss came to me and said, “It’s getting close to the time for the Christmas party, I want to do a LAN party again.” The gist of it was that every developer received a copy of the game we were going to play and we made sure all machines could handle the game. (Most of the development staff already had dual 20″ Dell monitors)

We took a Saturday, all gathered at the office including, some of our friends and played all day. The day of the party, my boss gave me his credit card and told me to go up to the local Toys R Us and buy enough Nerf guns so that everyone can have one. it was the only time I have every checked out with $150 worth of Nerf firepower and I’m pretty sure the cashier had never processed an order like that.

Aside from the obvious “cool factor” this boss was a good boss because he took the time to understand his team.

Led by Example

All of the bosses I’ve worked under have helped shape the type of manager I am but none have affected me more than these two, Paul Mueller and Ray Taft. Paul, because he taught me how to lead. He taught by example and he taught with humility. Ray, because Ray showed me how to treat people. I thought I knew how to treat employees but it turns out I really only knew how to pamper them. Ray showed me how to treat them right but be firm when necessary. Whenever I am faced with hard management decisions, I always look at the examples that these men provided for me and usually, the answer, even if it’s not the one I want, becomes clear.

So let me ask you, if you are a boss, are you a good boss or a bad boss? In 20 years, is someone going to look back at their time under you and thank you for the lessons you taught them? If you are a boss, be a good boss and lead by your example.

Until next time,
(l)(k)(bunny)
=C=

Leadership In Software Development

Dear Reader,

[Editor’s Note: This is an editorial that was originally published on Freshmeat back in 2000. As I’m cleaning up my content, it stuck me that I had never published this here.]

Me to the everybody: “Hi, my name is Cal… and I’m… I’m a manager.”
Everybody: Hi, Cal!

I am a developer who made the conscious decision to move into management. My training, my experience, and my love has always been developing software. I’ve worked under sales managers, business managers, and (shudder) a CTO who believed that all the good software had already been written so we didn’t need to write anything; we could just buy everything we needed. I made the leap into management for one reason: I had a manager who “got it” and showed me by example that developers can make great bosses for other developers. (Thanks, Paul M.!)

During my career as a developer, I learned many different things but the one thing that has stuck with me is this axiom:

“If you have never been a software developer, you have no business managing software developers.”

There, I’ve done it again. At least one third of you are now mad at me. But regardless of your feelings towards me, I stand by my statement because, time and again, whether through personal experience of 24 years or war stories from others, it has survived.

Before you fire up mutt and flame me, let me be quick to point out that I do not believe that this maxim is universally applicable to all situations or walks of life. I am not belittling any person or occupation, but I believe that, in most cases, we as humans, co-workers, and professional colleagues have enough shared experience to be able to relate to each other. I do not believe that this maxim applies to the sexes or to races. However, there are a few areas where it does apply, and the one I know most about is software development. Here are three different thoughts on why I believe this is true, what I believe has caused the current crisis, and what I think we can do about it:

The Balancing Act — Why we are here.

There are very few professions that combine the creativity involved in good software development and the rigorous deadlines, often imposed from the outside. Hurry up and create! The ideas have to keep flowing, they have to be scheduled, and they have to be completed on time. If you have to go figure something out, go. But make sure you are back after lunch and make sure your schedule doesn’t slip. Developers, especially now as we work in Web years, are under increasing pressure to “Get it out the door fast!”.

The rigorous detail work of quality software development, however, has not changed. It still takes time to develop quality software. (You can have it good, fast, or cheap; please pick two.) To those on the outside, it may sometimes seem that what we do is easy. (Heck, we may feel that what we do is easy!) The ease with which developers manipulate the tools of the trade is often misconstrued as ease with which the task can be completed. Only a developer understands the countless hours it takes to master new tools, new languages, and new concepts. In this age of rapid development, new concepts come at us like a fire hose of knowledge. We are supposed to know how to soak it all up and be able to use it in our next project. This is almost a bearable burden if management understands what we are faced with. The problem is that, having never been there, most managers cannot empathize. (And most don’t even bother to sympathize.)

The Boss From Beyond — What has caused the current crisis.

It’s generally accepted folklore in the IT community that managers are managers because they can’t do anything else. What has led us to this state, a climate in which developers don’t respect their managers and managers try to manage a software development team like an accounting department? Volumes have been written on when and why people are promoted into positions they are not qualified to hold. I won’t rehash that here. I have a different take on it.

The question we ask should not be “Why don’t managers understand software development?”; the question should be “Why don’t those of us who do understand the process step up to management?” The obvious answer is that there are very few developers who want to be managers.

In the past, developers would have to turn away from promotions to management (and sometimes raises) so they could remain in development. These days, they find other companies to work for that will pay them more and allow them to continue to develop (but that’s a story for another day). The problem exacerbates itself. The more developers steer clear of management positions, the unhappier software development teams will be with the candidates that become their managers.

We, the IT community, have the bosses we have because we refuse to step up to the plate and take the job. I am not advocating that all developers climb the management ladder; far from it. In most cases, a developer pressed into service as a manager will do no better a job than an accountant forced to code. But until the development community learns to train its own management structure, we are doomed to be managed by PHBs.

Managing In Chaos — What can we do about it?

So now we are all on the same Merry-Go-Round from hell. What can we do to get off? At least part of the answer is obvious. We, as a community, have to train our own managers. For me as a manager, that means that as I interview candidates for development positions, I have to keep my eyes open for potential managers. I have to make sure that I mentor as I was mentored. I have to realize that if I don’t train new development managers, I’m as big a part of the problem as non-development managers.

For me as a developer, and all other developers reading this, we have to make sure that we educate our managers.

We have to teach them concepts like:

  • Deadlines cannot be set from the outside without input from the development team they are being imposed on.
  • Sometimes, it just doesn’t come to you and you can’t force it.
  • You can’t run most modern IDEs on crap hardware!

I’ve found that, in many cases, they can learn. They want to learn. They are PHBs because they’ve never been taught not to be. There are some that won’t learn or, worse yet, think you have a lot to learn about business. If you are under one of these and you work in America, change jobs! Life’s too short and the job market is too tight to deal with goobers like that.
Closing

To fix the present situation, we, as developers, have to make one of two choices. We can take a stand at our present jobs and educate upper management so that we don’t work for PHBs, or we can find other jobs. But make no mistake about it; it is ultimately up to us to fix the problem.

Until next time,
(l)(k)(bunny)
=C=