TL;DR: Engineers like to be concise, but a concise communication style is not always the most effective one. Being a bit more verbose can increase clarity, emphasize important points, and create an atmosphere that allows for more creative exploration.

I used to hate running meetings. I still don’t particularly like it. Sometimes it feels like I am throwing words at people who would much rather get back to their work, and who are only in the room because their calendar is telling them to. Then I think it’s my job to talk them out of their unwillingness, to motivate them, to get them engaged — only to find that I quickly run out of words.

I have never been a big talker. Probably, this is part of what drew me towards a technical field. As a software engineer, it pays off to be concise. Precise. To the point. “Don’t repeat yourself!”, or DRY, is one of our mantras. In our code, we want to maintain every functionality and every piece of data only once, written in the best way possible. We carry this conciseness over to our verbal communication. We don’t tell each other novels, and we do not want to say the same thing in three different ways. We are disdainful of “management speak” as an inflated way of communicating and appearing important.

Among technical people, this works fine in general. However, if everyone is concise in meetings all the time, there will be little fluent conversation, and a lot of awkward silence instead. Consider the following conversation, where Simon is running a brainstorming with his people:

Simon: “So. Which tech initiatives should we consider for Q3? Any ideas?”

Everybody: (silence)

Simon: “Sarah, what do you think?”

Sarah: “We should focus on performance. Our app has become slower again.”

Simon: “Good point. Performance. What else? John, any idea?”

John: “I think we should clean up the data layer. The architecture has been compromised by the latest round of features.”

Simon: “Yes, I think the data layer could use some love. Anything else?”

Richard: “Improve modularization in the front end.”

Simon: “Good!”

There is a lot of back and forth between communication partners, with little flow of conversation. Simon has to somewhat force it out of his people. The meeting has just started, and everyone might mentally still be somewhere else. Simon’s short, to-the-point opening did not get them into the room.

Ignition

Sometimes, you have to inject a little bit of energy into a meeting to get people engaged. That does not mean you have to jump around like a circus clown, or come up with funny jokes. But it might mean leading by example and being a little bit richer in your communication. Let us have Simon try his opening again:

Simon: “So. Which tech initiatives should we consider for Q3? What are your ideas? Think of things that have been bothering you for a while, that you see deteriorating, that benefit us in the long run, etc. Front end, backend, build process, infrastructure. Is there a feature you want to make more efficient? Can we reduce data volume somewhere? Is development slow in some part of the system because of technical debt? What would really move us forward?”

Now, this is a very different introduction. Even though every engineer on the team should know what kinds of technical initiatives Simon is talking about, he spells it out for them in detail. He gives examples — improving efficiency, reducing data volume, increasing development speed —, names the parts of the application that should be considered — frontend, backend, build process, infrastructure — and gives them some more suggestions and stimulations. All this is much more likely to tickle their imagination, and results in a more engaged conversation:

Sarah: “Since you mentioned efficiency: I think we should focus on performance. Our app has become slower. I am not entirely sure why, and maybe that is also a problem: We should have better performance monitoring in place.”

Simon: “Good point. Performance and performance monitoring. What else?”

John: “I think we should clean up the data layer. The architecture has been compromised a bit, and this is slowing us down whenever we have to touch it. It would increase development speed in the long run.”

Simon: “Very good!”

Richard: “Speaking of development speed: I think we should improve modularization in the front end. The functionality there is still very intertwined, everything talks to everything else, and you can never be sure which parts of the system you affect. There are always a lot of bugs and unintended side effects you have to clean up.”

This looks a lot more like a conversation. People are more engaged and follow up on each other’s topics. The atmosphere is more exciting, and an entrepreneurial spirit is taking hold. From an engineering perspective, not everything the team says is absolutely necessary. There are redundancies — for example, “this is slowing us down” and “it would increase developer speed” are essentially saying the same thing. But is it inflated management speak? I would say no.

To non-engineers

Using some more words when talking among engineers can already bring positive results, as we have just seen. The same benefits show when you talk to non-technical people. First of all, they might not fully understand the technical aspect of the situation you are talking about. Second, they might not realize the importance of your message if you only throw two sentences at them. Imagine the dev team just worked their butts off for three weeks to overcome critical performance problems that put the entire quarterly plan in danger. The engineering manager is proud of his team. Now he tells the product manager:

Engineer manager to product manager: “I have good news: We solved the performance issues. My people reduced the response size by about 40%, and added caching to cut server time by 150ms. This means we can proceed with the feature roadmap for Q3 as planned.”

This sounds positive, but will it make the product manager appreciate how difficult this was, and how hard the engineers have been working on this? Hardly. She might also not know in detail what benefits the reduction in response size has. The news is delivered in a matter-of-fact way, and before the product manager has really started listening, the engineering manager has already finished.

Now, I think these hard-working engineers deserve some more appreciation, so let us add some redundancy to better get the message across:

Engineer manager to product manager: “I have good news: We solved the performance issues. I have just seen a demo, and the application is notably faster. It feels super snappy now. My people reduced the response size by about 40%, this makes view updates much faster, and it also reduces memory consumption on the client. Also, they added caching to cut server time by 150ms, on every single request. You can feel these 150ms. The devs put a lot of effort in, and they have come up with great solutions to some tricky problems. I am really proud of them. Starting from here, we can proceed with the feature roadmap for Q3 as planned.”

This gives a much clearer — or, at least, more impressive — picture of what has been accomplished, and what work was put in. The factual information conveyed is roughly the same: The response size and the server time went down, so the performance issues have been solved. However, the impression that the engineering manager now makes on his dialogue partner is a very different one. The product manager will appreciate much more that the engineering work was difficult, and that the accomplishments are substantial.

Add some padding

I think a lot of technical people could increase the effect they have by being more descriptive in their language, and, in a good way, repetitive. Compare the following message pairs, where the first message is brief and engineering-like, while the second message “adds some padding”: It is a bit more verbose and has a lower information-to-number-of-words ratio, if you will. The second message is uttered by an engineering manager who knows about the value of slightly redundant communication:

Engineer: “The way we organized the project this time lead to miscommunication. We should do it differently next time.”

Engineering Manager: “The way we organized the project this time lead to miscommunication. There were a lot of situations where it was unclear who should be informed of what, and this was confusing a lot of people. We should do it differently next time, with clearer responsibilities, and thorough alignment of who needs to take action when.”

While the second version does not contain any substantial information that the first version does not, it makes a stronger impression on the receiver of the message. Let’s look at another message pair:

Engineer: “When you are under time pressure, it is sometimes difficult to keep up coding discipline, and maintain high quality.”

Engineering Manager: “When you are under time pressure, it is sometimes difficult to keep up coding discipline. You want to please your stakeholders, you want to show them how productive you can be. You want to help them reach their goals, and make the deadline. You take some shortcuts, and stop writing tests. You don’t go for the clean solution, but choose one that is faster to implement, but also builds up some technical debt. You tell yourself you can clean it up later. We’ve all been there. It happens quickly. But maintaining high quality is difficult that way.”

Again, the second version of the message does not contain any substantial information that the first one does not. However, it describes the same thing from different angles, and in different aspects.

Communication takes time

In Patrick Kua’s Talking With Tech Leads, one of the interviewed Tech Leads describes the need to find different ways of communicating the same thing as follows:

“The Tech Lead starts to recognise how differently people can interpret the same message and has to find alternative ways of communicating the same idea to avoid misunderstanding.”

The Tech Lead goes on to conclude that “communication takes time”, and if all you do is fire laser-sharp, precise one-sentence explanations towards people, you do not allow for that time. The recipient of the message cannot keep up, and you lose them. Being a bit more verbose with your words, on the other hand, means keeping your audience with you.

Besides better understanding, the emotional response might also be much stronger, increasing the effect of your words. Martin Luther King, on August 28, 1963 in Washington, could have just said “I have a dream that all Americans are regarded as equals, and that racial segregation ends”. Would the people who were standing before the Lincoln Memorial on that day have agreed? Certainly. Would they have applauded? Probably. But would they have cheered, cried, hugged each other with emotion, and been touched to the core? Unlikely.

Inspiration

In the same way, you can either inform your team that you want to build your own compiler like this:

“I think we should go through with it. Let’s build our own compiler. It’s gonna be difficult, but we can do it, and it will enable us to do a lot of optimizations.”

The relevant information is there: What do we build? Is it difficult? Are we skilled enough? What will be the benefits?

Or, you can express the same thing in a couple of different ways:

“I know this is a big challenge, but I think this team is ready for it: Let’s build our own compiler. In the past months, I have seen this team produce amazing work, and I have the feeling it is getting better every week. Having our own compiler will open up a whole new set of possibilities: We will be able to optimize our code in new ways, and tailored exactly to our usage scenarios. If we can bring runtime down just by 2%, it will already have a large effect on the bottom line. This is our chance to really have an impact. It will be tough, but together, we will pull it off, I’m sure.”

Again, the core information conveyed has not drastically changed: We want to build a compiler, it’s difficult, but we can do it, and there will be new opportunities for optimization. However, the second version is much more emotional and inspiring.

In English, there is the metaphor of “hammering something home” that fits quite well here. The first version of the pep talk above is the equivalent of hitting a nail with a hammer once or twice. It won’t fall down from the wall directly, but it also will not carry a lot of weight. The second version is the equivalent of driving it all the way into the wall, so that it could hold a heavy bookshelf or more.

Conclusion

As an engineer, you might be used to expressing yourself succinctly and precisely. As a communication hub, though — which you become as an engineering manager — this kind of talking is not always your best option. During meetings, or when communicating with non-technical people, brevity might lead to a lack of flow of conversation, or prevent you from getting your message across.

There is a set of benefits that come with some more verbosity:

• Time to think: When you ask others to come up with ideas, they might be taken aback and unprepared at first. When you talk a bit longer, you give them time to think, and you might end up with a better discussion and better ideas. Keep talking until you feel others are ready to contribute. Often, all you have to do is bridge a few moments of silence.
• Clarity: Describing something from various angles instead of only from one single perspective can increase clarity. Your message gets across better.
• Atmosphere: Succinctness creates a business-like, curt atmosphere, which might keep people from thinking out aloud. For creative exploration, like during a brainstorming, this will prevent ideas from flowing. It should be allowed to explore while you talk. Often, others will be able to join in this creative exploration, and contribute valuable thoughts and perspectives.
• Inspiration: If you are always brief and concise, you will have a hard time inspiring anyone. Describe various details, and describe things from different angles to get people’s fantasy going.

That said, it is of course important to stay meaningful in your communication, and not overdo it with the redundancy. Once you see people falling asleep or rolling your eyes during a monologue of yours, you might actually have fallen victim to the “manager speak” disease. However, for engineers who are rather too concise, it is a good idea to make the other mistake for some time, and be a bit too verbose. You will most likely drift back towards the middle automatically.

Time investment

This blog post took me about 5 hours to write and edit.

Want to learn more on communication? Check this out: