Practicing Evolutionary Management at Trainline: Experiments in Self-Management and Wholeness

For the last year, I’ve led the web team at Trainline on a test and learn journey towards a new way of working called evolutionary management. Building on the foundations of agile, this management paradigm adds a new playbook of practices meant to promote self-management, wholeness, and evolutionary purpose.

Part one of this series describes my journey towards discovering this way of working and the foundations of evolutionary management. Here in part two, I detail what we learned from experiments designed to create breakthroughs in self-management and wholeness – the good, the bad, and the beautiful.

Self-Management Practices

The Advice Process


When our team was still small (<20), we agreed a new decision-making policy called the advice process. The advice process is simple – any person can make any decision after seeking advice from 1) everyone who will be meaningfully affected, and 2) people with expertise in the matter. This means that every decision has a responsible owner accountable to the group, but this person can be anyone within the team – not just those at the top of a pyramid.


Our team agreed to this policy because, as one developer put it, “it makes everyone empowered,” and indeed it seemed to boost engagement. However, we learned it was insufficient to ensure code quality and consistency, as our team members had differing understandings with our tech stack and standards. Particularly as the team grew, we realised that we needed someone in charge – but not an autocratic team lead. We simply had to define more stable decision-making accountabilities, particularly over code quality, without diminishing the power of team members. We found a solution in what I call the three-layer cake of accountabilities.


The Three-Layer Cake of Accountabilities


When the team grew past 25 (and eventually to over 50) people, we broke it down into five squads, each owning a different area of the application. The tech leads along with each squad’s developer in test ensured quality through the stack. To ensure consistency across the stack, we created a parallel guild structure with guild leads, inspired by Spotify’s org structure. However, we went beyond the Spotify template and defined a third set of roles, which we called the Champions of Excellence. The Champion of Excellence role evangelises for a particular aspect of product quality we care about, learning about and educating other team members on subjects like accessibility, performance, and security. While myself and our development manager suggested these roles, the team expanded and filled them voluntarily.


These new accountabilities remain in place, and the team is rolling. Code quality is high thanks to leadership from the squad leads and guild leads, but vesting more power in these roles has not disempowered others because there remain other accountabilities with power. Indeed, the great majority of team members now have meaningful opportunities for leadership and accountability beyond their day to day functional specialties. More importantly, the three-layer cake management structure was agreed and implemented by the team and therefore reflects our best efforts to self-organise around the challenges we face.


Wholeness Practices



We began by starting team ceremonies with a minute of silence as detailed in part one of this series. We then naturally moved to a verbal check-in practice whereby we’d go around the room, each team member sharing how they were feeling at that moment in a few words. This practice took about a minute and rarely finished without a round of knowing laughter. Each said what was really there for them, whether that was being excited for the week or hungover from last night.


Both these practices had the same effect – everyone got present. Laptops shut, eyes came up, and the group became intensely focused on the conversation. Our meetings became not only more efficient but also more enjoyable. We ended up sticking with verbal check ins longer. By speaking a small emotional truth, we were licensed to speak larger truths and get to the heart of the matter. And in doing so, we could simply be ourselves.

Words of Gratitude, Praise, and Acknowledgment


It is traditional in Scrum to have a demo day at the end of the sprint where the team shares their accomplishments. We certainly didn’t skip this. Indeed, we had somewhat decadent weekly wrap-ups with tons of sweets and snacks to celebrate. Adding to that tradition, we set aside time to honour not just works of achievement but also acts of cooperation. After demos were done, I asked the team a question – “Who would like to share words of gratitude, praise, or acknowledgment with your colleagues?” Team members then spontaneously addressed one another.


I always looked forward to asking this question. Team members have acknowledged each other for providing training, for responding quickly to crises, and for simply being there for each other on tough days. It is in these conversations in which the team has created who we are through our expectations for one another – we are generous, we are resilient, we are compassionate. I’ve found the practice remarkably powerful.


Performance Evaluations from Wholeness


Performance evaluations in the Achievement-Orange paradigm can be dispiriting conversations. While intended to be objective and dispassionate, they’re in reality often tinged with fear and anxiety.

I tried something different with one of my direct reports, Janie (not her real name). I gathered Janie and her closest colleagues in a well-lit meeting room, arranging the group in a rough semicircle around her. We began with a minute of silence, during which I asked the group to hold Janie in their hearts. Then, one by one, each of Janie’s colleagues offered her two gifts from a place of love and connection. These two gifts were the answers to the questions, What is the one thing I value most about working with you? and What is one area where I sense you could change or grow? While they spoke, I transcribed the answers on a whiteboard behind Janie, and I gave a photo of these answers to her after everyone had spoken. I then followed up with Janie to discuss what she discovered about herself and how she sensed she wanted to grow next.


There was an incredible love and generosity in the room throughout this process. Were it not for British norms against expressing emotion in the workplace, I felt there might have been tears. The results were not only moving but also useful. Valued traits were deep acknowledgments of strengths, some of which Janie had not fully appreciated, while suggestions for growth got right to the root her challenges. Those who participated from different teams requested that they receive such an evaluation, saying how it wasn’t fair that their teams didn’t do the same.


Handovers from Wholeness


I adapted the above format to bring wholeness to handing over my role as product owner for the web team. After 15 months of product leadership, I chose to hand over this role and pick up a new one as product owner for the data science team. I wanted to set up my successor for success, but I also wanted to acknowledge and celebrate what I brought to the team so that I could fully let go. When it came time to hand over accountability to my successor (who was Janie, in fact) for the mobile web squad, I gathered the group together in a semicircle around the two of us. After a minute of silence, each team member shared the answers to the questions, What is the one thing I valued most about working with you, Ian? and What is one wish I have for Janie for the future?


The team showed up as generous and authentic, sharing moving words for both of us about what they loved and what they hoped for. I felt complete and ready to move on, while Janie said she felt a new relationship with the team starting to grow. I look forward to trying this again for my next role transition.

In part three (coming soon), discover what we learned from experimenting with practices designed to evoke evolutionary purpose, including what I consider the most powerful evolutionary management practice.

About the author

Ian is a senior product owner at Trainline passionate about building great products, teams, and organisations. Born and raised in the San Francisco Bay Area, he has been working and learning proper English in London for the past six years. Ian has an MSc in Decision Sciences from the London School of Economics and a BA in Cognitive Science from Yale University.

<< Part 1: Practicing Evolutionary Management at Trainline: The Journey to Evolutionary-Teal and Beyond…

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s