Everyone has a price. Sometimes, though, the cost isn’t measured in dollars and cents. I recently read the article Top Ten Ways to Motivate Geeks, and being a geek myself, I got thinking about the inverse argument: what can a manager do to piss off their technical underlings such that they are less productive? After talking with a few of my fellow geeks, I present, in no particular order, our humble list of ways to de-motivate the technophiles that work for you. Note that I use the word “geek” to represent anyone that works with technology on a day-to-day basis, but particularly people working in software development or IT.
Disclaimer: This is not directed at my current employer or its management, and is not intended to describe any single person or any single company. It was compiled from the opinions of several geeks working at several companies in multiple states. Please don’t fire me. :)
1. Insult their ability or intelligence
The best geeks are confident, almost to a fault (sometimes not almost). As it is with any creative person, they don’t do what they do just to pay the bills. They don’t just do what they do, they are what they do. If you directly insult their programming ability, you’re not just insulting their code, you’re insulting them as a person, and as an artist.
Sound too wishy-washy? Maybe so. The best have a thick skin, and can absorb criticism pretty readily. I’m not suggesting that you should avoid criticizing them entirely — knowledge is a combination of instruction, experience, and feedback. Without a critical review once in awhile, they’ll just start assuming that they’re the best of the best. (This is undoubtedly why peer code reviews are becoming popular in XP environments.) Instead, restrict your criticisms to the product of their ability, not their ability itself.
Another thing to remember: misusing terminology implicitly insults a geek’s intelligence. “Oh, that problem can be solved easily! Just re-instance the variable with a generic!” Huh? If you don’t know the answer to a problem, don’t offer your opinion — particularly if you’re not a geek yourself, or if you don’t have the domain knowledge required to contribute. Don’t believe that by clobbering together a bunch of language keywords that you’ll convince anyone (particularly someone who understands what all those words mean) that you know what you’re talking about.
2. Take credit for their work
This is directly related to #1. Remember, a good geek’s work is a labor of love. When you take credit for their work, you might as well make a pass at their significant other while you’re at it. If you’re going to take credit, limit it to credit for directing them only, and leave any technical work that you weren’t directly involved in out of it. In fact, for bonus points, mention the geeks’ contributions to your superiors. Good geeks are team players, but they’re also proud, and it bothers them to never get recognition except as “a member of (manager)’s team”.
This particularly holds true for creative decisions. If you allow your geeks creative latitude (and you should, see #5), reward them when they take advantage of it and come up with a great idea. They will remember it, and they’ll be more apt to come up with creative solutions the next time around. Likewise, if you take credit, they’ll remember it — but they’ll start asking themselves why they bother to come up with good ideas anyway.
3. Don’t communicate enough with them
Geeks are information junkies. This is what lets them constantly improve their skills and continue on the search for better ways to solve problems. This also means that they want to know what’s going on in the company around them, and particularly the projects they’re involved in themselves. Within reason, answer their questions to the best of your knowledge. This doesn’t mean you should divulge things that the geeks shouldn’t know (for example, it’s probably best you don’t get into financial specifics), but they should be made to feel like they’re “in the loop”.
The best geeks aren’t just geeks, they’re also strategists, and capable of understanding business. They want to know what the company’s primary goals are, so they can adequately improve their skills to follow suit, and align themselves with the right projects. This is more about self-preservation than anything else, but it also stems from a natural desire to be on the cutting edge of everything. The grand majority of geeks are very forward-thinking, and aren’t interested in using technology that’s stagnated. They’d much rather try out that new circular saw than be comfortable working with the same handsaw they’ve been using for years.
Although you should be sure to communicate with them, you should never, ever, ever lie to them. Geeks spend the grand majority of their time dealing with factual data that is constrained by logic. They are also likely to be able to follow logic through multiple complex stages. If you do decide to lie to a geek, don’t ever go back on your statements, and don’t try to layer more lies on top. Geeks will be able to reason their way through your nonsense, and being naturally cynical, they will start to disbelieve everything you say.
4. Communicate with them too much
While it’s true that geeks want to be in-the-know, they don’t want to know about certain things (even if they sometimes think they do). For example, unless they’re wearing a sales-engineer hat, they should be left pretty well out of the sales cycle. Their deterministic nature will make it more difficult for them to understand why a client doesn’t see that their software is fantastic, because the code is so clean and it uses this really cool idea for caching that they came up with in the shower one morning.
Likewise, the job of a salesperson is to promise everything under the sun to the client, and then produce just enough of what they promised so the client doesn’t get pissed off. Don’t tell the geeks what the sales staff is promising customers, or you’ll start to see bottles of Maalox show up on their desks.
5. Stifle them
Software development is a lot like art. When confronted with the task of drawing a likeness of a person, anyone can draw a stick figure. Likewise, anyone can learn VBA in a few weeks and jam together something to track their coffee expenses. This artistry is one of the reasons why software engineers and mathematicians are not interchangeable. Geeks might not readily compare themselves to artists, but they’re much more on that side of the spectrum than, say, statisticians.
The worst possible thing that you can do to a geek is say: “Here’s a fun and interesting problem, but because of (insert illogical reasons here), you have to solve it in this way only.” Even worse, keep them in the dark about the restrictions until after they’ve finished a creative and effective solution, and then give them some nonsensical reason why it can’t be used, like “Our customers know Java! We can’t possibly sell something that’s not written in Java!”
6. Give them impossible deadlines or ask them to work ridiculous hours
Nothing destroys morale (and by extension productivity) faster than hopelessness. Everyone wants to feel like their work is going to make a difference, so if your geeks believe that success is impossible no matter what they do, they’re not going to bother. Bad morale is viral, too, so it only takes one person on a team to become discouraged for the entire team to be in danger. Worse yet, once they’ve caught the hopelessness bug, ask your geeks to work 14 hour days to meet the impossible deadline. Likewise, if you don’t set reasonable deadlines and instead ask that everything be completed yesterday, don’t be surprised when your geek ignores new requests and continues to work on what they’re already working on. Remember, you said that task was absolutely vital two weeks ago. If every task ends up at #1 priority, it falls to the geek to prioritize them, and that gives them the opportunity to prioritize based on what they want to do on a given day rather than what’s best for the project.
That being said, crunch-time is a reality in almost all software development projects. It’s impossible to perfectly estimate the amount of time required. Dozens of books have been written on the topic and yet no one really has the magical formula. Sometimes the timeframe will be have to be compressed in order to get the contract, or the customer will change their requirements, or there’ll be a flaw in the design that makes you take a couple steps back, or whatever. Asking geeks to work lots and lots of overtime will not yield more work. In fact, there are some very good arguments that stretching the schedule past 40 hours actually results in lowered production, because fatigue creates “negative” work which has to be corrected later during more lucid periods.
7. Make them work on “soul-crushing” projects
Every geek has been involved in, or knows someone who has been involved in, a project that can only be described as “soul-crushing”. The first requirement for a project to be soul-crushing is that the people that work on it consider it to be boring. Geeks, being creative individuals, want to be intellectually stimulated by their work. If they wanted every day at work to be the same, they would get a job driving a truck, or digging ditches. (This is of course not meant to denigrate the truck drivers or ditch diggers of the world. It’s just not my thing.)
There is a difference, however, between projects that are simply routinely boring and projects that are soul-crushing. To rise to the next level of pain, a project must meet other criteria. Here are some examples:
- It requires the creation of hundreds of similar components that are just different enough that they can’t be adequately abstracted.
- Just the development will stretch on for years, with no end in sight. Then, the geeks get to support it for the rest of their natural lives.
- It’s guaranteed to lose the company money. Everyone knows, and no one cares.
- It’s built on a terrible foundation, or it tries to re-use or re-purpose code that should never have seen the light of day in the first place.
Projects don’t start out being soul-crushing. Some projects are horribly uninteresting, but any project can be exciting to the right people under the right conditions. The existence of soul-crushing projects in a company can be a sign that the company is in trouble.
8. Make them misrepresent their work
Salespeople are capable of walking into a company and telling boldfaced lies about the stability or the features of a product. That’s good, because that’s their job. It’s a little like dating… you lie to the other person until they love you for who you really are. Without salespeople, the money would run out before the product *is* stable enough to sell, and the geeks couldn’t cover the monthly bills on their MMORPG habit.
There’s a reason geeks aren’t good at sales. The best geeks are hopeless perfectionists that can never be fully convinced that “good enough” is good enough. When they look at their work, they see it “end-to-end”, through the sexy interface to the flaky API, through to the buggy back-end and the twisted database with 14 bolt-ons that one day, they really, really want to fix if they could just have a little more time before it ships.
This understanding of their software (which you might call “x-ray vision”) allows them to do their job, but at the same time, it makes them doubt the product. They know that there’s a kludge in that function around line 43. They know that the memory requirements are such that the software won’t scale past about 10 concurrent connections given the current hardware. Worst of all, they know that the software hasn’t been tested yet, or if it has been tested, it has dozens of outstanding issues in the bug tracker. None of these things are apparent when all you can see is the sexy interface, which is as far as the salespeople and the customers see.
Unless sales is part of their job description, don’t make geeks lie about their work, not to the customer, not even to their co-workers. Even worse, when they tell you the software’s not ready or that guy in marketing that promised that customer a holographic smell-o-vision interface is nuts, don’t…
9. Ignore them when they know what they’re talking about
Sometimes, there’s a fine line between confidence and egotism. Sometimes, there’s a fine line between giving an honest opinion and crying wolf. If a geek raises the red flag and starts waiving his/her arms at you, pay attention to them at least long enough for them to try to plead their case. If you don’t believe them, don’t just ignore them — reason with them why you disagree. Remember that geeks are, above all else, built on logic. If you think they’re being overly emotional, chances are there’s a reason for it, and you might want to pay it heed. If you don’t take them seriously, it raises the chance significantly that they won’t take you seriously next time.
10. Don’t adequately protect them from customers
First, it’s important that you remember that the customer is not always right. Sometimes customers make stupid requests because they don’t understand what they want, or they don’t understand what they’re asking for. Some customers think using the telephone, and ask for something that they feel will solve a problem before reasoning out the situation on their end. It’s important that you don’t make geeks field too many of these requests. Unless everyone is sitting around playing World of Warcraft because there’s no work to be done, one of your jobs as manager is to triage the resources that you have available.
Unless they’re paid to do so, geeks don’t want to have to figure out what clients want for themselves. They want you to translate the “client-speak” into objectives, which they will then translate into code. If the geeks are spending their time on the front lines, they’re not spending their time in the trenches, making the product better. If their business card doesn’t say “support tech”, don’t put them on tier 1, because this will only result in less code being generated, and one very pissed off developer.
