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

Storytime: The Impossible Deadline

https://blog.snackablecto.coach/p/culture-first-learn-to-say-no

🍪 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

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

1. 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.
2. 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.
3. 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.
4. 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.
5. 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.

Bonus: Mindset is often already a game-stopper, and it’s based on soft skills and attitude.

When I talk to developers in conversations about how to become better in what they do or how to step up the game and become a senior, there is a big topic every time:

❌ The Resistance is an intrinsic force everyone knows somehow. The same force keeps us in silos and separates and prevents us from working in a team.

• I don’t want to see others know about my short-comings
• I don’t want my colleagues to see my code
• I am afraid of deploying; I don’t want to take the responsibility
• I don’t want to become blamed after pushing the PR.

These are just a few of the possible thoughts we have caused by our inner Resistance.

Having the right mindset is the key to overcoming Resistance. Mindset is one of the pillars of a good culture and is based on the self-confidence we get from the mix of soft and hard skills, paired with discipline and the will (Motivation) to improve.

Discipline and motivation can be hard to build up and keep, especially since discipline is a finite resource.

The power of the group; You are not alone.

So, to maintain a sufficient mindset, you need to keep up the following things:

• Soft-Skills
• Tech-Skills
• Discipline
• Motivation / Will

The last two are very influenced by the culture and the environment around you.

🍀 Do you have an inspiring tech lead? Are you surrounded by motivated peers who infuse each other?

❌ Or are you in an environment where every developer is for oneself? Isolated, hidden and silent? Only talked when I got asked. That is bad, this cannot lead to anything good long term.

Problems aren’t tackled, finger-pointing is a default symptom, and no one exactly knows what is going on.

Are you seeking a Software Engineering, Culture, and Leadership Mentor?

https://mentorcruise.com/mentor/adrianstanek/

Best,

Adrian