We wanted to go left, but we went right
Context
There was one recent meeting where when I mentioned about the rush to deliver caused the quality of our work to decrease, it was met with negativity, painting the notion that I mentioned it to just make an excuse as to why we ended up with lower quality work.
I generally kept it to myself, as I honestly didn’t fully understand why mentioning that fact warranted such a negative reaction.
I proceeded to mention that we already initiated some conversation related to our review process, to bridge the gap that could prevent such issues from passing through in the future.
In any case, the next day, my manager shared some points for improvement. I on the other hand was eager to share the thought process I had that I wanted to share the other day. Clearly, all of the information I got from the feedback hadn’t yet seeped into me at that moment in time.
After we wrapped up that thread, it dawned on me a couple of key things that my manager helped me realize.
Choose your words wisely
- “Choose your words wisely”. This is the general recommendation when we talk to anyone, and the same is true when doing a presentation.
- When defining a problem, be careful to not choose words that can be easily misinterpreted as an excuse.
- Our objective is to state the problem to build a context to highlight the importance of the solution we would present.
- If the way we state our problem comes off like we are just making an excuse, then it would paint a different picture in the minds of our listeners.
- Once a negative picture has been painted, it’s usually hard to erase it.
- Remember, excuses are generally used when we want to state that a problem is just a fact and we have to live with it.
- What we want are reasons why something wasn’t ideal, and then build upon that topic by presenting the solution.
- If we’re unsure if the word we are going to use can be interpreted as an excuse, we should prefer to admit that there is a problem, and express the eagerness to fix it. We could say:
There was an increase in bugs that passed through to higher-level environments, so we clearly saw that we had some gaps that we need to bridge so that it may never happen again. We decided to look at what was different from this sprint to the prior sprints and identified that the “deadline” factor was the unique point, and found out that the team was susceptible of prioritizing “shipping it” over quality. This presented us a clear opportunity to address to the team the importance of not shipping half-baked deliverables. We committed to delivering a beautifully presentable cake, but we ended up delivering a half-baked cake to our QA engineer.
It also revealed gaps in our automation tests and how we review our merge requests, where we already initiated a conversation across the teams on how to improve our review process.
- The tricky part is understanding beforehand which words are the best and which should be avoided. Most of the time, we are not afforded enough time to stop and think of the best words when we are the ones presenting during a meeting, so it is super important that we are dynamic and always on the lookout for the responses of our listeners.
- If we notice that our listeners are frowning a little, then it could be a signal that we might have said something that plucked some chords the wrong way.
- When that happens, back track a little and state what we know we would agree upon.
Conclusion
- I have to reiterate that our objective here is that our presentation relay the information to our listeners the way we envisioned it.
- What we want out of our presentation might be different from time to time. Sometimes, we want to spark a discussion to resolve a problem, other times, we want to highlight the wins to uplift the mood.
- The way we articulate and deliver our presentation is key to achieving whatever our original objective was that we wanted out of the presentation.