Thoughts, musings and commentary in the midst of the daily trials and tribulations of a contract programmer.These comments/views are my own, and in no way should be construed as those of my clients/Employers.They are responsible for their opinions, I'm solely responsible for mine.

Saturday, August 26, 2006

Management, Managers, Part#2

Before I get started, Tamar left a link in her comment and I followed it. Joel definitely has some interesting things to say on management. I definitely like his take on things. His company and their basic business plan sound solid as well. I hope he finds all the success he hopes for. You can read his Identity Management piece here.

So… back to qualities of a good manager… or at least those I think are found in great managers.

The last three items on my list are:

Knowledge not only of those being managed, but their jobs as well

An understanding of the company, it’s revenue sources, and how their department aids in revenue development

Remembering that everyone, including their ‘stars’ makes mistakes, often at the worst possible times.

Knowledge of those being managed, and their jobs

This is something that never ceases to annoy me. I can’t begin to tell you the number of times I’ve poured over requirements, tweaked functional design to arrive at what I truly believe is a realistic time line, only to have some non-technical manager toss it back to me with a “It can’t possibly take that long” dismissal of the project timeline.

I don’t care what the ‘job’ is, there are always hidden, often costly (especially in terms of time) needs in getting the job done.

In software development, one of the biggest is integrating new features into an existing application. In order to accurately estimate that, the person (or better yet, persons) responsible for the estimate, must have an excellent understanding of the existing application, the proposed new features, as well as the strengths and weaknesses of the development team.

It takes all of that knowledge to properly estimate the project.

Now I’m not talking about shifting a deadline a day, or even a week… I’m talking about a project that has say a 6 month timeline, and management cutting into 3 months to fit some budget number they invented prior to actually scoping the project.

In my experience, this is a classic means to development disaster. Initially, the development group will take on the challenge, as most love a challenge. However, as things progress, and about 30 days into the project the realization will hit them, that, regardless of what they do, they’ll never hit the target.

Inevitably, there’ll be some adjustment, attempts to better allocate the right individual to the right tasks, possibly add two weeks, maybe even a month to the deadline… but eventually, if the original estimate was properly done, everyone will see the ‘light’.

What happens next can often demoralize a previously productive team, and their manager. In order to focus ‘blame’ the other managers will often cite the developers, or their manager as being inept, unable to code to the requirements, or worse as totally incompetent.

Eventually, after things shake out, depending on how mission critical the project was, it will be scrapped, or the developer team will be scrapped and the project restarted. I’ve actually been called in to projects that were on their 3rd iteration of this cycle.

How their department aids in revenue development

Believe it or not, I’ve met managers, especially IS/IT managers who had no idea what the company’s primary revenue source was, or, the belief they did have was about as far from reality as it could have been.

Let’s face it, every company (yes, even a ‘not-for-profit’ company), is in business to make money. It’s not an altruistic endeavor, it’s a money making process.

It’s a huge mistake for anyone, especially a manager, to not fully understand what drives the company’s cash flow, how’s it’s gathered, how it’s spent and how much is left over as profit each year.

It’s an even bigger mistake to not fully comprehend where you, and your team, fit into that equation.

Are you helping drive revenue generation?

Are you providing tools to the sales folks to facilitate revenue production?

Is your group seen as an expense, or a capital investment?

If you’re in a situation where your efforts are viewed simply as a business expense, you’ll be subject to the same cost cutting strategies used to cut the cost of coffee in the break room. On the other hand, if you’re group is seen as an investment in the future of the company, and you produce as though the life of the company depends on it, you’ll be treated as the valuable asset you are.

It’s that simple really… Act like an asset, get treated like one. Behave like an expense, and you’ll be treated as a cost to be minimized where ever possible.

To be treated as an asset, you have to understand the fundamental difference between assets and expenses, to not do so, is corporate suicide.

Remember that everyone makes mistakes, usually at the worst possible time

This item, while it’s last, is certainly not least. I’ve seen some stellar performers just beaten into the ground over a single mistake. I’m talking about someone who’s produced quality work, day in, and day out, for say six months. Then, usually trying to meet one of those imposed deadlines, they miss a crucial test step, and a bad piece of code makes it out of development and into production.

Certainly they didn’t do it ‘on purpose’, if that’s suspected it’s an entirely different matter. No, in this situation it was a mistake, pure and simple, an oversight, a lapse in judgment, or even possibly the incorrect assumption that there was someone else doing sufficient testing ‘down stream’.

I’ve heard the same manager who last week was recommending this same person for a bonus, or some other company perk… screaming the next that “I don’t know why I let you stay on the team!”, “Why is it you never get anything right?”, “You’re damn lucky I’m not firing you over this!”, and on an on…

Look folks (especially if you’re a manager) let’s just set the record straight.

People, make mistakes.

It’s that simple, no one, not even the greatest of the great are ‘perfect’ every single day, at every single thing they do. Jerry Rice is arguably one of the best receivers to ever play professional football. Even he dropped the occasional pass, misread a signal and ran the wrong route… it happens.

A great manager knows this, and works with it, adjusts. Even the best of plans can’t include every single possibility, cover every aspect of potential failure, or test every possible key stroke a user might enter within an application.

The best managers I’ve worked for used every failure as a learning opportunity. They adjusted their overall plan, from start to finish to take this new knowledge into account and to minimize the chance it could happen again.

Notice I said ‘minimize’, not prevent, it from happening. There is no plan that’s 100% perfect in eliminating possible points of failure. The best plans though, are constructed to be flexible, and to look for, and catch as many as possible before they can leave the ‘shop’ and get to a customer.

I’ve got some more to say on management in general, but let’s just say for now, that I believe that having the right working environment, the right staff, and clear well defined (and communicated) goals are the core to making people productive.

Once again, I invite you to share your experiences, and thoughts, good or bad. If you’d rather not post them publicly, go to my profile and drop me an email.. If you email me, put “CCW Management” in the subject line so it doesn’t get caught in my spam filter!!

4 comments:

Qualityg - I'm not so sure it's so much an actual demise, as it is a divergence. There are many good, and great, managers...

Unfortunately, they don't get much press coverage.

It seems these days that it's mediocrity that's rewarded, not excellence. It’s those who don’t rock the boat who get promoted, and no one likes to promote anyone who has the potential to take “their” job.

To quote a professor of mine, who was explaining to me why I’d never rise to the top anywhere… “Mediocrity rises to the top Bill, not stellar performance.”

I think, in many companies today, that statement is truer than ever. Others though, like Joel’s, they’ve taken an entirely different approach.

Again, great insights. These truisms should be "obvious" but, as you know, they are not. You express them well. You should write a book!

Sometimes, though, former programmers are the worst managers in knowledge of those being managed and their jobs. They think that they know all of the factors in an estimate but they don't. They have rosey memories of the development process from 10 years ago. I could go on. I think that you get the point.

I love your section about mistakes. I have the misfortune to work with classic customers in this area. You can be a golden boy - but don't screw up because you'll get a "scorched earth" note copied to a management tree as high as your arm. When the mistake is theirs (signing off on a set of incomplete requirements then having to issue a costly change request), though, they are curiously silent. Management, and customers, really need to get this idea. Otherwise, when our horrid (at least in Southeast Michigan) finally improves, they'll find themselves minus some really good people.

CA - Thanks bro, I'm glad you enjoyed it!! If I could find a publisher who'd give me a shot, I'd love to write a book!!

I think in this 'perfection' culture we seem to be in, it's been forgotten that some of the greatest things we take for granted today, got here via a long list of 'mistakes'... like the light bulb, more than 10,000 attempts!!

Mistakes are crucial to the process... and contrary to the belief of some folks... no one is 'perfect'!!

About Me

There's not that much to say about me... pretty simple man and I live by the simple motto

"Don't make promises you can't keep"

Harder to do than it sounds, or at least that's what I've found.

Besides my family, motorcycling is my second passion, followed closely by software development and my love of custom, high performance vehicles!!

I think that's one of the reasons I enjoy developing software, it's a little like building a hot-rod... It's all the little tricks and tweaks that make the end result so satisfying... but you'll never see a reality show on it!!