Did you know that most experts agree that somewhere between 70 and 93 percent of all communication is nonverbal?

It’s a bonkers kind of statistic when you think of how things are handled in the business world. We spend an incredible amount of time fretting over the words we’re going to use... and as it turns out, there's substantially more emphasis not on what we say but on what we do.

Think about it: How many times have you pored over an unsent email for hours on end, changing a word here or a phrase there, trying to make sure it expressed your sentiment exactly? How many times have you written the talking points for your presentation, and then rewritten them, and then rewritten them again? Turns out you're likely emphasizing the wrong things!

An Adventure of Blink for Dev Team Leaders

As we continue our series "How to Win with Devs", we’re going to talk about hidden messages. No, this isn’t cryptography, or even about steganography. Nothing quite so advanced or intentional… we’re going to talk about messages hidden in plain sight; things you said without intending to say them. I think this is particularly important for company leadership, who often don’t get to share a lot verbally with their teams; in those cases, actions speak even more loudly.

Let’s try this one in Story Mode, shall we?

The Tale of the Copilots

Imagine that you’re a software engineer at Initech. You’ve been reading an awful lot lately about artificial intelligence as a coding copilot - you can have an AI pop into your IDE window and help you code. It does things like complete common code blocks for you, and explain how this bug is occurring, and even makes suggestions about how to reduce the runtime of this method you’re writing. You think… hey, that could be cool to try out at work!

What do you do?

(A) Well… Initech has a process. Your manager has to open a ticket to have the copilot license purchased and added to your company laptop. The ticket requires signoffs by finance and legal. You have to sign some wall-of-text attestation before they’ll push the installation to your laptop.

(B) Or maybe Initech’s process is more like this: You talk to your manager, who says “yeah that sounds like it would really help your productivity.” Your manager also checks with Legal to see if there are any unexpected ramifications of using the copilot, and they say “we just need documentation of who’s using it so we can protect you in case something comes up”. You add it to your expense report and start coding with your copilot.

What are the surface messages of each of these scenarios?

They’re the same thing. In both cases, the company is paying for the software, you notified Legal of the risk, and you got what you wanted.

What are the hidden messages, though?

In (A), you needed 3 different signatures to spend $20/month. And you had to sign some major legalese that no one besides an attorney can even fully understand. Even though you get what you asked for, it doesn’t feel like the organization puts a lot of trust in you as an engineer. Your manager has to make the request… why? Are you incapable of requesting it? The decision to frame the Legal notification as an “attestation” and require a signature before the license key could be released makes the experience seem big and scary and intimidating. “The Company really did you a favor by approving the use of this Copilot thingy, blink,” seems to be the implication of going through all that red tape.

In (B), the process felt like teamwork, though, didn’t it? All the “processing” was just conversation and awareness, and giving you the ability to expense it yourself is a direct testament to the trust the Company places in you… “we trust you to spend our money wisely.” Legal’s response being framed as “being here to protect you if something happens” is also a great touch - yeah, of course they’re paid to ensure the Company isn’t at risk, but they’re letting you know they’re looking out for you as an employee too.

The Tale of the New Guy

Imagine you just got hired by Initech...

(A) You show up on day 1 for your orientation session for your new hybrid job at Initech. Someone from the onboarding team has you pose for your badge photo. You go to the presentations and learn about all the benefits and policies and all the typical new hire things. At the end of the sessions, you’re required to take a quiz on what you just learned… and you have to pass it in order to be given your badge. You take the quiz, and barely squeak by, but you get your badge and head for work... though you're not sure what floor of the building your team lives on. You arrive at the entryway, and your badge doesn’t work because the database updates every night and it won’t be activated until tomorrow. When you arrive the next day, you finally get logged in, only to find that you’re already receiving system alerts that you haven’t completed training modules yet.

OR

(B) Two weeks before your start date, Initech ships you your equipment. The laptop arrives with a note that says “don’t turn this on until your start date”. On your first day, someone from the Support team calls you and walks you through the initial setup procedures. Once you’re connected properly, they show you how to find the training system with an agenda of orientation videos already queued up for you to watch, and you note that your manager has already scheduled a 1:1 with you for later on in the morning.

What are the hidden messages in these two experiences?

In (A), it feels like the Company just wants you to be grateful to be here. The process is designed to ensure they get everything they need to process the paperwork - even to the point of not issuing you a badge if the training quiz doesn’t get completed! - but there’s very little thought given to your experience as a new hire. The message, therefore, is that your productivity isn't as important as your compliance to policy.. You'll also notice that even though it's a hybrid role, the "happy path" to onboarding is on-site. You have very little consideration given to your remote experience in those first couple days.

In (B), all of the same needs exist, and in fact, all of them are met... but in a way that focuses on your experience as the new hire. The process shows empathy for someone who's brand-new to a team, who doesn't know where anything is or how to engage properly, and every step of the process ensures that there's good communication with the new person.

Why bother with all this kum-ba-yah empathy though?

Isn't it just a drain on our resources, coddling people all the time? This is a good question, a fundamental one for us to consider. Is it worth spending extra time and money on making a good experience? What do we get from it?

Most of the benefits of focusing on experience are investments that have to pay us back later, and often indirectly.

ROI opportunities from Developer Experience

• You create a bias for action.

When you create a positive developer experience, your engineers understand that they need to act in order to get things done. In the other cases, your developer learns that "the process is just like this" and every delay reinforces that they just have to be patient and wait instead of taking decisive action and moving forward. Engineers are highly paid because they're highly skilled - and in particular, you want to encourage them to be self-directing as much as possible because they're naturally so good at sizing up a situation and taking decisive action. When you teach them to just sit and wait for The Process to sort itself out, you deny yourself access to one of their most valuable abilities!

• You improve your company's reputation.

Engineers talk to each other a lot - at meetups, online, anywhere they can find each other. And they regularly talk about work-related things with each other... often commiserating about how bad decisions are being made around them! When a developer has a poor onboarding experience, or when the dev team of a company has some problems overall, that information is being passed to friends and colleagues and can affect the quality of your recruiting efforts! Alternatively, when a great dev experience exists, people gravitate toward it - everyone wants to join a culture of strong innovation and empathy. If you build a strong developer experience, your recruiters are going to have an easier time attracting better talent to apply and join your team.

• Engineers will make themselves more efficient.

Software devs are notorious for min/max-ing their workday. Most of them will actively seek out paths that lead to more efficient work! Think of it this way: if your company lays out stringent rules and constraints around everything, the devs who have to walk through those things will just despair and lose their desire to fix the system. But if you focus on providing a good developer experience, with appropriate flexibility in the right places and thoughtful applications of constraints, the devs will naturally find the shortest path. The role of developer experience isn't so much about prescribing as it is about enabling. Giving them the flexibility (within a base ruleset) to define their own path is empowering and engaging, and sparks innovation.

I had no idea, Blink. How can I spot hidden messages in my own communications?

It can be terrifying to think that you may be communicating in ways you don't intend. And since it's happening in spite of your efforts to the contrary, solving the problem of what messages are hidden in your communications seems daunting. How do you find something you unintentionally did? How do you track down something that you don't know exists?

Awareness is the first step.

Believe it or not, just being aware that this possibility exists can eliminate a lot of hidden messages. By stopping to attend to the fact that your communication attempt may be altered by any number of variables, you'll naturally begin to spot some of the things you don't like and eliminate them.

We said it last week: wear their shoes.

Learn to imagine what someone would think if they were reading your message / hearing your message / encountering your policy for the first time. Maybe take the time to walk through the experience yourself, as a brand new person, and look for the places where things go bump. Are you in HR? Sit in New Employee orientation, and participate with the whole process as if you're a new hire. Are you a manager? Get your manager to deliver the message to you as a listener, so that you can feel what it feels like to hear it.

Make it SAFE to tell you things.

The next thing you can do is to have someone evaluate your messaging before you send it out. Ask them if they think it sends the wrong signals or if it's likely to be taken out of context. This will require a degree of trust and safety that you might not have with many folks - be sure that you're careful to choose folks who are comfortable being candid with you. Bonus points if you find a trusted member of the target audience who's willing to share candidly with you! And of course - the more people that you can have this kind of safety with, the better - cultivate that in your relationships with your team.

Wrapping up

Every decision you make can be observed and interpreted by the team around you. What messages are hiding in your actions? How are your decisions communicating differently from your words?

Aligning our actions and our words is a critical step in establishing psychological safety - we must show ourselves to be trustworthy in order to earn the trust of those around us!

Thanks for taking this journey with me today. Be sure to tune in next week when we talk about Outcome-Based Performance Measurement!