The 6 Types of Software Engineers: Identification, Care and Feeding
The Cranky Product Manager is on vacation, but in her stead the CPM found a WICKED AWESOME guest blogger, an extremely talented writer/product manager/mom with the nom de plume “Another PM.” Her post is below, and it is so good and so TRUE… Damn, the Cranky Product Manager wishes she wrote it herself.
Please give “Another PM” feedback in the comments. We bloggers live for comments.
Enjoy and see you in a week or two or six.
The Identification, Care and Feeding of Engineers on Your Projects
by Another PM
Ah, Software Engineers. They are the creatures upon whom most of us rely in order for our organizations to continue claiming that we are the World’s Most Leading Global Provider of Integrated Buzzword Solution Suites (now, with Go-Green marketing!). To be a successful Product Manager in the software development world, you must understand the dynamics of your project team members, and of course engineers are a critical part of that team.
Early identification of the various engineering types on your project can save you time and effort down the road. So, grab your safari jacket, your notebook and a pen, and follow me into the jungle of 0’s, 1’s and bugs of all stinging severities. This post will help you to recognize some common engineering species, and how best to work (or not work) with them.1
Shortcuts: 1. The Veteran 2. The Hotshot, 3. The Great One, 4. The Teflon-gineer, 5. “Offshore”, 6. The Maverick
He’s been here for five years, and he’ll be here for five more.
Distinguishing Characteristics
- Cranky.
- For some reason, he’s permitted to use profanity in meetings and otherwise behave in ways that would make his mother cringe and your company’s attorneys start job hunting.
- Casual Friday dress is too formal. Facial hair is common.
- You’re never in on his private jokes.
- He’s eaten 5 Product Managers before you, and he will chew through 5 more after you’re gone.
- His manager is afraid of him. He’s eaten through 5 managers before this one, and he’ll chew through … etc.
- Yes, he is always a “he”.
Do you need this engineer?
Yes. He has the best only knowledge of your product’s undocumented, spaghetti code and he knows it, which is why he will never support projects aimed at documenting it. Also, if left ungoverned he can negatively impact the other engineers (except for any offshore team members, which he does not really consider to be part of his team.)
Project Pitfalls:
He can smell fear and ignorance, so don’t defer to him too quickly and don’t ask dumb questions. You’re toast the second you utter your first corporate buzzword in his presence. If he gives you a nickname such as “MBA,” you’re screwed.
Achilles Heel:
He wants to tell his project war stories, like how f-d up the project before this one was, and which “business people” on the project couldn’t handle the stress. He’s happiest when reminiscing about Assembler, or about launch 1.x of the product (which is now in V8.3)
Best Bet:
Bring food. Listen to his stories. Defer to his expertise on architecture, even if you think it’s wrong, because he’s probably right. Do this publicly, so he wins. But the architecture battle is your pawn: don’t compromise on anything user-facing, because if he discovers that can scope-cut one critical user-facing feature, this will set the pattern of your relationship.
Smart and knows it, often quite young. Has great ideas and hacks crap together at midnight, then… is done.
Distinguishing Characteristics:
- Unfortunately has little appreciation for what it takes to actually ship software and thus never really finishes his features and his stuff is often fragile or just broken. Can’t be bothered with making sure his stuff is internationalized, thread-safe or designed to scale.
- Can’t be troubled to fix what he built because he’s on to the next thing.
- Detests “process” and all the process hangers-ons like QA, PM, Training, and Project/Program Managers.
- Doesn’t read the documentation OR reads the documentation and codes something “better.”
- Says things that annoy his fellow engineers and managers like, “If it takes Ed more than 2 days to do this feature, then he is seriously stupid.” But of course, Young Hot Shot never actually added a real feature in just 2 days either.
- Rarely seen without headphones or earbuds. Plays World of Warcraft and Halo.
- Drinks Red Bull and stacks empty cans up in his cube as some sort of offering to the God of Unmaintainable Software.
- All shirts purchased from threadless.com. Appears to either skate or snowboard. Green IM status 24/7.
- Natural habitat is start up environments.
Do you need this engineer?
Depends on whether you’re building something that a person will eventually need to use.
Project Pitfalls:
None, really, because you are not even on his radar.
Achilles Heel:
Cannot build evolvable, sustainable software.
Best Bet:
Convince him he’s a genius who really belongs in your company’s “Innovation” or R&D group.
Where did this engineer come from, and can you have five more of him?
Distinguishing Characteristics:
- Always delivers on schedule, even when unforeseen code bottlenecks require more time that initially estimated.
- If unforeseen bottlenecks arise, you don’t hear about it from this engineer. Instead, you hear about how this engineer worked all weekend from one of his peers.
- Respected by engineering peers. Professional in meetings.
- Honest with estimates.
- May have a Star Trek accent or a superhero fetish. Loves watching “How It’s Made”.
- Solid code, sometimes delivers more than what was requested.
- After the feature is launched, asks whether it met the users’ needs.
- Keeps up with his bug queue.
Do you need this engineer?
Um, duh.
Project Pitfalls:
Try not to hug this engineer in public. He gets embarrassed and human contact is sometimes confusing.
Achilles Heel:
This engineer is so dependable that his manager tends to put him on every project. He sometimes has trouble saying “no”, so can become overstretched. Also he tends to be optimistic in his estimates.
Best Bet:
- Give lots of public credit to this engineer, even if he doesn’t care about that — because his peers might.
- Send nice notes to his management.
- Don’t ask him to attend time-waster meetings, but if he must, publicly change the agenda to accommodate his part first so he can leave quickly.
- Add time to his initial estimates to buy him some wiggle room.
- Play Halo with him Bring him food.
- Ask how you can help him, and ask often.
- Encourage this engineer to breed.
Will do anything to reduce his work. If you’ve asked for a sports car, this engineer will try his/her damnedest to meet your requirements with a Model T Ford. Deflects all bug assignments with his/her Teflon Work Deflector (in size J for Jerk).
Distinguishing Characteristics:
- Says things like, “Are you sure the users really want that?” and “Is XYZ functionality really that important? How many users did you talk to? Can I see your notes?”
- Reassigns his bugs back to you with updates like, “Please provide more clarity”, even when you’ve already referenced the spec page and section which spells out the original requirements with blinding clarity. When you reassign the bug back to him, you get his Out Of Office response.
- Attempts to lock you into a legal contract specifying everything down to the last minimalist kilobyte of code that will be written.
- During spec reviews or Scrum, says things like “Oh, you want the page to validate the user’s password entry? Well that will cost you an extra 2 days of work…plus another day if you want that alpha tested.”
- Attempts to break your will to live with never-ending requests for excruciatingly documented detail to the point where it would be faster to code it yourself (inclusive of the time it would take you to learn Python).
- When he delivers, his code is solidly mediocre. He never surprises, never innovates, and never has ideas.
- Even his peers think he’s kind of a jerk.
- Likes to watch When Animals Attack.
Project Pitfalls:
Serving your sentence for justifiable homicide will impede the project schedule.
Do you need this engineer?
Did you need your sibling to hold his finger one inch from your nose and say I’m not touching you. I’m not touching you. I’m not touching you…4
Achilles Heel:
His manager thinks he’s a jerk, too.
Best Bet:
Get this engineer off your project. Confront him/her, document as much of this crap as you can, then confront his manager. No good can come of this.
“Offshore”
Where are these guys, anyway, and what time is it there? Who knows; you always have to count the time difference on your fingers.
But anyway, they seem very nice, and they do try to read the documentation. They just don’t always understand it and it’s not their fault that they were home sleeping when those critical changes were decided last week.
Distinguishing Characteristics:
- Located in Malaysia, China, or a former Eastern Bloc country. (Ukraine is the new India).
- Their proper English is downright charming.
- Sometimes they say they understand when you know they don’t.
- They make a lot more work for you, including having to attend 9PM meetings. On the upside, it is nice to have a glass of wine in your PJs while discussing the desired behavior of wildly far-flung corner cases for no other benefit than that of QA.
- Will often do the needful.
- Sometimes their code isn’t great. But, as I have mentioned, they are generally quite polite.
- ARE ULTIMATELY NOT CHEAPER. But we’ll let CPM cover that topic separately.
Project Pitfalls:
Too many to count on your hands.
Achilles heel:
Communications.
Best Bet:
- Document the hell out of your requirements and functional specs.
- Provide completed mock sets,including exception scenarios.
- Keep up with change requests.
- Meet with them often, and for God’s sake speak slowly (but not louder, because duh) and speak clearly
- Stop the meeting conversation often to see if they have any questions.
- Also, I know you don’t want to hear this, but for best results, you really should just go there for a week or so.
He’ll do your feature IF he can do it in Ruby on Rails. Or Haskell. Or Python. Or <other hot new language that his peers don’t know and therefore can’t evolve or maintain.>
Distinguishing Characteristics:
- Smart. Creative.
- Doesn’t want to build on or maintain the existing codebase (because it’s a spaghetti nightmare AND because it’s written in Java, which is sooo passe), so he’ll roll his own. This will include the creation of an exotic protocol and adapter layer so that the old code can call his code.
- Dependable — if you let him do it his way.
- Magically finds his way off the project if he is not permitted to build in his preferred language.
Project Pitfalls:
Oh, you’ll get your feature all right, and you’ll get it on time and it’ll probably be done well and it may even delight you and your users, but once that guy leaves someone is going to have to refactor it in order to evolve it. And we all know there are few words a PM likes less than “refactor”.
Achilles Heel:
Back in my hometown, we used to say “That dog won’t hunt” when referring to someone who simply and inexplicably will not do the obvious, such as build on the tech stack into which he was hired.
Do you need this engineer?
Maybe you could aim this smart engineer at a custom one-off or a stand alone widget that doesn’t need to be evolved or maintained. No.
Best Bet:
Be prepared to make your perfectly reasonable case for building the feature in the existing language in a public forum. Make said case without emotion, and in front of his peers & manager because, trust me, they don’t want to support his alien creation any more than you want to.
1. Caveat: I have only done eng-thropological field work in limited sections of North America,so please comment with your own archetype additions and corrections. Perhaps together we can create a collective academic body of work for Steve Johnson’s Pragmatic Marketing Product Management courses.
2. I apologize for the heavy use of the male gender in this post. I tried hard to make these descriptions work using gender neutral pronouns, but it sounded awkward. In the end, the truth of my experiences won over: almost all of the engineers with whom I have worked over the years are men, but duh of course we all know that women are engineers, too.
3. The Hotshot is CPM’s entry.
4. Shout out to Suburban Bliss for reminding me about this game.
Comments
18 Responses to “The 6 Types of Software Engineers: Identification, Care and Feeding”
Leave a Reply
-
-
Sponsors
Enjoyable read, right on the money!
It is very differenet in other Geo’s
However, there is one rule that apply to them all…
did you notice that the deeper low level the code the engineer writes the morethe dressing code loosens
A kernel engineer can come to work with boxers, crocs & some old t-shirt
while a GUI developer will always look sharp, with nice ironed shirts, in the pants, etc.. After all he is user interface…
I could write a similar post about the Israeli engineers but it will take some time
The sketches are Japanese cartoons style and so on. But they’re just sketches.
Here you are:
http://picasaweb.google.com/tblkba/The6TypesOfSoftwareEngineers?pli=1&gsessionid=yJP211-y3f78jn6aCHAJUw
AHHHHHHHHHHH, so true! Especially the physical description, the profanity in meetings - EVERYTHING!
God, I’m so glad I’m not the only one! This is like a support group - very therapuetic!
Painfully accurate! The only problem with The Great One is that often when they’re surrounded by the other types, they decide to find a new environmental niche. Especially if one of their mentors leaves the company - they’ll often follow him or her.
Awesome post… sooo right on.
Highly entertaining and so right on. Two suggestions:
* I miss “The Shy One”.
* I’ve never met a Maverick. They don’t seem to exist in mid-europe.
Great exposure. Somehow anonymous guest-blogging must become a resume builder. we will work on that for you. Congrats!
I like watching “How It’s Made” …
From a programmer’s point of view, I think the whole thing degrading, evaluating programmers not as people but as clichés. The easy thing for me would have been to write an equally degrading view of PMs; Instead, I decided to take the high road: I got together with some of my peers to discuss the characteristics of a PM. The conclusion: PMs have but two configuration variables from which all interactions with them derive. Read more here:
http://blog.radvision.com/codeofcontact/2008/09/10/your-product-manager-configuration-and-you/
You forgot about “The Imposter”
- Thinks he is the smartest person in the country.
- He loves to brag/exaggerate about previous accomplishments.
- Thinks he can tell everyone how to do their jobs.
- Regularly interrupts you and completes your sentences incorrectly
- A good programmer with a bad case of the god-complex.
- He will definitely not stick to any kind of project plan, except his own. Subsequently, he’ll blame defects which are directly related to his non-compliance on the development process.
Soooooo true !!!!! Incredible !!!
Thanks for releaving us all =)
[...] the Cranky Product Manager found this awesome comment on the “Six Types of Engineers” post. “From a programmer’s point of view, I [...]
[...] revenue quarter over quarter, for her stock options to be worth something again one day, for the Teflon-gineer to be kept off her product, [...]
[...] so, maybe you could whip up a drawing of each of the "The 6 Types of Engineers" that could accompany the post of the same [...]
[...] tethered to a communal table in a stifling hot “War Room,” inhaling the body odor of The Veteran, trying to tune-out the grandstanding arguments between two nimrod Hotshots (“My idea is [...]
I have another sub-type.
The Clockwork Mouse
This engineer type is unique from the others because it is often a female. The Clockwork Mouse works consistently, quietly, and diligently on any project, sub-project, or tiny little feature that is given to them. They are the perfect engineer to assign that boring file conversion job to.
Distinguishing Characteristics
Rarely leaves the safe haven of the cube. Must be forced to join meetings.
People often ask how long that person has worked here when the Clockwork Mouse is seen outside the cube even if the Mouse has worked there longer than the person asking.
Often talks with a very meek voice and is unwilling to contradict anybody even when they clearly know the right answer.
Nobody knows what this engineer does on their personal time.
Will consistently finish projects on time in the most bland manner as possible.
Their sense of interface design is non-existent. The interface will either be horribly complex and confusing or so primitive as to make you wonder if if a C:\ prompt would be better.
They often code something completely different than the specs because they are afraid to ask questions.
Project Pitfalls
You may not know this engineer is actually on your project
Achilles Heal
Any type of social interaction will cause so much stress that the Clockwork Mouse may blow a spring.
Best Bet
Assign non-interface related projects that are intricate, yet boring. The mouse will thrive in this environment.
Wow. Just came across this and already it is in my development hall of fame! One tip for the manager of Eric’s Clockwork Mouse: try this person in a QA position. I did and they flourished!