How to introduce technical concepts to management

I’ve heard many times the statement “technical guys talk another completely different language” after a demo meeting. And although it’s usually passed on as a joke between folks outside the development chain, it reflects the lack of connection to those ideas presented. For us “techie folks” a console screen with may log lines defining what is happening along with a very very long sentence including those kind of verbs that you won’t use in a regular conversation is the very embodiment of excitement (or it is for me!). However, that tells nothing to somebody that is not used to work with computers on a profound level.

Teams working under scrum methodologies put effort on setting up a demo showing new features after each sprint. They are engaged and excited after performing complex jobs, and proudly want to shout “hey, take a look at what we did!”. And for the duration of the meeting, they are met with stares of boredom, or even complete disregard. After the slides, when the feature is demonstrated, the attendees might give a glance or two at the screen, perhaps. And then, they will quickly return their attention to their mobiles, the ceiling, or their nails. And this leads the team to resentment that will turn eventually into feeling neglected from their managers.

Doesn’t make for the most exciting slideshow…

This is the perfect opportunity for scrum masters to involve themselves on the team retrospectives. If your team didn’t adopt scrum, a similar role can perform this job: product owners, technical leads, middle managers… The team needs someone able to translate “technical” to “business”. That is because they speak of very different things.

Teams want to talk about technology, features, processes… They desire to spread word of their preferred library, of a new component, of architecture and microservices. But what the leading people want to hear is about customer impact, time to market and benefits. They specially want to hear about how the investment is going to turn into profit. Balancing loaders? Forget about that, talk about doubling userbase capacity. Automated testing on each Release Candidate? That is an impressive achievement, but what will move the bosses is making them understand that the QA phase will be shortened.

You have to employ simple terms. There is no need to explain in detail your architecture, because -and this is a fact- they will not understand what is going on. Stress that, and then read it again. Then tattoo it on your arm. Accept to live with that fact, because that is exactly why you are hired: you understand technical concepts way better, you apply the required best practices for software, and you are the one making it happen. It is not about the how, but the why. If you really must talk about technical stuff, use metaphors. Balance load and data consumption easily transform into a highway with vehicles. Memory usage can be explained with cookies (or any other food will do, actually). Data architecture nodes can be warehouses and stores, being provided data by vehicles… See what I mean? Use the very raw concept behind the technology, but avoid it altogether if you can.

Color-coding is also a great strategy. Use comparisons before and after the changes. Use graphics, arrows pointing up and down. You do not need to make use of real data, although some numbers will have to be provided to back up your claims. Use icons, screenshots… Why explain how to arrive to a specific form on a website, when you can show it?

As well, record your presentation in video form. Play this video in the background, on your explanation, while you perform the exposition. This will give your speech cohesion, will allow you to focus on your audience. Your body language says a lot to those in the room, and being vaguely aware of what is happening on your screen while you try to recite your script does not back you up.

Finally, it is recommended to include reminders of older presentations. A slide or two to refresh a term in the form of quick recaps will put everyone on common ground — especially if an attendee couldn’t appear on the latest performance.

Try applying these ideas on your retrospectives, and let me know if you notice a change of attitude on the observers.


Originally published at alvarogcachon.com on August 29, 2016.