Category: Leadership

When I was first enlightened to the Agile Manifesto, I was an enterprise IT Service Management practitioner, occasionally feeling more like a hindrance to the software delivery process, rather than a helper. I felt like my eyes were opened as I discovered this passion for DevOps that grew within me. Ironically, I wanted to transform my surroundings into DevOps culture all at once with a “Big Bang”. I was very excited to evangelize DevOps to my colleagues, but many of them were skeptical at best and I constantly had to remind myself that change doesn’t happen overnight. I thought the solution was to create a new DevOps Engineer role that I could help bridge the gap between Dev and Ops. This did not happen like I hoped it would. But as they say, fine wine gets better with time and as I matured over several years, I gradually introduced new DevOps concepts in bite-sized chunks, built a structured road map, and I began to see the fruits of the fundamentals by simplifying our ways of working. I broke it down into five fundamental questions about DevOps maturity.

1. What do my business leaders need from my team and what problem(s) am I trying to solve?
2. What are viable ways to solve these problem(s) with the skills I have in-house?
3. What are some ways to foster hidden DevOps skills, encourage new leaders, and promote cross-training to develop more T-shaped skills models?
4. Have I implemented very basic Agile principles and processes with the tools I have to establish velocity and productivity metrics for my team?
5. How can I create measurable mechanisms of accountability, such as SLAs and OLAs, for my team to be held accountable by our business leaders?

I imagine my story is not unique. Many tech evangelists are enthusiastic about the next big thing and we like to develop complex frameworks to handle major changes. In terms of DevOps, we may have overcomplicated some things as the DevOps train gained speed over the years. The benefits of DevOps are real, but DevOps practitioners must be more responsible by being better IT Leaders and better stewards of DevOps culture.

No doubt, bringing in a DevOps Engineer to any organization at any maturity level will yield some immediate results, but they can only go so far and will quickly burn out if Senior Leaders and Executives do not understand the major roadblocks of traditional org structures. Before any IT manager drops a job posting for a DevOps Engineer in hopes to get immediate value, I think it is important to go back to basics of their own business and evaluate themselves based on these five questions.

Each of these questions can spawn major initiatives of their own right. Do not underestimate them. Even if these questions have been answered it is good to regurgitate them with your stakeholders quarterly, at minimum, if not more frequently to better evaluate the growth and health of your team. Each question should be associated with a maturity model, such as a Capability Maturity Model (CMMI). From within one’s own IT team, “maturity” can seem like a subjective interpretation when self-evaluating, but so long as your stakeholders agree on measurement criteria it can be a powerful driver in your DevOps journey. This is what a CMMI does – it helps your team establish real criteria for levels of maturity.

Let’s go out on a limb and say that your IT team has self-evaluated their Agile and DevOps team maturity as a Level 2 or Level 3 using CMMI. At this point, team members are likely to have some common language in the Agile framework, they understand the general principles of DevOps, beginning to automate simple development or infrastructure requirements/tasks on a repeatable basis, and they are operating in a somewhat measurable manner. Even still, a DevOps Engineer might not be your “missing link” that will supercharge your team.

Given that an IT org should be understanding core concepts of Agile and DevOps, they should understand what “technical debt” means for their team. They should also understand how to identify and remediate some of this tech debt. In personal finance, how do you pay down on debt? You create margin in your daily activities to pay off debt little bits at a time. Same is true for tech debt. Know that tech debt isn’t just code that needs to be refactored, or improving log monitoring, or that nagging error thrown when a user session ends instead of rerouting safely to the login menu. Tech debt is also future debt, similar to how a municipality uses set aside funds to upgrade roads and bridges in preparation of a new heavy industry. In software terms, that could be improvements to your software delivery pipeline, or creating flexible, ephemeral infrastructure through automation. You may choose to use your team’s existing knowledge of things like good source code management, or build and unit test automation to create repeatable, consistent, and reliable flow of code to Dev and Test environments.

The point here is that a DevOps Engineer that really understands their value can certainly be worth their weight in gold, but a great DevOps Engineer also acknowledges that the members of an existing team could be better off leveraging existing skills and capabilities, rather than adding a new functional DevOps role to the team. Consider creating a DevOps Center of Excellence, or an internal “DevOps Dojo” community of practice that focuses solely on facilitating continuous learning and improvement for existing Product Teams. Try these alternative ways to build effective DevOps team structures to help unlock hidden potential in your journey to DevOps maturity.

As leaders, we’ve all encountered a team that’s struggling—an underperforming group that seems stuck in a cycle of missed deadlines, low morale, or inconsistent delivery. It’s tempting to double down on oversight or push harder for results, but I’ve learned that the real breakthrough comes from giving that team a voice. Not just a platform to vent, but a structured way to articulate their challenges, take ownership of their work, and show upper management what they’re capable of achieving with the right support.

The key? Pairing accountability with visibility through meaningful metrics—drawn from DevOps, CI/CD, and Agile practices—and using those numbers to tell a story of progress, not just problems.

Step 1: Empower Through Accountability

An underperforming team often feels voiceless because they’re caught in a reactive loop—firefighting issues without a clear path to improvement. To break that cycle, start by giving them ownership of their process. This isn’t about blame; it’s about trust. Introduce common DevOps and Agile metrics that resonate with their day-to-day work and align with broader goals. Think:

• Cycle Time: How long does it take to move a task from “in progress” to “done”? This shines a light on bottlenecks without pointing fingers.
• Deployment Frequency: Are we shipping small, frequent updates or stuck in long, risky release cycles? This ties directly to CI/CD maturity.
• Mean Time to Recovery (MTTR): When things break, how quickly can we recover? This reflects resilience, not just failure.
• Sprint Velocity: Are we consistently delivering value, or are scope creep and interruptions derailing us?

These aren’t just numbers—they’re a language the team can use to define their reality. Sit down with them, set baselines, and agree on what “better” looks like. The act of measuring empowers them to hold themselves accountable, shifting the narrative from “we’re failing” to “we’re improving.”

Step 2: Turn Metrics Into a Megaphone

Here’s where leadership steps up. An underperforming team rarely has the clout to get the resources or attention they need from upper management. That’s your job. Take those same metrics—cycle time, deployment frequency, MTTR, velocity—and weave them into a story for the C-suite. Don’t just dump data on their desks; show trends.

For example: “Three months ago, our cycle time was 14 days due to manual testing bottlenecks. We’ve brought it down to 7 days by automating key checks, but we’re still capped by limited QA bandwidth. With one more engineer, we could hit 4 days—unlocking faster feedback and happier customers.” Suddenly, the team’s struggle isn’t a complaint; it’s a business case with a clear ROI.

This approach does two things: It gives the team visibility—proof they’re not just spinning their wheels—and it positions you as a leader who bridges the gap between boots-on-the-ground reality and executive priorities.

Step 3: Celebrate Progress, Not Perfection

Metrics aren’t a stick to beat the team with; they’re a compass. Celebrate upward trends, even if they’re incremental. Did deployment frequency jump from once a month to twice? That’s a win. Did MTTR drop by 20% after a post-mortem led to better alerting? Shout it out. These milestones build momentum and morale, showing the team their voice is being heard—and acted on.

Upper management notices this too. When they see consistent progress tied to tangible outcomes (faster delivery, fewer outages, happier stakeholders), they’re more likely to invest in the team—whether it’s headcount, tools, or training. That support fuels the flywheel: accountability drives improvement, improvement earns trust, and trust unlocks success.

The Payoff: A Team That Speaks for Itself

I’ve seen this play out with a team that was drowning in technical debt and missed deadlines. We started small—tracking cycle time and velocity to pinpoint where they were stuck. They owned the numbers, I amplified their story, and within two quarters, we secured budget for a new CI/CD pipeline. Deployment frequency tripled, morale soared, and the team went from “underperforming” to a case study in resilience. They didn’t just find their voice—they became a chorus.

Leadership isn’t about fixing every problem yourself. It’s about giving your team the tools to define their challenges, the metrics to measure their progress, and the visibility to earn the support they need. When you do that, you’re not just lifting a struggling team—you’re setting them up to lead.

If you know me a little bit, you know that I have fond memories of riding adventure motorcycles and exploring my world on two wheels. When there’s time, I still enjoy the adventure. It is about the journey and rarely about the destination. When you’re on a metal horse, it’s a thrilling dance with the open road or trail, where the engine’s purr, the wind’s embrace, and the boundless horizon create an exhilarating symphony of freedom and connection with the world. Simultaneously, the journey can seem quite daunting at times when you find yourself in incomprehensible predicaments, occasionally feeling lost or alone. The journey presents its fair share of challenges.

Similarly, the journey of DevOps transformation in Software Engineering is a thrilling, yet challenging ride where streamlined processes, collaborative teams, and the pursuit of excellence converge, creating a symphony of innovation and efficiency that leaves a lasting impact on the way we build and deliver software solutions.

To start on your journey, you must first know where you are. One way to help assess where you are is by viewing your organization through the lens of Conway’s Law. Conway’s Law is a consistent observation and theory by computer scientist Melvin Conway in 1967 that suggests that the way an organization is structured significantly influences the architecture and design of the software it produces. This is a widely accepted principle still observed in software engineering today. If teams within an organization don’t communicate effectively or work together cohesively, the software they develop may suffer from integration challenges and lack a unified design. It underscores the importance of aligning organizational structure with the intended software architecture.

Although the adventure is the personal experience felt throughout a journey, the adventure can be quite costly and unsafe if you are not considerate of the dangers around the next turn. It is important to have a strategic approach to get to your destination safely. This is particularly true when designing software solutions.

I introduce to you the Reverse Conway Maneuver. The Reverse Conway Maneuver is a strategic approach that reverses this relationship. Instead of allowing the existing organization’s structure to dictate the software architecture, it involves first defining the desired structure of the software and then organizing teams, processes, and communication flows within the organization to align with this vision. In other words, it reshapes the organization to optimize the software architecture for specific goals, thus fostering more efficient, adaptive, and collaborative development processes.

Implementing the Reverse Conway Maneuver in your software development team involves aligning your team structure with your desired software architecture. Here are some examples of how this can be done:

1. Team Composition Based on System Modules: Identify key components or modules within your software system and organize teams around these components. Each team is responsible for a specific module, allowing them to have in-depth expertise and ownership. This way, the organization of teams mirrors the software architecture.
2. Cross-Functional Feature Teams: Instead of organizing teams by skill sets (e.g., developers, testers, designers), create cross-functional feature teams. Each team is responsible for end-to-end development of a particular feature or user story, including design, development, testing, and deployment. This aligns team structures with the flow of work in the software.
3. Domain-Oriented Teams: Structure teams around specific business domains or areas of expertise. Each team focuses on a particular domain and is responsible for maintaining and improving the software related to that domain. This approach can lead to more cohesive and specialized teams.
4. Service-Oriented Architecture (SOA): If your software architecture is based on microservices or a service-oriented architecture, organize teams around individual services. Each team is responsible for developing, maintaining, and evolving a specific service. This approach supports the decoupled nature of microservices.
5. Strategic Alignment: Ensure that your team structure aligns with the strategic goals of your organization. If there are specific areas of the software that need rapid development, such as a new product feature, create a specialized team for that purpose. Conversely, if there are stable components, form teams to maintain and optimize them.
6. Evolution and Adaptation: Be prepared to adapt your team structure as your software evolves. Teams should be flexible and able to reorganize when the software architecture requires it. Regularly assess and adjust team structures based on the needs of the software and the organization.
7. Clear Communication Paths: Ensure that there are clear communication channels and responsibilities within and between teams. If you find that teams have to communicate outside common and comfortable channels, this could indicate inefficiencies in communications. Thus, resulting in inefficient software systems. Effective and efficient communication is essential to make this approach successful.

The crucial step is aligning your team structure with your software architecture and organizational objectives. This alignment accelerates development, enhances system ownership, and fosters effective communication, essential in software development teams. Whether you’re on a journey through rugged terrains on knobby tires or navigating your DevOps transformation, using a strategic approach like the Reverse Conway Maneuver is a compass guiding you to your destination.