The three engineers you meet in product management heavenby Commentary |
Today is a good day to gloat that I am a product manager. After all, The White House just appointed their first Director of Product Management. With over a decade of experience in similar roles, I have basked with my team on sunny days. Naturally, I have also been pelted by rainy ones.
Good days at work motivate tears of joy and tension in equal parts. Solid product teams push their mates to reach beyond comfortable answers. Occasionally, the imagination of a team member meanders outside the realm of feasible solutions. Then his team pulls him back to the planet where people have to ship something within constraints. Crews that have mastered this tug-of-war between imagination and creation, often land on breakthrough product concepts.
When the weather is downcast, however, then one of two things happen: there is a lot of talk and a little code. Or there is a lot of beautiful code but no product—i.e. a problem not worth solving has been elegantly resolved.
For product managers, the climate at work is largely affected by interactions with the engineers on the team. Perhaps this is the case because the throughput and quality of an engineer’s output hinge on inputs from an individual in my role. Meanwhile, product managers have little to show for their hard work if the engineering team doesn’t produce anything. Below I introduce you to three personas of my code producing peers along with tips on how we productively worked together.
Silent force
They think hard and listen even harder. They are thoughtful and analytical in their approach. They offer researched facts over impassioned opinions. Rarely, if ever, do they rely on superlatives to describe anything i.e. their mind is never #blown.
Unfazed by a long haul, they are great with complex problems that need steady hands to work patiently and carefully. These self-motivated individuals can work alone or in teams with big personalities.
Rules of engagement: Engage these engineers as early as possible. They need a heads-up so they can ramp up their knowledge and carry out analysis independently, from which they gain confidence. These dependable and prolific team players forget to brag about their achievements, so do it on their behalf.
Dark side of their force: They are wary of people with fuzzy work styles or who can’t bridge from the big picture to the details e.g. from the roadmap to features to edge- cases.
They don’t like to be rushed into decisions or commitments. When repeatedly cornered into such situations they take on an excessively pessimistic stance.
Fast and (a tad) furious
If I sketched an avatar of these quick thinkers, then it would sport all the latest gadgets, on-trend outfits, and have at least a bazillion light bulbs hovering over their heads. These worker bees juggle many side gigs and are always game to tinker with the latest idea, technology or problem.
Rules of engagement: To this brand of engineers conceiving ideas for the product is just as important as building it. Involve them before you have cracked all the puzzles and thought through all the details. Also, they take a lot of pride in their work so schedule frequent demo-days so they can show off their craft and get feedback to make it better.
Dark side of their force: It pains them to ship even one line of shoddy code. Ensuring the beauty of what they produce may take precedence over deadlines. They drag their feet when asked to work with stale technology and legacy systems (barf). They are individual contributors, so they get a little furious when they have to pause their real job(s) to mentor people or coddle clients.
Full-stack(ish) product person
These hybrid employees can toggle between modes of product manager and engineer. They can empathize with the end users and design and evaluate business models. Presentations, people and politics are not dirty words in their dictionary.
Rules of engagement: First, you need to find them. These unicorns are not easy to locate or afford. When you do, then frequently rotate them between the two roles so they can continue to hone their skills in both domains. This suggestion should not be confused with staffing them to shoulder dual responsibilities simultaneously—the separation of concerns related to customers and product is key.
Dark side of their force: Their engineering pedigree can cause them to jump to solutions a little too quickly. Unchecked they may converge on answers before defining the problem adequately. During development phases, however, when it is time to stop debating options and start developing something, they may continue to question assumptions and rehash past decisions.
The three archetypes that you met are rough sketches that represent a narrow sample of my colleagues from the engineering department. The takeaway is that product teams should blur organizational lines that divide roles and responsibilities. We already cater to the needs, stories and motivations of people we build stuff for. We should do the same for the people we build stuff with.
Find Natasha on Twitter at @natashaawasthi. We welcome your comments atideas@qz.com.
