In 2016 a change started in our company. We wanted to transform ourselves into a flatter organisation. Since we are an e-commerce company, the best place to start was with the department running our site. In the years before, the focus had been on technology, rather than the product. This has resulted in a fantastic platform, but the new website we wanted to replace the monolith was still not live.
We realised that development of our product should go hand in hand with the technology changes we wanted and reorganised. This was not an easy process (perhaps I’ll talk about that later) but it resulted in product (scrum) teams with a product owner working together with the engineers to deliver user value and at the same time transform the monolith into several services and sites. We called this the Pac-Man strategy. Eat parts of the monolith and replace them with new technology.
The combined power of product owners (representing the customer) and tech-loving engineers resulted in powerful teams. They delivered customer value in every sprint and at the same time replaced our monolith by microservices and -sites. This gave us a new challenge, however. How to make sure those self-supporting teams stayed on the same course? We wanted to give the teams some ways to align. This resulted in lightning talks, tech talks and pathfinding. These are all about sharing knowledge and getting teams aligned.
Lightning talks are mostly about technology. Subjects vary from things we learn on the job (like replacing Cassandra by DynamoDB for Akka persistence), WTF experiences (there is always a learning) to what we can do with analytics (a 101 for engineers). Tech talks are meant for teams to share what they have done. They are a great way to share experiences with technologies and how they are used.
Pathfinding is a bit different. When we started with the transformation, we did not know what needed to be done to convert our monolith into a microservices platform. We needed a way to find answers and challenge solutions and it helped us greatly. Not only then, but even now. Although we have really smart and resourceful people working at Wehkamp, it is always good to challenge ideas. This usually results in better solutions that are supported by many people.
Another great thing about pathfinding is aligning cross-team changes, like preparing ourselves for the GDPR. This requires work in many teams and as most of us are engineers, we are functionally lazy. We needed a solution that we could all benefit from, with as little work as possible. Discussing the options with people from several teams helped us to find a solution that works best for all.
The best thing about pathfinding, in my opinion, is that it brings people together. This means front-end engineers, Java, Scala and .NET developers and platform engineers are trying to find the best solutions together. Information is shared, ideas are challenged and knowledge gaps are filled. This helps us to find the best answer for any problem we face and get better at what we do.
So, what does it take to have a good pathfinding session? Most importantly, we needed to make it an open space. Safe for everyone to enter and give their input. We try to keep the spirit positive (can-do mentality) and allow individuals to leave, whenever they want (law of two feet). We do not limit a technology-specific problem only to people working with that technology. We believe that anyone who is there can contribute to finding the best solution.
We have a room and time slot reserved every week. We have facilities for people who are not in the office to join the sessions we have an open agenda and a slack channel to discuss topics and share the results. If there are no paths to find: that is okay as well, but the last year has taught us that there is enough to discuss.
Pathfinding has become part of our way of working and we believe it will help our teams (now and in the future) to stay aligned and our people to grow.