Hi readers,
Why should we focus on our soft skills?
As you may very well know, we, software developers, tend to spend most, if not, our entire time focused on developing 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 come up with a good idea and not be able to eloquently pitch it to your team. You may need to go to greater lengths to convince your team or your idea will be rejected because you did a poor job to advocate it.
The focus of today’s post will be about soft skills in an engineering career. It is a core and crucial asset that will add tremendous value to your arsenal. The ability to communicate effectively will have a non-negligible impact on your growth and the opportunities that you can seize. So let’s talk about how to become stronger 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 you don’t see any value in the idea, people will know.
Your levels of enthusiasm and energy as you are explaining what you hope to achieve will be your biggest advocates. When talking to others, your positivism will definitely show as you are trying to convince 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 idea.
Make sure that your plan is easy to grasp
It is oftentimes very likely 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 down on you to make it simple to take any action on your idea. In fact, after making sure that you have positivism in check, your next biggest advocate to get something accepted is simplicity.
Engineers usually evolve in intricate environments and the cognitive load can already be quite high. If you want to convince someone that taking an interest in an idea is a solid business decision, you are going to need to make it easy for them to decide that it is.
For example, you may be 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 the yearly expenditures 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 awesome idea. Congratulations! Now isn’t the time to celebrate; in fact, it’s the opposite. If you let yourself get overwhelmed by your idea, 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 engineering brain 😉
You might think that 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 to help them understand what is in it for them. Your pitch changes from talking about the why of a solution to how much better life could with this new idea. In fact, as you are presenting your pitch, demonstrate the different outcomes in a world with and without the idea. As you can see people getting reeled in, that is when you start listing all the reasons as to why the idea is a good one.
Remove the noise and the clutter
If you try to get people behind the idea by getting too much into the details, they might not follow or you could simply lose them during the explanation. Just 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 idea and now it becomes more 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 key points of your idea is how you will influence people. It is not about showing them that you are a smart 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 you can dedicate to this new thing when there are 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 outcome that it’ll bring makes you unprepared for the hard questions. I know that it can be sad to think that your idea could be rejected by your team, 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 easily transferred to another vendor. How do you suggest that we 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 that we have 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.
Adapt the proposition to your audience
When you will be 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 and they will 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 rather, an opportunity to improve the existing infrastructure. See what I did there? Don’t focus on the negative, people would rather think of positive things. When you come in with a suggestion, do not think of it as before was bad 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 wasn’t an obvious or any 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 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 solution 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 the most popular features are going to be impacted by your new idea.
All those little things that you do on your end will help you get people onboarded with your idea. Remember what we said before about simple key selling points? What was mentioned to say 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 intimidating to be that one person in your team 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?
Do not forget that YOU are a MEMBER of a TEAM! You absolutely shouldn’t go alone; I’d advise against it. What you need to do is to start talking, informally, to one person or a few people that would easily buy into the idea.
Evaluate your idea and think about people in your organization. From your internal network, there must be people who should think as you do and/or could easily be swayed on your side. Those are the people you’ll want to talk to first. Just 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 some 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 amazing 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
Success: Convincing an organization to run internal hackathons to spark innovation
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 every day how to do things better. 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.
In my previous organization, a few weeks after I first started working, 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 to build 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 on the proposal,
- Getting the proposal accepted quickly (took well over a year…),
- Trying to get the ‘best’ version of how 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. I think 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 whom was outside my development team decided that F# looked cool and would probably help him solve a business problem of his. 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 supervising 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.
There have been a few more small tools 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 on the table and they could do most of the work F# did with C#. From my perspective, I have failed there. Yes, I managed to introduce F# as a new technology to the team and implement a few things with it. 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 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 sort of annoyed me (read a lot) that we couldn’t be protected by silly DevOps/development problems in the cloud in regards to 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 the UI aspect of our app and that wouldn’t help. A nice thing was that we were developing our own automated testing framework to build end-to-end tests with our desktop app so I decided to dive a bit 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 that 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 more 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 which would then be investigated. There were a few details that needed to be tweaked and thought of, but we were in a much better shape than we ever had been before.
Fast-forward a few months, we were running our second internal hackathon and I had a team of 2 fellow engineers who wanted to make the process of data collection, aggregation and rendering automated like I did (I’ll spare you the gruesome manual details…).We created, in the span of 5 days, a great looking PowerBI dashboard which 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 talk 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 to think of selling points for this proof-of-concept that we built in a few days. Overall, it was a tremendous success.
Conclusion
We’ve discussed a lot about your soft and communication skills. As mentioned before, those are major skills to work on during your software engineering career. I’ve heard a great thing on Twitter where someone said that you could have all the great tech in the world, it won’t matter. Software engineering is all about people processes. Technical skills can only bring you so far.
If you want to go fast, go alone. If you want to go far, go together
So I am hoping that this article helped you understand what you can start doing today to help your career progress. It’s totally fine if the first few times that you try to influence people 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.
As usual, 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 wrote on the matter! If you have any comments or stories to share, don’t hesitate to post a comment 🙂
Thanks,
Kevin
Black Coding Adventures 