- Software engineers are spoiled for job choice, so companies that want to hire them need to show them what's in it for them (beyond a salary).
- Connecting software developers with customers can help developers solve problems.
- Think of your hiring process as a sales funnel and qualify prospects as you go, aiming for the best cultural fit.
Steve Garrity
SAN FRANCISCO — “The best engineers can always get jobs — it’s not hard,” noted Steve Garrity of Hearsay Systems. So how are you supposed to find the very best people to build your real estate software?
On stage at Hacker Connect, part of the programming at Inman Connect San Francisco, Garrity explained how his company was able to build a culture that draws high-quality software engineers.
What kind of software engineering company are you?
Garrity discussed three different software engineering philosophies that he sees.
There’s a traditional enterprise developer, working on a stack “designed by/for your parents,” big teams with big specs, slow and bureaucratic decision-making, disconnection between developers and customers, and “just trying to catch up with what sales promised” the end user.
Then there’s a “consumer” or more modern developer — these are engineers who are most likely to be working on the latest, greatest social media software. They’re characterized by small teams, rapid iteration cycles, data-driven user testing, experimentation with new technology and making decisions close to the product technology … and because they’re moving so quickly, security might not be their forte.
That can be a really fun environment for an engineer, but it may not make the most stable software. “Security’s a really reasonable complaint against these fast-moving teams,” noted Garrity — they don’t always test thoroughly before they ship.
Take Snapchat as an example of a consumer-based “modern” engineering model. Regular users know that developers are always adding new features, and those features don’t come with alerts or instruction manuals; discovering them requires playing with the app. And Snapchat users are willing to do that.
But using an ever-changing piece of software like Snapchat as a model for enterprise development for paying customers is probably a poor plan, Garrity noted. (Can you imagine how frustrating it would be if your CRM or digital signature software released hidden new features on a regular basis?)
“Do you have to have an enterprise, slow-moving, boring engineering team, or do you have to be really fast and sexy?” he asked.
“It’s a false choice,” he added. “Either one of those is going to put you in extremes where you don’t want to be.”
Garrity’s third philosophy encompasses a combination of the traditional and the modern developer to form a sort of hybrid developer.
Reaching the middle ground with first principles
“Why don’t we have both?” Garrity asked.
What would that look like? A modern user interface, rapid iteration and happy developers — plus scalability, reliability and security.
You can do this by establishing “first principles” — determining what you believe to be true and then following where it leads you.
If you’re a software company, then your first principle is most likely to build a software company or an engineering team in an existing company.
OK, so you want to put together a group of people. Should you find people who know how to code and hire them as quickly and inexpensively as possible — or would it make more sense to put together a team of the best people you could possibly find?
If your first principle is really to build good software, then the answer is clear: You need the best engineers you can find. And good engineers want to have a voice in what they’re doing — they’re opinionated, and they can often be stubborn.
To keep an opinionated, stubborn engineer happy, Garrity noted, it’s probably best to allow your engineers to make their own decisions. Let them decide how to solve problems and what customers need based on what they know — because if a gifted engineer can’t make any decisions about what he or she is doing during the workday, that engineer has one decision left to make: Quit this job for greener pastures.
“Whoever is going to do the work has to make the decision,” Garrity opined.
This might seem like it’s giving the developer too much power — and what’s to stop them from playing around with a silly project or feature that’s more entertaining than useful?
Another first principle can keep this concept from spiraling out of control: “We build what customers want.” Therefore, your engineers need to think about what makes customers happy.
That means your engineers are going to have to have some communication with customers so that they listen to and understand what customers need (and want) in the software they’re building.
Hiring the right people
If you hire the right people and give them the right information, then trust them to do their job (with occasional check-ins to make sure they’re on the right track), then you’ll make your way to a profitable software business, Garrity explained.
So how do you find the people who want to work for you, specifically?
He discussed Elon Musk’s unique proposition — “I’m trying to save humanity; would you like to help?”
Saving humanity isn’t going to appeal to everybody, but there are certainly engineers who are as passionate as Musk about it.
“You do need to hire for both ability and interest to interact with customers, in addition to obvious technical skills — think of it as early qualifying in a sales funnel,” Garrity noted.
“There are a lot of great engineers who won’t be great at your company or my company,” he added. And you need to figure out what you can offer them — because remember: Software engineers don’t have trouble finding jobs in 2017.
At Hearsay, Garrity explained, “we tried to build entrepreneurs.” The company’s engineers work heavily with the customer service department, and they realized it was part of their attraction to potential high-quality employees.
“We’re a relatively small company that wanted engineers in front of customers and in the business, and we ended up recruiting a lot of people who wanted to go start their own companies in three, four, five years,” he said.
Meet with customers to seek problems, not solutions
Garrity talks to his team about finding problems instead of solutions when meeting with customers.
One example he shared involved a customer request for a blue button. When Garrity started digging into why the button needed to be blue, he learned that it was the only feature of that specific page that the customer used — so the button needed to stand out.
After discovering this, Garrity suggested removing the rest of the features on the page. “You can do that?!” the customer asked him incredulously.
Garrity says to “take every opportunity to get your dev team in front of your customers — everyone, no excuses.”
You can do this through user studies, conferences, lunches, dinners, office visits, open houses, talks or quarterly business reviews.
He notes that software developers typically come back with one of two reactions:
- “You get people coming back massively embarrassed because they see how the customers actually use the software.”
- “You get people coming back and saying ‘I knew they needed this thing, but nobody else wanted to build it!'”
And it’s huge for consumers, he added. “When you let them talk to actual engineers, people are just blown away.
“They think of software as this thing that they get handed and can’t change,” he added. “Engineers understand it’s code and they can change whatever they want to; to most people, it’s black magic.”
Get your dev team and customer support team together
Every week, Garrity explained, three engineers at Hearsay Systems move their desks down to where the support team sits.
Their development work for the week is put on hold. Their job is to be on call for ticket escalation, triage, answering customer questions and tooling to help customers.
He also does his best to promote the relationships between the product and support teams. He sponsors mixers, events and one-on-ones inside and outside the office.
Engineers need to own the road map
Your software developers need to come up with the road map, pitch it, agree to it and deliver it.
“The rest of the company gets the time they need to make their case,” he said. But when your engineers have decided that X is the next most important thing on the list — then X is what they will be doing.
“If you overrule the engineering team, they still have one decision they can make, and you won’t like it,” Garrity reiterated.
