Throughout my career as a developer, cloud architect, and Delivery Manager, I have observed how different leadership models either restrict or unleash a team’s potential. The most fundamental shift I make in my approach to leadership is turning the traditional corporate hierarchy upside down.
I call this The Inverted Triangle Leadership Framework.
In a traditional corporate pyramid, executive leadership sits at the top, issuing top-down commands. The engineers and domain experts—the people directly building software and delivering customer value—end up at the bottom under the weight of reporting lines and bureaucratic control.
In my leadership philosophy, this pyramid is inverted:
TRADITIONAL HIERARCHY THE INVERTED TRIANGLE (MY PHILOSOPHY)
===================== ====================================
/\ Leadership (Command & Control) \ Customers, Developers & Teams / (Broadest:
/ \ \ Delivering value & code / Highest autonomy,
/ \ Middle Management \ / direct impact)
/ \ \ Tech Leads & Enablers /
/________\ Developers & Specialists \ /
\ Delivery Manager / (Foundation:
\ & Support / Psychological safety,
\__________________/ shielding & enablement)
Those closest to the code and customer problems are best positioned to make operational and technical decisions. The goal of leadership is to maximize autonomy, ownership, and focus for this layer.
The role here is not surveillance, but alignment—connecting cross-team initiatives, unblocking dependencies, and ensuring processes support momentum rather than slowing it down.
As a leader, I position myself at the bottom. My primary job is to absorb organizational noise, clarify strategic context (“why” and “what”), secure necessary resources, and provide a stable, trusting foundation for the team to build upon.
A leader’s primary duty is not dictating how tasks are solved, but removing friction (“unblocking”) and ensuring the team has what it needs to thrive. When a team encounters CI/CD bottlenecks, ambiguous requirements, or unrealistic deadlines, it is the leader’s responsibility to step in and resolve it.
Decisions should be made by those closest to the impact of the decision. Instead of micromanagement, leaders provide boundaries, business goals, and architectural principles. The team owns the implementation.
When leadership supports from below, it creates a safe environment for experimentation and growth. Production failures are met with blameless post-mortems and continuous learning rather than finger-pointing. When engineers know their leader has their back, they feel empowered to innovate and take calculated risks.
Instead of measuring hours logged or story points closed, success is evaluated by how smoothly and sustainably value flows from concept to production. Leadership focuses on eliminating context-switching and unnecessary handoffs.
In my day-to-day work as a Delivery Manager and SRE / Cloud consultant (working with organizations like Knowit, Tet Digital, and Nordic Financial Cert), I translate this philosophy into actionable habits:
This framework forms the foundation of my leadership approach. In upcoming articles, I will explore key pillars in greater depth: