Lunar Way’s journey towards true autonomy (Part 1)

Agility in a silo organization

For years enterprise companies have been organized in silos, where specialists with the same skillset are hired into the same department, working side by side to fully utilize their knowledge.

Today, most have realized a silo mindset will result in sub optimization and longer lead times, because the coordination of deliveries between departments becomes a nightmare. Bottlenecks will arise everywhere and people within the organization become demotivated, because each individual’s effort has little impact on the real world end users.

Throughout the last ten years, most of the largest IT organizations in Denmark have been trying to adopt an “agile mindset”.

Instead of being organized around a certain skillset, most are now talking about “feature teams”, and trying as hard as they can to solve the problems by rolling out modern agile processes like Scrum, Kanban, or something in between.

This is a positive tendency. Agile processes are doing a great job of slowly but steadily breaking down the organizational silos into cross functional teams, focused around end user features. The only problem is these feature teams are left with an even harder underlying problem that most companies still try to avoid.

Conway’s Law

Any organization that designs a system (defined more broadly here than just information systems) will inevitably produce a design whose structure is a copy of the organization’s communication structure
— Melvin E. Conway, 1968

In relation to tech, Melvin had the idea that any technical platform architecture over time will become a reflection of how your organization is structured. So if you’re organized in silos, you have a tendency to build a silo. If you have built silos or monolithic systems for decades, the amount of legacy is so enormous that no matter how hard you try to become agile, the gravity of the underlying platform will keep pulling you back to ground zero.

It is hard — or in my opinion impossible — to delegate project governance, service responsibility, and build autonomous feature teams if the underlying systems are still operational, and are being deployed as giant monoliths.

Unfortunately, most of the financial tech ecosystems suffer from this pattern today, because their roots go back to the 1960’s.

Emerging silos out of nowhere

Even though we only have 30+ employees at Lunar Way, and have been around for a mere two years, we have experienced everything mentioned above.

When we started out back in 2015 the backend developers soon gathered their own team, had their own meetings, took their own decisions and managed their own development cycle. The same applied to the app developers. As more business developers joined the organization they felt a natural connection too, and ran their own agenda. Everybody was happy and we were able to go live within six months, with a beautiful monolithic rails backend and two native apps.

It was also the beginning of a period where bottlenecks started to arise. The app developers were always waiting for the backend developers. The backend developers had a hard time making changes to the existing system because everything was so tightly coupled. Handovers from business to tech also became harder, because tech always wanted to challenge everything, and didn’t feel like they were part of product decision making anymore.

It was scary to observe how quickly and easily silos sneaked upon us, and Conway’s law was starting to prove true.

Feature Squads Inspired by Spotify

Luckily, we understood the underlying problem and took action right away. Our CEO had talked about Spotify Squads for a while. The backend developers had some initial ideas about splitting our architecture into smaller services, but they also knew we needed someone with a modern DevOps mindset to fulfill our high level Microservice vision.

We began splitting our organization into “Feature Squads”, each consisting of backend developers, app developers, business developers and marketing people. Each with their own squad leader.

The initial aim was to bring people with different skillsets closer together, and everyone closer to the important product decisions.

We introduced the idea behind squads with Henrik Kniberg’s vision

Instead of overthinking the process, we took action overnight. Our initial idea was for each squad to be accountable as a whole for its output, with features resulting in seven initial features squads:

It’s easy to reflect and say this was not an ideal setup, but nevertheless, this became our first important step towards true autonomy.

To be continued…

comments powered by Disqus