BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage Articles Culture is the True North - Scaling at Jimdo

Culture is the True North - Scaling at Jimdo

Bookmarks

It's always a scaling problem!

Perhaps this claim is an oversimplification, but a lot of the pain that large and medium-sized organizations are facing boils down to scaling. It is not difficult to have 5-10 people working together in one room. Everyone knows what is going on and what needs to be done. Communication is simple and decisions are made quickly. However, as your business becomes more successful and your hiring increases, you will start to see problems.

The old way of doing things may still work as your grow to 20 or 30 people, but at some point you will need to incorporate some sort of structure to help coordinate your efforts. Most companies begin to install several layers of middle management, new functional departments, and more rigid planning. All of this has value but often comes with a price. Suddenly your team seems to have less fun at work. Creativity and innovation become hindered and inefficient. Sooner or later you begin to ask yourself where all the problems came from and longing for the old times when everything was simple.

At Jimdo—a company offering an easy-to-use website building solution in 12 different languages—we find ourselves facing all of the challenges surrounding rapid growth. Over the course of five years our team has increased from 30 to 180 members. We all began to notice the problems, but we felt we needed to take a different approach to the scaling issue. The consequences of the standard reaction would not work for us. Culture is too important to Jimdo (see blog post on Jimdo culture). Anyone familiar with our company would understand that a traditional hierarchical organizational structure would not fit.

There is a second reason that Jimdo can not take the typical approach to combating scaling problems. We simply cannot afford any sort of long-term inefficiency. This might sound like a truism (nobody likes inefficiency!), but it is actually a real problem for us. To understand this better, we need to take a quick look at the company history.

Jimdo is a bootstrapped company and we have grown entirely from our revenue. We have accepted very little funding (500k) and are not burning any VC money. Two years ago, the founders even turned down an 8-figure offer. They made the explicit decision to keep full control of the company and that they are not going for an IPO (initial public offering). Those familiar with the startup community know that this is not only extraordinary, it’s also very challenging because the competitors won’t do the same thing! Basically this means that our main competitors have access to significantly more money than we do and can overspend us at any time.

Returning to the scaling problem, due to these financial constraints, we simply cannot invest in inefficient organizational structures. We can’t just throw more money towards additional hires or massive amounts online marketing. In order to stay on top with our product we needed to come up with a different solution that fit our particular set of circumstances.

At Jimdo, our approach to scaling relies on three major factors: culture, communication, and kaizen. Let’s discuss them in reverse order.

Kaizen

The literal translation of kaizen is “continuous improvement.“ It was popularized by Toyota and is most well-known from lean production practices. However, over the past few years kaizen has become a bit of a buzz word in our industry, expanding far beyond the agile community.

There are several ways that kaizen can be implemented – ranging from simple employee suggestion systems to systems designed to trickle goals down from management to departments to individual teams. For Jimdo, kaizen is not a one-time thing. It is not something that people work on only when they have a little spare time, nor is it something only used by one particular team. We consider kaizen a necessity for the entire company and are striving to embed kaizen thinking deeper and deeper into our company DNA.

To fully integrate kaizen into our workflow, Jimdo uses the Kanban Method developed by David Anderson1 as a guideline. Kanban suggests six core practices:

  • Visualization
  • WiP limitation (WiP = Work in Progress)
  • Flow management
  • Explicit policies
  • Feedback loops
  • Improvement through collaborative experimentation

Here are some examples of how Kanban looks at Jimdo.

As you walk throughout our office, you will notice about 30-40 whiteboards mounted on the walls. Some of the boards represent classic Card Walls (“Kanban Boards”), while others show data and graphs. Some look like checklists or timelines. The purpose of each board is to provide the right information to the right people at the right time.

This kind of visual management enables self-organization and good decision-making by those who are affected by various decisions. When a new team or temporary task force forms (which happens quite often), the first thing they will do is to set up a board. This allows them to organize their work and have the right discussions based on what is displayed on the board.

(Click on the image to enlarge it)

Visual Management can be found everywhere at Jimdo, not only at the development teams. This picture shows the boards of the internal coaching team (A-Team) and the board the chef uses for organizing the meal orders.

The second thing new teams will do is establish a daily standup meeting. Standups are short, focused team meetings that take place on a regular cadence (usually every day). The purpose of these meetings is to update each other on progress and problems and to organize collaboration in order to finish the most important tasks (for more information on standup meetings see this article). These standups are part of the regular routine of Jimdo employees and act as an initial feedback loop.

We use retrospectives as a second feedback loop. Retrospectives are workshops which serve the purpose to improve the way a team or larger groups is working (see this free ebook on Valuable Agile Retrospectives). At Jimdo, most teams do retrospectives on a regular schedule of  2 or 4 weeks. Each of these sessions is moderated by an external moderator from a different team. This creates interesting problem as we have about 150-200 retrospectives happening each year.

In order to find people to lead all of the retrospectives, we trained and coached team members with different backgrounds, like development, operations, design, support etc., to become good moderators. The trainings are quite thorough and include teaching moderation skills and retrospective skills, co-moderation with an experienced moderator, and supervision.

We also created a Community of Practice for Kaizen. This is a regularly meeting group where moderators can share knowledge and experience. This group is not only open to existing moderators, anyone who is interested may also attend.

We currently have a pool of 21 moderators from which our 20+ teams can draw when they are ready to do a retrospective. The country teams, online marketing, support, the SEO team, they all do retrospectives. We are not only talking about development teams here. Even the chef and his staff had their first retrospective recently - one outcome being the ability to visualize batch sizes of the served meals in order to improve predictability.

Interestingly, retrospectives are deeply supported by our three founders. If a team asks one of them to take part in their retrospective they will try to make it happen. Why would the team ask a founder to participate? The retrospectives belong to the teams. In some cases, however, it is valuable to have a founder taking part, eg when it comes to issues that involve several teams or require bigger system changes.

In especially stressful times, it is often one of the founders who reminds a team to do a retrospective; although it is important to note that the founders never control the outcomes.

The typical actions from our retrospectives vary quite a bit. We’ve seen teams begin offering “internships” for members of different teams in order to improve mutual understanding. Other teams decide to try a new framework or even to dissolve their own team. In most cases, we tend to try smaller experiments instead of making larger changes that are more difficult to reverse.

A good example of this is when one of our developer teams discussed introducing pair programming. There were several lengthy discussions about the pros and cons which resulted in an agreement to conduct an experiment. Two of the developers paired on one feature and then reported their experiences to the rest of the team. The overall reaction was very positive, and based on that experiment, others became curious and started pairing as well. Today pair programming is an essential part of that team and they have become a champion for the practice and a valuable resource for the rest of the company.

The Prime Directive serves as a ground rule for both, retrospectives and collaboration in general at Jimdo. For more details on the Prime Directive see2.

A final note about how we use retrospectives at Jimdo is that we do not limit them to the team level. After we organized our first conference for Jimdo users last year, the conference team did a retrospective before rejoining their original teams. We also did this after the launch of our iOS app. The project was a huge, company-wide effort and the following retrospective included representatives of all 20+ teams as well as the three founders themselves.

It is almost impossible to talk about kaizen without talking about slack time. Slack time means having the freedom to work on improvements. For example, in many organizations it’s not uncommon to agree on set of action items that will improve the team without getting any of them done. One reason for this pattern is that people do not have any slack time beyond their retrospectives. All of their time is devoted to working on their regular work tasks.

So how do we make sure we have enough slack time to work on improvements at Jimdo?

First, Fridays are different from the rest of the week. They start with a company-wide breakfast and include presentations and other forms of education in the afternoon. This does not mean that no one does any “regular” work during the day, but we have found that it is much easier to drop out of the context of your regular team at the end of the week.

A second technique we use to increase slack is to have “hackathons” every few months. During these events, small teams are formed in order to work on something new for one week. The topics are very diverse and agreed upon in advance from popular vote. A Hackathon is not a fancy name to kick off yet another project. The purpose is to have time to work outside your regular context, i.e on uncommon topics, together with people from outside your regular team.

Ultimately, it all comes down to a question of culture. Does the organization value improvement efforts or not? In most cases it's up to each individual team to self-organize and come up with a plan to get improvement work done. There is no manager they need to ask for permission.

Communication

According to Systems Thinkers like Russell Ackoff, “the performance of a System is not the sum of the performance of its parts taken separately, but the product of their interactions.”3 This has a lot of implications on the design and development of an organization. Yes, you need good people with great skills and experiences, but that's not sufficient for a good overall performance at the organizational level.

Imagine a football team comprised of the world's best individual players. Would that be the world's best football team? Probably not! The players need to be able to communicate and interact with each other effectively in order to succeed. The same is true for any organization. The interaction between individuals and their teammates is key. At a higher level, the interaction between the different teams is also extremely important for the organization to be successful.

How does Jimdo maintain and improve these kinds of interactions? At the the team level the standups and retrospectives pretty much do the trick. We augment these practices with access to team coaches who can assist with things like moderation, conflict management, and other areas where an outside perspective can be helpful.

In regards to our inter-team communication we are using several different formats. Some of them are quite common in the Agile world, while others seem to be unique to Jimdo.

Communities of Practice

As Jimdo grew, our teams became much more cross-functional. The members of the teams no longer always shared the same skill sets. This created a new problem where we had to find a way to coordinate all the subject matter experts who were now located across different teams. For example, all of the designers need to maintain a common understanding of the design standards of the company while also staying up-to-date with current trends and tools.

Communities of practice (CoP's), a popular staple of the agile world, serve this purpose at Jimdo. The different CoP's meet on a regular schedule, normally every other week, for 2-3 hours. During this time, the members exchange knowledge, set and re-arrange standards, and solve actual problems.

There is a growing number of CoP's at Jimdo, including PHP, Infrastructure, and even Whisky Tasting. We also utilize another format which has some similarities to CoP's. We have dubbed these new groups “Matrix Teams.” And, yes, it's a reference to both a matrix organization and the popular film! But that discussion will have to wait as the creation of the Matrix teams is an entire story in itself.

Teamverløtung

Monday afternoon is Teamverløtung time. This means everyone in the Hamburg office—around 130 employees at any given time—gathers for the weekly roundup. The meeting begins with the founders presenting the current numbers (e.g. new signups and sales) and then announcing any new hires. The new colleagues introduce themselves and everyone is given a round of applause.

Next, any important news will be announced before four teams present updates from their area. The teams share where they are making progress, what problems they are facing, and where they need help from other teams. There is a round-robin mechanism in place so that every team only has to present every four weeks.

Finally the Feel Good Manager usually has a couple of announcements regarding thing like company events and also holds the weekly lottery for who should drink tea with whom. “Tea Time” was created to allow colleagues, who may not know each other very well, to sit together over a hot beverage and chitchat.

After 20-30 minutes the Teamverløtung comes to an end, and everybody at Jimdo should be up-to-date. The meeting is videotaped so that the teams in San Francisco and Tokyo are able to stay in the loop as well.

The Teamverløtung structure has changed quite a few times over the years, but the idea behind this casual meetup remains the same. If possible, all employees should always be up-to-date and on the same page. Ideally this should be done through face-to-face communication, with as little as possible in the form of written documents.

We’ve also observed an additional benefit of these gatherings. Following the official ending of the Teamverløtung, small groups will remain to discuss certain topics and coordinate their efforts. This proves to be extremely valuable, especially for teams who are located on different floors and don't see each other that often. Gathering 130 people for 30 minutes is obviously quite expensive, but we are very confident that it would be even more expensive to not do this meeting.

Open Prioritization Meetings

Open Prioritization Meetings (or OPM's as most people call them at Jimdo) are another format that we use to improve the inter-team communication. Different teams like the shop team, the payment team, or the office admin team offer OPMs on a two-week cycle. Any colleague is invited to come by and bring a request for the team, a feature request, or an improvement idea.

The different stakeholders begin by pitching their requests by explaining why they think that their particular ticket has a high business value for the company and should be done next. The team, usually along with one of the founders, will then decide which tickets they will accept for the next two weeks and which ones they will reject.

One important principle behind this meeting is: “Never make promises you can’t keep!” This requires each team to understand exactly what their capabilities are. How many new tickets can they manage? How big can these tickets be?

The tickets that are not accepted are returned to the stakeholders immediately. Sometimes people are told: “Please come back with this request in 8 weeks.” And sometimes it is decided that a request won't be done at all. Of course it is frustrating for the person whose ticket is rejected. However it is much better to have this initial letdown than to live with false hope that would lead to greater disappointment down the road.

The OPMs ensure that there is never a huge backlog of stakeholder requests. In our experience, this is the best kind of expectation management! And, by the way, the OPM usually only takes 20-30 minutes. We started this format with one team and it quickly lead to other teams doing the same thing (often without being asked to do so).

We’re seeing a couple of positive effects:

  • The team’s workload capacity is more visible. Now it’s easier to avoid overloading the team.
  • Queues lead to stress. (“Look at all the work we have to finish! We can never do this!”) By abolishing some queues (many requests are not stored but rejected immediately), the stress level decreased.
  • During the meetings, the stakeholders communicate directly as opposed to the ticket system before. This prevents misunderstandings and builds trust.
  • The different teams have valuable discussions about what their most important request is, because they know that only one or two items will be accepted.
  • Everyone who is present at the meeting learns the reasons why certain things are worked on and others aren't. The founders are forced to lay out the company strategy on a regular basis. (“Your idea is good. But this year we want to focus on another target group. The reasons for this are X, Y and Z. So we won't do your thing this year.”) In this case, OPM's are a means of improving the company strategy and educating the employees about it.
  • The meetings result in an incredible amount of knowledge and experience from different disciplines gathered in this one room. This makes it possible to find simple and creative solutions immediately.

Goal#1 Meetings

One of the biggest challenges when scaling an organization is to maintain, or regain, alignment. As an organization grows and is broken into teams, or departments, these groups tend to build a strong focus on their group goals. This is exactly what we want them to do!  However, at the same time we know that Jimdo can only build the world's best website builder when all the teams move in the same direction. Although we know that the entire company cannot work as one big team the whole time, we want to align the different teams as often as possible to achieve outstanding things.

The format we've come up with to align our focus is called Goal #1. The concept is heavily influenced by the work of Stephen Bungay4. The idea is pretty simple: the founders need to answer what Bungay calls the “Spice Girls Question” - “Tell me what you want. What you really, really want!” What's the one thing that's most important for the whole company right now?

There can only be one most important goal, everything else (especially local team goals) needs to be subordinated. Until now every Goal #1 had one team at its core and the entire company understood that the team must never be blocked. The team should receive immediate infrastructure support, translations, or technical assistance. If any team needs to prioritize their service for other teams, the Goal #1 team moves to the top of the list.

The launch of our iOS App was our first G#1. It may sound like a regular project, but for Jimdo it was a major change and a big challenge, because it meant moving from a pure browser-based web service to becoming a cross-platform company. In the course of events, (almost) the whole company was involved. Different teams like product development, infrastructure, press, country management online marketing and support needed to collaborate effectively.

The Goal #1 concept brings a lot of clarity and helps lead us to company-wide alignment. Of course it also brings frustration as there are times that teams need to delay their own goals. But that's the price we are willing to pay.

In order to achieve a Goal #1, 20+ teams need to coordinate. The main feedback loop for this coordination is the Goal #1 meeting. Here, delegates from all teams meet every 2-4 weeks. The Goal #1 team reports their progress, points to any problems, and asks for assistance. The other teams listen, provide feedback, and offer help to keep the project moving. The meeting never takes longer than 45 minutes and in most cases is complete within 15-20 minutes.

Goal #1 started as an experiment, and although not everything went exactly as we hoped, we have observed several advantages even in just a short time:

  • Focus: Goal #1 leads to clarity which is the prerequisite for alignment.
  • Quick decisions: Because the three founders have set the Goal #1, they have an obligation to act accordingly. When the Goal #1 team reaches out to them for help, they need to take care of it immediately. For example, the team was repeatedly blocked because it needed support from the infrastructure team. The founders were able to step in and decide that from now on, two full-time administrators would join the team./li>
  • Self-awareness: After one of our Goal #1 meetings, one of the employees said: “Wow, I did not even know how much power we have at Jimdo!” The company simply became more self-aware and developed a greater feeling of togetherness that can be directly linked to Goal #1.

A final note about communication: the way you design your workspace heavily impacts if and how people communicate with each other. This is the major reason why we have “Captain Chaos” at Jimdo. The Captain is a professional architect - and we are not talking about a software architect. Her mission is to equip all Jimdo teams with the best working environment possible. She puts a lot of thought and effort into creating opportunities where random employees can meet and have a chat without having to book a meeting room. Sometimes this even means tearing down a wall. When walking through the Jimdo offices, you will not only find lots of couch corners, but also an aquarium room and a napping room, but again, that’s another story as well.

Culture

The way we scale the company includes a lot of flexibility. Our processes change all the time. Tools like the Open Prioritization Meetings or the Goal#1 Meeting need to be tweaked constantly, and at some point, we might even decide to cancel or replace them. We are always prepared to manipulate the different roles we have installed or even change the team structures if necessary.

This might sound very chaotic or even haphazard, but it really is not. Our core belief that “Everyone can do great things” is quite stable. Ultimately though, it is our company culture that acts as our “True North”. It provides a calm focus which helps guide us through the sometimes murky waters of continuous change.

Jimdo has always been proud of it’s culture. The founders knew that they didn’t want to sacrifice it for growth. They loved coming to work every day and knew how much that drove their motivation to make a great product. They didn’t want to lose that, and they wanted new employees to feel it too.

The big question then was how to protect that company culture while continuing to rapidly scale. The founders decided that the first step was to work out exactly what “Jimdo Culture” meant - to create a common understanding of Jimdo’s core values. They quickly realized that this was more than an afternoon task. They selected ten team members to spend a week together in Denmark to identify each of these values and how each one affected the working atmosphere in Jimdo.

A word of caution to those reading! Culture is a curious thing. I’ve witnessed several failed attempts by companies to define and control their culture. In my opinion it’s outright impossible to simply define the culture you desire and then build the company around it. In reality, culture works the other way around. It already exists in the way a company works. It is valuable to identify what works, what you and each employee value, and what needs to be worked on or changed. Once these values are identified, they can be written down to reinforce that the company stands behind them. Actions should then be taken to nurture, strengthen, and grow the culture – beginning with the actions of the founders who will set the example for everyone else.

The cultural values that the small team from Jimdo identified during the week in Denmark became the basis for the Jimdo Culture Manual. Some of the broad principles documented in the manual include:

  • Acknowledgement that everyone is human and therefore mistakes will happen
  • The philosophy that everyone should be able to have fun at work
  • That everyone should strive to be the best that they can
  • That it's okay to be a little bit crazy sometimes
  • And that we do not accept dog-eat-dog mentality at Jimdo

Another important step in fostering Jimdo culture was to hire a Feel Good Manager. At the beginning, it was unclear exactly what being a Feel Good Manager entailed. However, what was not in question was the myriad benefits that the position could provide to every team member. Looking back, this experiment has proven to be even more successful than they had originally hoped. The role of the Feel Good Manager, like so much else at Jimdo is in constant evolution, but here are few things that the Feel Good Manager currently takes care of:

  • Helping new employees settle into their new positions, new city, and sometimes even new country
  • Ensuring that employees understand the way Jimdo works, and making sure they have everything to work happily and effectively
  • Organizing regular feedback sessions and trainings for employees
  • Helping everyone maintain a work-life balance and creating a fun work environment by organizing sporting and social events
  • Maintaining a general awareness of any staff problems or needs and helping to solve them

So there is more to being a Feel Good Manager than simply being a “happy” person who tells jokes all the time and hands cookies to the employees. She's watching the company culture without policing it. She tries to nurture and grow the culture without telling people what to do.

(Click on the image to enlarge it)

Jimdo carries out a large culture survey each year. All employees are given the opportunity to evaluate and comment on how well they feel the core values are respected. This example shows one question related to structures and processes.

The importance of culture might sound fuzzy, but it is actually very relevant to our daily work. When facing difficult situations, tackling big changes, or even hiring new people, we can stop and ask how our core values can help us deal with the situation. This approach has always led to good results and helped us deal with many problems and conflicts. We truly believe in the value of a healthy company culture and and are not afraid to invest in it heavily. When it really comes down to it, Drucker is right when he says “Culture eats strategy for breakfast!”

Summary

Scaling is a major challenge for every large or medium-sized company. At Jimdo we chose an approach to scaling which is quite different from traditional approaches. We do not have a blueprint for scaling the company, and we try to avoid most of the “usual management stuff” like middle management, budgets, and detailed planning. Instead, our approach to scaling relies on three main factors that enable us to constantly evolve and find the best possible solutions for our company: culture, communication, and kaizen.

Book references

1Kanban: Successful Evolutionary Change for Your Technology Business. By David J. Anderson (2010).
2Project Retrospectives: A Handbook for Team Reviews. By Norman L. Kerth (2001)
3The Democratic Corporation: A Radical Prescription for Recreating Corporate America and Rediscovering Success. By Russell L. Ackoff (1994), page 23.
4The Art of Action: Leadership that Closes the Gaps between Plans, Actions and Results. By Stephen Bungay (2010).

Learn more about Kanban on infoQ

About Jimdo

Jimdo is an intuitive CMS that enables anyone to create his own website, no technical knowledge required. Founded in 2007, Jimdo now has a passionate team of 180 people in four offices worldwide: Hamburg (where all the product development takes place), San Francisco, Tokyo, and Shanghai. You can create your own website at www.jimdo.com. More about Jimdo in the blog of the three founders, Matthias, Fridtjof and Christian and in the eBook `Doing things differently!”

About the author

Dr. Arne Roock works with Jimdo in Germany - a company that provides a really easy-to-use construction kit for websites. Arne has a great deal experience with Lean and Kanban in different contexts like start-ups, medium sized companies and international corporations. He is fascinated by Systems Thinking and loves to experiment with ideas from Ackoff, Drucker, Deming etc. Arne is founder of the first Limited WIP Society in Germany as well as board member and organizer of the conference Lean Kanban Central Europe. Back in 2012, Arne has been rewarded with the Brickell Key Award for his engagement in the Lean/Kanban community. You can contact him via Twitter, his blog or his e-mail adress.

Rate this Article

Adoption
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

BT