今日推荐英文原文：《5 Bad Habits of Absolutely Ineffective Technology Managers》
今日推荐英文原文：《5 Bad Habits of Absolutely Ineffective Technology Managers》作者：Ravi Shankar Rajan
5 Bad Habits of Absolutely Ineffective Technology Managers
Bad management is a lot like smoking — it is not ignorance but a bad habitBarely a week goes by without at least one article or study bemoaning the things managers don’t know or do. They are the perennial punching bags in any industry, and software is no different. In fact, 90% of programmers have a hate-love-hate (in that order) relationship with their managers. On one hand, they hate the restraints enforced by the manager, and on the other hand, they crib if the manager is not around to hear their woes.
It is a catch-22 situation even for the best of managers. They strive to make everybody happy, and at the same time, somebody sometime is bound to be unhappy.
That said, there are no perfect managers but most of us who are managers do like to think we are perfect anyway. I do my best as a technology manager but know that I am not always great.
You might argue here, “Not everybody is perfect. Everybody can make mistakes. What is the big deal?”
The big deal is bad habits you pick up as a manager, which causes grief to the team. You may think your imperfections are yours to own, but they negatively affect everyone on your team. Your bad habits are like smoking in front of your team. Everybody passively inhales the toxicity of your actions.
And the haze of smoke is not only due to the bad habits of the manager. It is also created and sustained by millions of individual behaviors taken, or not taken, again and again — despite their actual, known, and chronicled downsides — by the entire team.
In short, the entire team suffers. The project suffers. The organization suffers. And here are some of the worst habits you should kick to the curb before it is too late.
1. Releasing a Product Before It’s ReadyYour real test as a good technology manager comes under a crisis when you’re under pressure to deliver a product to market before it is ready.
If your behavior changes during a crisis, then you are not a good manager. For example, if you have enforced the discipline of test-driven development (TDD) in non-crisis times but abandon it during a crisis, then you do not really trust that TDD is helpful. If you enforce great coding practices during normal times and let things go haywire during deadlines, you are doing everybody a great disservice.
Never neglect the little things. Never skimp on that extra effort, that additional few minutes, that delivery of the very best that you can do. It does not matter what others think; it is of prime importance, however, what you think about you.
Always remember that cutting corners will haunt you — if not now, later. You usually have one chance to delight a customer, and in the case of a product release that becomes a quality disaster, you have probably lost the customer for life.
2. Hiring Someone Who Is Not Quite Qualified, but Is LikableHiring a good developer can be a tricky business at times. Sometimes you may have a great developer who is a bit loony, broody, and eccentric at times and not liked much by everybody, but he is competent and does his job well.
On the other hand, we may have an extremely likable person as a developer who is all fluff but no stuff.
And instead of hiring the most experienced and talented employees, bad managers often target potential employees who aren’t likely to outshine them or question decisions. By focusing on their own emotional needs rather than the needs of the project when hiring, bad managers sabotage the ability of the project to work effectively. Developers who have substandard skills or training make more mistakes and decrease productivity.
The rule of thumb is don’t hire a developer who “fits in the culture.” Hire a developer who “fits in the job.” As technology managers, you are not running for a popular vote here. You have a project to complete, and you need the best people.
3. Avoiding or Postponing the Toughest ActivityJez Humble has rightly said, “If it hurts, do it more frequently, and bring the pain forward.”
Perhaps this above statement is one of the most important principles of successful software delivery.
Yes, I know, doing the hardest thing first is usually the LAST thing any of us want to do. However, it is a bit like taking off a bandage. We all know that if you try to pull off a bandage slowly, the pain seems worse and lasts longer. So most of us would rather just yank it off and be done with it.
For example, if integration is a painful phase of your project, do it more frequently in small bits and alleviate the pain. If testing is a painful step in your project, don’t do it at the end. Instead, do it continuously right from Day 1 of your project.
If application documentation is something that is hated throughout your project, do it as soon as a new feature is incorporated into your project. Make documentation an integral part for signing off on the feature.
The point is rather than waiting until the last minute with the pressure mounting on you all day, just do it! Wake up in the morning and do hard things first so they are out of the way.
4. Making Every Decision a Consensus Decision
“Democracies don’t make great products. You need a competent tyrant.”Perhaps this one statement of Jean-Louis Gassée, a former Apple executive, summarizes one of the most important traits every good technology manager should have.
Consensus decision-making sounds like a way to achieve the best possible outcome from the decisions made at work. If you can bring all team members on board, you will have developed a decision that everyone likes, respects, and supports.
It is a good theory, but it fails to bring a good outcome most of the times. Taking into account all of the varied sources of information required to prioritize (customer input, technical feasibility, market demands, things that need fixing, and so on) and getting the team to unanimous euphoria may not be practical.
And you end up agreeing to a middle-of-the-road solution, which may not be the best solution. Nobel Prize winner John Nash Jr. calls this the Nash equilibrium. In this situation, you cannot make any more changes without making a particular team member better off (or worse off). The decision may not be the best solution, but it is the fairest option.
And a fair decision is often the lowest common denominator agreed upon by the group, one which satisfies the team members but is not optimal for the project.
Remember, as a technology manager you don’t need consensus, but you do need a decision based on consistent decision criteria, which you can get by taking everybody’s feedback. Incorporate all the feedback and take the decision that is the best tradeoff possible in the scenario.
5. Poor CommunicationGeorge Bernard Shaw rightly said, “The single biggest problem in communication is the illusion that it has taken place.”
Communication. It is about honesty. It is about treating people in the organization as deserving to know the facts. You do not try to give them half the story. You do not try to hide the story. You treat them as true equals, and you communicate, and you communicate and communicate.
If you have important information to share with your boss, colleagues, vendors — even if it is not great news — do not wait. If you put off providing them with actionable information until it is too late to act, then your news will never be well received, whether it is good or bad.
In almost every conceivable scenario, it is to your advantage to communicate as quickly as possible, allowing everyone involved to understand and digest the information, formulate an appropriate reaction, and respond accordingly. If it is bad news, your early warning just might allow for sufficient planning to minimize the damage.
Above all, remain professional, polite, direct, and clear — all traits that will move your communication in the right direction during your time at your current place of work.
As the saying goes, professionalism is not the job you do. It’s how you do the job.