“You don’t need to fire people and hire new people: you need to create an environment where people can learn” – Jez Humble

How would you describe your typical working week? This was mine: taking a deep breath outside the main entrance Monday morning – “Attack!” and then tumbling out  Friday evening.

But after almost two years, my colleague and partner in enterprise battle and I agreed, we could be proud of what we had accomplished.

Joining this enterprise, I was somewhat enlightened about the urgent, critical, messy situation, but reading the all-lean leadership values I felt confident I could drive my way and make a difference. I also have some work companions* that, like me, tend to be attracted to these dysfunctional setups. I mean… it can’t get worse anyway, can it?

We had now completed a very long list of improvements. Some were easily fixed and some took extensive, exhausting fighting. And then there were the true battles, the over-my-dead-body-argumentation – and somehow, we had won them as well! Here they are:

1. Budget structure: the way investments are distributed in the enterprise
2. Contracts with main partners: the way a successful collaboration is defined and measured
3. Culture: the environment we create for people

Where we were

A very challenging financial period made the enterprise outsource everything that could be outsourced some years back. For IT this meant around 90% of people were let go and replaced by a few main partners. What was left was mainly an order management function. This in turn resulted in a classic setup for IT divided into:

1. Application Operations, AO: daily operations of infrastructure and applications
2. Application Maintenance, AM: reactive defect fixing, software upgrades
3. Projects and Change Requests: “new requirements” and anything not covered by number one and two

The first two were included in the IT domain operational budget while the third was covered by the investment budget. This naturally comes from the financial separation between OPEX (the cost to support regular business) and CAPEX (the cost to create future benefit). Mixing these, like we want to do with teams, puzzles the finance controllers – so make them your best friends!

We had all of the anti-patterns: large project teams with 100% contractors handing over to the AM and AO teams and then walking out through the door. Quality not built-in but rather added at the end. Architecture controlled on an enterprise level but not practiced on an application level. Deploys orchestrated at night-time with roll-back criteria and a plan. IT Operations guarding operations environments with change control boards and complex processes. SLA-s with scary penalty statements.

On top of that, we had an offshore setup where development and AM/AO were geographically separated, limiting the collaboration and feedback loops significantly.

Battle #1: Team Contract

First, we defined product teams with a mixed onsite and offshore setup. Team members rotate geographically, so over time the proportion of team members having worked onsite increases, strengthening business knowledge and collaboration. Every other month a team from Stockholm also travels to and works with teams in Chennai, further closing the gap. A diverse and learning environment is a good and developing place to be in, and thanks to our Indian partner, we have 30% female engineers!

Then we terminated all AM contracts, clarifying that the team also owns the 24/7 support of its product. This was done of course in agreement with the teams.

Finally, we redefined the AO contract to mainly cover general infrastructure (cloud, network, backups, security) while moving responsibility for product development environments and deployment to teams.

Results from Battle #1

So much daily frustration was more or less instantly erased. Teams were eager to pick-up deployments and manage their own product.  In parallel, quality started to improve.

Here I also want to draw the obvious connection to the elements described by Daniel Pink in Drive about what motivates people: autonomy, mastery and purpose. Clarifying a general product ownership while removing underlying obstacles and providing necessary support and mandate meets these elements.

Very rapidly this helped us to move toward, maybe not yet continuous delivery, but a surprisingly frequent delivery.

Battle #2: Culture

During my first visit to teams in India, it was all about executive briefing, project deliveries, excuses about poor quality and increasing people turnover.

Since then, we have let go basically all managers and overhead roles while given developers the right mandate and responsibility. We have focused on how we do things instead of what we do. We have prioritised deployment frequency, technical debt, customer value and automation over deadlines, project deliveries and cost. We have worked on creating an engineering culture with software craftsmanship, learning and sharing in focus.

Harini**, an amazing developer in the on-board-services team said proudly: “My team will have zero code smells!”

Battle #3: Shifting the Investment Budget

So, when it was time to start the yearly budget processes, the winds were blowing in our direction: overall cost had decreased while team performance and product quality had significantly increased. Let’s have more of this!

Me: “Why don’t we move the investment budget to the teams?”

Enterprise: “What will they work on? How do we know the results?”

Me: “Well, they need to define their product vision together with their stake holders, set goals and agree on KPI’s to measure how we are doing. We will learn – continuously!”

Tomorrow is the first day of our new financial year. We have been given a large trust and mandate. So now, we will just roll up our sleeves, continue to deliver and be prepared for the next battle!

*Thank you Daniel Cala, Anders Ågren and David Fuchslin for joining one more frustrating, bumpy, crazy journey with me. 

**Harini now works onsite in Stockholm and continues to be a female kick-ass developer. I’m working on giving her the equipment she deserves and hope her employer understands to appreciate her as much as we do.