In my journey through various organisations, I’ve come to realise that leadership plays a pivotal role in driving cultural and organisational change. This change is essential for supporting frequent and reliable deployments across multiple teams. Today, I want to share some insights on how leaders can effectively facilitate this transformation, drawing from my experiences and observations.
Setting a Clear Vision and Goals
One of the first steps leaders should take is to establish a clear vision and set achievable goals. In Dan Pink’s book Drive, he emphasises the importance of autonomy, mastery, and purpose. Among these, purpose stands out as a crucial element. When leaders articulate a clear vision, they provide their teams with a sense of purpose. This connection allows team members to see how their daily work contributes to the organisation’s overarching objectives.
- Connect the Dots: Help your team understand how their roles align with the organisation’s goals.
- Foster Purpose: Encourage discussions around the impact of their work, reinforcing the significance of their contributions.
To achieve continuous delivery, organisations must invest in the right tools and automation. If your infrastructure relies on on-premises servers and it takes weeks to provision new environments, you’re setting yourself up for failure. Continuous delivery requires agility, and that means eliminating bottlenecks.
- Automate Everything: From deployments to environment setups, automation is key to speeding up processes.
- Support Learning: Encourage teams to explore new technologies and tools that can enhance their workflows.
Architectural Considerations
Many organisations have legacy applications that may not be architected for continuous delivery. As demands on products evolve, so too must the architecture. This isn’t just about adding new features; it’s about enabling teams to make incremental improvements.
- Long-Term Thinking: Understand that architectural changes can take time. For instance, the Azure DevOps team took four years to overhaul their test infrastructure.
- Invest in Refactoring: Allocate time for teams to refactor and improve existing systems, ensuring they can meet future demands.
Continuous Learning and Improvement
As leaders, we must foster a culture of continuous learning and improvement—not just for ourselves but for our engineering teams as well. Are your engineers under constant pressure to deliver, or do they have the bandwidth to discuss necessary changes and improvements?
- Prioritise Quality: Short-term wins at the expense of quality can lead to long-term losses. Encourage your teams to focus on sustainable practices.
- Create Space for Discussion: Allow time for engineers to reflect on their work and discuss necessary changes without the looming pressure of immediate deadlines.
Breaking Down Silos
Organisational silos can create friction and hinder collaboration. If team members report to multiple managers across different functions, it complicates their ability to work towards a common goal. Leaders must actively work to dismantle these barriers.
- Encourage Collaboration: Foster an environment where teams can work together seamlessly, without the constraints of hierarchical reporting.
- Lead by Example: Demonstrate the behaviours you want to see in your organisation. Your actions will set the tone for the culture of collaboration and trust.
Conclusion
In conclusion, the role of leadership in driving cultural and organisational change cannot be overstated. By setting a clear vision, investing in automation, considering architectural needs, promoting continuous learning, and breaking down silos, leaders can create an environment that supports agile practices and fosters collaboration. Remember, the journey towards effective change is ongoing, and it requires commitment and courage from all levels of leadership. Let’s embrace this challenge together and pave the way for a more agile future.
In organisations, leadership plays a pivotal role in driving cultural and organisational change that enables you to support the frequent and reliable deployments across multiple teams. There are a number of key things that leadership probably wants to focus on or at least try to see if it can have an impact on these things. One is setting clear vision and goals. If you look at Dan Pink’s book Drive around autonomy, mastery, and purpose, purpose is a huge part of that, and setting clear vision and goals enables people to have purpose. They can see how the work that they’re doing every day benefits the overall organisation worked to achieve those goals.
So making those connections, leaders can also invest in automation and tooling. If you want to do continuous delivery to production, it’s going to require a number of things to happen within your organisation. One of those things is that you need to support that ability to deliver faster. Right? So if you’ve got on-prem servers where on-prem environments, where if the developers ask for a new environment, it takes six weeks for the operations team to go buy the hardware, build that out, deliver that in some way, then you’re not going to be able to move to continuous delivery. It’s not possible. Right? That’s a six-week blocker in the middle of that six weeks constraint.
So investing in learning around these technologies, automation, and tooling to be able to support that, to be able to support teams moving more quickly, automated deployments, automated building out of environments, automated everything. Right? Then that’s one piece. The other piece is that the applications that you currently have, that you may have a long-term strategy for, they’re going to be around for a long time, may not be architected in a way because maybe they’ve been around for a long time already, may not be architected in a way that’s suitable for continuous delivery to production. That’s just reality.
As you change the demands you’re putting on the product, you’re going to have to change the architecture of the product in order to support the new demands that you’re putting on it. So investing in the time and effort for the teams to be able to work towards those outcomes. And we’re not talking about delivering any new features because we’re trying to do this. We’re talking about enabling them to do a little piece at a time.
The Azure DevOps team had some architectural changes they needed to make in their test infrastructure in order to reduce their time to market. To completely clear off the old test infrastructure took four years. Right? We’re not talking about a shorter time frame; we’re talking about long-term products that exist in the market. Azure DevOps, the product that is Azure DevOps, was originally released in the market in 2006. We’re now in 2025, so it’s 19 years that product has been in the market, been making them money, been a flagship product within that context.
Visual Studio has been a product for longer. Right? These are long-term products, and they need long-term thinking about investment in architecture, investment in refactoring, investment in automation, and in change. Right? Because your needs, your demands as the business on engineering, the demands of the customer on engineering are going to change over time, and you need to change your product and invest in changing your product to support that.
So that really comes back to this idea of continuous learning and improvement, not just on your plate as leaders but also on the engineering team’s plate. Are you putting your engineers under so much time pressure that their biggest problem is getting stuff out the door, or do they have time to talk about and discuss how what they need to learn, how they need to change the product, the refactors that they have to do? Or when they start talking about those things, is the immediate answer, “No, we don’t have time to do that because we’ve got to ship some features”? That’s a losing proposition, absolutely a losing proposition.
It’s not a short-term losing proposition, but it’s a long-term losing proposition. There is no way to win cutting short-term quality, cutting quality for short-term wins rather than long-term wins. So those things together as leaders, along with, there’s loads of things you could do. You could break down silos in the organisation. So if you have coding hierarchy and test hierarchy, anytime you’ve got a test manager and a dev manager, and then you get team members that are reporting to multiple people because they’ve got the team that they’re on and perhaps a product manager that they’re dealing with, and then they’ve got their dev manager as a line manager, and other people in the team have their test manager as a line manager, that’s a mess.
Right? That’s complicated. That’s people being pulled in different directions. That’s teams having more difficulty, more friction in working together towards a common goal than in not working together towards a common goal. Right? Because there’s more things pulling them in different directions. So breaking down silos and ultimately leading by example. People are going to look to their leaders to see how are we expected to behave within the context of this organisation, and our leaders need to present that example that we can use to build that culture of collaboration and trust within our organisation.
