Fostering cross team co-operation in our Product-Oriented organization
Our context
In the online/digital cell of VRT (aka DPC; Digital production center) we are currently organized in around 10 fairly stable, cross functional product teams. These teams have high autonomy, leading to fast and continuous delivery of product improvements and new products/features/formats.
The Challenge
Product team autonomy comes at the cost of lower alignment between teams.
Teams regularly face similar challenges and will (more often than not) re-invent the wheel several times. In some cases this leads to multiple great alternatives finely tuned to the teams specific conditions and challenges. In some cases, this leads to wastefully implementing (near) exact functionalities resulting in more than desired variance in the end result.
This autonomy, enabled by this product-organization, presents some challenges:
- (Cross team) knowledge sharing between specialists, ways for people to deepen their technical expertise
- (Effort) alignment between teams, ways to pool resources to make and support great general purpose components/platforms that more teams can benefit from
In our view, both challenges are quite different and require a different approach to address them well. We have decided to start experimenting with two cross team cooperation forms, each tuned to solve (or at least lighten) each of the problems.
To clarify, an example of a common problem solved by multiple teams is the VRT media player(s). Every team needs to integrate a media player into their products to be able to play video & audio. This player is typically a standard component ‘wrapped’ with VRT-specific enhancements such as:
- Analytics: for getting statistics about the online consumption of our content
- Digital Rights Management : for protecting our digital copyright & broadcasting permissions
- Generic capabilities: ‘auto-play next a next video’, ‘casting’, …
Multiple teams have written variations on this ‘wrapper’ resulting in different analytics approaches between product, missing features & avoidable rework. In this case, all could benefit from contributing to one standard ‘vrt media player’ implementation.
In addition we wanted to create a culture where bottom up innovation is fostered. As Steve Jobs said: “We don’t hire smart people to tell them what to do, we hire smart people to tell us what to do.”
Enter “Chapters & Communities”
Going forward, to address the challenges, we want to introduce the concepts of ‘Chapter’ and ‘Community’. Both are (already) loaded terms used in among others the spotify model and SAFe, so it is important to note that we choose to (re)define these terms to fit our context.
Both a Chapter and a Community is a kind of virtual cross-team group, but the Chapter is geared towards solving problems of ‘Effort alignment’ whilst the Community has a bigger focus on ‘Topic based knowledge deepening & innovation’. We will explore these two concepts further.
Community
We see a Community as an organically evolving group of people with similar professional knowledge & skill interests. For instance, a design-community or an AWS-community.
Teammembers of all teams are free to (start or) join communities purely on their own interest and desire to learn more about certain topics and we highly encourage them to do so. They are explicitly awarded 10% of their time (half a day per week) to engage in Community work (organizing or attending presentations/discussions/hackathons/PoC’s…, writing/reading related blogposts/books, doing experimentations, …). Of course, the more the results of this work is shared throughout the rest of the organization, the better!
Communities may come and go depending on the changing needs of (all of) the team-members, and that’s perfectly fine and expected.
We try to get together all active Communities on a Wiki page together with some basic info about them and 1 or 2 key contact persons (our ‘Community Connectors’) so that people searching to join know where to start.
Chapter
As stated earlier, a Chapter has a different ‘purpose’ than a Community. The focus of the chapter is on coordinating/pooling different teams resources towards creating and maintaining a common ‘deliverable’ that is essential for each, but generic enough that it can be reused by all.
In practice this requires a Chapter to have it’s own ‘scope’ (eg Media Player) usually resulting in a Backlog/Roadmap and time needed to ‘make it happen’. This requires a clear management decision and support, as forming the Chapter will pull effort away from the teams towards ‘something else’.
In our context, we solve this by allowing people to ‘pitch’ possible Chapters to the leadership team. If the leadership team feels the Chapter is necessary to achieve our goals, a ‘Chapter Owner’ (analogous to a Product Owner) is appointed to craft a vision/roadmap/backlog for the Chapter as well as (in close cooperation with the teams involved) propose who is needed on in the Chapter and how much time they should be freed up to make the Chapter a success.
After this, the Chapter acts like a (long lived) task force, improving and expanding the shared component/platform/service for as long as is needed.
So, now what?
We started with telling people what we wanted to achieve through communities and chapters. We made a call to action and asked people to come with idea’s.
A hand full of people have shared their idea’s and eventually some rolled up their sleeves and showed initiative to start a chapter or community.
As a leadership team, we must support these people as much as possible. They are the forerunners and changemakers, their efforts will determine this initiatives success or failure. Others we need to encourage to participate more freely (by reminding them they have the freedom to spend 10% of their time in community work, by actively asking about possible Chapter ideas, …).
No ‘Silver Bullet’ / Use with care
We hope these initiatives will lead to better cross-team cooperation & better knowledge sharing. But we are well aware that this is not a ‘silver bullet’ that will solve all of these problems at once. Furthermore, not every challenge faced by each team warrants a ‘Chapter’ approach. Overuse would lead to over-centralization, negating the benefits we now reap from our autonomous team organization.
The hard work is still in front of us, but we believe that strong Chapters and Communities will arm us better in tackling the (real) challenge ahead; delighting the Flemish public with amazing digital products & content.
PS. If you have ideas or caveats regarding the contents of this blogpost, I truly appreciate the time put in letting me know & eagerly await your comment!
