Advanced Team Structure
Here I’m going to share with you an experience that lasted for years and when I think about it now, it triggers happy emotions and confidence.I am able to see its long-term effects and it’s all based on practical experience and not theory. This is a story, which inspires me and I’d like to share some of my experience with you in this very short write-up.
CONTEXT
We are going to talk about a department of around 25 people, with Engineers, Engineering Leads and Product Managers in it. The department was formed in 2016, with a purpose of creating a set of technical components that would replace a part of old monolith. Therefore, departments was split in three teams in a way, that ensured the fastest and safest delivery of new components. The business didn’t wait for them to finish, but they coped well with incoming requests business. At some point the components were nicely implemented, but the incoming requests kept coming and they changed in nature. New requests were affecting all teams and we had to re-think our set-up.
STRATEGY
The idea was to go big and become “one team”. Engineers were asked to learn components of other two teams. To enable that we created a 24×7 group, that would ensure stability of all components in our department outside of working hours. This was willing to take additional responsibility and they were generously paid for that. Very soon members of 24×7 gained all important knowledge about all systems and improved them along the way. Company surveys showed great health of the team. The department were ready for the new model.
NEW MODEL
Department came together to a Workshop. The main challenge was “How to structure the teams for the upcoming work?” Team roughly estimated work for the next year (yes, Product Managers greatly did a homework identifying so much work by talking to other teams and company leadership). When estimating, teams identified affected components and dependencies. This was possible because roughly half of the colleagues knew all components. As a result, it was clear that we won’t be able to deliver the scope with the same team set up. The question was either to redistribute the components differently across the team or… become a truly “one team”, that would dynamically assemble and disassemble smaller teams to accomplish certain missions. We voted and decided to go for the dynamic teams set up. We decided to call this “Mission Teams”.
IMPLEMENTATION
The job of Product Managers was tough: they had to come up with a canvas, explaining the mission objective, scope of work, stakeholders, rough estimations (created with a help of Principal Engineers) and staffing needs. These missions were stored in a backlog that we called portfolio, and regularly prioritised in the smaller round.
Engineers got a chance to learn from the colleagues of their choice and to have a say on the missions they like most. The work atmosphere was refreshing, Engineers were able to deliver end-to-end in a focus way, without being spread across too many topics. Company surveys showed excellent health of the team like never before. We were cracking mission after mission and accomplished tremendous amount of work while having fun. More and more people were able to deliver across all components.
To take care of components we had a group of maintainers. Incidents were taken care with ease. Everyone knew everyone. Many team members got promoted because of the impact they made.
TODAY
More than two years this model serving the Company and Engineering team. It was a rockstar, but it is not permanent. Recently we hired many new Engineers and needed a new model that would offer them less broad scope to start being independent and productive. We also wanted our new members have a lead in the same team where they were working to help them grow. We also decided to improve the health of our components by focusing on them even more. Today’s set up is a great move and traditional set up is the right way to calm things down, become more advanced, and collect energy to be prepared for the next hyper-productive model.
One Comment
Thanks for your blog, nice to read. Do not stop.