Did you know that many projects are delivered on time, on budget, and on scope… and are still considered failures?
That’s because they don’t satisfy the user. And that disconnect is exactly what many software laws have been warning us about for decades.

The Unwritten Rules of Software

Before agility was a thing, practitioners were already documenting the harsh realities of software development. These weren’t official standards or processes—they were empirical truths, learned the hard way, and observed so consistently that they became known as software laws. A few stand out:

• Conway’s Law – Software architecture mirrors the communication structure of the organization.

• Ziv’s Law – Requirements will never be fully understood until there is a working version of the software.

• Humphrey’s Law – People don’t know what they want until you show them something they don’t.

• Brooks’ Law – Adding manpower to a late software project makes it later.

These aren’t just fun quotes for talks—they reflect the reality of building things in complexity, where what’s supposed to work on paper falls apart in practice.

Why These Laws Exist

Because software isn’t predictable like traditional engineering. It:

• Changes constantly.

• Is highly abstract.

• Is based on rules we invent as we go.

• Is deeply affected by communication, expectations, and context.

And because of that, decisions have side effects. Bad practices don’t just delay timelines—they erode trust, waste resources, and burn teams out.

When Management Ignores Them… It Shows

According to the CHAOS Report 2015:

• Only 11% of Waterfall-managed projects succeeded.

• 29% completely failed (cancelled or delivered nothing).

• The remaining 60% were over budget, late, or missed scope.

And that’s because traditional management models operate as if the system were simple or complicated, not complex—they try to control it instead of working with it.

The Turning Point: 12 Principles That Changed Everything

In 2001, after decades of seeing these laws violated again and again, a group of practitioners came together to codify the antidote. The result was the Agile Manifesto, and more importantly, its 12 principles.

They didn’t come from theory—they came from practice.
From Conway, Ziv, Humphrey, Brooks, and thousands of unnamed failures.

The 12 principles and the 4 values are a distilled compendium of observations from the field. They recognize that:

• Change is constant.

• Value is more important than scope.

• Working software matters more than detailed plans.

• Collaboration beats contract negotiation.

• Reflection and adaptation are non-negotiable.

And that’s just a glimpse.

These are only a few of the ideas they capture—each principle holds layers of hard-earned wisdom gathered from real-world experience.

Did you know?

According to Google’s Project Aristotle, the most successful teams weren’t the ones with the most technical talent, but those where leadership fostered psychological safety—environments where members felt safe to speak up, take risks, and make mistakes without fear of punishment.

A Gallup study found that 70% of the variation in team engagement is directly linked to the immediate leader. Teams with empathetic and committed leaders show higher productivity, lower turnover, and greater customer satisfaction.

MIT Sloan Management Review revealed that teams led by individuals who adopt a coaching approach—rather than traditional supervision—are 39% more likely to exceed their annual goals.

If modern developers have evolved into autonomous, creative professionals—capable of critical thinking and focused on delivering value— (Post)… What kind of leadership do they need?
Does the traditional role of a boss—someone who supervises, approves, and controls—still make sense?
Or is it time for leaders and managers to evolve into something more aligned with the reality of modern teams?

The work of a software engineer today goes far beyond writing code. They contribute to product decisions, collaborate with stakeholders, refine requirements, improve processes—and most importantly, they take ownership of the value they deliver.

Leading a team like this isn’t about knowing more than them or controlling every step.

It’s about creating the conditions that allow them to perform at their best.

Another fundamental trait of modern leadership is the recognition that the team is responsible for its work—and for everything required to make it happen.

The leader is not accountable for the team’s output, but for the team itself—the people doing the work.
This perspective has also been expressed by Simon Sinek, who states:

“Leaders are not responsible for the results. Leaders are responsible for the people who are responsible for the results.”

The team is made up of professionals who are fully capable of organizing themselves, making decisions, and executing—often better than any external figure, including the leader.
The true value of leadership doesn’t lie in telling people what to do, but in ensuring the conditions exist for the team to do it well.

That means taking responsibility for the team across multiple dimensions:

• Their emotional well-being, by avoiding toxic or unsustainable environments.
• Their relational health, by fostering trust, respect, and open dialogue.
• Their operational clarity, by removing friction, ambiguity, or overload.
• And also their holistic development: supporting their professional, economic, technical, personal, and collective growth.

A healthy team doesn’t just work better—it learns, innovates, and stays.

In this transformation of leadership, we’re talking about a fundamental shift in how we think, act, and relate to teams.
Leadership rooted in control, obedience, and top-down supervision no longer works in environments that demand adaptability, ownership, and critical thinking.

This shift isn’t just about tone or personality—it’s about moving from control to trust, from supervision to support, from task focus to value creation. It requires letting go of outdated habits like micromanagement, rigid reporting structures, and one-way communication, and instead embracing collaboration, clarity, feedback, and shared purpose.

Did you know that over 70% of projects following a traditional approach fail in environments with high uncertainty or constant change?
Studies like the Chaos Report have shown that failure often lies not in execution… but in choosing the wrong approach.

What if the real issue isn’t the method you choose, but not understanding the kind of problem you’re facing?

Before deciding whether a traditional or agile approach is best, it’s essential to understand the nature of the problem.
To do this, we rely on two complementary frameworks:

• The Stacey Matrix

• The Cynefin Framework

The Cynefin Framework was created in 1999 by Dave Snowden, a Welsh researcher in complexity theory and knowledge management.

This framework is a decision-making tool based on the nature of the context or problem. It is widely used in business management, strategy, leadership, and the resolution of complex problems.

The Cynefin Framework

It reinforces the idea that not all problems should be approached the same way, as they depend on the nature of cause and effect.

3. Complex

Approach: Experimentation, short cycles, continuous learning.

4. Chaotic

Approach: Immediate action, containment, stabilization.

Conclusion

It’s not about being a fan of agile or traditional methods.
It’s about understanding the problem before applying the solution.

When the environment is stable and predictable, a traditional approach may work.
But in uncertain, changing environments with multiple actors and viewpoints, you need flexibility, adaptation, and short cycles.