Recently, I’ve been hearing about more and more companies building “Product Operations” functions. This appears to be especially true of startups with high operational-complexity; particularly marketplaces.
So, what is Product Operations? Do you need it? Or, is it just another fad?
I spoke with several founders/leaders at a number of high-growth and operationally complex startups who have invested in Product Operations functions, including Uber, Thumbtack, and Zipline.
So, what is it?
The definition of “Product Operations” varies somewhat between companies but here are the main themes I hear:
can be part of the Product organization, but distinct from Product Managers
can also report into the Operations organization
works very closely with operational teams
very detail-oriented and data-driven, especially as it relates to process optimization
provides the bridge between the operations teams and Product Managers, solving problems and being supportive, and ensuring communication is effective
The simplistic distinction between Product Management and Product Operations seems to be as follows:
Product Management – “what should we build?”
Product Operations – “is what we’ve built working?”
So, is it a fad?
This is where my own cynicism started and where I got the first whiff of a possible fad.
To me, being very close to customers, even if internal customers, and having a great finger on the pulse of whether what you’ve built is working is a major aspect of any Product Manager’s job. If a Product Manager is not doing that, they’re not a good Product Manager, right?
Pragmatism Rules
Everyone I spoke to agrees with me…in theory.
However, the reality is that it’s very hard to find Product Managers who have a natural affinity for what’s involved in operating a complex business “at the coal face”. This makes sense because most Product Managers come up through the ranks of product and engineering organizations.
Although a Product Manager’s job is to understand and empathize with users, it seems it can be more pragmatic to hire people with an operational background who just more naturally “get it” and put them in a Product Operations role as the go between operation users and the product team.
Put simply, one person I spoke to said that Product Operations “makes sure operations are getting respected” by the Product organization.
What to look for
So, who makes a great Product Operations person? Here’s a summary of what I’ve heard:
have an operational background (vs a product/engineering background)
adaptive
empathetic
data-driven
strong personalities willing to fight for what they think operations needs
Side effects
Are there any undesirable side-effects of introducing a Product Operations function? The consensus seems to be that two problems can occur:
there is some duplication of effort/ownership between the Product Management and Product Operations and therefore some potential ambiguity and politics that needs to be carefully managed. To mitigate this, the distinction between the two functions summarized above must be made very clear to both sides.
the introduction of Product Operations risks Product Managers retreating further to their ivory towers, allowing them to get more divorced from the (internal) customers they serve.
You’re sitting in a quiet meeting when a stranger suddenly bursts into the room, screaming and ranting – what is your immediate reaction?
Your answer might say something about your personality. If your first instinct is to act – perhaps to tackle the person, or run and hide – you’re likely a “doer”. If your first reaction is empathy; to wonder why the person is so upset, you’re probably a “feeler”. Lastly, if your first reaction is purely internal – to consider why the person is so mad – you’re a “thinker”.
This simple personality model – doer, feeler, thinker – is of course just one of many. Like any model, none of us fits perfectly. No one is purely a doer, feeler or thinker (we’d be a weird bunch if we were), but we do tend to have a primary or dominant characteristic. Further, it’s important to be aware of the weaknesses of each of these dominant characteristics.
One of the complimentary comments that several members of the team at Wonolo have said to us over the past 4 years is that they think Yong (CEO), AJ (COO) and yours truly (CTO) are a good exec team because we are all very different.
It’s of course very nice to hear and I think the truth here is that, by compensating for each others’ weaknesses, we achieve more than the sum of our parts.
AJ (COO) is a doer; a man of action. His catchphrase might be “Just Do It”.
Last year, when he heard that the US government recommends people walk 10,000 steps per day, he set himself a goal of doing it every single day. At the time of writing, he’s not missed 1 day in 326 – despite weather, holidays, travel, vacation, etc – not one! It’s hard for me to imagine having the consistency and commitment to achieve this.
Yong is a feeler. We use Slack for internal communication and Yong’s handle is “sobstory” (handles are generally chosen by the team).
I think it’s only right and proper that we have a feeler as a CEO, given that we are in the people business. Yong uses his “sob stories” to motivate and inspire the team and to bring empathy and humanity to our business.
That’s not to say that Yong’s not a thinker and a doer too – as well as being one of the nicest guys I’ve ever met, he’s also one of the hardest working. AJ, too, is one of the smartest people I know. But, again, we’re talking about the the dominant aspect of their personalities.
On the flip side, one weaknesses of “doers” tends to be that their bias to action or impatience can make them act before necessary analysis of all the options is done – doers have a low tolerance for long discussions and theory.
Doers also tend to be highly competitive. AJ’s Slack handle is “bookie” owing to his tendency to bet on anything he thinks he can win.
Being competitive is of course a positive quality in many situations. But, for doers, it can also mean that needing to win the argument is more important than making the right decision, and that achieving the goal can become more important than considering whether the goal in question is actually valuable or important.
As to feelers, their empathy can mean they tend to focus too much on how something feels rather than how it is. It means they struggle with decisions they know are right but which negatively impact people. They can be subject to emotional manipulation by others who know they can exploit the feels.
I myself am a thinker. My Slack handle is “dirtyprofessor” (“knowitall” was another candidate).
As a thinker, one of my weaknesses is that, once I’ve worked out how to do something, I’m less interested in actually doing it. I’m more interested in the theory than the practice; the abstract over the concrete. Learning for the sake of learning is fun for me.
Another weakness is that by being very analytical and data-driven, I can tend to get disconnected from the real-world, human impact.
AJ and Yong, respectively, definitely help counter these weaknesses.
I first met AJ and Yong in the summer of 2014 when they were working on Wonolo inside Coca-Cola. I’d love to say that we immediately saw this complementary set of personal styles and that’s why we decided to join forces but the reality, like many things in startup life, is that we simply Got Lucky.
As I’ve aged and learned, I believe I’ve managed to compensate for the weaknesses of being a “thinker” and become a more rounded person but it’s nice to know that Yong and AJ have my back.
What this experience reminds me of is the importance of recognizing your own weaknesses and not hiring solely in your own image. By hiring people who are different to you, you can compensate for our own weaknesses; your blindside. There are no “right” personality types and no one fits precisely in one bucket but, by having a well-rounded team, you will avoid many pitfalls.
If you asked me to choose the 3 most important things that determine success or failure of a startup, I would say:
company culture – it has a profound and pervasive effect and it’s essential to consciously and deliberately nurture it.
focus – doing many things badly rather than a few things well is surefire startup suicide.
cognitive biases– the cognitive weaknesses of the human brain can if, unrecognized, wreak havoc.
I’d argue that luck is an even bigger factor than any of these 3 but, by definition, luck is outside your control.
So, let’s talk about #3 – Cognitive Biases…
Definition
“A systematic pattern of deviation from rationality in judgment and decision making.”
Despite what you might like to think, your brain is not a rational, logical computer – you’re a human being. Your human brain has limitations. It has bugs.
Cognitive Biases have been experimentally proven (again and again) to exist.
So What?
Cognitive Biases are potentially dangerous to all people and organizations but I think are particularly deadly to startups because:
Startups involve making a series of low-data, high-risk decisions. With limited data, Cognitive Biases have a stronger sway.
People working on startups are often stressed and working long hours, making them more susceptible.
The room for error is often very small because of limited funding runway.
Startups are commonly started and staffed by younger people who have less prior knowledge to counteract the impact of Cognitive Biases.
I believe that understanding and being aware of Cognitive Biases leads to better decision making and that better decision making, on balance, leads to better outcomes.
So, let’s look at 12 Cognitive Biases that I have seen are particularly prevalent and particularly dangerous to startups, and how you might spot them and counter them:
1. Correlation vs Causation
Did you know that sleeping with your shoes on is strongly correlated with waking up with a headache?…
…therefore, sleeping with your shoes on causes headaches!
Of course it doesn’t; this is a classic example of confusing correlation with causation.
For some more amusing examples, Tyler Vigen created a great series of charts over at tylervigen.com. Here’s just one for illustration:
In my experience, confusion between correlation and causation is rife in startups.
Partly it’s the limited availability of data…but I’ve also seen that more data can actually make the problem worse. With so many metrics tools available, people tend to get lost in the data and miss the bigger context.
Startups run at high speed and many things are changing in parallel, with little ability to control variables. For example, on several occasions I’ve worked to optimize conversion in a product funnel and been happy to see that the optimization worked, only to discover later that conversion improved due to an unrelated change elsewhere – e.g. positive media coverage.
Remember to always ask yourself, does A really cause B? Always consider that, perhaps:
B causes A
both A and B are caused by C
A and B effect each other
it’s a coincidence
2. Confirmation Bias
Confirmation Bias is the tendency to search for, interpret, favor and recall information in a way that confirms one’s pre-existing beliefs or hypotheses.
More commonly, you might call it “cherry picking”.
I think that Confirmation Bias is a particular problem for startups because they generally have a lot invested in a particular view of how the world should be (or will be) but have very little solid data to go on, especially at an early stage.
Life at a startup is ambiguous; startups struggle and go through hard-times. Therefore, belief is often what carries a team through the tough times.
Startup founders tend to be “true believers”, with a tendency to get high on their own supply. One aspect of Confirmation Bias is that it can maintain or strengthen beliefs in the face of contrary evidence.
Always ask yourself whether you’re truly open to evidence that contradicts your existing views and beliefs. Startups regularly pivot but often pivot too late.
3. Overconfidence & the Planning Fallacy
“the most pervasive and potentially catastrophic of all the cognitive biases to which human beings fall victim” – Svenson (1981)
Sydney Opera House:
Planned Completion Date: 1963, Planned Cost: $7M
Actual Completion Date: 1973, Actual Cost: $102M
Unfortunately, your confidence in your judgments is reliably greater than the accuracy of those judgments. You are overconfident.
The real kicker is that this is especially true when your confidence is relatively high.
Read that again: you’re probably wrong and the more confident you are that you’re right, the more likely you are to be wrong.
One particular aspect of Overconfidence is what is referred to as the “Planning Fallacy” – most people who are involved in software development are probably familiar with it. The Planning Fallacy is the primary reason that software development projects are almost always late.
The Planning Fallacy is the tendency for people to be overly optimistic in how much time will be needed to achieve a task. Counterintuitively, experience doesn’t seem to eliminate the problem – i.e. knowing that similar tasks have taken longer than expected doesn’t solve the problem.
The good news is that the bias behind the Planning Fallacy can be mitigated with a couple of relatively simple “hacks”:
ask someone else – overconfidence generally only occurs when people are estimating their own tasks and disappears when people are estimating for others. So, never ask the person who will be performing the work how long it will take – ask someone else. Better still, ask a number of other people.
In software development, a common technique is “Planning Poker” where a group of people provide blind estimates (so they don’t influence each other) of how long a task will take and the median is used.
break tasks into smaller chunks – experiments have shown that the estimation for how long it will take to do a task is generally always less that the sum of the sub-tasks once they are broken out.
4. Group Think
“Yes; we are all different!”
“Group Think” is probably a term that most people are familiar with.
My experience is that, in startups, it’s closely linked to the Confirmation Bias problem. As discussed above, startups are carried forward by true believers (founders) and dissent is often considered heretical.
Perhaps the best way to understand Group Think is to look at what people do that makes it happen:
Minimize conflict – with a few exceptions, most people don’t want to fight. Hey, startups are stressful enough. However, there are sometimes necessary conflicts.
Suppress dissenting viewpoints – startup founders are usually, almost by definition, very strongly opinionated and convincing. The flip side of this is that they tend – consciously or otherwise – to stifle viewpoints that contradict their worldview.
Isolate outside influences – some startups have company cultures that are cult-like. While this may be very useful in getting everyone aligned on an objective, taken too far it is dangerous, leading to “not invented here” syndrome and hubris.
Appeal to authority – startup teams must be encouraged to “speak truth to power” and call out the elephant in the room.
5. The Curse of Knowledge
It’s extremely hard to imagine what it’s like to not know what you know. i.e. you can’t “unknow” something. This is the Curse of Knowledge.
In the context of a startup, one of the biggest problems is trying to put yourself in the shoes of your user or customer. The reality is that you can’t. You’re so deep into the problem that you’re trying to solve that it’s impossible to see it in the same way that an outsider would.
This really underlines the importance of doing User Testing on your product using real users, not internal team members. Watching people unfamiliar with your business and the problem you are trying to solve use your product is always extremely revealing. There are always many implicit assumptions that you’ve made and these are only exposed through contact with real users.
6. Anchoring
Anchoring is the tendency to rely too heavily on the first piece of information you get and a tendency not to adjust your position based on further evidence that contradicts it.
Anchoring is what skillful negotiators – e.g. car salespeople – exploit to get the deal they want. The first price discussed tends to anchor the subsequent negotiation.
In a startup, your first customer deal, your first hire, your first customer loss, etc tend to set a mental template for “how things work” with your business. It’s important to periodically ask yourself if you’ve become anchored in a world view that isn’t necessarily correct.
7. Sunk Cost Fallacy
You might call this “flogging a dead horse” or “throwing good money after bad”.
Sunk Cost Fallacy is a tendency to continue to rationalize decisions and actions when faced with increasingly negative outcomes. A “sunk cost” is a cost that you’ve already paid and can’t get back – money that is already spent whether you continue or not.
Sunk Cost Fallacy is, I think, one of the primary reasons that many startups pivot too late and end up running out of money.
Being rigorously data-driven is probably the best antidote to Sunk Cost Fallacy (and other Cognitive Biases). Set specific metrics that need to be achieved by specific dates in order to assess whether a particular initiative or direction is working and hold yourself and your team to them.
8. Attribution Bias
Attribution Bias is the tendency, when evaluating the causes of the behaviors of a person you dislike, to attribute their positive behaviors to the environment and their negative behaviors to the person’s inherent nature.
We all have to work with people we don’t necessarily like. It’s important to realize that we probably can’t accurately understand others’ internal motivations and try not to take personally the behaviors that we consider negative.
9. Ostrich Effect / “The Elephant in the Room”
The Ostrich Effect is the avoidance of risky/difficult situations by pretending they do not exist.
The “elephant in the room” is an obvious truth that is being ignored or going unaddressed.
It’s critical to build a company culture in which people are encourage to call out the elephant in the room. If you don’t, you will be trampled by the elephant.
10. Hindsight Bias
“I knew it all along!” …actually, you didn’t.
Hindsight Bias is our tendency to see an event, after it has occurred, as having been predictable.
Hindsight Bias is a large and fascinating topic. I can’t possibly do it justice here.
It’s unfortunately one of the hardest to counteract. The only known way is to ask whether or not alternate hypotheses and predictions would have been equally believable ahead of time.
11. Survivorship Bias
Ever had a conversation like this? “Uber did X therefore we should be doing X!”
In reality, it’s likely that there were many other companies that did X but which don’t exist anymore…so you won’t be hearing from them.
Survivorship Bias is concentrating on the people or things that “survived” some process and overlooking those that didn’t because of their lack of visibility.
Survivorship Bias is one of my favorites simply because it is extremely common in Silicon Valley. Beware of people claiming that companies succeeded because of specific reasons without data showing that those reasons were in fact the reasons they succeeded.
12. Bias Blindspot
Lastly, we all tend to think of our own perceptions and judgments as being rational, accurate, and free of bias.
In a sample of more than 600 residents of the United States, more than 85% believed they were less biased than the average American.
This is despite the overwhelming amount of experimental evidence that they are not.
Summary
Firstly, forget any idea that you can eliminate these biases – you can’t. However, you can educate yourself about them, build awareness in your team and encourage people to question themselves and call them out when they see them.
Additionally, the #1 thing you can do to help counteract these biases in your startup is be Data Driven. Data of course does not solve all problems but, by asking the right questions and getting accurate answers, you can cut through many Cognitive Biases.
Lastly, it’s important to note that these Cognitive Biases are subtle and pernicious. Companies do not usually fail because of one Cognitive Bias affecting one decision. Instead, the impact Cognitive Biases have is across a series of decisions over time. Be mindful.
Further Reading
There are a few other Cognitive Biases that didn’t quite make the list but which I still think are hugely relevant and I’ve observed in startups:
illusion of validity – belief that additional information generates additional relevant data for predictions, even when it evidently does not
information bias – the tendency to seek information even when it cannot affect action
zero-risk bias – preference for reducing a small risk to zero over a greater reduction in a larger risk
loss aversion – the tendency to focus more on what you might lose from a particular decision than what you might gain
I’m surprised by how often I encounter someone in a leadership role who has never had to fire anyone. I suspect it’s a combination of technology companies generally having pretty flat organizations and also the tendency to have dedicated HR functions in larger companies that insulate people from any “unpleasant business”.
Whenever I’ve had to fire someone, I’ve not slept well the night before. Regardless of the reason, you are changing someone’s life and everyone deserves to be treated humanely. It definitely gets easier after you’ve done it a few times but I hope that it never becomes routine.
Here are my 10 recommendations for how to fire someone humanely:
1. Immediately set the tone of the conversation upfront. It gets super-weird if you have a friendly “how are you?” conversation and then fire someone. I normally get straight down to business and open with “I’m sorry we have to have a difficult conversation today” before the person even sits down.
2. Do not use the word “fire”. The word “fire” creates an emotional reaction – to“fire” someone implies an active act of aggression. I generally say “this will be your last day”. That way, it’s not a value judgment or a process – it’s just a fact.
3. Keep it short. There is no point in dragging it out. But, you should at least give the person a short and true reason as to why it’s happening, unless there is a good legal reason not to.
4. Do not get drawn into arguments. If someone wants to argue, be clear that this is the decision, it’s already made, that you understand they are angry but that it’s not beneficial for either side to drag it out.
5. Have your paperwork in order and be aware of the local employment law. For example, here in CA, it’s the law that you have to give an employee their final pay in the form of a check when they leave.
6. Say you’re sorry it didn’t work out. It helps humanize you in the process. It might seem trite or hollow to say “sorry” but, on balance, I believe it helps soften the blow.
7. Don’t fire someone on a Friday. You’ll read conflicting recommendations in this regard but I am strongly in the camp that says firing someone on a Friday is a Bad Idea(tm). It means they are likely to just seethe about it all weekend. If you fire them during the week, they are more likely to focus on finding another job.
8. Have others ready to cut the cord. You will need to confide in a small group of people ahead of time so they are cued up to terminate account access, etc as soon as the person leaves the room. Create a list of accounts ahead of time so it is not a rush and nothing gets missed. You may be tempted to think something like “I’ll just leave Dave’s email on until the end of the day”. Resist this temptation at all costs. Although this may seem counter to the “being humane” approach, the potential benefits in terms of seeming more humane and feeling better are massively outweighed by the downside risk of the person doing something stupid.
9. Treat the person with respect and try to make it as comfortable as possible. If possible, try to make sure that their team mates are not around to gawp as the person clears their desk, etc. This will again require the confidence of someone you trust.
10. It should not be a surprise. Firing someone should be culmination of a process of clear and honest communication over weeks if not months. If you are a good manager, the person on the receiving end should be clear on the gap between what is expected of them and their performance. With the exception of gross misconduct, if there hasn’t been such a dialogue, you probably shouldn’t be firing the person.
This is of course a topic that many, many others have written about but here’s my quick take on what it means to be a Good Boss(tm).
I took the approach here of thinking first about what I like in a boss. Then I did a quick survey of the people that currently work for me at Razoo to see what they think it means. Here we go:
1. Listen, listen, listen
Sure, sometimes things just need to get done. However, we’re all human beings so we appreciate being heard and empathized with, even if there is nothing our boss can actually do to change the situation or our boss just simply disagrees.
One of my team looks for “quality in response – provide good responses showing understanding with empathy“.
As a boss, part of your role is to be a therapist, like it or not.
2. Set context
Management often focuses too much on the “what” and not enough on the “why”. Not only is the why vital for maintaining motivation – few people enjoy working on tasks that seem pointless or futile – but the context is also a big part of enabling people to think outside the box; it enables people to come up with a different “what” in the service of the same “why”.
As one of my team put it, a Good Boss(tm) “helps the team understand and focus on what’s important“.
3. Define success
As well as telling me what my role and activities mean in the context of the bigger picture, be specific in defining what achieving the objective actually means; the more specific, the better. That way, the danger of a misunderstanding is minimized and trust is maintained.
Couch this success both in terms of what it means for me, the team and for the company as a whole.
“Quantify results – provide measurable metrics for all my requirements,” said one of my team.
4. Give me what I need to be successful
Once you’ve told me what success means, if you’re not giving me the tools, information and support to be successful, you’re setting me up to fail. A Good Boss(tm) realizes that his or her role is to support the team; to be in service of the team, rather than the other way around.
5. Manage me at the right level for me
We’re all different. We arrive at our jobs with differing levels of preparedness for the role. Sometimes we’ve done a very similar job at a very similar company. Other times, it’s a step up for us in responsibility and/or a new industry.
Depending on who I am and my experience, I will need different levels of hand-holding.
By default, a good starting point and principle is to trust me to do the job that I was hired to do, unless and until you have evidence warranting otherwise.
I was also told that a Good Boss(tm) is “respectful of people’s abilities and aspirations but also of their limitations and reality“. Well said.
6. Understand what I need to be motivated in the long-term
A Good Boss(tm) understands that superficial carrots and sticks don’t motivate in the long-term. Doubly so in a knowledge-worker industry like IT, with 100% employment.
Most of the research that’s been done over the past 20-30 years has pretty categorically shown that knowledge workers actually do worse when working towards a reward/bonus. For an interesting and fun example, check out this TED talk on the “marshmallow challenge”. In the software development industry, there’s also this classic from Joel Spolsky.
Feeling like I’m doing a good job, adding value to the business and that my contribution is appreciated by my peers and superiors will motivate me much more in the long-term than any threat, reading of the riot act, bonus scheme or desk ornament.
A Good Boss(tm) has to have the courage to tell it like it is. I would much rather you tell me about concerns or negative feedback immediately, before it festers. If you wait to say something until it has become a Big Issue but I have no idea, trust is lost and the results are almost always bad.
8. Inspire me to be better
A Good Boss(tm) pushes me to continuously improve what I do and how I do it.
As one of my team put it, a Good Boss(tm), “knows how to safely stretch people outside of their comfort zone”.
A good part of this is of course leading by example. A Good Boss(tm) needs to also be “passonate – show that you care about what you do“.
9. Build and nurture a high-performing team
The above points are more about the individual and the 1:1 relationship between boss and employee. Of course, a Good Boss(tm) is fundamentally in the business of building teams that function. This requires an understanding of many issues such as the differences in personality types, learning styles, backgrounds and experiences as well as being good at hiring and managing “up or out”.
A Good Boss(tm) “facilitates healthy discussions, defuses tense/poisonous situation” and “fosters a positive work atmosphere, favors collaboration“.
Again, you’re a therapist; get used to it.
10. Always try to be a better boss
It’s a two-way street. You have to help and inspire others to get better but you also have to continuously strive to get better yourself. A Good Boss(tm), “reaches out to the team constantly to get better at being their boss“.
Thanks to Patrick, Vince, Stephen and Alex who put up with me being their boss and contributed to this post.
I am one of probably a relatively rare breed. I started my career as a software engineer, then moved over to the “dark-side” for a few years but more recently have come full-circle back to running a development organization. I’ve been a CEO, GM, CMO, CTO, VP Corp Dev and VP Bus Dev.
Honestly, I’ve never felt 100% at home on either “side” and I’ve come to accept that this part of the value that I can provide. I am a hybrid that can “translate” between engineers and sales people. Sometimes this causes me an enormous amount of “cognitive dissonance” but mostly it proves useful.
Fighting
Now and again people come to me asking me to help resolve disputes or to explain why engineers don’t respect sales people or sales people don’t respect engineers. Often, the person in question is hopping mad and simply cannot understand the other side’s behavior. This is a quintessential problem for any technology company and I’ve seen it in every company I’ve been involved in. It’s the basis of many a Dilbert strip.
The first step to resolving any dispute is for each side to understand the other. So, this post tries to explain what makes engineers and sales people tick, looking at the differences and similarities.
I have realistic expectations and you should too. I don’t think the “sales versus engineering” dispute will ever be completely resolved in any organization but I do think both sides can cut each other some slack as a result of better understanding.
We are all weirdos
So, at the risk of offending both sides at the outset, the first thing we have to accept is that both sales people and engineers are weirdos.
Sales people are weirdos because their job essentially involves talking to people who don’t want to talk to them, getting rejected again and again and repeating that process day after day. If they weren’t sales people, they’d probably be diagnosed as having a personality disorder. Most “normal” people would quickly become discouraged and demotivated and, once that happens, you can’t sell anymore.
Software engineers are weirdos because they have to talk to computers all day and get them to do what they want them to do. Computers aren’t like people. Computers have no common sense. Computers have no manners. Computers are unforgiving, humorless and pedantic to the extreme. Computers don’t get ambiguity and shades of grey. It’s either precisely right or it’s wrong and it won’t work.
This is partly selection bias – i.e. being a software engineer or sales person attracts a certain kind of person with certain characteristics to start with – but it’s also partly what the job does to you. When I’ve spent long periods writing software, I’ve found myself becoming more like the stereotype of a software engineer – more introverted, more cynical, more negative. If you talk to computers all day, and people much less, you start to think and communicate in a certain way. Likewise, when I’ve been on the front lines talking to customers and trying to close deals, I’ve become more like the sales stereotype – more outgoing, more predisposed to bend the truth.
Stereotypes
As a disclaimer, a lot of what I have to say here involves stereotyping. Stereotypes are useful but there are always exceptions to them. There are extrovert, positive engineers that I’ve met. Honestly, I’ve never met a negative, introverted and cynical sales person but there’s always a first time…
Motivations
When it comes to motivations, let’s start by seeking some common ground:
I believe that both sales people and engineers are, like almost anyone, motivated by the respect of their peers. They want to be respected by people they respect.
However, beyond that, engineers and sales people have fundamentally different motivations and different cultures. That’s where a big part of the conflict originates.
Engineers are generally motivated by learning new things, understanding abstract ideas and doing smart things. In the eyes of their peers, they want to be regarded as being clever.
An important thing to realize here (and one of the perennial problems with managing development teams) is that being clever has nothing directly to do with getting things done. Software is never “done” and there are many extraordinarily clever software engineers who are very bad at delivery and will happily tinker with any software indefinitely, if left to their own devices.
In terms of an engineer’s motivations, the means are often more interesting, and therefore more important, than the ends.
In contrast, sales people are generally motivated by building relationships, achieving objectives and winning. In the eyes of their peers, they want to be regarded as being successful.
For a sales person, the means only exist to serve the end – getting the deal done. This leads to the perennial problem of sales people over-promising to get a deal done.
Personality Type
Engineers are generally introverts, sales people are generally extroverts.
The distinction between extrovert and introvert is commonly misunderstood and oversimplified as being simply whether you are socially outgoing or reserved. That is true to some extent but misses more fundamental differences between the way the two types think and interact with others.
Extroverts think out-loud. They find interaction with other people energizing. They solve problems and get things done by externalizing them – talking about them with others. To an extrovert, having a meeting to talk about something is getting the job done.
Introverts think internally. They find interaction with other people draining. They like to get their thoughts straight before they externalize them. They solve problems by working on their own until they have a solution they’re happy with. To an introvert, having a meeting to talk about something gets in the way of getting the job done.
Beyond the simple introvert versus extrovert distinction, there are other common distinctions. For example, if you’re into Myers-Briggs personality types, the stereotype engineer is an INTP (Introverted, iNtuitive, Thinker, Perceiver). A fuller discussion of this topic is an attractive rat-hole but I will resist the temptation.
A typical day
A sales person’s typical day is very different to an engineer’s.
The sales person’s day is generally driven by a series of scheduled calls and meetings, each with a determined start and end time and, hopefully, clear objectives. A sales person’s typical day is largely focused on a lot of communication with other human beings. Outside of scheduled meetings, it is also commonly “interrupt driven” – e.g. a potential customer calls and you pick up the phone and talk to them.
The engineer’s day is generally driven by long periods (sometimes extremely long) of concentrated, heads-down thinking around solving a particular problem.
You can only be effective in this mode if you can be truly focused and able to get into a state of flow (also referred to as “being in the zone”). On any given day, it takes time to establish focus and it is very easily broken. Unfortunately, once its broken you can write off the rest of the hour, and sometimes the day. Different people have differing abilities to get themselves into the zone quickly and at will but it’s definitely a big issue – it’s not just a question of time lost but you’re also much more likely to introduce defects into software if your train of thought is interrupted.
This is where another very common source of conflict comes in. You’ve probably witnessed something like this firsthand yourself: the sales person gets a call from a potential customer that is close to signing a deal. The customer has one remaining technical question that the sales person cannot answer directly. Being an extrovert and being motivated to please the customer and get the deal closed, the sales person doesn’t send an email but rather calls or walks over to the engineer with the customer on the phone still to ask the question…
The engineer emerges from what seems like a dream like state and stares blankly at the sales person. The engineer is pissy and, if the sales person is lucky, answers the question, albeit in an extremely terse way.
The sales person doesn’t understand why the engineer is being so difficult and unpleasant, especially given that this is a question from a customer that is about to sign a big deal. On the other hand, the engineer is annoyed because the sales person has just interrupted their flow and they know they’ll find it hard to get back into what they were working on.
Furthermore, the engineer doesn’t understand why the sales person couldn’t answer the problem for himself. After all, the engineer’s motivation is to understand things and seem clever so they don’t get why the sales person wasn’t as interested as they would have been to work out the answer themselves on their own, rather than appearing dumb by having to ask someone else.
In contrast, the sales person doesn’t understand why the engineer doesn’t care about winning the deal.
However, once you understand the difference in motivations and cultures, it makes sense.
Culture
Along with the differences in personality type and motivation, come some big differences in culture.
If high school is a microcosm of “real life”, think of it this way: sales people are the jocks and the engineers are the nerds that got pushed into their lockers in the hall every day by the jocks.
Digging a bit deeper, let’s look at what it takes for a sales person to be successful:
Sales is about building and finessing a story that sells. Contrary to what the other side may think, it’s not generally about telling out-and-out lies but it is about managing perception and, for the sales person, perception is reality.
That story and that perception is fragile and needs to be carefully massaged and continuously buoyed-up.
Likewise, because the sales person faces continual rejection, day after day, the sales people themselves need careful and continual massage. This makes sales people generally very sensitive to people who come along and burst their bubble by asking hard questions or being negative.
Unfortunately, this is exactly what engineers tend to do. Engineers are extremely suspicious, and often downright hostile, to the “story” that sales people are selling – they see it as artifice, fakery, puffery.
Is this simply because engineers are cynical, negative people? Sort of – but, the problem is confusing cause with effect. Engineers are cynical and negative because it’s essential to doing their job well. Remember that, when you’re dealing with a computer, there is no perception, there are no shades of grey – it’s either exactly right or it’s wrong.
Therefore, engineering culture is deliberately extremely suspicious of, and aggressively hunts down and eliminates, artifice and “perception management” because it hides the truth and the right answer. It is kryptonite to the engineering process.
People who try to manage perception don’t survive very long as engineers because they have to tell computers what to do and computers aren’t having any of it. In contrast, managing perception is what sales people do for a living.
This all results in two very different cultures. Sales culture requires being buoyed up on a cushion of positivity, whereas engineering culture requires negativity and challenging everything.
Religious Arguments
A side effect of the engineering culture is to spend many hours engaging in what are referred to as “religious arguments” – Python versus Ruby, Mac versus PC, etc, etc, etc.
Because engineers and engineering culture is wired to seek and find the one correct answer, engineers have trouble dealing with the concept of differences in opinion and equally valid choices.
VibratingMelon 