Filtering your language as an engineering leader

The most painful lessons learned in engineering leadership can be from when imprecise language has been used.

Linguistic filters

In May 2012, the author Robin Sloan noticed a trend on Twitter: people were increasingly posting tweets describing something that had just occurred, prefaced with the phrase ‘That moment when…’. Robin commented that this phrase helped cool down and add distance to their experience, and described the effect as ‘a linguistic Instagram filter’.

Over the years, I’ve built up my own vocabulary of linguistic filters: small turns of phrase that I find useful to say to quickly set up my teammate with a mindset to be receptive to what follows. My goal is that by sharing them, I can help you sharpen your communication.

‘Here’s what I’d be worried about…’

Used when: I want to warn someone about the risks of a path they’re considering taking, while still giving them ownership of the decision.

When I first moved from being an engineer to a manager, my head was still full of the technical details of the system I’d been building up to that point. As is common in this transition, I still thought my primary value to the company was technical, and so would tell my team not just what to build, but also how they should build it. Essentially, I was treating my engineers as extra sets of hands to write my code for me.

When I got the feedback that this was disempowering to my team, I moved to telling folks what needed to be built, but asking them to design how it should be implemented. In theory, this was an improvement, except that I then bottlenecked the build on my approval, and in reviews would correct the engineers if they weren’t planning to build it in what I perceived as the right way. This was probably worse than the original situation!

I grew from this by learning that I was removing my team’s autonomy, and depriving them of a chance to explore and learn from their own mistakes. So, instead of telling them not to do something, I moved to saying what concerned me. ‘Here’s what I’d be worried about: what will this do to database performance?’  ‘The warning light in my mind: will this work well on mobile?’ I was no longer a roadblock, but a guide. If the engineer chose to press ahead, the worst case was they learned from their mistake. (In the best case, there was no problem after all, and I was just wrong to worry!)

So think about when you’re insisting on a change because you have a really solid reason, versus pushing for more thought on something that sets your spidey-senses tingling, and frame your feedback appropriately.

‘This is just a half-baked idea but…’

Used when: I want to gauge a reaction to, or get some honest feedback on, an idea, but don’t want the listener to take it as a set-in-stone direction.

As leaders, we’re often perceived to have more insight into strategy and direction than we actually have. With that perception comes risk: a comment about a potential change you’re considering can be taken as a completed decision. In your mind, you are merely discussing options, but your teammate interprets your musings as a certain change which they will need to react to. This is especially risky when discussing changes to team structure, as gossip can start to fly and become ‘the truth’ without warning.

So I use phrases like ‘This is just a half-baked idea but…’ or ‘I haven’t thought this through completely but…’ to set the tone. I’m spitballing and floating ideas, and I want honest feedback and reactions. This idea is closer to being scrawled on the back of a napkin than being typeset and laminated! Nothing is decided, I’m looking for feedback, and this is early enough that I won’t be upset if your feedback is ‘I think that’s a bad idea!’

‘I’m going to give you some feedback…’

Used when: I want the listener to be actively aware that I’m delivering feedback

At my last job, the company ran quarterly ‘pulse’ surveys of employees, which allowed them to give anonymous ratings and comments on a variety of topics. The scores were rolled up at the manager level, giving us visibility into how our teams were feeling.

One quarter, I noticed that the engineers who reported to me were less likely to agree with the statement ‘My manager gives me feedback which helps me improve.’ than other teams in my area. I thought I’d been doing a good job of delivering positive and constructive feedback, so I spent some time digging into the situation.

What I learned was that the way I presented feedback was often somewhat socratic. I would ask questions in a 1:1 to guide them to reflect on their behavior, rethink assumptions, or find different approaches to challenges. While this was effective, it didn’t ‘feel’ like feedback; it felt like a discussion or problem-solving.

The quickest way I found to tweak the perception was simply to be explicit about the purpose of the discussion: I preceded the conversation with ‘I’m going to give you some feedback.’  This small adjustment set the tone and changed the focus, and resulted in a more positive score in the following quarter’s Pulse survey.

‘Here’s how I like to think about it…’

Used when: I want to convey my mental model for decision-making, rather than the decision I would come to.

When helping someone dissect a problem, it’s easy to jump to delivering a solution. You’ve built years of experience, and so the answer is obvious to you. ‘Just do X, Y, and Z.’

One of the most important ways you can scale your leadership is to help people come to the decision you’d make without having to talk to you! So I’ve learned to focus on communicating my mental model: the trade-offs I’m considering and experiences I’ve had that are leading to my recommendation.

‘Here’s how I like to think about it’ is as much a reminder to myself as it is a filter for the conversation. Paired with ‘Here’s what this reminds me of’, it makes clear what my worldview is and helps me convey the most important parts of my decision-making process in a way that can be built upon (and questioned) by the person I’m collaborating with.

‘Let me try to explain it. Correct me where I’m wrong…’

Used when: I am wanting to make sure I’m not being an out-of-touch engineering manager.

A risk of moving from an individual contributor role to management is that you probably spend a lot less time in the weeds of the system your team is building. Over time, it’s guaranteed that there will be engineers on your team who are far deeper experts than you. However, there will also be times when you find yourself in a position needing to discuss technical aspects of your team’s work, so you need to make sure you continue to have a solid, ‘manager-level’ understanding. For example, if I am going to talk with the manager of another team about a bug in a component they own that I’d like them to prioritize fixing, I need to know enough about the cost and implications of the bug going unfixed to have a reasonable discussion.

To enable this, I make sure and look for opportunities with my team to test my knowledge. I explicitly lower my status, put myself in the learner position, and encourage people to correct my mistakes, before describing some technical details or an issue in my own words. Doing so means that not only do I get to validate my understanding, but also it helps remind the team that I have some (rusty) engineering chops, and reduce their perception of me as a ‘pointy-haired boss’.

I hope the opportunities to use these phrases are recognizable, and their potential clear. Try using them the next time you need to, and see if they are effective for you too.