Introduction
One of the things that I often recommend when I speak at conferences or in my writings is that a trait of professional software engineers is to “Be a Squeaky Wheel”. "Be a squeaky wheel" is an American phrase that means advocating for yourself or your interests in a persistent and assertive manner. The phrase comes from the idea that a squeaky wheel, like on a cart or machine, draws attention because of the noise it makes. In a similar way, if you speak up, make your needs or concerns known, and keep pushing for what you want, you're more likely to get the attention, assistance, or resolution you desire. It's often used in the context of advocating for better customer service, addressing problems, or seeking attention to an important issue. Even the late Steve Jobs (founder of Apple) understands this is important.
![Picture]()
This simple phrase that encourages you to speak up, to me, falls into two main categories if you want to be a professional software engineer and grow in this industry. Before I discuss them, I’d like to say that I fully realize that this might be tougher for some cultures. If speaking out is discouraged in your culture, then I hope that this encourages you to speak up on the job. Since I was born and raised in America, I will be speaking from my perspective.
I have been a software engineer for over 20 years, and I know from experience that if you don’t speak up, nothing will change. Speak up with your input and make recommendations. Speak up on issues that no one else is bringing up. I know that each of us is different, and this might be difficult for some. Heck, if you can believe it, it’s still hard for me at times. But when you feel it’s important to speak up, do it! We are all here to create software and services that users love that improve their work or personal lives. We are all in this together, so I hope you will heed my words.
Speak Up with Recommendations and Issues
When on the job, remember you are an expert! They hired you based on your skills, so to them, you are the best person for the job. Speak up on the technologies that the project should think about using. Remember, you should be up to date on the latest technologies, frameworks, and services, including the cloud. I can guarantee you that from your manager on up, they are not up to date on these subjects. They are looking to you for this type of information.
Make sure to speak up in meetings and with your teammates. I know this can be difficult for many, including myself. Engineers tend to be introverted and think in their heads. On top of that, many of us suffer from impostor syndrome to some degree that might prevent us from speaking up. If this is you, then try starting off with small suggestions and build up from there.
Another thing you can try is to create a list of questions or comments before the meeting or other situations to be better prepared. This will make you more confident speaking up. This is why I like meetings to have an agenda of what will be discussed. Sadly, most companies I work at do not do this as a common practice. If your company is this way, send a friendly message to the meeting organizer and ask for a meeting agenda. If they don’t create an agenda or push back on your request, I suggest raising the issue with your manager.
If speaking up in a group of people is challenging for you, then try starting with your manager. Bring up ideas and issues with them in person (preferably) or send an email if they are busy. They should know you and hopefully will react positively. If there is an upcoming meeting on the subject, they can mentor you and even encourage you to bring it up in front of the rest of the team. This will give you more confidence. This is why working with a great manager is at the top of my list when looking for a new position. The more you speak up, the easier it will become!
To be a professional software engineer, it’s important that you can talk to the CEO on down which includes product and project managers, salespeople, tech support people, customers, and more. Not all of us get this opportunity, but you should be able to, just as I have during my career.
Giving Advice to a CEO
To prove my point, a long time ago, back in the internet bubble days, I became part of the first official development team for Proflowers.com. At the time, Proflowers was the first company that shipped flowers directly from the grower to the consumer. Their flowers could last two weeks, whereas the ones purchased at the florist or store will last less than a week. I believe at the time, they were the #2 website for purchasing flowers in America.
Since the site would go down every Mother’s Day week, they, for some reason, decided to hire an outside consulting firm to build a new website instead of the internal team. After this firm delivered the first version that we could start testing, we discovered that the site would crash after just a few concurrent users. It didn’t take long for the CEO, Bill Strauss, to find out and call me into the main conference room to discuss.
I don’t remember why he only invited me, but he wanted to know what was going on. Maybe he did since I always say it like I see it, and I don’t sugarcoat things. Not only did I tell him that the site failed with just a few users, but I also told him that it did not even meet the business requirements. I also told him that after looking at the code, I’m not sure if it will ever work with the traffic needed to make the company profitable.
As you can guess, he didn’t like what he heard and asked me what he should do, which included asking for the money back from the consulting firm Stelcom Services. First, I told him that I did not know what was in their contract with Stelcom, so I could not really answer that. I did tell him that Stelcom failed to meet even the minimum business requirements. I’m not sure if they ever talked to the business development team at all, It’s going to take a lot of time and money to fix so we can properly sell the flower arrangements. Since the site would fail in just a few minutes, we might have to get it rewritten and essentially start over. I also felt that we (mostly the CTO) failed to properly manage the project from our end. I believe Bill stated that they already paid about $200,000 for the site, and I did hear later that he got some of the money back, but not all.
After this, since I was the temporary director of development and the DBA became the temporary director of operations (while he was looking for a new CTO), the DBA and I spent the next month locked in a conference room to come up with a brand-new website and database design. He and I came up with a design that would meet business needs, not go down during peak times, and would allow us to start bringing on retail partners like Sears and others. It was also the first site that I designed that heavily used queuing (MSMQ back then). I liked the design so much that I showed it to my students at the University of California San Diego for many semesters.
Looking back over this event that happened over 20 years ago, I can confidently say that if I wasn’t already speaking at local groups, conferences, and teaching at a local university, I’m not sure if I would have been confident enough to tell the CEO all of this bad news and give him advice, especially in a way that he would understand.
Not Everyone Will Listen
Let’s face it, even though you might be an expert, not everyone will listen to you. I will admit that when people don’t listen to my recommendations, I sometimes have a hard time accepting it, especially since I am usually the expert in the team these days.
In some teams, there might be a person who will shut you down, talk down to you, or make you feel bad (just as in life) if you speak up. In my experience, these people usually do this to make themselves look or feel better. If you do have a person in your team like this, talk to your manager so they can address the issue. If the issue continues or your manager does not do anything about it, it might be time to move to a different team or company. Don’t let this throw you. Remember it’s their issue, not yours. Ignore them the best you can and keep bringing up ideas and issues.
One recommendation that I will make is if you do speak up and get rejected and you still feel strongly about your recommendation, make sure to document it! There is a very good chance they might try to place blame on you for failures in the future. It’s happened to me many times.
The Risks of Not Speaking Up
At one company I worked at, I wrote the company's very first public API (way back in the late 2000s). Not only did I write over 90% of the code, but I spent many months on architecture and a lot of time writing thorough documentation that would make it easy for any of the partners to understand. I even created a .NET Framework assembly to make calling the API very simple for those teams using .NET.
One of these partners owned over 300 automobile repair shops in America and Canada. For the first version, I worked a lot with this partner to satisfy their requirements. Since this partner would be the first one to use the API, once I was done with the first version that was ready to test, I flew to Kansas City, Kansas, along with the program manager to teach two consultants they hired exactly how to use the API so that they could quickly implement it.
I was there for two days and spent most of that time in a conference room with these two consultants. I went over the documentation I wrote along with showing them in C# on how to use the API. Throughout this process and at the end, I asked the consultants if they had questions, and they never did. Not even one question! I could not believe it. Either I did such an excellent job that they didn’t need to ask questions, or they didn’t know what to ask, or maybe they didn’t care.
Due to this, before I left the partner's office to fly home, I met with the partner manager. I expressed my concerns and recommended him to fire the consulting company they were using and find a better one. He told me he hired them since the consultants that they usually used and liked were unavailable, and he felt he was stuck with them. I think my recommendation worked since a few months later. He did exactly what I suggested.
Speaking Up About Issues
Due to my over two decades in this industry being part of many successful projects and some not so successful, I am pretty good at knowing what issues might arise when trying to release it to get it into the customers’ hands. In many planning or architecture meetings, most people talk about the “happy path” assuming everything will go right and fit into the schedule and be released on time. I’m here to tell you that everything will not go right, and there is a very good chance that there will be slippage in the timeline. There is a saying that goes, “The last 10% of the work takes 90% of the time.”
In these meetings, I do think about the “happy path”, but I also ponder what issues will come up. If no one is bringing up issues, then I do! This sometimes makes me the person who always brings up issues, but I’m okay with that. I’m here to deliver great software to our customers. I’m not here to kiss up to anyone. I’m not here to keep quiet so I can do as little work as possible, and I won’t apologize for that.
No matter what level of software engineer you are, it’s your responsibility to bring up issues. Even if you are unsure or need to do research first, it’s on you to bring them up. Let me explain by telling the story below.
Project Speedway, A Cautionary Tale
At one company I worked at (I’ve written about this before), the contractor who was working with me and I found very serious performance issues retrieving data from SQL Server. As soon as we found this issue, I immediately went to my manager and others and told them that we couldn’t release the product (a Windows application) until we tackled these issues. I cautioned them that if we do, we will start losing customers. Also, this would be the first version of the product that customers could try before purchasing, and I said that we would have a very hard time attracting customers with this poor performance that we saw.
Not only did they not listen to me, but they also even told me that we would work on performance after release. I could not believe they said that to me since I held the highest-level software engineer position at the company (Principal Software Engineer). If I don’t know what will happen and the dangers of releasing these issues, then who does?
We released the application about 4 months later, in December of that year. Guess what happened? You’re right! We started losing customers to our major competitor, and we could not attract new customers. Because of this, the VP of Project Management came up with a new initiative called “Project Speedway” to improve the performance.
I have previously written about this in my factional story called “The Adventures Of Inspector Cody: The Week From Hell And The Tale Of Project Management Gone Wrong” on dotNetTips.com. In a nutshell, they asked one of the other Principal Software Engineers to come up with a solution to fix the performance. A month later, in a meeting with him, my manager, and myself, he showed us his solution. After he did, I said that what he designed was the Microsoft Sync Framework, so why don’t we investigate that framework since even Microsoft uses it? Well, they didn’t, again. After he worked his solution into the application and I saw how it performed, I told management that it’s now even slower than it was before! This degrading of performance in the application was released despite my concerns.
We Want More Features!
Many months later, I was in a meeting with my manager and other managers from the company and vice presidents. They talked at length about the features they want in the next release, including improving performance. After listening to their requests, I became frustrated and raised my hand to voice a concern. I told them that if they do not allow us to redesign the database (to date, the worst design I have ever seen), everything they want will either be impossible or take so long that our competitor will beat us to the punch.
All the managers (except my boss) and VPs looked at me like this was the first time they heard this. Luckily, my boss chimed in and said, “Dave has been telling you this for four years; why don’t you listen to him?”. Again, they didn’t heed my advice, and they continued losing customers to their competitors ever since.
What made it worse, they decided they wanted to sell the company and started massive layoffs. I got caught up in the third round, where they laid off all the Principal Software Engineers in my department. They lost the entire brain's trust in the application and were left with beginner and intermediate developers with no leadership. This product has been limping along ever since! It’s too bad because it was a product that the users really needed to improve their jobs at automobile repair shops. I saw a lot of potential for the application.
While I’m on the subject, if your company is purchased by an investment firm, start looking for a new job right away. In my experience, investment firms are only there to cut costs and sell it to someone else for a profit. They have no interest in you or the products or services you are trying to build.
Ask Questions
A trait of professional software engineers is that they ask questions! A long time ago, when I was discussing my frustration that my students didn’t ask enough questions, the business owner and book author Daniel Appleman said to me, “There are no dumb questions, only those too dumb to ask.” For years after that, I showed that quote to my students at the university at the beginning of every course.
Daniel is correct, but I’d like to add sometimes people don’t know what to ask or feel uncomfortable asking in front of a group. That’s why I told my students that, in this case, just email me the question, and I will answer it in the next class without revealing who sent it to me. I even suggest that people do this at my conference sessions and during my show, Rockin’ the Code World with dotNetDave.
Now don’t go overboard in a situation. This might be a sign that you are not up to speed on whatever is being discussed. In this case, write down your questions and research them later. You can even bring up these questions to your manager or lead developer in a one-on-one meeting if this is more comfortable for you.
Asking questions will show your manager and teammates that you are interested and engaged in the topic being discussed. This will make you look better to others. I do recommend researching the topic being discussed and even jotting down questions to ask in these situations.
Summary
If you don’t like talking in groups, to become a professional software engineer, you must overcome this fear. When I started working as a software engineer talking in front of people was my #2 fear, right behind death! The way I overcame it was to become a founding member of a user group and start forcing myself to get in front of people to give presentations. I kept doing this until I could talk in front of small groups, speak at conferences, and even teach at a university. Now, I never get nervous or fearful when I speak in front of others, no matter how many there are! My number one suggestion to any engineer is to put yourself in situations like this until it no longer creates fear and anxiety.
I also suggest that if the team you work in does not encourage you to speak up and instead constantly shuts you down, find a different team or company. Staying in a team like this will not only hamper your career but will cause a lot of frustration and stress. Stress really does adversely affect your health.
I hope that these suggestions will help you speak up in your team so you can become a professional software engineer and have a long and happy career. If you have any comments or questions, please make them below.