This week's post is the beginning of a new series I'm calling "How to Win with Devs". I'd like to think of this whole series as a sort of "Open Letter" to HR and Engineering Management... my goal is to share some of what I've seen and provide an opportunity for dialogue which isn't always available when psychological safety is lacking.

Note: for the rest of this series, I'm going to use the term "Engineer" to mean "Anyone whose role involves the creation, implementation, and maintenance of complex computer software and hardware systems." This is neither the time nor the place for a Holy War about the definition of "Engineer". Let's just agree that's what I mean by it and move on, shall we? 😏

Today's post (as you can see from the title) is about Empathy. But I'm not going to waste the page extolling the value and benefit of being empathetic. Surely by now you've learned that "walking a mile in their shoes" will teach you a great deal about someone. So we're going to LEAD with Empathy today, and start practicing it right out of the gate!

What Engineers will get out of this series

All communication goes two ways... whether intentionally or otherwise! I hope that engineers will reflect on places where they've been rigid & inflexible as we explore who they are and how they think - and that they'll be willing to provide a little more flexibility and understanding of their colleagues from other areas who may not do the "handshake" right, but are genuinely trying their best.

What Non-Engineers will get out of this series

My hope is that this series becomes a way for marketers, business-folks, and organizational leaders to peek into the minds of these often-eccentric, sometimes rough-shod, usually weird people. Businesses in the 21st century are living and dying by how their technology/engineering teams operate, and whether you love your devs like I do or merely tolerate them as a "necessary evil", you're going to have to work with them. I'd like to give you some things to keep in mind that make tolerating them more fun, and perhaps even tip you over the edge to thinking of their eccentricities as "endearing"!

The Engineering Audience

Engineers are a complex group for other parts of the organization to understand. One one hand, it can seem that they're easy to please - I mean, what other parts of the organization would pull an all-nighter for a couple pizzas 🍕 and some beer 🍻? But organizations who eventually break through the surface-level analysis to develop an understanding of their engineering teams are usually surprised to find a depth, a warmth... a complexity that they completely overlooked! It's therefore no mistake that many companies have created a "Developer Experience" or "Developer Relations" team, particularly in tech marketing organizations, who specialize in reaching out and engaging this particular group of people. Talking to engineers requires a different approach from standard marketing; there are lots of "secret handshakes" and degrees of trust and respect that must be gained to reach an engineering community effectively.

What Engineers Want

What does anybody want, really? It's an unfair question that buys into stereotypes to ask what "all" engineers want, doesn't it?

Well, kind of.

See - stereotypes became stereotypical because of how frequently they were found to be true statements! So there is some value in the Engineer stereotype that we can use to help us guide our initial connection.

Engineers are Tinkerers

They love to see how and why something works. They want to open it up and look at the little fiddly bits inside and see how the magic happened. The universe is a big puzzle box to them. And that's precisely what attracted them to this profession in the first place! So when we talk to an Engineer, we don't always get the same ability to "gloss over" the technical jargon that we would get when talking to other folks.

Engineers Respect Knowledge... and Honesty

Their tinkering nature sort of leads straight to this next point - Knowledge is super-important to them! Every interaction they have with other people will carry a small subtext: "How can I learn from this person? What do they have to teach me?" This is a double-edged sword, as you might imagine - the negative version of this becomes "non-technical people are useless" while the positive version becomes a deeply caring and thoughtful person who knows how to use their power for good. When you talk to an engineer, you never know which side of the coin you're getting, so it's important to do your homework. Know what you're saying... and (critically important!) be up-front about the parts you don't know. They generally don't disrespect someone for not knowing something, but they'll eviscerate someone who pretends to know and tries to fake their way through it.

Engineers Know How to Teach Themselves... and (usually) Prefer It

Tinkerers don't wait for a class on how to do something. They'll grab hold of it and kick the tires and experiment in a safe space. In fact, they'll probably do that in the back of the classroom and tune out the instructions, if the opportunity arises...

That's not to say your classroom time with them is completely wasted. It's just... going to need some tweaks. If you're teaching engineers in a classroom setting, try disposing of the slides and getting into live-building. And if it can be done in collaboration, where everybody has a chance to experiment together? That's a win. Engage them in kinesthetic learning rather than lectures.

Symbolism is Important

I was once on a support team where the manager went to a halloween decoration store and bought a shrunken zombie head, and the person with the oldest unresolved support ticket would have "the zombie head" pinned to their cubicle wall until they could get their old ticket closed. And people on the team got emotional over that thing, man... voluntarily staying late or working a problem through lunch to eliminate the old ticket - or even the second-oldest ticket, so that they wouldn't even be at risk of getting the zombie!

When you work in systems all day that are made up of configuration values and variables and other, erm... symbols... it becomes part of how you think. Symbolic acts - like a manager staying late with the team, or a thank-you breakfast after an all-night outage problem, or even the zombie head for the oldest ticket - become very, very meaningful to your engineering team. They take pride in their work, and those little things mean a great deal. There's a statement attributed to Napoleon Bonaparte: "A soldier will fight long and hard for a bit of colored ribbon." This is very true of engineers, where small symbols can often have an effect disproportionate to their size and value.

Use this to your advantage - a genuine token of gratitude for something "extra" or a company-culture thing like a bit of swag you earn for completing some task can provide huge benefit-for-cost returns. But take care not to stretch things very far, lest the gesture lose its symbolism!

Engineers Can Smell a Rat 🐀

There's one stereotype I'm not buying into - which is that Engineers don't pick up on social cues.

They may not be social butterflies, and might be in fact pretty awkward in public settings... but remember: they've spent their entire careers training their brains to see patterns and diagnose when something is 'not normal'. When something isn't quite right, even in a space where they don't have a lot of expertise... they're bound to attune to it because it's different and out of place.

This aligns very well with the earlier statement about being clear and transparent when you don't know something. However, I'd like to take it a step further and propose to you that they'll be more sensitive to organizational policy changes too! We'll get into this in more detail in next week's post - this warranted its own dedicated week! 🙂

Developing Empathy for Engineers

Maybe you don't have much of it right now, and you realize that it's important. How does one develop empathy?

Wear their shoes 👞

Not literally! But this was a Twilio mantra that I really appreciated during my time there - in fact, "wear the customer's shoes" is so important to Twilio that the gift for a 5-year Twilioversary is a bronze pair of sneakers! If you're not an engineer, it would be worth taking a day or two to pair up with someone and learn how they work. What are the challenges they face during the day? How do they overcome or work around? What's happening when they're at their most effective, and least effective? You could also try just building something yourself, to get into the mind of someone who builds. You don't have to build an enterprise-grade software solution to understand what it's like to build software. Find a small project - maybe something in a guided tour on youtube (heh, I have a few of these here on The Adventures of Blink, with more coming soon; maybe give me some 💕 on those!) and build it along with the instructions.

Create safety 🦺

Engineers often find social niceties tiring. We're used to operating in factual spaces... either the code had an error or it didn't! So one of the best things you can do is give us a safe space where we can share what's on our minds without being worried about whether we're damaging our career by saying something wrong. Once you've established that trust, you'll be surprised at just how much an engineer is willing to open up! But it's going to require two things:

• You need to protect them from "repercussions". Psychological safety is about being able to maybe say things in a way that ruffles feathers, but not fear reprisal. They may not be able to elegantly articulate what's wrong - and they'll default to "blunt". Giving them space and help assembling their thoughts will earn their respect!

• You need to act on what you learn from them. First, find out if they're just venting or if they're looking for help. It's ok to ask - direct is usually better! If they're looking for help, the worst thing you can do is ignore what you learned; they're opening themselves to you, which is not and if they tell you they want your help, they mean it!

Give them space

The worst thing you can do to an engineer is micromanage them. Just don't. They're used to being self-directed - they learn on their own. They build on their own. To them, being herded around feels childish, like you don't trust them to be an adult.

They'll understand that there are boundaries, and that you're required to maintain those boundaries as a manager. But they'll expect clear communication about where those boundaries are, and then they'll work best if you just leave them alone until they seek you out for help.

Wrapping up

As we begin this series, I hope that you've now obtained a good understanding of the engineers you'll be dealing with. They're a bit different from other personas you've encountered, but can be every bit as warm and inviting once you get through the (sometimes) prickly shell!

If you'd like some further reading on this topic and can't wait for next week's post, try this book by Twilio's co-founder and former CEO Jeff Lawson. As a software engineer himself, Jeff has always had a heart for developers and his incredible leadership at Twilio for 15 years was always centered around enabling Builders. I get a small commission for purchasing from the link above, I greatly appreciate your following it to make your purchase!

Tune in next week where we dig into the importance of Symbolism and Patterns to our engineer friends, as we discuss Hidden Messages!