Long time readers of this blog will remember that back in 2019, we published a feature on the benefits of rotating engineers between teams. For those of you who have not seen it, the article described an initiative that aimed to establish cross-functional knowledge sharing, encourage cross team collaboration, and bring greater product awareness, by providing engineers with an opportunity to work on different teams within our Developer Productivity department.
Within Zalando, we are incredibly passionate about enabling our engineers to progress and to develop. This empowerment and growth mindset is deeply woven into our fabric. Take a peek at Our Founding Mindset. Four of them are focused on empowerment. I myself am particularly drawn to #makeUsBetterNotBigger.
Let’s take a look at how another of our business units, Zalando Direct, our B2B marketplace, is using Internal Mobility as a catalyst for development. Within the unit, the leadership team maintains a directory of opportunities that are used to foster growth within engineers. This repository covers community driven initiatives such as our architecture review groups and our weekly hacking sessions, in addition to our department driven topics and task forces such as improving observability of systems. One development opportunity is Internal Mobility.
Internal Mobility is described as an exciting avenue for growth that enables engineers to join a different team on either a fixed-length assignment, or on a permanent basis. In this article, I would like to focus on the former, which was our most recent success story. This story involved a Frontend Engineer who had been with Zalando Direct for over one year, and was joining my team on a short-term assignment for one month.
The goals of the team swap were to:
- Provide a solid opportunity to expand knowledge and expertise by contributing to a new domain.
- Provide the destination team with an experienced extra engineer to contribute to their large and growing backlog.
- Further highlight that Internal Mobility should be used to successfully provide a development opportunity for our engineers.
Kicking Things Off
The engineer’s lead initiated the assignment, so let’s understand what that entails. First and foremost, it is imperative that our engineer is comfortable with, and excited about, the opportunity. Taking ownership of one’s own career progression and personal development is something that I look for when an engineer is on a seniority trajectory. I am always more than happy to double down my investment in them if I know that it will be maximised.
Thereafter, it is important to agree on scope and duration. Engineers know that diving into an unscoped project is a fool’s errand, and this is no different. Up front, it is important to be clear on what is expected from all parties, and what are the boundaries. In this case, it was agreed that the duration would be one month, and that the scope was to work on a particular area of partner-facing functionality within our platform, zDirect. For some additional context, zDirect is a web application that enables our partners to grow and steer their business on Zalando.
Onboarding a new joiner to our team is always a great opportunity to critically assess how well our process is. One factor that can accelerate onboarding productivity, is if the new joiner is familiar with the languages and tools. We were able to keep the tech stack unified, which is a subset of the technologies sponsored by Zalando as part of the tech radar. This, coupled with the engineer’s understanding of the ecosystem, meant that we were able to get up and running in no time at all. Additionally, we got some incredibly helpful feedback that enabled us to improve our onboarding documentation. Given that we are growing at an incredible pace, streamlining the onboarding process for new hires pays dividends on productivity and experience. Always be squeezing your Time-To-Ship!
From this point onwards, we had a new team member. They joined all of our ceremonies, paired with their colleagues, and got to grips with the team’s ways of working. Similarly, they attended social settings such as team lunches and activities. They immediately started shipping value, and right away boosted our team’s throughput. This required collaboration with our engineers, our product manager, and our designer. We do not work in isolation, and this is an important aspect of the assignment. Please don’t extract somebody from their team environment and have them work alone. A well known study on team dynamics stated that “Who is on a team matters less than how the team members interact, structure their work, and view their contributions”.
Use this opportunity to solidify your team and to hone the dynamics of collaboration.
So How Did This Experiment Go?
Ultimately, this assignment enabled our team to deliver increased value for our stakeholders. Throughput aside, however, the assignment yielded much more. As a leader, I thrive from helping my team to succeed. One of the most rewarding stages of this assignment was doing a final retrospective with our new team member. Throughout the process I could see a continuous stream of high quality deliveries, but I wanted to drill down further into the personal experience. To hear that they
“developed technically, acquired a better understanding of how the business operates, and identified different processes and ideas to bring back to their own team”
was of course music to my ears. Moreover, they were inspired to go out and enroll into a Typescript course (we provide every engineer with a healthy training budget to use for their own growth) and incorporate it into their development plan. I like to think of this as the flywheel effect on growth.
My last question to them was “Would you do it again?”, which was answered with an enthusiastic “Yes”.
Internal mobility assignments are a really effective way to provide engineers with an opportunity to learn new skills, to work in a new domain, and to push themselves out of their comfort zone.
All experiments come with learning opportunities, and the goal of trying something new is to broaden our understanding and experiences. Two important learnings for us (as receiving team) were that
- We needed to improve our onboarding documentation.
- Engineers should not have to switch back and forth during such an assignment.
For the former, our new member was able to pinpoint some gaps in the process, and we have since created an internal ways-of-working document to alleviate this for the next person. For the latter, there was an instance when our new member needed to respond to a topic for his original team, which broke the productivity flow, and led to some context switching. This is something that we will avoid next time.
Sidenote: Context-switching is a productivity killer. I remember reading Quality Software Management: System Thinking, by Gerald Weinberg, and being horrified by the impact that switching has on delivery.
That being said, I believe that any endeavour that yields learnings is a successful endeavour. The benefits and learnings that come from internal rotation are in abundance, and I would highly recommend that you try this in your organisation. Presently, we have a number of engineers on different assignments, ranging from weeks to months.
I opened up this article by referring back to an experiment conducted back in 2019. One of the goals that the authors hoped for was that rotations would become more of a regular thing in Zalando, and it’s awesome to be able to write this piece two years later, and say that, yes it is something that we are doing regularly, and continuously learning from.