Every year Klarna hosts the Expo, an event where over a thousand employees gather in one place to share what they have been working on and what’s next — similar to a science fair. Together with The Expo there is a learning lab where employees can give talks to share their experiences. A colleague (Kenneth Gibson) and I decided to share an interesting technique that we created, called Architecture Golf, that improved knowledge sharing within our teams. Since then, we’ve received so much positive feedback from many teams within Klarna that we decided to take it public.
Press enter or click to view image in full size
Before we dive into what the technique is and how it works, let’s see what problems we had that lead us to create this technique.
At Klarna, we used to work in a domain called the “Consumer App Experience” which started around two years ago with a small group of people and has since grown into a massive domain (a domain is a group of teams working on the same problem space, in our case, the Klarna app experience). Following the principle of Start Small and Learn Fast, many teams were created to explore different problems. Some teams lived on and continued as independent teams and others were merged together.
My team was in the early stages when I joined. The people in the team were mainly front-end developers and they were finishing the last round of prototypes and tests. After a few weeks, the team was ready to build the real thing, so we naturally split into two groups: one group putting the production infrastructure in place, writing the services and so on; and the other group was shaping the user experience, adding new features to our app.
After a while, we achieved the goals we set out to. All the nuts and bolts were in place but we found ourselves in a difficult situation. We had two knowledge silos in the team and we were about to release our features. This was scary since more than half of the team didn’t have the knowledge of the other half.
Trying to solve this issue I put together an exercise that could help with our situation. We had a couple of sessions and it looked promising. I shared the experience with my colleague, who promptly adopted the technique and from that point forward we started bouncing ideas around and shaping what we now call Architecture Golf.
My colleague had a similar issue. After running for about a year, two other teams were merged into his team. We’re not talking about 20 people on the same team. They were around eight. They couldn’t afford to operate as three independent teams — they needed to become a single team.
Press enter or click to view image in full size
After many months and many attempts, they still remained as three individual teams working in three separate directions. Everyone was a specialist within their own problem space but a complete stranger to the others. They found it extremely challenging to share knowledge amongst all the team members. It’s quite a lot to ask for everyone in the team to sit down and pour through pages and pages of documentation and learn about the other two problem spaces. It’s even more difficult when a new person joined the team and they had to learn about three problem spaces!
So why is it so important to share knowledge?
Have you ever felt trapped, attending five meetings per day to say the same things over and over? Do you feel that you aren’t able to delegate tasks or meetings to the other team members because they don’t have the knowledge or context required?
Are you the team member that is always the one answering questions?
Do you spend a crazy amount of your day being interrupted when people want to ask you something? Or maybe are you always having to point at someone else when someone comes to ask you a question?
Press enter or click to view image in full size
If your team has problems with knowledge sharing then these are the sorts of problems you can run into. For example, many teams here at Klarna have “on-call rotations”. This means that someone is available 24/7 in case something goes wrong. This works great if you can share this responsibility with your team members so that you don’t need to be on call your entire life. But now imagine that you’re the only person in your team that knows about something — you can’t ever take a vacation or even get sick. You’ll be on call 24/7, 365 days a year.
What is Architecture Golf?
We use this exercise to help share knowledge of our architecture, onboard new team members, and even revisit previous decisions. Let’s see how it works.
Step one: gather your team.
Step two: get a whiteboard and a single whiteboard pen (you can have more colors if you like).
Step three: state a process or practice that you want to learn about as a team. For example: “How do we onboard a new team member?”.
Step four: pick a person to start “randomly” — this person draws the first stage in the process.
Step five: give the pen to the next person. This person then has to draw the next stage of the process. But wait! What if this person has no idea what the next stage looks like? That’s OK! In fact, that’s expected. This person should then take a guess and draw what they think the next stage is. It’s OK if they’re wrong. At this stage, the group validates whether what’s been drawn is correct or not. If it’s not, the next person in line can correct them. If this person can’t then it keeps going down the line until someone can. The person with the pen then updates the diagram. It’s up to the team to make sure that this person understands well enough in order to update the diagram correctly. It’s important that it’s not just one person always immediately answering or correcting the team.
Step six: are you done? If not: go back to step five. If you’re done: then the team can have a discussion about the reasoning and context behind the current process or solution. It may become clear at this point that some things should change or could be improved. Here you can write down some action points. We usually reserve one hour for the exercise and have follow-up sessions if we need. It is better to have more sessions than long ones. The exercise gets faster as the team gets used to it and becomes familiar with the subject.
Get Túlio Ornelas’s stories in your inbox
Join Medium for free to get updates from this writer.
We call this exercise Architecture golf because it helped us explain the crazy architecture that we sometimes have. Each team member takes one swing at a time which pushes them closer to the solution, just like a team version of golf. Although we dubbed the technique architecture golf, the exercise can equally as successfully be applied to share any knowledge.
Each team member takes one swing at a time which pushes them closer to the solution, just like a team version of golf
Teaching someone is a great way to cement the knowledge in your head. You very quickly find any gaps in your own knowledge when you have to teach someone. Sometimes you may even find that team members have different understandings about something. Teaching someone can be a scary situation, but in a safe environment that is a small group of fellow team members, it can give you the confidence you need to take the first steps. Using architecture golf, every member of your team has the opportunity to teach other team members.
The exercise can come in many different forms but must follow what we call the Architecture Golf manifesto. The manifesto contains four simple but crucial rules. Let’s take a look:
The exercise should be done in a small group, let’s say up to 8 persons
All team members should feel comfortable and trust that there will be no judgments for getting things wrong.
The team is exploring and learning a process together
There is no single person driving or doing all the talking while the others all watch and listen
All team members get an equal chance to contribute
The only person drawing on the whiteboard is the person whose turn it is
It’s very easy to just jump in and draw on the board when it’s not your turn. Having only a single whiteboard pen can help prevent this. The person with the pen needs to sufficiently understand the stage in order to visualize it on the whiteboard.
Over time we have applied this technique to solve different problems, and realized that the core concept of learning through practice can help in almost any situation. For example: how your team handles support issues, what an interview process looks like, or even when designing your next architecture.
Architecture golf doesn’t have to focus on sharing existing knowledge. It can also be used to improve existing processes or even design new ones. The same manifesto and steps apply.
Let’s say we want to design a new process and share this knowledge with the team. Why would you use this exercise when designing something new?
Leverage teams strengths
Every team member has different strengths and weaknesses — leveraging this at the beginning of a process is the best way to allow your team members to show their strengths
Reduce “solution bias”
Press enter or click to view image in full size
It’s often hard to think of your own ideas or solutions if you’ve already been influenced by someone else’s
Knowledge sharing from the get-go
No need to spend time sharing knowledge with the whole team after something has been designed — the team gets the knowledge from the start
Saves time
Less back and forth — explaining to the team, getting feedback, redesigning, etc.
How do we do it?
Step 1: Gather the team.
Step 2: Explain what it is we want to design — without providing a solution but explaining the problem. If there are more than four of you then it’s best to split up into smaller groups, usually four people per group are optimal. Each team should create a solution for the problem following the next steps
Step 3: The first person draws how they would imagine the first stage to look like. The team asks questions and the person explains. The team agrees on the approach or disagrees. The person with the pen needs to update the board based on the discussion.
Step 4: The team takes it, in turn, to draw one stage at a time until they have a finished solution.
Once each group arrives at a solution they should get together and exchange notes, discussing the strengths and weaknesses of each solution. From now on is up to the team to do whatever they want with the outcome — usually a merge of the solutions. The difference from your standard approach is that everybody is aware of the problem, they had the time to think about the implications and provide a solution.
Now, even if not all team members continue to work on the solution, everybody will feel ownership and appreciate that their ideas were listened to and their thoughts considered.
Since we started experimenting with architecture golf we have successfully applied it to a variety of different problem spaces. Now there are even more teams at Klarna using this approach to share knowledge within their teams.
Press enter or click to view image in full size
The feedback we have received so far has been really positive. Our team members find that being involved and being encouraged to think through a problem has helped them to learn things much faster. They prefer this approach over long meetings, and they found themselves more engaged. We even have our team members asking us: “when’s the next architecture golf session?!”.
How are you sharing knowledge within your teams?