Never Use Team Meetings to Sell New Software Engineering Ideas

As a software engineer the ability to ‘sell’ is not something I had considered important early in my career. I thought in the technical world of writing code our ability to influence people should be based on technical prowess not sales tactics.

But when I started Logic Room, I was faced with the problem of bringing on new clients; I had never been much of a salesperson so I invested in some coaching to learn how to sell. I enlisted the help of a sales coach…

Selling To Groups

One of the first things my coach told me is that selling in groups is tricky. The reason for this is because people in groups tend to follow a herd mentality. They are often pressed for time and let’s face it; software engineers hate meetings. For this reason, presenting ideas can often be met with resistance of many different angles.

It’s almost impossible to debate and argue each point individually with people in a group. And for this reason, if you have a great idea, even if you hold a good standing in that group, you will no doubt meet resistance. What’s worse if your attempt to sell an idea on meeting number 1 fails good look getting it to meeting number 2.

You run the risk of becoming a stuck record; you could find your ideas put to sleep before they had a chance to percolate!

Selling One-to-One

A much better approach is to use what I like to call the Serengeti approach. This approach treats the selling of ideas more like an archetypal hunt! With you as the hunter; and your team as the herd of gazelle that need to be picked off, one by one!

With the Serengeti approach you ditch the idea of bringing it to the group. Instead, you sell your ideas one on one, to individuals directly in your team. Once you have picked off the lone gazelles then you can bring your idea to the group once you have support!

Because when you do this, you will find that people are more patient with you and are more likely to give you honest appraisal of your ideas. In fact we teach this approach in our UI Architecture Academy; because some of the ideas we teach are quite different to the typical approach a team may take; we get our students to find an ally first to help them adopt the new approach they learn with us. And it totally works; in fact 70% of our students successfully introduce our concepts into their teams...

The Serengeti Sales Approach

There are two basic steps to selling your ideas one to one.

Firstly, you should be equipped with the exact problem you are trying to solve. For example, if you want to suggest a new architectural paradigm then it’s not enough to have your idea and code samples. You should start with the ‘why’. This idea should be fully rooted in the exact problem you are trying to propose. This problem should be rooted in the exact problem not as you see it but as the people you are selling it to…

For example, if you wanted to sell the idea of automated testing, you should identify the sorts of workflow problems that the engineers on your team hate; that testing can solve. By figuring this out you immediately add relevance to the problem.

Once you know this you should start by identifying the most likely person on your team that has this problem and that is likely to agree with you. Once you do this then you … set a meeting with just that one person – you can call this person your ally!

In this meeting you can approach it very softly and really ask them for their thoughts and feedback on your idea. People are much more likely to accept your ideas when you approach it humbly with a sense of humility.

Even if they disagree with you on this meeting, it still gives you some time to pick away at them gently and convince them over a number of meetings. So, you start the process of selling it to the team by selling it to just this person, do that job well before trying to throw it into the hungry pack of lions in the group.

If after convincing this person (and it may take you a few meetings) you can then begin to involve more people. Now instead of blurting out your idea in a group and having it shot down, you stand a much better chance. Doing it one member at a time, starting with someone who most closely shares your values, ideas or historical reference points is the best way to go.

Conclusion 

In our rush to excitedly propose new ideas, as SWE's we often default to introducing our new ideas in retros, planning or other meetings. But discussing anything too radical in groups is risky; gives little time for you to fully explain or for people to fully understand.

Instead, you should seed ideas with close allies first and work on your proposal until you have them fully convinced. Afterwards you can develop your ideas with your allies to introduce further into your team. What could start as a 1 stop no, could turn into a 4 stop maybe, maybe, maybe yes. This is good for you as a leader, and your team as the beneficiary.


Author: Pete Heard

Pete is the founder of Logic Room. He designs the companies core material for JavaScript architecture, test automation and software team leadership.

LinkedIn

Want to learn 5 critical lessons for framework-agnostic JavaScript UI app design and structure?

Download our 28-page book exploring big picture ideas to help you create better architecture with any UI framework (inc. React, Angular or Vue).

Download
Close

50% Complete

Book Trial

Please fill out your details if you would like to trial our system.