In my numerous interactions at conferences and through my written works, I consistently emphasize the importance of a characteristic that sets professional software engineers apart: being proactive or, as the saying goes, “Being a Squeaky Wheel.” This American phrase implies advocating for your interests persistently and assertively, much like a noisy wheel draws attention. In a professional context, speaking up, expressing your needs, concerns, and pushing for what you believe is essential will get you the attention, assistance, and resolutions you seek. This proactive approach is valuable when aiming for better customer service, problem-solving, or addressing critical issues. Even the late Steve Jobs, the founder of Apple, recognized its significance.

This simple phrase, which encourages individuals to voice their opinions, can be categorized into two primary aspects when striving to become a professional software engineer and advancing in this industry. Before delving into these categories, I want to acknowledge that I am fully aware that adhering to this advice may present challenges in certain cultural contexts. If your culture tends to discourage speaking out, I hope this message empowers you to express your thoughts in the workplace. Given that I was born and raised in America, I will be sharing my perspective from that background.

With over two decades of experience as a software engineer, I can attest that remaining silent leads to stagnation. It’s imperative to articulate your insights and offer recommendations. Don’t hesitate to address issues that others might be overlooking. Recognizing that each individual is unique, I understand that this can be daunting for some. In fact, believe it or not, there are times when I still find it challenging. However, when you perceive the need to speak up, seize the opportunity! We are all here with a shared goal: to develop software and services that users adore, enhancing their professional and personal lives. We are united in this endeavor, so I urge you to take my words to heart.

Speak Up with Recommendations and Address Issues

When you’re on the job, always remember that you are an expert in your field. You were hired based on your skills, which makes you the best person for the job in their eyes. It’s crucial to proactively contribute your expertise, especially when it comes to suggesting technologies that could benefit the project. Keep in mind that you should stay updated on the latest technologies, frameworks, and services, including those related to cloud computing. I can assure you that, from your manager and upwards, most people may not be as informed in these areas as you are. They rely on your knowledge and insights.

Speaking up in meetings and with your colleagues can be challenging, and I understand that, as many engineers, including myself, tend to be introverted and prefer internal contemplation. Additionally, many of us struggle with impostor syndrome to some extent, which can hinder our willingness to voice our opinions. If this resonates with you, consider starting with small suggestions and gradually building your confidence from there.

Another effective strategy is to prepare a list of questions or comments before meetings or other relevant situations. This will help you feel more self-assured when speaking up. Personally, I find it beneficial for meetings to have a predefined agenda of what will be discussed. Unfortunately, not all companies adhere to this practice. If your organization is one of them, I recommend sending a friendly message to the meeting organizer and politely requesting an agenda. If they resist or don’t comply with your request, consider discussing the issue with your manager.

If speaking up in group settings remains challenging, consider initiating discussions with your manager. Approach them in person if possible or send an email if they are busy. Your manager should know you and, ideally, respond positively to your ideas and concerns. If there’s an upcoming meeting related to the subject, they can provide guidance and even encourage you to share your thoughts with the rest of the team. This mentorship will boost your confidence. This is one reason why having a supportive manager is invaluable when seeking a new position. Remember, the more you speak up, the easier it becomes over time.

To excel as a professional software engineer, it’s essential that you can effectively communicate with individuals at all levels, from the CEO down to product and project managers, salespeople, tech support staff, customers, and more. While not everyone may have the opportunity to engage with such a diverse range of individuals, it’s a skill you should cultivate, as I have throughout my career.

Offering Advice to a CEO

To illustrate my point, let me take you back to the days of the internet bubble when I became a part of the inaugural development team for Proflowers.com. At that time, Proflowers pioneered the concept of shipping flowers directly from growers to consumers. Their flowers had a remarkable longevity of up to two weeks, a significant improvement over those purchased from traditional florists or stores. In fact, they were ranked as the second most popular website for purchasing flowers in America.

However, despite their initial success, the website experienced downtime issues, particularly during the week leading up to Mother’s Day. In response, the company decided to engage an external consulting firm to construct a new website, rather than relying on their in-house team. When the initial version, delivered by the consulting firm, began to falter under minimal user loads, it didn’t take long for the CEO, Bill Strauss, to become aware of the issue and summon me to the main conference room for a discussion.

Although I cannot recall precisely why he singled me out, it’s possible that he valued my candid and straightforward approach. Without sugarcoating the situation, I conveyed to him that not only did the site fail with just a few concurrent users, but it also failed to meet even the most basic business requirements. I openly expressed doubts about its potential to handle the necessary traffic to sustain profitability after reviewing the code.

Naturally, Bill was displeased with this feedback and sought my advice, including the possibility of seeking a refund from the consulting firm, Stelcom Services. I informed him that I couldn’t provide insights into their contract specifics, but I did stress that Stelcom had fallen short of meeting even the minimum business requirements. Moreover, it seemed that they had neglected to engage with the business development team, which would necessitate significant time and financial investments to rectify the situation and enable the proper sale of flower arrangements. Given the site’s instability, it might even require a complete rewrite, essentially starting from scratch. I also acknowledged our team’s shortcomings, especially in project management. To Bill’s dismay, he disclosed that they had already disbursed approximately $200,000 for the site, and while he managed to recoup some of the funds, a full reimbursement remained elusive.

In the aftermath of this encounter, as the temporary director of development, I joined forces with the DBA (Database Administrator), who had assumed the role of temporary director of operations while the search for a new CTO was underway. We locked ourselves in a conference room for the next month to conceptualize an entirely new website and database design. Our goal was to align with business needs, ensure uninterrupted service during peak periods, and accommodate the onboarding of retail partners, including Sears and others. Notably, this project marked the inception of my extensive use of queuing, primarily MSMQ at that time. I held the design in such high regard that I incorporated it into my teaching curriculum at the University of California San Diego for numerous semesters.

Reflecting on this event that transpired over two decades ago, I can confidently assert that my prior involvement in public speaking engagements, conferences, and teaching at a local university significantly bolstered my confidence in delivering candid advice to the CEO, even when the news was unfavorable, and ensuring he comprehended the gravity of the situation.

Not Everyone Will Be Receptive

Let’s be realistic, even when you possess expertise, not everyone will be willing to heed your advice. I must confess that when my recommendations are disregarded, it can be challenging for me to accept, particularly since I often serve as the resident expert on my teams nowadays.

In certain team dynamics, there may be individuals who exhibit dismissive behavior, condescension, or even attempts to belittle you when you express your thoughts – a phenomenon not uncommon in both professional and personal spheres. In my experience, individuals like this often engage in such behavior to bolster their own image or self-esteem. If you encounter someone like this within your team, I recommend discussing the matter with your manager, enabling them to address the issue promptly. Should the issue persist or your manager fails to take corrective action, it may be time to explore other team or company opportunities. It’s essential not to let such encounters discourage you. Keep in mind that this issue belongs to the person exhibiting such behavior, not you. Do your best to disregard their negativity and continue to proactively bring forth your ideas and concerns.

One piece of advice that I would like to emphasize is the importance of documenting your recommendations if you speak up and face rejection but still firmly believe in the validity of your ideas. There is a significant likelihood that, in the future, they might attempt to shift blame onto you for any shortcomings. I’ve personally encountered this scenario on multiple occasions.

The Consequences of Keeping Silent

During my tenure at a previous company, I had the opportunity to develop the company’s inaugural public API, a task that dates back to the late 2000s. Not only was I responsible for writing over 90% of the code, but I also invested numerous months in architecting the system and dedicated a substantial amount of time to creating comprehensive documentation, designed to facilitate partner comprehension. Additionally, I crafted a .NET Framework assembly to simplify API utilization for teams working with .NET.

One of our prominent partners, who owned a network of over 300 automobile repair shops spanning across America and Canada, required significant collaboration to meet their specific requirements. Given that this partner would be the first to integrate the API, I took the initiative to fly to Kansas City, Kansas, accompanied by a program manager, to instruct two consultants they had hired on the intricacies of API usage, enabling them to expedite its implementation.

During my two-day stay, I predominantly occupied a conference room with these two consultants. I meticulously went through the documentation I had prepared and provided hands-on guidance in C# regarding API implementation. To my astonishment, throughout this entire process, and even at the conclusion, not a single question was raised by the consultants. It was baffling; I couldn’t discern whether my documentation was exceptionally clear to the point where no queries were necessary, or if they were uncertain about what to inquire, or perhaps they simply lacked interest.

Due to this perplexing silence, prior to departing the partner’s office to return home, I scheduled a meeting with the partner manager. During our discussion, I expressed my reservations and strongly recommended terminating the consulting company they had engaged and seeking a more proficient alternative. The partner manager disclosed that he had chosen this consulting firm because the consultants they typically used and favored were unavailable at the time, and he felt somewhat constrained. However, I am pleased to report that my recommendation appeared to resonate, as several months later, he indeed took the step I had suggested, ultimately improving the situation.

Addressing Concerns and Voicing Issues

With over two decades of experience in this industry, encompassing involvement in numerous successful and, admittedly, a few less successful projects, I have honed my ability to anticipate potential hurdles that can arise when striving to deliver a product into the hands of our valued customers. In many of our planning and architecture meetings, the prevailing narrative often revolves around the “happy path,” assuming that everything will proceed smoothly, adhere to the schedule, and be released promptly. However, I am here to impart a dose of reality: not everything will go perfectly as planned, and the likelihood of timeline slippage is very real. There’s a familiar adage that aptly captures this sentiment: “The last 10% of the work takes 90% of the time.”

While I certainly consider the “happy path” in these meetings, I also make it a point to contemplate the potential issues that might surface. If no one else is raising concerns, I take the initiative to do so. This might occasionally label me as the person who consistently brings up issues, but I wholeheartedly embrace that role. My primary objective is to deliver exceptional software to our customers. I am not here to curry favor with anyone, nor am I here to maintain silence in order to minimize my workload. I refuse to apologize for prioritizing the quality and reliability of our work.

Regardless of your level as a software engineer, it is your inherent responsibility to address and voice concerns. Even if you harbor uncertainties or require additional research, the onus falls squarely on your shoulders to initiate these discussions. Allow me to illustrate this with the following story.

Project Speedway: A Valuable Lesson

At one of the companies I worked for (as I’ve recounted previously), a contractor and I uncovered severe performance issues when retrieving data from SQL Server while working on a project codenamed “Project Speedway.” As soon as these issues became apparent, I promptly approached my manager and other relevant stakeholders, emphasizing that we should not release the product (a Windows application) until we addressed these performance challenges. I cautioned them that proceeding with the release would likely lead to customer attrition and hinder our ability to attract new ones, particularly since this version allowed potential customers to evaluate the product before making a purchase.

To my disbelief, not only did they dismiss my concerns, but they also informed me that we would address performance concerns post-release. This response was especially perplexing given my position as the highest-ranking software engineer in the company (Principal Software Engineer). I questioned, if not me, then who would understand the potential repercussions and risks associated with releasing the product with these unresolved issues?

Approximately four months later, in December of that year, we indeed released the application. The outcome? As expected, we began losing customers to our primary competitor, and attracting new customers proved to be an insurmountable challenge. Consequently, the VP of Project Management initiated “Project Speedway” to rectify the performance issues.

I have previously chronicled this experience in my factual story titled “The Adventures Of Inspector Cody: The Week From Hell And The Tale Of Project Management Gone Wrong” on this site. In essence, the company tasked another Principal Software Engineer with devising a solution to improve performance. A month later, during a meeting involving him, my manager, and myself, he unveiled his proposed solution. After his presentation, I pointed out that what he had designed closely resembled the Microsoft Sync Framework, suggesting that we explore this framework, as even Microsoft employed it. Yet again, my suggestion went unheeded.

After implementing his solution into the application and witnessing its performance, I informed management that it had actually made the application slower than it was before. Despite my reservations and concerns, the application was released with this performance degradation.

Desire for More Features: A Missed Opportunity

Many months later, during a meeting attended by my manager, other company managers, and vice presidents, the discussion revolved around the features they envisioned for the next release, with a particular emphasis on performance improvements. As I listened to their requests, my frustration grew, and I raised my hand to voice a pressing concern. I candidly conveyed that unless we were allowed to redesign the database, which, to date, represented the most poorly conceived designs I had ever encountered, achieving their desired features would either be impossible or would take so long that our competitor would outpace us.

The reaction of the managers and VPs in the room, aside from my boss, suggested that this was the first time they had heard such a concern. Fortunately, my boss interjected and reminded them, “Dave has been raising this issue for four years; why aren’t we listening to him?” However, once again, my advice fell on deaf ears, and they continued to lose customers to their competitor.

To compound matters, they decided to sell the company and initiated widespread layoffs. I found myself caught in the third round of layoffs, during which all Principal Software Engineers in my department were let go. Consequently, the application lost its entire reservoir of expertise, leaving behind junior and intermediate developers with no guidance or leadership. Since then, the product has struggled to maintain its footing. It’s regrettable because the application held significant potential and addressed a genuine need for users in the automobile repair industry.

On a related note, if your company is acquired by an investment firm, my advice is to start seeking new job opportunities promptly. In my experience, investment firms primarily focus on cost reduction and reselling the company for a profit. They typically lack interest in your welfare or the products and services you are working diligently to develop.

The Value of Asking Questions

One hallmark of a professional software engineer is the willingness to ask questions. I vividly recall a valuable lesson from the business owner and esteemed author, Daniel Appleman, who once said to me, “There are no dumb questions, only those too afraid to ask.” This insight resonated with me so profoundly that for years, I made it a point to share this quote with my university students at the beginning of every course.

Indeed, Daniel is absolutely correct. However, it’s essential to acknowledge that sometimes individuals may not know what questions to ask or might feel uncomfortable raising them in a group setting. That’s precisely why I encouraged my students to email me their questions privately, assuring them that I would address them in the next class session without disclosing the sender. I even extend the same courtesy during my conference sessions and on my show, “Rockin’ the Code World with dotNetDave.”

Nonetheless, it’s crucial not to overdo it in a given situation, as excessive questioning might signal a lack of familiarity with the subject matter under discussion. In such instances, consider jotting down your questions and conducting research later. Alternatively, you can bring these questions to your manager or lead engineer during a one-on-one meeting if you find that more comfortable.

Asking questions serves as a clear indication to your manager and teammates that you are actively engaged and genuinely interested in the topic at hand. This not only enhances your understanding but also fosters a positive impression among your peers. Therefore, I strongly recommend researching the topic beforehand, preparing questions, and actively participating in discussions.

In Conclusion

If you find it challenging to speak up in group settings, conquering this fear is crucial for your journey toward becoming a professional software engineer. When I began my career in software engineering, speaking in front of people ranked as my second greatest fear, just behind the fear of death! To overcome this apprehension, I took the initiative to become a founding member of a user group. I forced myself to step into the spotlight, delivering presentations until I became comfortable addressing small groups, speaking at conferences, and even teaching at a university. Today, I no longer experience nervousness or fear when addressing an audience, regardless of its size. My primary advice to fellow engineers is to immerse yourself in such situations until the fear and anxiety dissipate.

I also strongly recommend that if your current team does not foster an environment that encourages you to voice your thoughts and continuously dismisses your contributions, consider exploring opportunities with a different team or company. Remaining in such an unsupportive environment not only hinders your career growth but also leads to considerable frustration and stress. It’s worth noting that excessive stress can have adverse effects on your overall well-being.

I trust that these suggestions will empower you to confidently express yourself within your team, ultimately paving the way for a fulfilling career as a professional software engineer. Should you have any comments or questions, please feel free to share them below.

Further Reading

Rockin’ the Code World: Special Guest Robert Bogue

The Adventures of Inspector Cody: The Week from Hell and the Tale of Project Management Gone Wrong