Each of our feature teams at Teads chooses how it operates based on its specific needs and mission. In this article, I will take the example of the SSP team, in charge of automating the selling of ad spaces through real-time bidding to 1.2 billion users per month and generating more than 1 million bid requests per second.

The SSP team grew significantly during the past years and we had to rethink our organization along the way.

When I joined the team, we were applying Scrum with 2-Week-long Sprints. At that time, we were 5 and the team was only a year old.

Although everything is supposed to be fixed during a sprint planning, we couldn’t freeze for so long. We always had new priorities coming from tech challenges or business requests.

Following that, we tried to adopt some Kanban principles. Tasks priorities were now allowed to be modified, should something arise. The board was changing regularly with one rule: once started, a task cannot change anymore.

This priority scheme worked for a while and the team kept growing. After a few months, we were now 8, we realized that we were always prioritizing major features that held the most business value. Smaller tasks that could be blocking someone else in the company were never prioritized and awaited for a long time.

We reached a point where we were struggling between roadmap and on the fly requests. In addition, bugs were not tackled fast enough and debt was accumulating. We needed to take a step back to think about our organization and how we could best handle incoming requests.

After reviewing different options with Xavier, we decided to split the workload into two separate lanes, while keeping the same principle: tasks priorities can change until we start to work on it.

1- Fast lane

Quick response for day-to-day requests

The Fast lane handles small requests, features or bugs that need to be executed quickly.

These tasks should take less than a week to be completed. This lane acts as a buffer for the team and prevents from interruptions caused by bug reports, production incidents or any other unexpected event.

Simply put its mission is to protect the strategic lane.

The Fast lane follows the exact same Kanban-inspired principles.

2- Strategic lane

Focus on product milestones

This second lane is dedicated to the roadmap with high-priority, high-value tasks that usually take a few weeks to develop. We tried different configurations to efficiently address these strategic tasks:

• To begin with, we tried a spec-challenge approach led by the product team. During this, we first define the scope of a feature and write the full specifications. Once complete, we gather the team (including the Fast lane) to challenge the specs and iterate around key questions (what’s missing on the product side, is it technically acceptable, etc.). It worked for a while but we ended up specifying too much and were falling back into good old V-model quirks. We managed to get good results and gained a lot of focus but it lacked reactivity for important specs (aka “tunnel effect”).
• On our second try we adopted a very light product specification phase (who is it for, what are the needs and core goals). Following this, we build a dedicated team to go in depth and adjust the specs on the go. The strategic features are then split into smaller tasks. We use a mix of Scrum / Kanban methodologies where we prioritize these tasks and iterate regularly with new versions in production.

At that point, we were capable of tackling bugs and requests as soon as they appeared, as well as execute our roadmap efficiently, thanks to the focus of the strategic lane.

However, dealing with production issues and deep tech revamps was still complicated. To solve the latter, we introduced a new lane.

3- Tech lane

Focus on debt management and Engineering roadmap

We were then 10 engineers in the team, which was enough to create a new lane, dedicated to complex and deep technical topics over several weeks. It could be a project on performance optimization or rethinking parts of the SSP’s architecture.

At the same time we decided to allocate a day per week (Fridays) to prevail over the debt. During these “Fridebts” we undertake a backlog of small refactorings, components or library updates.

Lane rotation

Lanes shouldn’t be mistaken with separated teams, regular rotation is key to make it work. But the challenge is to find out how to do this without breaking the team’s focus and keep ourselves motivated.

Indeed, each lane has its pros and cons:

• The Fast lane might appeal to some that need constant action and novelty but at the same time it can be very demanding due to a constant flow of requests,
• After a few weeks on the same topic in the Tech or Strategic lane you might want to move on to something else.

We couldn’t use a fixed time frame because the timing would never be right for long lasting tasks. Rather, I decided to use strategic lane milestones as a breaking point to perform a full or partial (not every team members) rotation.

On average, rotation happens every 2 months (1 to 3 months).

Lane management

Growing several lanes has caused some team management challenges. I was not able to keep track of everything that was happening in the team so we introduced a lane lead mission. It’s a temporary role that changes on every rotation. Everybody in the team can be a lead and when you are, your mission is to report on what’s happening in the lane.

We also had situations where we were not enough and someone ended up alone in the Fast lane. It did not go well and our buffer was quickly overflowed. Since then we try to always have at least two person in a lane with a maximum of 3–4 (pizza team) so that communication remains easy for everyone, plus it lessen the burden of reporting.

At the time of writing we are now 12 Software Engineers and 1 Engineering Director on the development side. The team is distributed as follows:

• a Fast lane with 2 people,
• 3 Strategic lanes (4–2–2 people), one of these lanes is a permanent Data Science lane. When we need to focus on a large subject we separate it and distribute it to the different Strategic lanes.
• a Tech lane with 2 developers,

The whole team also includes 2 Product Managers plus 1 Technical Solution Engineer.

Organization and Rituals

Developers are responsible for specs and documentation, the product team keeps an overview of the process and is in charge of translating the business needs.

Our rituals are Scrum-inspired:

• We have a daily standup to share what’s happening (10 minutes). During these, lane leads are the only ones who report to save time.
• 3 separated Weekly meetings, one for each type of lanes (Fast, Strategic and Tech) where we invite product and a business sponsor. During a weekly, we share what was done during the past week, changes, ETAs. We also do a Demo so that everybody can keep track of the advances and then review the backlog.
• General demos once every 3 weeks. We have two types of demos and alternate between both. First, we have internal demos with the team only. These are essentially detailed standups where we share code. We also have external demos, opened to other engineering teams, where we do more formal presentations.
• Retros, on demand, when we feel that’s needed. Usually every 5 or 6 weeks.
• Dedicated meetings with product and engineering to prioritize the roadmap.

On a practical level, we decided to colocate the lanes right after launching the Tech lane to reduce the noise in the open space and focus.

How to keep growing?

Each newcomer follows a specific onboarding journey. After a general company onboarding she/he will spend a week as a spectator in the different lanes to meet everybody and understand how we work.

Then she/he will do a first rotation in the Fast lane with an experienced team member to get to know our tech stack by working on a lot of different topics. Once this first rotation is done, getting into more complex tasks won’t be a problem.

Unfortunately, a feature team cannot grow indefinitely. As a manager who had kept a lot of technical responsibilities there was a point where I couldn’t spend enough time with the team. I was becoming a bottleneck so I decided to create 4 specific roles to share some of my duties:

• A production incident supervisor that monitors alerts before they are picked up by the Fast lane,
• A code review supervisor, who is responsible for the development workflow. Prior to that, we sometimes had pull requests that waited for a while. We needed to have someone keeping track of what can be reviewed and prioritize PRs. We receive internal PRs coming from our team and external ones from the whole engineering department. This role needs a deep knowledge of our component to make sure that reviews are performed in accordance to their level of criticality. This person is also responsible for merges and production release management.
• A tech debt whistleblower, who is in charge of detecting pain points during code reviews, defining priorities and has full permission to fill the Fridebt backlog. This person is also involved in Tech lane planning discussions.
• And finally, a team organizer in charge or animating team rituals and making sure that they are not skipped.

These missions are part of the day-to-day activities and do not impact the lane organization.

Conclusion

Overall we can say it’s a success. The lane organization even inspired other teams, even though each organization is purely personal and context dependent.

From a developer’s point of view, lanes bring several positive aspects:

• It empowers the team with great responsibilities,
• We gained a lot a focus, Strategic tasks are not disrupted anymore, we are also able to keep a zero-bug backlog and efficiently monitor production,
• The rotation enables to see a lot of different subjects and work closely with all the members of the team,
• The temporary Lead role is a chance to discover reporting activities for some and gives more autonomy,

Of course some of us will prefer one lane over the other but each has its advantages and we never had to look for volunteers:

• The Strategic lane is a chance to focus on one specific subject and be totally invested in it,
• The Fast lane is interesting as well as it will deal with many other components of the platform (Ad Formats, Analytics, Web Apps, etc.),
• And finally the architecture dimension of the Tech lane is really stimulating.

Although it’s not hard to implement, if you want to try a similar organization it’s important to be careful with a few things:

• The minimal required size of the team is quite important, starting from 8 people it was great,
• It requires to invest a lot on code sharing between lanes. We are working on an important and shared component so we try to perform inter-lanes code reviews as much as possible so that everyone can see what’s going on.

For me, the takeaways from this journey are:

1. Be pragmatic and avoid being dogmatic about your team organization.
2. Learn about everything, cherry-pick what you think is best for you and your team.
3. Then try, analyse and change as soon as it’s needed. Rinse & repeat.