How to build trust when building software

Engineering leadership lessons from Dale Carnegie’s, ‘How to Win Friends and Influence People’.

Rolling out a new software platform means change, and no one likes change. Major change, especially to the way people do their job and earn their living, triggers everyone’s biggest fears. At the least, they’re afraid new systems will disrupt their established routines and workflows. At worst, they’re afraid new software means they’re becoming obsolete or redundant, or that their expertise and effort is less important to their company.

‘Digital transformation’ became a buzzword because successful software roll-outs bring fundamental changes to how work gets done. To users on the ground, the prospect of having to relearn newfangled ways of doing things when you’re perfectly comfortable with the status quo is daunting – even if that status quo involves working around a broken, outdated, legacy system.

We humans cling to our workarounds, which become part of our process, like a safety blanket. I figured out how to make this work! Therefore I am smart and important.

One of my favorite leadership books is Dale Carnegie’s classic, How to Win Friends and Influence People. Even though it was published in 1936, it’s packed with insights that apply to managing change and software rollouts inside organizations today. The ultimate lesson of Carnegie’s book is this: ‘Become genuinely interested in other people.’ For anyone who works in technology, this is our most important goal.

‘About 15 percent of one’s success is due to one’s technical knowledge, and about 85 percent is due to skill in human engineering and the ability to lead people.’

In the spirit of Carnegie’s timeless insights, here are four ways for leaders to win friends and influence people as they build, iterate on, and roll out major software platforms.

1. Forget the big-bang launch

‘The person who can speak acceptably is usually given credit for an ability out of all proportion to what they really possess.’

Think about a blockbuster movie release. A feature film is a years-long project that gets teased and talked about for months. Then, at its world premiere, to much fanfare, a red carpet rolls out, celebrities walk, champagne glasses clink, and a completed film plays on-screen to spirited applause and press coverage.

Software is nothing like this.

Unlike movie producers, digital leaders should never aspire to a big-bang release. If you spend months talking about what the platform will do without showing any actual working software, people will tune out or dismiss it as vaporware. And a perception of vaporware breeds skepticism, grumbling, and scoffing. The big bosses are living in a fantasy. This thing is never gonna happen.

Instead, release early. Bring functioning but incomplete software to users as soon as humanly possible – warts and all. You won’t get any applause, but you’ll prove what you’re working on is not vaporware.

By showing stakeholders and users working software, you make the platform real to its first users and inevitable to its future users. You’re demonstrating that you are delivering an actual product that exists, that others can touch and feel, even if it’s limited. Invite users to see the unfinished parts that haven’t been built yet. (This takes a level of humility and vulnerability that is part of good leadership.) Show this unfinished work humbly, with full acknowledgment that it is just getting started and has a long way to go, and that there’s a lot more work to do. Make users a part of the journey alongside you, and show them that you’re in this uphill battle together.

From there, orchestrate and communicate a steady cadence of releases that add features and fix bugs. Make it really clear what key parts of the system are getting colored in overtime.

2. Convert your allies into advocates

‘There is only one way under high heaven to get anybody to do anything. Did you ever stop to think of that? Yes, just one way. And that is by making the other person want to do it.’

When you’re leading a major software effort, the people who are most likely to be your allies will show themselves early, during user interviews. Typically they are the folks who are in the most pain: the legacy system fails and frustrates them, they’re doing a lot of manual work they know can be automated, they’re tech-savvy and don’t like having to wrestle broken or outdated technology. They want and need relief.

These people are primed to be your friends and allies. Your job is to turn them into advocates. Advocates are your partners, your influencers, and the ones who will help you tell the story to their colleagues about why the new system is better. 

Bring the people in the most pain inside the process. Explain the vision, show them the sketches, share the priorities. When you’re ready, make them your platform’s first users. Ask them what they think. And when they weigh in on the product roadmap, address their biggest pain points first, even if it’s in small ways.

When they see the platform steadily evolving and getting better, they will become your advocates. At the watercooler, at the lunch table, during chit-chat at the beginning or end of meetings, they’re the ones who will mention and even show off what’s working, what’s coming, and what’s possible.

Then something magical will happen. The skeptics will start looking over advocates’ shoulders and asking, Whatcha got there? Does it actually work? Can it do this or that? How would I use this? Eventually, the question will be, When can I get this? 

3. Build anticipation by managing change

‘When I go fishing, I don’t think about what I want. I think about what they want. I don’t bait the hook with strawberries and cream. Rather, I dangle a worm or a grasshopper in front of the fish and say: ‘Wouldn’t you like to have that?’ Bait the hook to suit the fish.’

Change management is a discipline in and of itself, and in a nutshell, it’s the practice of giving everyone a heads-up. Whether or not you’ve got a change manager staffed on your team, it’s a huge part of the job, because with iterative releases, the changes keep coming. Every release, and every change, is an opportunity to build excitement or lose people.

When you let stakeholders and users know ahead of time what to expect and when, they’re on the journey with you. Demonstrate, with working software, that every change makes the system better, smarter, easier to use, and easier to understand. Get users excited about the features they care about and show them that their requests and use cases informed and influenced the work.

4. Understand every user’s perspective

‘If there is any one secret of success, it lies in the ability to get the other person’s point of view and see things from their angle as well as from your own.’

Great communication is a critical part of any successful software rollout, but that communication isn’t just a series of one-way announcements – it’s a conversation. Ensure that all users have an avenue to talk to you about what they think of the system – and listen, deeply. Create an easy-to-use process for capturing user feedback. Make it obvious inside the interface of the software itself. (For example, include instructions for sending a note or screenshot of what went wrong on your error screens.)

The more user feedback, feature requests, bug reports, and complaints come in, the more your users care. While you don’t have to fulfill every request on every user’s terms, what’s important is that everyone is heard, and that feedback gets considered one way or another. (Even if that consideration is, We know this is a problem, but we’re prioritizing it below several other items first.)

Reflections

When you’re rolling out a major software platform, success hinges on your ability to relate to the people who will be using it. Becoming genuinely interested in your end users is the best way to build trust and relationships – and those relationships are the bedrock of success. Software is only as good as what people do with it, so bring your stakeholders and users along with you on the ride to a better world.