The Culture-First Approach – It's Hard To Say "No" in Software Development
The Three Pillars Of A Good Culture – Part 2.1
Foreword – Why do we often have such bad cultures in software development
I still remember the day business announced the impossible deadline, the kind that makes your stomach drop. As the lead developer, I knew this was a disaster waiting to happen, but I nodded and agreed, afraid of rocking the boat.
Today, I want to write about a dramatic story that many developers know very well; the typical story sometimes makes the developer’s life hard to endure. Even then, when the profession is actually about engineering and creativity – unfortunately, it is more often about delivering something in an unrealistic, inhuman timeframe.
But there is hope. Today, I will cover the problem and the root cause, which was often the case when I helped companies and tried to help my own organization.
The following story is something I, unfortunately, know very well, and it took years to understand what was going wrong. I see this so often today, but it is still true in companies I work with.
On Wednesday, there will be the podcast+article version, where I detail how the three pillars are the foundation for the solution to the problem.
Adrian
• Part 1: The Challenge of the Dominant Team Culture
• Part 2: The Three Pillars of Developer Maturity
• Part 3: Human-First: Why Culture Trumps Technology
• Part 4: The Mentorship Model: Leadership and Loyalty
• Part 5: Bridging the Gap Between Business and Development
🚀 This multi-part series is about the Culture-First Approach, my favorite topic. We will go through the following parts.
Storytime: The Impossible Deadline
🍪 Cliffhanger: See the full podcast video next Wednesday here on SnackableCTO.
Back in the day, the product owner walked into our cramped meeting room with an urgent announcement; I knew something was wrong. A new project required us to build a feature in just two weeks—a task typically took a month to make right.
As the lead developer, I felt the weight of this unreasonable demand. My team was already overwhelmed with ongoing projects, and the pressure to deliver quickly was immense. Despite my reservations, I agreed to the deadline, hoping to avoid conflict and disappointment – A wrong choice.
The Consequences of Shortcuts
As we began working on the project, the pressure intensified. We took shortcuts to meet the deadline, sacrificing testing and documentation. We worked long hours, fueled by caffeine and stress, but the more we rushed, the less stable the code became.
Arguments flared up over trivial issues, and our team spirit fractured. When we finally delivered the feature, it was riddled with bugs, causing problems across the system.
The aftermath was brutal: customer complaints missed milestones and shattered trust within the team and with stakeholders.
The Turning Point
We needed to rebuild our team's credibility and focus on sustainable development practices.
Realizing that something had to change, I called a meeting with my team. We discussed the impact of shortcuts and how they had harmed our product, reputation, and relationships. It was a difficult but necessary conversation. We agreed to never compromise quality for unrealistic deadlines again. We needed to rebuild our team's credibility and focus on sustainable development practices.
In fact, we had those meetings very often. Colleagues will remember it.
Rebuilding Trust and Embracing Quality
…saying "no" is often the most critical choice, even if it's uncomfortable.
From that day forward, we advocated for realistic timelines and emphasized thorough testing and proper documentation.
Saying "no" to shortcuts and "yes" to quality became our guiding principle. This shift in approach helped us rebuild team morale, repair relationships with other departments, and deliver better products. It also made me realize that saying "no" is often the most critical choice, even if it's uncomfortable.
👉 This was when testing became important, and TDD was introduced.
A Valuable Lesson Learned
The experience taught me that shortcuts may offer temporary relief but lead to long-term problems. We created a more sustainable and successful development environment by taking responsibility for our work and committing to quality. Saying "no" isn't just about rejecting a request; it's about maintaining integrity and ensuring the health and longevity of our projects.
Ultimately, this shift in mindset allowed us to grow as a team and deliver products that met our high standards of quality and reliability.
When to Say No and How to Say No
learning to say "no" can be a pivotal skill
In software development, learning to say "no" can be a pivotal skill for maintaining product quality and team morale. Saying "no" becomes necessary when unrealistic deadlines or excessive pressure compromise quality, leading to technical debt and burnout.
To say "no" effectively, teams must build credibility through consistent, high-quality work and clear communication. Explaining why a deadline is unattainable is crucial, providing evidence of the impact on product quality and future timelines. By addressing these issues with maturity and offering alternative solutions, such as a revised timeline or additional resources, development teams can navigate challenging situations while maintaining stakeholder trust.
Ultimately, saying "no" should be a collaborative effort to achieve sustainable success.
Take-Away
Deliver Consistent Quality: Credibility in a development team is built on consistently delivering high-quality work. Teams prioritizing robust code, thorough testing, and reliable functionality are more likely to earn stakeholders' trust.
Clear and Transparent Communication: Credibility is reinforced through clear, honest communication with stakeholders. When developers are open about challenges and realistic about timelines, it helps establish trust.
Adopt a Proactive Approach: Proactively identifying and addressing potential issues before they escalate demonstrates a commitment to quality. This proactive attitude enhances a team's credibility by showing they can handle unexpected obstacles.
Demonstrate Responsibility and Ownership: Teams that take ownership of their work, acknowledging successes and failures, are viewed as reliable partners. This sense of responsibility contributes to building credibility over time.
Show a Willingness to Improve: Credibility grows when a development team continually seeks to improve their skills and processes. Teams that embrace learning and adapt to new challenges are seen as trustworthy and dependable.
The follow-up podcast/article will be released next Wednesday.
Seeking guidance? Whether it's a collaborative journey for your team or a personalized 1-on-1 mentoring experience, I'm here to help. Reach out, and let's find the perfect fit for you.
Have a great week!
Adrian Stanek, snackableCTO
Here is the actual presentation deck.
When you say no, you are actually focusing on what matters most.