5 Lessons I Learned About Explaining Your Ideas As A Software Engineer From A Missed Opportunity With My Former CEO
How communication is crucial to grow in your career as a software engineer.
Hey, my new email course is out!
Discover the 5 Biggest Mistakes Software Engineers Make Working In A Startup For The First Time!
The Story
A few years before writing this post, I was in a conversation with my former CEO.
At the time, we had 1 hour every 2 weeks he called: “Office Hours”. At that time, anyone in the company was allowed to join the call and discuss anything they wanted with the CEO. I took that opportunity every time I could.
We were a small startup then, so I took any opportunity to express my ideas and ask questions about the board, the business, and the company.
During one of those conversations, we discussed shortening the feedback loop.
I was trying to explain to him how it was the best way to:
Increase efficiency in our team.
Ensure we deliver value to the users.
At the time, we worked using PRD (Product Requirements Document) to ensure engineers had a “contract” to rely on when developing a feature.
My thesis was that PRDs were only increasing the bureaucracy without helping engineers understand the value of what they were building, and, most importantly, it became an excuse for them to avoid critical thinking.
I spent almost 30 minutes explaining to my CEO why the solution was not to increase the time spent planning a feature but to reduce the scope of each feature. He listened to me while I spoke without taking a breath for about 5 minutes. At the end, I asked: “Is that clear?”
He answered: “No, not really.”
At that specific moment, I realized how I missed a huge opportunity.
After a while, I wrote a post on Linkedin about this story. In this post, I also mentioned how I solved that issue.
Here are the 5 lessons I learned to improve how you explain your ideas as a software engineer.
Lesson #1: Understanding > Decision
When you explain your ideas, you should focus on sharing the value of it.
In many situations, I pushed for a decision on my listener. When you aim for a decision on the other part, you may encounter immediate rejection. However, on many occasions, they reject your ideas because they don’t understand them.
Let me be clear:
If they don’t understand the value of what you share, it’s your fault.
When you explain an idea, a tool, a technology, or an architectural pattern, you should focus on demonstrating the value of it.
Your goal is to finish the conversation with the other person, understanding the value of your idea. Don’t push for a decision. Let them elaborate for a few days. When you explain an idea, you have a lot of time to elaborate on it, refine it, and think about it in the context of your work.
Finish the conversation when you are on the same page.
Your goal is to have another conversation about the same topic with a clear understanding of the other part.
Lesson #2: Follow up
People forget.
When you are a tech lead, software architect, or engineering manager, there is a high chance that you will need to discuss things with executives. These people are extremely busy. They don’t forget about your conversations or messages because they don’t care. They are just busy.
That’s why you need to follow up.
I thought I was annoying for many years, but trust me, it’s the opposite.
I realized how follow-up is appreciated when I was on the other side. When I became a Tech Lead, I did many things: documentation, organizing projects, preparing meetings for the engineering team, etc. When an engineer texted me to discuss something, I forgot to answer them for a few days.
Sometimes, they didn’t text me again, and when I realized I had never answered them, I felt so guilty.
I realized they had a problem and wanted to discuss a possible solution with me.
The problem was not that I didn’t care; it was just that their message got covered by others, and I forgot about it. It was my fault, of course. However, I started appreciating when people texted me multiple times.
Do the same; if you don’t get an answer, simply send another message:
Hey, did you get the chance to think about my message?
Or, even better, if you need time to discuss, schedule a meeting with them:
Hey, I scheduled a meeting with you to discuss X. Feel free to reschedule if the time doesn’t work for you.
That’s probably the ideal solution.
Lesson #3: Be Ready To Be Wrong
I’ve fallen in love with ideas many times.
The result is that I push for approval without listening to objections.
When you have an idea or want to explain a strategy, a tool, or a pattern, what is the reason why you want to have such a conversation? Did you already decide and just want a signature to move on? Or are you open to discussing your idea and finding the best solution?
If you are open to discussion, you are in the right mood to help the listener understand your point of view.
Being open to changing your mind is crucial.
Your goal should be to challenge your idea and be ready to accept another proposal. When you explain your idea with this mindset, you want to make sure the other person understands it so that they can raise meaningful objections. You need their point of view to validate if your idea is a valid solution.
You want they to know you work in the same team and you have the same goal:
Build the best product possible.
Lesson #4: Patience Is Key
Some decisions are time-related, some are not.
When you need to decide on a tool to implement a new feature, your decision must be made at a specific time. The more you wait, the more your release will be delayed. Situations like this one require prioritization.
The ideal strategy for these kind of situations is to have two discussions:
Explain the problem and provide a solution.
Discuss your solution once the other person clearly understands the problem.
Other decisions can be made without pressure.
When writing this post, I was working in a startup, and I proposed the idea of using ADRs.
I proposed Architectural Decision Records a few weeks after joining the company. It was clear to me the need for a tool to track architectural decisions and discuss them. I briefly talked with our architect, but we never committed to it.
I didn’t push for that, but occasionally, I raised the topic again when I felt it was relevant in discussions.
There is no rush to commit to decisions like this one. The more you wait, the more you gather examples and data to prove your point.
The story ended with the other person proposing ARDs in a discussion with the whole engineering team and showing my post about the topic.
Lesson #5: Verba Volant, Scripta Manent
The title of this lesson is Latin, and the translation is:
Speak fly, writing stays.
I mentioned multiple times the value of writing for software engineers.
Writing can help you land a new job, improve your understanding of a new topic, and create valuable documentation.
But there is more.
When you write about a topic, you create a permanent asset that you can use at any moment to explain something.
In the story I mentioned at the beginning of this post, I shared how I used a post I wrote to explain a topic to my former CEO. The key in that example was that many people need to read something for multiple reasons:
They might get distracted during a conversation.
They need to read it numerous times.
They understand better when reading than when listening.
In any case, it is not your fault or theirs. It is just that some people are simply better learners when they read about something rather than when they listen to a speech about the same topic. Some people learn better when they listen to an audiobook, while others need to read it.
For this reason, you want to have all the tools at your disposal.
Since I started writing this newsletter, I shared my posts in multiple situations.
PS: If you enjoyed this post, please consider sharing