Many software engineers dream of managing a software company or leading a development team, striving to make a meaningful impact. I share this very ambition. Over the years, I have had the privilege of leading teams and serving as the Director of Development at Proflowers.com, albeit for a brief period. Additionally, I have had the opportunity to oversee software development on a global scale at another company.

However, despite these experiences, I have never fully run a software company, except for my solo consulting venture, McCarter Consulting, which I founded in the ’90s. It is important to note that McCarter Consulting is a one-man operation—me. Throughout my extensive two-decade career as a software developer, I have witnessed both triumphs and failures. These firsthand experiences have led me to favor contracting positions, as they allow me to work from the comfort of home while avoiding the stress of companies that fail to embrace the core principles that, in my opinion, are essential for a thriving software company.

The Importance of Trusting Your Employees

Trusting your employees should be the cornerstone of any software company. Trust is a foundational element of all relationships, and it is just as crucial in a business setting. A friend of mine who completed a short contract at Quicken Loans shared practices that left an impression on me, and now I cannot help but wonder what it would be like to work there.

One such practice involved a surprisingly simple solution to the tedious task of submitting business trip expenses. In most companies, I have had to submit an expense report after a trip, only to get caught in a long, frustrating back-and-forth with the accounting department. At one company, the VP of my department had to intervene multiple times just to expedite the reimbursement, which detracted from my ability to focus on my work. At Quicken Loans, however, employees are issued an American Express card for business expenses, eliminating the need to submit reports after a trip. While I questioned the potential for abuse, my friend assured me that employees who misuse the system face termination.

What struck me even more was Quicken Loans’ refusal to grant any special privileges to executives. In stark contrast to many companies where top leaders enjoy exclusive perks, such as reserved parking spaces and lavish restrooms, Quicken Loans executives park in the farthest lot, just like everyone else. The company fosters a culture of mutual respect, where employees who prove untrustworthy are shown the door. This level of trust and equality within the workplace is rare, and it is one I find deeply appealing.

Reflecting on America’s history, there was a time when companies placed trust in their employees, leading to a more positive work environment and better products. In the past, many people spent their entire careers at one company, earning a pension upon retirement. Sadly, this is no longer the norm, and the absence of trust in the workplace has contributed to the erosion of employee loyalty. If a company cannot trust its employees, why hire them in the first place? Building trust should be an investment—one that software companies should prioritize for long-term success.

Crafting a Developer-Friendly Work Environment

The work environment is critical in keeping software development teams happy and productive, yet many companies do not get it right. It is not just about the physical workspace; office dynamics and the overall culture play a huge role. Let us start with the workspace.

A developer’s work environment should be tailored to their unique needs, distinct from those of sales, management, or support teams. Developers thrive in quieter spaces with natural or soft lighting, cooler temperatures (since we tend to run hotter than other teams), and a general sense of tranquility. Creating an ideal workspace is not a one-size-fits-all approach, but it is essential to consider individual preferences and needs.

In my experience, very few companies have fully grasped this concept. However, I did see a positive example at Microsoft. There, developers transitioned from having private offices to working in open team rooms that featured tables, plenty of power outlets, and breakout areas for meetings or collaborative sessions. Administrative staff were mobile, able to move between rooms to provide support as needed. This model was embraced by everyone, from the CEO on down.

While I am a big fan of creating a comfortable workspace, companies should also remember the importance of sustenance. Providing free food and beverages can be a game-changer, especially during late-night work sessions. Unfortunately, many companies, including the one I worked for recently, do not even offer something as simple as coffee. Personally, I bring my own lunch as a cost-saving measure, and I tend to decline late-night work when food options are not provided. However, I still fondly remember a time at a past workplace when a member of the QA team brought me a pizza and half-gallon of beer to ensure I stayed late to resolve an urgent issue. This act of kindness went a long way in fostering a positive work relationship.

Microsoft exemplifies this practice with its wide array of free beverages, including coffee machines that grind and brew coffee right on the spot, and catering meals for teams during lunch and dinner hours. Their on-campus food court offers a variety of fresh, made-to-order meals—an all-encompassing approach that addresses the basic needs of employees.

Collaboration with Other Teams

A critical aspect of a software company’s success is fostering collaboration between the development team and other departments. Unfortunately, many companies inadvertently create “silos” that hinder such collaboration.

Quality Assurance (QA)

In many organizations, Quality Assurance (QA) is often relegated to the final stages of the development cycle. However, for a truly effective process, QA should be integrated from the very beginning. The question is: how can QA effectively test software if they aren’t involved throughout the development process? To ensure high-quality code, there must be a collaborative approach between developers and QA from the outset.

Furthermore, QA should never be the responsibility of software engineers. While some companies attempt to save costs by eliminating or downsizing their QA teams, this approach is “Penny Wise, Pound Foolish.” When QA is cut or neglected, the consequences are inevitable: the quality of apps and services will decline, leading to user dissatisfaction and, eventually, user loss. Without a dedicated QA team, the effort to build and maintain a loyal user base becomes significantly more challenging and costly.

Sales

When managing a software development team, one of my top rules is that the sales team must engage with developers before making any commitments to customers. Unfortunately, I have often seen this practice ignored. At one company I worked for, the sales team frequently made promises about product features and delivery dates without consulting the development team, leading to immense pressure and unrealistic expectations. One particular instance involved the sales team promising a delivery date to one of the largest insurance companies in the U.S. without input from us. We were forced to work under incredibly tight deadlines, resulting in a delayed and underwhelming product.

Conclusion

These are just a few examples of the challenges that arise when teams fail to communicate and collaborate effectively. In Part 2 of this article, I will share more insights and personal anecdotes on how to create a successful software development environment.

I would love to hear your thoughts: If you were in charge of a software company or team, what steps would you take to improve collaboration and trust? Please share your ideas in the comments below.

If I Ran a Software Company – Part 2

Pick up any books by David McCarter by going to Amazon.com: http://bit.ly/RockYourCodeBooks

If you liked this article, please buy David a cup of Coffee by going here: https://www.buymeacoffee.com/dotnetdave

© The information in this article is copywritten and cannot be preproduced in any way without express permission from David McCarter.