TechOps have worked in an end-to-end, cross-functional, ‘you build or buy it, you support it’ delivery model for three years now. We’ve tweaked it, and we’ve played with some of the details as we’ve learnt things along the way, but generally, it has worked well for us in delivering value according to TW’s priorities and changing direction.
To achieve this outcome, our TechOps team was organised into the following three areas:
2. Core teams governed by TechOps leadership and focussed on the underlying, and often ubiquitous, tech and processes necessary to run a company: e.g., networks, infrastructure, security, collaboration tools
3. Workspaces teams governed by TW’s regional Heads of Operations. These teams were responsible for keeping our offices and all our devices running. Where the first two types of teams are focussed globally and work very distributedly, the workspaces teams are designed to have a local focus and often act as the face of TechOps in the individual regions. Whilst working within a light framework of global standards and governance, they have the flexibility to respond to local needs.
Overall, as a structure, it worked. We were quickly and efficiently delivering value that was closely aligned with overall business priorities. We cleared out a lot of backlogs and revamped the way that we approached internal delivery. However, we always knew there were risks associated with this siloed structure. From late 2016 we started to see the impact of those risks as we sought to address some of ThoughtWorks’ more complex operational issues.
The issues we saw emerging included:
- Being great at serving one group of stakeholders at a time but not really great at designing for user journeys that involved collaboration across multiple business functional areas. We were optimising locally rather than across the organisation as a whole
- ThoughtWorkers interact with our products across many touch points - digital and physical - but those touchpoints are disconnected from one another, creating what we called ‘Scenarios of Pain.’
- ThoughtWorks struggling to make global changes and tackle large programs of work due to conflicting cross-functional prioritisation and collaboration issues
- Regions needing significant variance in systems to support financial, legal, regulatory and cultural needs
Platforms as a Service underpinning all our work.
Service Experience teams focussed on E2E, multi-touchpoint experiences rather than remaining siloed around individual business functions.
Hybrid Workspaces teams who are still ‘on the ground’ in each of our regions play three roles in our new structure;
They work with regional leadership to make certain that all our infrastructure is sorted - offices, laptops, networks,
They are responsible for creating the services round ‘Offices’ and ‘Devices’ that will feed into our Platform;
They act as an SME for the Service Experience teams - remember how we mentioned that we wanted to create services that spanned both digital and physical environments? Well, these are the people that best understand the ‘physical’ part of that equation.
So far the reception for our evolution has been really positive, most people were saying “this is absolutely the right way to go”, “we should make this broader than our IT”, so we knew theoretically we were heading in the right direction.
It took us the rest of 2017 to move all the pieces around to get the new teams up and running. We think the next stage will be the real test and we know we will iterate over our approach as we try things out and learn what does and doesn’t work.
Some of the things we’re concerned about and trying to mitigate include:
- The platform teams being disconnected from their users and the reason for their existence - creating a platform as purely a technical exercise. After an initial false start the team is now more firmly focussed on the ‘developer experience’, recognising that if they don’t make it valuable to their end users, those users will make minimal use of the platform.
- Our business function stakeholders adjusting to not having an IT team directly responsive to just their specific needs. To date, we’ve had minimal problems with this.
- Capability and capacity within our Workspaces teams to create and maintain services for the platform.
- Funding and governance models - currently our funding is tied to the operational function teams’ funding. This, at a fundamental level, still creates a view that we should directly tie development to individual team’s needs; a view that is at odds with the need to address organisation wide priorities. We’re looking at different options. Are they the right ones? We think so, but it will slow us down if we get it wrong, as additional time will be spent reporting against both old funding models and new structures, and because of time spent mitigating the risk of our stakeholders reverting to siloed behaviours because they see their budgets on the line.