Today, Thoughtworks has about 220 globally distributed people working in its internal IT organisation: TechOps, as it’s called here. We look after everything related to hardware, networks, infrastructure, software, and enterprise systems across all 15 countries and 42 offices that we operate in.
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:
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:
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:
1. Function teams who were directly governed by areas of business operations: e.g., Sales, Finance or Recruiting. Priorities and budgets were ‘owned’ by the owner of each business operation. For example, the Head of Finance was responsible for high-level prioritisation and budget decisions in consultation with the TechOps Finance function team. The functions teams were responsible for full end-to-end design and development for apps and associated processes focussed around their particular business operations area.
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.
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.
Decreasing the friction in delivery, increasing useful consistency and enabling faster experimentation and innovation both for TechOps and across the business as a whole. Most of our old ‘Core’ teams are being absorbed into the Platform
-
Service Experience teams focussed on E2E, multi-touchpoint experiences rather than remaining siloed around individual business functions.
We have four teams focussed on the four key phases of our business - ‘Opening up early stage Demand and Recruitment opportunities’, ‘E2E Customer Stewardship’, ‘TWer Experience’, and ‘Balancing our Business’.
The priorities and goals are a shift from an individual operational function to key business competency. Instead of asking “what’s the biggest priority for Finance?” we ask what’s the biggest priority for “E2E Customer Stewardship?”. With our new cross-functional group of stakeholders, we have very different and more valuable conversations. These conversations encourage different operational functions to optimise for achieving particular goals rather than optimising for siloed, functional efficiency. Our old ‘Function’ teams have all been moved into Service Experience teams
-
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.
Challenges/Questions going forward
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.
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.
- Some of the underlying thinking by our Head of Technology (TechOps) that informed our own platform strategy
- Our Workspaces journey - Why IT departments must reinvent themselves
Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.
