From Process to Principles
TL;DR: We identified significant challenges in our product discovery and delivery. We created a ways of working framework from the ground up, and iterated it over 18 months. What proved valuable was not the process and artefacts we focussed on initially, but the underlying principles and the ongoing conversation and collaboration. To make it stick, we 1) made principles the heart of our framework, 2) provided accessible, practical and relevant information, 3) formed a culture of collaborative creation
You may recognise this situation:
You identify a problem. You have a great idea to solve it. You put a lot of effort in bringing it to life. It solves your problems. Then you start to tinker and change and tinker a little more. You tinker a little more, and it becomes clunky to the point you can’t develop it further. But the amount of knowledge you gained while living with it, tinkering with it, and struggling with it is invaluable.
So you flip it on its head and create something that encapsulates all of your learnings. You put a lot of effort in bringing it to life. It solves your problems. Then you start to tinker…
We identified a problem
When we started to look at our product development challenges and talked about how to tackle them, we conducted user research with people to understand what currently happens between an idea and it being in the hands of customers. What we learned was that our problems are what most growing organisations struggle with
- No clear priorities and success metrics
- Little focus on the users and their needs
- Siloed design and delivery of initiatives
We had a great idea to solve it
As an outcome of the research, a great idea started to form. We would introduce a common language across product discovery and delivery and build a toolkit that teams can use to tackle their product discover and delivery challenges.
The result was a framework we lovingly called RuDDEr — for Research, Design, Delivery, Evaluate. It was designed to address the problems at hand. And it did. It introduced new language into the organisation, shifted the focus from more towards discovery work. It introduced new tools and artefacts into the product teams. And, most importantly, it fostered conversation about all the good that is already happening at SiteMinder.
We put a lot of effort in bringing it to life
Every week, we would have a new version of the framework, get candid feedback, and get teams to share how they practically applied it, evolved it and what they learned. We
- Delivered half day training sessions on Research, Design, Inception
- Created How-To guides (How to do research, How to run a design sprint)
- Sketched templates, tools and artefacts teams could use to help them navigate the complexity of discovery and delivery
- Introduced and a few design sprints
- Established a forum to showcase and provide feedback on ways of working
- We embedded ways of working into the employee onboarding journey
Our RuDDEr had undeniable flaws, of course. It felt very process heavy. The way it was laid out was very left to right, waterfall-y. All good intentions and assurances of its flexibility aside, that’s what stuck with people. The documentation was one big dump under each stage (“This is everything you need to know about research, everyone!”). It was difficult to evolve, add information, or allow people to find information themselves.
Then, we started to tinker
In a quest to provide direct value to our teams we focussed our efforts on making RuDDEr more accessible, relevant and practical.
- Transparency. We created a physical wall with all initiatives across all product teams, and established portfolio scrum of scrums designed to escalate, solve and track blockers and bottlenecks.
- Focus. We started conversations about outcome based roadmaps and OKRs, as well as organisation-wide priorities. We also worked with teams to limit their work in progress.
- Collaboration. We brought people from outside of product & engineering closer to our teams, such as Marketing, Sales, Customer Support, Success and Onboarding teams.
- Capability. We embedded coaches into some teams and gave them freedom to help the team tackle their problems at hand, with the help of the underlying framework.
It worked. We could see teams flourish, embedding and evolving new ways of working and making them work for their teams. Planning, dependency management and collaboration improved. The level of conversation, autonomy and care for people shifted significantly.
And yet, we hadn’t solved the initial problems. The framework still felt process heavy and waterfall-y, with a lot of high level information and templates, but little change in documentation for 18 months. People wanted to be involved more, but the structure didn’t lend itself to it. The Ways of Working Guild that had formed initially had petered off.
Now, we flipped it on its head
We revisited all our learnings over the past 18 months, how teams had involved and how they actually used the guidance, plays, and templates that form part of RuDDEr. And we realised that it wasn’t a process. What people took to heart was the underlying, unspoken principles that formed our ways of working.
As we went about to summarise them, they turned out to be 14 principles that people valued. Some of these principles are
- Understand User Needs and their Context
- Continuous Delivery
- Pragmatic Processes and Practices
- Measure What Matters
- Create Space for Learning and Mastery
Bringing it to life once more
The key to unlocking the value of those principles is Distributed Ownership. Finding people in the organisations that are passionate about these areas and willing to evolve them.
- Distributed Leadership. Every principle has 2–3 leads, people who are passionate about the topic and interested in seeing it evolve. These leads are from different crafts — so “Understand User Needs and their Context” is led by people from Design, Product, and Marketing.
- Practical Application. We are starting to run quarterly retros for every team across those 14 principles, similar to the Spotify or Atlassian Health Monitors, but based around our ways of working principles.
- Self-service. All our documentation, plays, templates, examples are structured around those principles. So as teams become curious about improving a certain area of their ways of working, they have a starting point that is constantly evolving, filled with contributions and examples from teams playing well already in this area.
- Continuous collaboration. Our Ways of Working Guild, consisting of the leads for each principle, will have the opportunity to share and evolve what “Ways of Working” means for SiteMinder.
These changes are recent, but incredibly exciting. We have a long way to go, but are on the right trajectory.
