Cross-functional, independent teams
As Ed Conolly described in his blog post about the tech culture in OVO (here), OVO's engineering teams are truly cross-functional and have a high degree of autonomy. Each team is challenged to continuously create value in their domain, they are set up for success at delivering value to our customers end to end. As such have they all have the required skills within the team to do this: software engineers, product managers, UX/UI and/or designers. In addition to this, all engineering teams in OVO are also free in their choice of technology to solve the challenge in their domain.
Principles & guidelines over checklists
The moment OVO scaled up its engineering capabilities, the initial thought was that we needed a mandatory service checklist in order to make sure our teams complied to a certain level in non-functional areas like security, logging, monitoring and others. Recently opinions from teams and engineers indicated this checklist was mostly experienced as waste in the engineering process: principles didn't apply or were slightly different for their tools or processes. As such, the checklist has now been transformed in a collection of guidelines, but still known to our engineering teams. The teams themselves however have autonomy on how to approach those principles and guidelines, we trust our teams to make the right choices in these different non-functional areas.
Modelling challenges of autonomous independent teams
Driving change and best practice
An effect of having fully autonomous teams is that there is not a single team or group responsible for driving change or best practices across OVO Technology. In order to mitigate this effect, we have created Champion Groups. Initially we created Champion Groups in areas like: Logging & Monitoring, Testing, Agile and others.
Some of the Champion Groups were really successful and had high engagement and involvement, others however evolved to be groups that didn't really drive change or best practices, but were mostly used to share news or discuss interests of their members.
Although autonomous and independent teams means they are ultimately set up for successful delivery, it also results in a somewhat scattered landscape of technologies, interests, knowledge and skills. Teams are using all kinds of different technology stacks, take different approaches towards similar challenges and have no organised way of sharing information.
Introducing OVO's internal Communities
To address the challenges described above, we have gone back and gathered the different thoughts people in the tech organisation had around the ways and type of communities we should have. Based on that feedback, we've identified the following three type of communities we'd like to have in OVO.
OVO Interest groups
To address the need for a group that exists around a shared interest, we created the OVO interest groups. These interest groups are a way for our technology members to share ideas, create social relationships and connect to diverse opinions. Everyone in OVO Technology can create an OVO interest group and potentially get beer and pizza sponsored. We keep a calendar of all meetups, so everyone has visibility of the available meetups happening.
OVO Community of practice
As said earlier, due to the distributed nature of some of our job roles, there wasn't a way for those people to connect. For this we've introduced OVO's Community of practice, our internal community where people with the same role or practice can come together. These communities are mainly there for people to discuss ideas, working models and approaches in the context of OVO. Members will discuss and debate opinions and as such learn or develop skills that they will use in their day to day work. Creation of these groups can be done by anyone in OVO, but they need to be sponsored by senior leadership, in order to provide credibility to the specific group.
Introducing the former two community types allows us to go back to our initial idea of making our Champion groups responsible for driving change and best practices within the company. A slight change we made, is making it explicit that Champion groups have the ability to reflect decisions made in the backlog of our internal teams, and as such making sure the desired change is visible to our internal organisation and required tasks executed.
Although we have created different communities for different purposes, we're continuously trying to make these communities better. One of the things we're planning is to iteratively introduce tools for these communities, like calendaring, easier creation and management of the communities.