As Container Solutions grows, so does the number of projects we commit to every year. To keep quality high and continue to serve our clients well, we have learned to streamline the way we deliver our services.
The challenge is to make sure we’re not wasting time and energy reinventing our service delivery, but balance that efficiency with personalisation. What we and our clients need, therefore, is a flexible process: One that achieves a consistent level of service while also making sure our clients’ opinions and specific needs are heard and taken into account.
From that challenge, a customer onboarding process was born. The co-parent of this newborn is Eckoh, a software company based in the U.K. and the U.S. that specialises in payment processing and contact-centre solutions.
Eckoh is a software powerhouse. Its leaders and engineers want to get products, and services, and application features to market and into their clients’ hands faster, and attract new talent. Becoming a Cloud Native company is the vehicle for Eckoh to reach these goals.
Eckoh’s leaders started gathering information. At Cloud Native London, Eckoh’s technical director, Keith Ward, and its chief operating officer, Ed Johnson, met representatives of Container Solutions. Soon enough, our engineers were over at Eckoh’s offices, conducting an assessment of their current status. We kept working with them, running proof-of-concept experiments to help determine the next steps for Eckoh.
We asked Eckoh to send a delegation of people from different departments of the company to our Amsterdam offices: developers, operations, program owners, security leadership, and so on. They sent 15 people, a strong show of their commitment to make their Cloud Native Journey a success.
As we prepared the workshop before the Eckoh visitors’ arrival, we knew four things: It had to be fun. It had to be educational. It had to result in the first steps of building a joint team. And it had to deliver results at the end of day three.
Both Eckoh and Container Solutions wanted to create a process that we could all refer to when delivering our services to clients. This would give us:
Let’s look at the workshop’s three-day program to see how Eckoh and Container Solutions worked toward those goals.
We welcomed Eckoh’s representatives to our offices, and had breakfast together to socialise in an informal setting. As the workshop kicked off, we introduced ourselves to each other. It was amusing to see that, at this stage, people tended to sit with colleagues from their own department.
After this, we gave a short introduction about Cloud Native and what it means to us, and started a discussion about what it means to Eckoh. Participants got the option to write that down on Post-It notes, and we gathered their thoughts for further discussion. The intention is to create alignment and a common vocabulary and understanding of Cloud Native.
Next, we asked Eckoh participants what they wanted to get out of this workshop—their goal and expectations. This is very important, because this onboarding process is about them and not about us. Once everyone agreed on a goal, then we moved on to a social pact.
What‘s a social pact? It’s an on-the-fly document we created in collaboration with the onboarding participants, about behaviour and respect for each other. Rules in the social pact might include things like, ‘We speak the truth to everyone’, ‘We don’t point fingers or blame’, ‘We do not use phones in meetings,’ and so on.
This social pact can be seen as a code of conduct. It is great to see the change of behaviour in a couple of hours because we will point out the social pact when we see things happening that we didn’t agree to. ‘Psychological safety,’ or creating an environment where people can share their ideas freely, without fear of negative consequences, is central to our work at Container Solutions. We think it’s important in problem-solving and innovation, and make sure it’s part of our work with clients too.
Next, Eckoh and our onboarding team created a goal. Goal creation starts with a number of goals that are refined into one goal everyone agrees on. At this workshop, the goal was: ‘We want to increase automated code coverage for quality and deliver 50% faster’.
Once we established our goal, we need to figure out the actors to use for the next step. In this case, our actors were: development, operations, program owner, quality assurance (QA), and leadership.
Why do we need those actors? For impact mapping. Impact mapping is used to determine what impact the different actors want to create and as a result what deliverables are needed to be able to create that impact.
When you observe this process, it becomes clear why this is so important. The business people in the room used different words than the engineers in the room to create their impact definitions—but their deliverables were the same.
During our three-day workshop, all of the events are intensive, and everybody collaborates. This way, we create a common understanding and vocabulary. Eckoh’s participants were fully committed to the process. They slowly took over the event and started to do things on their own.
In between these workshop events, we did a lot of fun activities to re-energize: They ranged from imaging what would happen with this group on a tropical island, to escape rooms, to silent sorting in many orders, to seemingly random high-five lineups and jumping around in a circle. We had shared dinners and drinks every day. We deliberately ate most lunches out of the office moving between work and non-work spaces.
About 40% of the time was deliberately spent focusing on the non-technical goals of the workshop. This was all about having fun and having time to process and talk about the day in an informal setting. All of this was very important to build the comfortable, interpersonal relationships between the Container Solutions and Eckoh engineers. For us, a key factor of success is that we win and lose together.
At the end of day two and beginning of day three, we started something called event storming. The basic idea is to bring together the different domain experts and learn from each other. To make this learning process easier, it is meant to be fun!
We created together with Eckoh a better way to move forward. During event storming, we discussed People and Process. Who is responsible for what? Why aren’t we involved in a certain step? How can we optimise this? Do we need to change our organisation or even our role?
Finally, we discussed Technology. Eckoh and Container Solutions were able to create a dynamic, lean, logical design. This will be used as a starting point and will be updated during the engagement. During the last phase of the workshop, we created first user stories and backlog.
It was a special workshop together with this amazing customer and its people. In three days we discussed culture, mindset, process, and technical solutions—and everything came together.
For me, the most important thing was that Eckoh came in on day one as individuals not knowing what to expect and not fully understanding Cloud Native. I think I can say that they left as one team—even better, I believe we all left the workshop as one team. Relationships were created, and we had a common goal and understanding of how to reach the goal.
We want to thank Eckoh for this amazing experience and their participation. We are set for success.
We also want to thank the amazing team of Cloud Native Engineers, Riccardo Cefala, Charlotte Mach, and Hamish Hutchings. Uncertainty is part of running a workshop, but you showed commitment, responded to every situation, and nailed it.
Arien Mol, Winston Taylor, and Keith Ward co-authored this blog post.
Check out our whitepaper on "The Cloud Native Attitude" below: