Get better at engineering with communication skills

Hi readers,

Why should we focus on our soft skills?

As you may very well know, we, engineers, tend to spend most, if not their entire time focused on developing their technical skills. While we should not aim to be perfect across the board, we'd be better off reeling it in a bit. It can be frustrating to develop a good idea and not eloquently pitch it to your team. It would help if you either went to more extraordinary lengths to convince your team, or your vision will be rejected because you did a poor job of advocating it.

The focus of today's post will be on soft skills in an engineering career. It is a core and crucial asset that will add tremendous value to your arsenal. Communicating effectively will have a non-negligible impact on your growth and the opportunities you can seize. So let's talk about how to become more assertive communicators.

It starts with your belief in yourself and your idea.

The goal here is to convince others that your idea is a winner. If you are trying to do so because someone asks you to do it and don't see any value in the idea, people will know.

Your most prominent advocate while you're trying to convince others will be your level of enthusiasm and your energy. When talking to others, your positivism will definitely show as you are trying to persuade them. As you are working on your goal, an important factor will be to make sure others understand why your idea is exciting and make them buy into the picture.

Make sure that your plan is easy to grasp

In software development & IT, dare I usually say in engineering, it is so comfortable to get all tied up in the details of things. Your way of thinking makes sense to you, and it feels that your idea, once you've explained it through and through, should be accepted by your team. In fact, you could be thinking, why aren't we actually doing that? It's so obvious!

In an enterprise environment, everything is not always black and white. There is a lot to consider and think about before making a decision. To lower any entry barriers, it falls on you to make it simple to take any action on your idea. In fact, after making sure that you have positivism in check, this is your next most impressive supporter to get something in, simplicity.

Engineers usually evolve in complex environments and the cognitive load can already be relatively high. Suppose you want to convince someone that taking an interest in an idea is a solid business decision. In that case, you will need to make it easy for them to decide that it is.

For example, you are thinking about switching database vendors from A to B because:

You are more familiar with B,
You know that B is way more popular than A,
Moving to B reduces our yearly budget spends by 20% because it is open-source,
There are a lot of people who contribute to the project,
There are multiple releases per year, so the project is active,
The database would make feature A, B, C, D & E better,
Having better tech makes it easier to hire people,
Etc.

Focus on the sizzle and the meaning of the idea

Multiple reasons lead you to your new fantastic idea. Congratulations! Now isn't the time to celebrate; in fact, it's the opposite. If you let yourself get overwhelmed by your vision, you may very well become the worst advocate for it. Engineers are very technical people who will fundamentally focus on the specifics of a given topic. That requires a special kind of mindset.

Don't do that. Don't become a victim of your engineer's brain ;-)

You might think by focusing on the technical details of an idea; people will rally behind it. That won't be the case for people who aren't technical, which is why you must try a different approach. Instead of selling your solution to others, you'd be much better trying to sell them what they'd be missing. This is, in fact, a popular marketing technique, don't sell the steak—sell the sizzle!

As you can observe in the link that I shared, it is about seeing things from the perspective of others and help them understand what is in it for them. It would help if you started with changing your approach to selling ideas. Forget about telling someone why a solution is a good one to consider. Instead, paint your audience a picture of how much better life could be with this new opportunity.

In fact, as you are presenting your pitch, demonstrate the different outcomes in a world with and without the concept. As you can see people getting reeled in, you start listing all the reasons why the idea is a good one.

Remove the noise and the clutter.

Suppose you try to get people behind the idea by getting too much into the details. In that case, they might not follow, or you could lose them during the explanation. keep it simple, don't go too much into the details of your idea until you are asked to do so. By then, people already bought into the picture. Now it becomes about putting together a plan on how to achieve it. But let's not get ahead of ourselves quite yet ;)

Removing the noise and only focusing on the simple selling critical points of your idea is how you will influence people. It is not about showing them that you are an innovative and capable person. They already know this. Focus on persuading and showing them in the simplest way possible how they can get an easy and/or valuable win with your idea.

Even if your idea is simple, why would people want it?

As mentioned before, there are several factors to consider when you want to introduce a new idea at work. One of them is how much time can dedicate to this new thing when urgent matters to squash. Your primary focus should then be on demonstrating how this idea can make their lives better.

There can always be objections to your idea. That is a crucial part of the preparation that you will need to work on. Simply thinking about the positive that it'll bring makes you unprepared for the hard questions. I know that it can be sad to think that your team could reject your idea, but it is a reality to consider.

Based on the last example, you should really try to anticipate some questions from your team, such as:

A lot of our design work isn't portable to another vendor. How do you suggest that we can get around this problem?
A document-based database would actually be slower for X, and most of the core client features are based on that. Why would we consider your new database?
The database has decades of data and is not easily portable to a new database. What do you suggest that we do?

This part also boils down to believing that your idea is a solid win for your team. You wouldn't want to spend your time on something that does not matter to you, right? Well, so does your team. Think about them. By understanding what they usually go through, you may see an opportunity on how to satisfy them.

Adapting to your audience

When you are pitching your idea to others, you have to put yourself in their shoes. You have to try to think about what matters to them and understand their thought process. There are multiple factors involved in selling your idea to others. They will not convey the same level of excitement for everyone. You will need to prepare your proposition and have it tailor-made to the person or group of people you're talking to.

So, we already see a problem in the organization or an opportunity to improve the existing infrastructure. See what I did there? Don't focus on the negative. People would instead want to think about positive things. When you come in with a suggestion, do not think of it as before was terrible and the future will be good. You can never know what transpired and led a corporation to take the decisions that it had to. Sometimes, there was no prominent or rather; there was no real solution, , so they just picked the one that had the fewest downsides.

For instance, when talking to other fellow engineers, you can try to sway them by focusing more on the technical details. Let's continue with the previous example. Now that we want to sell the idea in the simplest way possible, we can illustrate the following points to the team:

The features in the application will get faster by design. At a minimum, we can expect at least a 25 to 40% gain on writing ops and 50% gain on reading ops,
Being open-source, anyone can contribute to fixing our bugs.

When talking to non-technical people or your development manager, you can talk about matters such as:

This means that we have more money in our pockets. We can invest it for innovation, or we could increase our hiring cap budget,
We can fix bugs in the open-source database and gain notoriety in the field,
The customers will be happier once the idea has been implemented by getting an improved suite of features in the product. You could even focus on how your new idea will impact the most popular features.

It's all those little things that you do on your end that will help you get people onboarded with your idea. Remember what we said before about simple key selling points? What was mentioned to speak to your engineer coworkers or non-technical people were, in fact, simple and easy-to-follow selling points for your idea.

It's risky to go alone - create a critical mass.

It can feel risky that one person in your team is trying to push an idea. It will always feel like there are more pressing matters; we wouldn't have the time to do this, is the team actually interested in doing that? Will management allow us to even spend the time on it?

Legend of Zelda image - I do not own this image.

Do not forget that YOU are a MEMBER of a TEAM! You absolutely shouldn't go alone; I'd advise against it. It would be best to start talking informally to one person or a few people who would easily buy into the idea.

Evaluate your idea and think about people in your organization. There must be people who should believe as you do and/or could easily be swayed on your side from your internal network. Those are the people you'll want to talk to first. test the waters and check whether you can generate some traction for your idea. That will allow you to practice your pitch multiple times as you communicate with different people.

When discussing with these people, they may help you by:

giving you tips to make your pitch better,
thinking of the arguments against the 'opposition,'
convincing others that your idea's great.

By building a critical mass, you are, in fact, showing your leadership skills to your organization. It is not a small matter to introduce new ideas and concepts in your company. You are doing fantastic work while doing that. When the time comes to present your idea, you won't have to do it alone. Your coworkers will help you with the people that might need more convincing.

War stories: successes and failures while championing ideas

I thought a more personal touch to this article could be helpful to someone looking at how things can go when they manage to implement some of my recommendations in their workplace. I am far from being an effective communicator, and that’s okay — I aim to learn how to do things better every day. One thing I would like to say is that I am glad that I had friends and mentors along the way. It had a tremendous impact on how I perceive things.

Success: Convincing an organization to run internal hackathons to spark innovation

A few weeks after I first started working in my previous organization, I was asked about what I thought would be things the company could do to improve the workplace since my perspective was still untainted. One thing jumped at me, and I pitched it during a meeting: running and hosting internal hackathons. My college days weren’t that far behind me, and I loved those events.

They seemed to like my idea, so I was tasked to research how companies were doing it and building a presentation for the engineering and management teams to go over in Confluence. That went well. People really seemed to like things. Where things didn’t go so great were:

Getting people to respond quickly to the proposal,
Getting the proposal accepted quickly (took well over a year…),
Trying to get the ‘best version of an internal hackathon should look like before hosting one.

In the end, we managed to run internal hackathons twice during my time in the organization, and things went great. The best feedback I got from those events was when a fellow engineer told me that the hackathon week had been his best week at work ever since he joined. I knew then that it had been the right move to push for it.

Failure: Using F# as a core technology to solve business problems

An event that didn’t go as great as I anticipated was when I tried to push for F# internally. I started to speak about it at work, and nearly no one had ever heard of it. To remedy the situation, I decided to host a workshop where I did an overview of F#’s 101 and how a small program can differ when implemented in C# and F#.

One engineer at work outside my development team decided that F# looked cool and would probably help him solve a business problem. He had to create custom UI views from XML specification files, and that would take about 8 to 16 h, depending on who was doing it. He saw a lot of power in F# and how we could use it to play with the data. I helped supervise the project and mentored him in functional programming and F#, and it was solely for his project. In the end, we spent ~80 hours combined on a script, and it automated 89% of the grunt work, which saved him and his team a total of 500 hours per annual.

A few more small tools were built using F# in the company, but there never was a buy-in from the software engineering team to leverage it. They didn’t feel like F# was bringing much to the table, and they could do most of the work F# did with C#. From my perspective, I have failed there. Yes, I introduced F# as new technology to the team and implemented a few things. But I was “the subject matter expert,” and didn’t manage to create any critical mass that would help convince others that embracing F# was an excellent idea. It was a humbling experience that will help me to think of the best ways to sell an idea to people in the future.

Success: Introducing performance observability

A performance problem arose at work one day where a feature suddenly got slower, and no one knew why, and we managed to get the problem fixed. Being part of the DevOps-focused group, it annoyed me (read a lot) that we couldn’t be protected by silly DevOps/development problems in the cloud regarding performance. Something had to be done about this…

That’s when I got introduced to BenchmarkDotNet while conducting my own research and learned about microbenchmarks. This felt great, but we were having issues in our app's UI aspect, and that wouldn’t help. We were developing our own automated testing framework to build end-to-end tests with our desktop app, so I decided to dive deeper.

At that point, I went to talk to a few engineering colleagues about my discovery and quickly rallied people behind me. I was told by the team never had a rock-solid approach for performance testing, and my solution sounded great. Plus, it seemed to be an industry standard which made things that much simpler for me to push my idea to my team.

I observed that BenchmarkDotNet had an MIT license and looked a bit at their code to see how they were profiling .NET code. From there, I created our own way of executing and observing the execution of synchronous and asynchronous .NET workflows. We used that tool in what we called user experience automated tests where you’d recreate what a user would do in a performance-critical scenario and collect the performance data in a file. Once the test finished running, the data could then be investigated. There were a few details that needed to be tweaked and thought of, but we were in much better shape than we ever had been before.

Fast-forward a few months, and we were running our second internal hackathon. I had a team of 2 fellow engineers who wanted to make the process of data collection, aggregation and rendering automated as I did (I’ll spare you the gruesome manual details…).In the span of 5 days, we created a great-looking PowerBI dashboard that was connected to an Azure SQL database and showed all the performance data in one centralized view.

The people in the organization got super excited when we showed this. One thing that helped along the way was to ping interested parties and talked to them about the specific problems they’d face while analyzing the data and/or collecting the data. We used their feedback to make the automated environment better suited to their needs, and they even helped us think of selling points for this proof-of-concept that we built in a few days. Overall, it was a tremendous success.

Concluding remarks

We've discussed a lot about your soft and communication skills. As mentioned before, those are essential skills to work on during your software engineering career. I've heard a great thing on Twitter where someone said you could have all the great tech in the world. Software engineering is all about people processes. Technical skills can only bring so far.

Originally tweeted by Daniel Moka⚡ (@dmokafa) on April 24, 2021.

If you want to go fast, go alone. If you want to go far, go together – African proverb.

So I am hoping that this article helped you understand what you can start doing today to help your career progress. It's okay if the first few times that you try to influence people that it doesn't go as you pictured it. Anyways, we're not here to bend others to your will but to help your organization to grow and get better over time.

It has been a pleasure sharing this with everyone! This has been a topic that's been on my mind for a long time, and I am happy to have finally written on the matter! If you have any comments or stories to share, don't hesitate to post a comment :)

Thanks,

Kevin

P.S For those who enjoyed this article, I have my own blog here. I will be posting more often on HashNode; this is, in fact, my very first article on the platform!