Software engineering, Scaling
Balancing productive tension: the essential push-pull between developers and management
In the fast-paced world of startups, the race to achieve goals before time or funding runs out is relentless. The stakes are high because there is a 50% chance the startup does not make it to the fifth year. As a developer you are in the frontline and this means navigating tight timelines and high expectations. However, there's an often overlooked issue in this dynamic: developers not pushing back enough against management decisions. This lack of pushback can lead to significant negative consequences for both the project and the team. In this post, we’ll explore the productive tension between developers and management and discuss ways to create an effective balance that benefits everyone.
Quality vs time to market
For a software developer, the goal is to deliver a product that is both high in quality and scalable. Management often sees an opportunity in the market they want to capitalize on before competitors beat them to it. When either viewpoint is taken to the extreme, it leads to one of two scenarios:
- A low-quality product rushed to market Startups frequently adopt this approach, and initially, it might lead to success due to early adoption. However, quality issues and failure to meet user expectations can result in a rapid decline as users migrate to competitors.
- A high quality product that is entered in a high saturated market This is common among technical founders who aim for perfection. They might create an excellent product but find themselves outpaced by competitors, needing to spend a lot of money to capture market share.
So how to navigate these extremes? What I typically do is emphasize to management the importance of investing time to improve quality in favour of scalability'. All founders want to aggressively scale their user base, and when I present this argument, they are generally receptive. Additionally, I set aside my tendency towards perfectionism and focus on the essentials, adding non-essentials to the backlog. Another practice that I emphasise is making releases easy and boring. This allows the organization to quickly ship features and gradually improve and enrich them.
Predictability vs pace
Early-stage startups often promise the world to their first clients and investors and it's up to the tech team to deliver the product. Management or sales teams frequently do not understand the technical complexity of certain features, which can lead to unrealistic deadlines. Not delivering on time could mean losing a potential investor or client, something startups cannot afford. This puts the tech team in a challenging position. Developers might feel that the only way to meet these deadlines is by working long hours but following this strategy for to long can backfire. Research shows that consistently working over 40 hours a week can lead to a decline in productivity, an increase in mistakes, and eventually, a higher chance of health issues like burnout.
On the other hand, startups operate with limited resources and need to ensure they maintain the best possible pace to fulfill their promises. How to deal with this conflicting interest:
- Accept it is part of startup life First, understand that a fast-paced, high-pressure environment with occasional long hours is part of working at a startup. If that doesn’t align with your work preferences, you might consider working for a larger corporation, where the pressure is generally lower.
- Address the unrealistic deadline When faced with an unrealistic deadline, I address it by explaining the technical challenges that may have been overlooked and discussing the risks associated with the timeline. I then initiate a conversation about possible adjustments—whether that’s slightly delaying the deadline, reducing the feature set, or bringing in additional help. In my experience, there’s usually some room to adjust the plan.
- Hold yourself to your word Lastly, I want to emphasize the importance of building a reputation as a developer who reliably meets their estimated deadlines. If I miscalculate an estimate, I take accountability and put in extra hours to meet my commitment. The organization knows that I stand by my word and deliver on what I promise amd this gives me some credibility during the discussions
Collaboration vs leadership
A good developer understands when to push back and when to do the job. If you constantly push back, management might feel that you do not understand what is at stake or respect the chain of command. On the other hand, if the startup is managed by 'leaders' who rule by dictate, that's not good either. When I start at a company, I begin by building trust and spend time understanding the business. In discussions, I clearly state the impact of their decisions, propose alternatives, but always emphasize that it is their decision, thus respecting their role as manager. This approach fosters a culture of trust and collaboration
To summarise: There is sometimes tension between management and developers, which can harm a startup when there's a lack of mutual understanding. I hope I've made it clear that this isn't solely the responsibility of management to guard the balance; developers should play their part as well. Here, using your soft skills is as important as your coding skills to the success of the startup.