At Teamtailor we are fortunate to have an incredible team of builders in the Product team. 40+ designers and developers with an average professional experience of more than 13 years. In addition to their expertise and care, the key to our success is our culture and how we work together.

Culture: how our values shape our work

“How we spend our days is, of course, how we spend our lives”*. Culture is not what you say, it’s what you do. So what we do on a daily basis is what shapes our culture and the experience of working at Teamtailor.

Our core value Personal means we believe in autonomy, in people deciding for themselves how, when, and where to best do their work. It means that when we have a clear goal and understanding for why that matters, each person and team is empowered to find the best way to get there.

Different means we believe in diversity, in everyone using their unique perspective to come up with creative ideas and solutions. It means not trying to conform, but finding our own path to bring joy to our colleagues and customers through our way of working and the things we build.

And finally Kind means we believe in trust, in avoiding micromanagement and control and instead growing through a sense of ownership and supporting each other along the way. It means treating each other as responsible adults but always being there to lend a helping hand when needed.

So how do we put all of that into practice when building Teamtailor? The methodology that best fits our values that we’ve found is Shape Up from 37signals (creators of our programming framework of choice Ruby on Rails). We have been using it for many years now, and it provides a good balance of alignment and autonomy, leaving plenty of room for diversity and trust. Here’s how we do it.

Shaping: setting the direction

We work in small teams in six week cycles. Six weeks is long enough to build and ship something meaningful, but short enough to not lose sight of the end. That means we have to stay focused and make trade-offs along the way. It also keeps the risks low and gives us enough flexibility to change course when needed.

Before a cycle begins we start by “shaping” work in the form of project pitches. We have three people in the Product team who are responsible for this as part of their jobs — our co-founder David, our Head of Product Suzan, and our Product Manager CJ — but everyone in the Product team can write pitches for their ideas.

A project pitch has four main components:

That’s it. A pitch is usually around 1–2 pages of text and maybe some rough sketches. Enough to explain the idea, but leaving enough latitude for the team to take ownership of the project. No detailed specification, user stories, or mockups.

The Product leadership team then decides which pitches we want to “bet” on in the upcoming cycle. We strive for a 50/50 balance each cycle between projects based on customer feedback and innovation. Basically between giving customers what they want, and delighting them with things they didn’t know they wanted.

We also set an “appetite” for each project. Instead of estimating how much time a project will take, we decide how much time we want to spend on it. In Agile terms, this is known as “fixed time, variable scope”. It helps us avoid frustrating delays and keep a steady momentum of shipping, and empowers the teams to make the necessary trade-offs.

Right, the teams. After deciding on which projects to tackle during the upcoming cycle, and what our appetite is for each project, we then form teams around them. Each team consists of two full stack developers and one designer. When assigning the teams we take into account technical expertise, domain knowledge, specific areas of interests, availability, and team dynamics, and so on. Some people prefer more stability and like working together with the same people over several cycles. And some people prefer variety and like getting to work with and learn from lots of different people. 

Building and Shipping: getting things done

Once the cycle starts the Shaper has a handover meeting with the team where they go through the pitch and clarify questions. The team then takes ownership of the project and they are responsible for designing, building, and shipping the best possible solution to the project, given its appetite and constraints.

The team is empowered to make all the necessary decisions around scope, using their creativity and problem solving skills to find effective solutions. If a project has an appetite of three weeks, it’s the team’s job to ask themselves “What’s the best three week version of this feature, this will achieve the project’s goal?”, and then design, build, and ship that before the cycle is over.

To do that, the team needs to be able to really focus on the project. If they constantly get distracted and pulled away by responding to urgent tasks from other parts of the company they will fail. So we have a dedicated team of Tech Heroes that don’t work on any planned projects during a cycle, but are free to deal with the urgent tasks that pop up from time to time. Such as fixing bugs and helping other departments with their needs. In between, they work on small improvements here and there in the product. But more on that later.

The team also has full autonomy when it comes to deciding how they should work together. No unnecessary meetings. But if they want to have daily check-ins, weekly planning, or something similar they do that. If they want to do pair programming (or even mob programming) most of the time, they do that. There is no project manager or scrum master to organize the team’s work for them, but the Shaper is always available to provide feedback and support when needed.

The main success criteria of a project is that we shipped something we can be proud of. The team can always reduce the scope, but cutting scope isn’t lowering quality. If we ship a small but good feature we can learn from it and expand on it in a future project.

Cooldown: innovating and improving

After six weeks of focused work we take two weeks to cool down and regroup before the next cycle. A change of pace. A breath of fresh air compared to some scrum teams’ tendency to sprint, sprint, sprint, sprint themselves to death. Or at least burnout. Sprinting all the time is not a sustainable pace.

We’ve split our Cooldown phase into two distinct parts:

Innovation Week

We take a break from focusing on shipping and instead experiment with new ideas to learn and have fun. This is completely self-organized. We start the week with a meeting where everyone can pitch ideas for Innovation Week projects. That can be experimental feature ideas, exciting new technology, or trying out new tools or ways of working. Everyone then votes on the ideas they think sound most exciting to give an idea of how valuable the rest of the team thinks it is, but everyone is free to work on whatever idea they want. They can team up and work on it together, or tackle it on their own.

We finish Innovation Week with a big demo where everyone shows off what they’ve been working on. A highlight of every cycle, there is always so much exciting stuff being shown. A lot of our innovation focused ideas for upcoming cycle projects come from this, and when we shape a project pitch around a concept from Innovation Week we also try to include the people that first experimented with it in the project team. That gives them an opportunity to take their concept all the way and ship it to our users.

Improvement Week

Finally, we start preparing for the next cycle with Improvement Week where we focus more on maintenance and housekeeping. Everyone in the team works on smaller improvements across the product and codebase that don’t warrant a full project. Tasks that take no more than one or two days usually. We ship about 80 or so improvements to our users every Improvement Week. Small things that together have a huge impact on the quality of our product and the experience of our users.

Getting maintenance tasks out of the way also means that it will be easier to focus on the projects when the next cycle starts. It’s our “Mise en place” where we put everything in place to make sure we are prepared to do great work when the new cycle starts the following week.

These three segments — a six week project cycle, Innovation Week, and Improvement Week — each with their own distinct feeling, creates a wonderful variety and seasonality to work. It never gets boring. And together with the autonomy, diversity, and trust built into this way of working it sets the tone for our culture and lets us be Personal, Different, and Kind.

Building things you’re proud of together with great people. That’s what it’s all about. Come build with us.

Additional resources