Leveraging domain sponsorship to organize product teams at scale

Picnic is growing at a rapid pace in all of its departments. As a tech company with big aspirations for the future, the teams concerned with technology are no exception to this rule. This is no different for the FCA team, the team responsible for building the software that will power Picnic’s upcoming automated fulfillment centers — the team I am a part of as well. Our project’s scope is immense, and we need a large number of software engineers to stem this in the projected time frame. Due to this, we saw a great influx of new team members over the recent months — even considering the current COVID-19 situation.

The big challenge for us lies in organizing the team efficiently while growing in size, such that every sub-domain of the project’s domain is understood enough by the engineers to develop it independently under our tech lead’s guidance. This spring, not long after the kick-off of the whole project’s software engineering and development efforts, together with our tech leads, we identified that our velocity could be increased and that our way of working was becoming inefficient. The team’s engineers jumped all over the sub-domains for each task they worked on while never really deep-diving into one of them. The slide at the side is taken out of a presentation that our product owner held a week before introducing the solution to these problems.

These problems meant that the small number of tech leads compared to the larger-growing number of engineers quickly became the bottleneck in improving our velocity — for three reasons:

1. The tech leads became the only ones versed enough in the entirety of the project’s domain to engineer good solutions.
2. For many questions that arose, the engineers had to consult the tech leads, decreasing everyone’s time working on actual solutions.
3. The engineers had less actual engineering work at hand and more straight forward software development work to do instead.

Thus, last June, we devised a new process to accommodate the sheer size of our project’s domain with the ever-larger growing resources available to us: Domain sponsorship. The rest of this article elaborates on this process:

The idea is that each engineer sponsors one or multiple sub-domains of the entire project domain. That means that they govern their sub-domain, become an expert in it, as well as the primary person to approach for questions by others regarding that sub-domain. Importantly, this does not mean that the sponsor of a sub-domain has to also implement all tasks in it. Furthermore, the tech leads are still there to oversee the architecture of the developed software, including overarching design decisions.

As for our automated warehouse, this turned out to work especially well since we are bound to physical components and processes happening in the warehouse. These have a lot clearer boundaries than non-physical processes, and the topics that are overarching multiple sub-domains are few and clearly definable. Nevertheless, we believe that this model works well for non-physical domains as well; only the definition of the boundaries might either be a bit more difficult or fuzzier. After this short boundary definition phase, one could find sub-domains such as the following ones, and a lot more, in our project:

• Registering incoming stock into our warehouse system
• Storing stock in our storage system in an orderly and efficient manner
• Determining when to start fulfilling an order just-in-time
• Effectively selecting stock to increase throughput
• Keeping enough supply and load on our system to stay efficient
• Powering the whole process of picking orders
• Resolving issues that surfaced (e.g., damaged stock)

Working with this process on a day-to-day basis shall not stay unmentioned in this article, of course. Each sponsor is responsible for specifying the tickets within their sub-domains regarding the current milestone. The milestones are created in synergy by our team leads, the product owner, as well as business analysts. They are designed to encapsulate small, partial components of the system with the focus on being testable and demoable individually. Nevertheless, there is an order to them as some milestones built upon earlier ones. We do, however, try to make them as parallelizable as possible. The sponsors just have to keep an overview of what still needs to happen to complete their share of the milestone. We are using a regular JIRA instance for this, having set up the following workflow:

Once a week, the tech leads put due dates on tickets with the NEEDS SPECIFICATION status. This day is just a preference, and the sponsor is expected to communicate back to the tech leads if the day is not feasible due to whatever reason. This tells the sponsors by which day the ticket should be READY FOR DEVELOPMENT. They do so by specifying the ticket, possibly splitting it up into further sub-tasks. The IN SPECIFICATION phase usually consists of talking to the sponsors of interfacing sub-domains as well as the tech leads, while writing documentation of what was engineered. If questions arise, there is a Slack channel for every sub-domain that the sponsor is urged to post in such that everyone that has an opinion can react to it, to arrive at a solution in a timely manner. Additionally, it helps to keep smaller decisions documented that might not make it into the finalized design’s regular documentation. Once the sponsor deems a ticket to be specified, they change its status to READY FOR DEVELOPMENT, which will trigger the tech leads to either move it to the BACKLOG if they generally agree with what was specified, or to move it back to IN SPECIFICATION, discussing with the sponsor what should be improved. This ensures that there is a terminal quality gate leveraging the tech leads’ experience. What follows is regular Scrum in our case, but any other methodology would work as well, as far as we are concerned. To keep the described process efficient, we personally found JIRA’s dashboard functionality to work well for us.

The effects we experienced after introducing this new process were overall very positive:

1. Our development velocity saw a tremendous increase.
2. The tech leads have more time for other tasks as most questions concerning a specific topic can be answered by the sub-domain sponsors.
3. It gave more genuine software engineering responsibilities back to the engineers, which most were very happy about. Using the above-mentioned workflow, each sponsor can have a clear picture of what should be ready, at which point in time, allowing them to organize their workdays more precisely.
4. Our meetings turned out to be way leaner and thus more focused than before since only the interfacing sub-domains’ sponsors take part in it, plus maybe a tech lead, if necessary. This does mandate that decisions are properly documented, but our focus has shifted toward this immensely — which is necessary for a project of this size anyhow.

The major negative effect that we experienced is that the sub-domains can become silos over time, trapping their sponsors in them:

1. This can have negative effects in the form of overloading some sponsors with work, which we want to avoid, of course. This is by far the biggest challenge, and when implementing this process, take care to keep employee satisfaction high and stress levels low. Make sure to regularly check back with the sponsors on how it is going.
2. It can be difficult to keep a good balance between domain sponsorship efforts and development under this process. Thus, keep an eye on the time distribution, and either split up the sub-domains to decrease the domain sponsorship workload per sub-domain or let one sub-domain be sponsored by more than one person.
3. The knowledge about that sub-domain getting trapped in its silo is another problem that we try to tackle with adequate documentation, as already mentioned. We can claim that this works well as new team members seem to be up to speed swiftly after joining. Nevertheless, this is an ongoing effort for the whole team.

A final note is that this process was for now just devised and utilized by the FCA team within Picnic. However, our CTO is aware of this process, as well as its positive and negative effects. Possibly, other teams within Picnic will adopt it as well in the future — after all, it is particularly applicable for larger domains and team sizes.

To summarize, the core of the devised process is to give more software engineering responsibility back to your company’s engineers. Importantly, I purposefully used the term engineer throughout this article instead of software developer or programmer. This mandates a few pre-conditions: The hired people must be comfortable with engineering, not just developing, and they must be up for the challenge — it is certainly not everyone’s cup of tea in this space, which is perfectly fine, of course. Since the number of sub-domains is finite, a hybrid approach is also conceivable, where only some people sponsor sub-domains. Finally, the tech leads and the CTO must be comfortable with putting trust in their engineers’ abilities, which is certainly the case at Picnic.