Happy Geeks are Productive Geeks
I was pointed to a blog entry called “How NOT to Lead Geeks“, and I found several items very interesting and eerily familiar:
The main reason IT people are unhappy at work is bad relations with management, often because geeks and managers have fundamentally different personalities, professional backgrounds and ambitions.
In my IT career, I’ve almost always played the role of Geek+Manager, or Manager+Geek, depending on which part consumes the larger percent of my time. I’ve played on both sides of this table, locking horns with Management about the wrong way to lead their technical staff, as well as trying to “herd cats”; as a Technical-Manager-of-Geeks.
In my OSS world, I also have to lead and manage and guide geeks, many of which I will only ever know through email. Not knowing your team personally has a distinct impact on your ability to build trust and confidence. The rules change quite a bit.
I recommend every Manager work with a team of people he will never meet in person, and hone his skills there, to be a truly successful manager with the team of people he does work with in-person.
Here’s the Top 10 from “How NOT to Lead Geeks“:
- Downplay training
- Give no recognition
- Plan too much overtime
- Use management-speak
- Try to be smarter than the geeks
- Act inconsistent
- Ignore the geeks
- Make decisions without consulting them
- Don’t give them tools
- Forget that geeks are creative workers
Of these, #2 and #9 are the ones where 99.999% of all “Managers” fail. Almost every manager fails here because they believe they are there to “manage” people, “tell” their staff what to do, and they expect those things to get done.
WRONG!
A manager has one job description: Give his team all of the tools necessary to do their jobs (i.e. meet their goals, as agreed to by the entire team), and then step out of the way.
When political pressure threatens to affect the progress of that team (geeks or otherwise), the “manager” is expected to step in the way and deflect it. At no point should a team have to deal with anything political to get their jobs done.
These tools can be physical tools (applications, access to systems), communications tools (introductions to the right edge teams to minimize overlap), or social tools (meet-n-greet with other members, build camaraderie, offsites to let off steam, training..).
Many managers believe their “subordinates” (they already building walls by using that term) are supposed to do “what they are told”, and not complain or cause waves. It ends up building a situation based on office posturing and finger-pointing when things slip or don’t get done on time. To cover the situation, good people get fired or laid off. When you see this happening, it is always because of bad management, not bad technical people.
Rarely do you see the Geeks survive the pink-slipping, while managers get to keep their jobs… the same jobs they’re doing poorly time and time again.
If your technical team is performing poorly, you need to look at a few key items. All of these items point back to the competence of the manager, not the team itself:
- Did you hire the right people with appropriate skills to achieve success? You were responsible for hiring and selecting the team. If they lack the skills, you chose poorly.
- Do they have all of the tools and training necessary to do the jobs being asked of them? Did you provide access to the right systems, people, training for your team to grow and complete their goals?
- Are the deadlines and goals realistic? Is everyone in agreement with the goals? Did you consult with the team to find out what their opinion was? Did you listen to their opinions and comments objectively?
- Are you (the manager) in the right place in the team? Not too close to smother or micro-manage the team, and not so far away that you lose sight of the progress on goals.
Another good point in this blog was:
Geeks usually know the technical side of the business better than the manager, so making a technical decision without consulting them is the biggest mistake a leader can make.
I have seen one major company implode based solely on this exact problem. We went from 250 people down to less than 30 people in 2 years, and rotated through 4 CEOs and 5 rounds of layoffs in that time. Hundreds of amazingly-qualified, brilliant technical people were laid off in wave after wave. Why? Because they were never asked if what the company was doing, was the right thing to do.
The “Managers” (and I use that term loosely here) at this company were agreeing to do work for clients that was simply impossible to do, under even more impossible deadlines. If the geeks were consulted, the projects would have been realistic, on-time, and completed to profit. That never happened, so who had to go? Not the manager of course: The geeks. Very sad to see hundreds of talented colleagues laid off time and time again.
In my experience managing and being managed by dozens of managers in my IT career as I moved up and around the corporate landscape, I have only had 1 manager that did exactly this, and in 2 years, everyone under this manager received a promotion every year, because of the rapid success and accomplishments. I was on my way to my third promotion in just as many years, when I decided to resign and work for the company above, that fell on its face.
But I strive to be exactly the style of manager that I had when I was at my best. High-volume, low-stress, clearcut and productive with every task and project.
I should also add that I’ve never been fired or laid off from any job I’ve had, both as Geek or Manager, and I don’t intend to. I make my points heard, even if it means risking my job. In every case, my voice has either saved the team, project or company with realistic objectives.