Why we all need to know sales

Three scenarios and a model

Not (necessarily) like this.

I’m part of a small peer group of software engineers that meet informally roughly once a quarter. One topic that comes up, to state it vaguely: “how does one drive influence in their respective organization?”

Naturally, this topic leads the conversation to various influence and persuasion models from the business domains of sales, marketing, and public speaking. Which initially struck me as odd, as one would expect a group of software engineers to talk about, well, topics falling squarely within the software engineering domain.

But when you think about it, it’s actually not odd at all. As professionals striving to improve our ways of working, we constantly find ourselves butting up against decisions that have been made for us. Or if not decisions, then assumptions (if we’re lucky, it’s the latter).

So let’s say we have some flexibility in changing the conditions we find ourselves in when we set off on the goal of doing our best work. We still don’t work in isolation (and in fact should never aspire to), which means it’s our co-workers who we then have to win over, to the “better way” as we see it, while still leaving room in our minds to be thoroughly refuted.

Scenarios

I hope I haven’t lost you. Let me drive my point home with some scenarios.

1. You, the architect on the team, reviews a PR¹ for an ostensibly minor change that makes the existing architecture marginally worse.

Should you reject the PR and tell the PR author to fix the architecture, getting them to re-submit a new PR with their attempt (leading to a major change being proposed)? Or should you accept the PR and take it on yourself to fix the architecture? Or none of the above?

2. A Product Manager (PM) asks you, the Team Lead (TL) to estimate the backlog of a team, while also asking you to do it without bothering her team-mates, so they can focus on completing the existing WIP.

Let’s also assume that, as a principle, you believe in either collaborative estimation, or no estimation at all. Should you then go against your principles and capitulate to the PM? Or should you ignore the PM’s request (they’re not your boss after all, and you’re pretty sure that you’ll get away with it)? Or none of the above?

3. You, a senior engineer, joins a team that is split into two sub-teams with their own codebases — a “backend” team that owns an API and a “frontend” team that owns the UX that consumed said API.

From your experience, you know that organizing teams this way generates far more waste than organizing as one team with a similar mix of skillsets but with a shared ownership across the entire “stack”. Do you complain daily to your co-workers about how inefficient the current setup is, while grudgingly rolling code? Or do you instead save your complaints for your exit interview, after you’ve given notice of resignation? Or none of the above?

If you were at least inclined to answer, “none of the above” to any of the above scenarios, then you likely understand why the topic of “influence” comes up so often at my peer group.

---

“All models are wrong, but some are useful.”
— George E. P. Box (Statistician)

I’ve learned of a few useful models for resolving scenarios such as the ones described above. I’ll end this post with the first model that was introduced to me near the start of my career.

Levels of Awareness

About a dozen years ago I worked at a startup called Fusenet. You won’t find any reference of it today, as it eventually morphed into Audiobooks.com (a story for another time). As the first hire, I was very vested in how we ran things, especially when it came to software development. In particular, I felt that we needed to be more Agile.

I would go on about how we needed to adopt more Agile practices, but my pleas fell on deaf ears. I realized why my efforts kept failing when our executive coach pointed out this model to me.

The model originates from Breakthrough Advertising by Eugene M Schwartz. Written in the decade of Mad Men (the 1960s), it is impressive (yet perhaps not surprising) that it still holds relevance. The model states that a product or service has to pass through Five Levels of Awareness until a sale can close:

1. Unaware: This is when a person doesn’t know that they need something, or they don’t understand why it’s important to them. They may believe their existing situation is all there is.

2. Problem Aware: A problem-aware individual understands what the issue is, but doesn’t know how to solve it.

3. Solution Aware: A solution-aware individual has been shown the way out, but they need a little nudge in that direction for something beyond their comfort zone. They know what needs to be done, and they’re willing to do it.

4. Product Aware: Customers who are product-aware have seen your message before — they know who you are and that your product / service can help them

5. Most Aware: A person who is Most Aware is ready to go. The next step is the logistics (i.e. taking payment, product delivery, scheduling an appointment etc.)

The first step is to understand what level you’re selling at, then tailor the message appropriately. In my case, I was pitching at a level of awareness of 2, while the other managers were still at level 1. They didn’t see a problem.

Here’s another important insight of the model: as you attempt to sell at lower levels of awareness, the effort required increases exponentially; it is X times harder to sell at a level 2 than at a level 3 (see the above diagram for a visual depiction).

I learned this the hard way when founding my second startup: an app that matched real estate agents with buyers and sellers by allowing them to compete on commission and rebates transparently. Even if the preceding sentence alone explains the concept effectively to you, I still have to convince you why it’s better than the status quo. Before I sell the product, I have to sell the concept. This is near-impossible to accomplish via search engine marketing, for example (what do your customers google for?).

Wrap-up

Levels of Awareness is just one of many mental models that I find helpful when putting forward potential solutions to perceived problems. In a follow-up post, I’ll present a few others. However, I’m curious to learn how you approach this challenge, if at all. Do let me know!

1. Pull Request. A common way for a Software Engineer to propose a change to a codebase while also collecting feedback on the change.