Operation Teams usually work as a part of a value chain that responds to customer needs, change demand and periods of unexpected intensity to deliver reliable, high-quality outcomes at the lowest cost.
Examples of Operations Teams might include:
Operations Teams are the custodians of some of the most critical organisational metrics - customer satisfaction, revenue and margin and play a variety of key roles in the value chain:
Operations teams are probably the most challenging to lead in a remote context for a variety of reasons. Operations teams are the most likely to:
They are also the teams that conduct the most ‘repetitive’ or ‘procedural’ work during their average work day. It’s relatively easy to motivate a team to solve a problem or create an outcome, it’s quite challenging to motivate a team to manually migrate hundreds of customer records, clean up data, or chase down unpaid invoices.
remote:af Operations teams are comprised of an Operations Lead and Operators which are usually technical specialists or process/task specialists.
The size of the teams can vary although should not be greater than 15 people.
remote:af Operations Leaders manage their teams using a combination of care and empiricism. They are patient with new starters, ensuring that they are clearly instructed and supported. They understand the lumpy / seasonal nature of work and use the slack in the system to implement change. They ensure that their work environments are safe and productive and create efficiency through a focus on key metrics and small, evolutionary improvements. They ensure that their team is prepared for crisis and are prepared to switch modes, taking control during time-critical events and ensuring that the team acts methodically during the response and controls risk.
Operations teams tend to be funded out of Operational Expenditure (OPEX) and are usually very cost conscious.
One of the interesting nuances of enterprise finance is that most executives are rewarded based on EBITDA performance. Capital expenditure (CAPEX) is recorded as an Asset on the balance sheet instead of an Expense. This means that OPEX is often a lot more tightly controlled than CAPEX. By virtue of this, Operations Teams are constantly searching for efficiencies.
Within the team the boundaries tend to be quite explicit. Tasks are usually executed by an individual or by a set of people with clear roles in the process. Specialisation is common and often critical.
Operations teams have low failure tolerance at their boundaries. Because they are designed to run highly efficiently an error in a process can have significant system consequences. For this reason Definition of Ready and Definition of Done in an Operations value chain are highly explicit and the boundaries between teams are well defined.
Operations Teams tend to operate as links in tightly coupled value chains. In a remote environment the fewer steps in the chain the better but we can be more tolerant of chained systems for operations teams due to the explicit nature of the interface agreements. Operations teams:
Operations Teams suit talent that enjoys the rewards of task accomplishment and who can remain calm and act methodically in a crisis. Team members must be highly competent, reliable and risk-aware. Operations Teams ideally suit process, task or technical specialists who excel at structured learning and problem solving.
Development programs for Operations Teams tend to be tightly structured and based around the skills and knowledge required for the job at hand.
Same as the other team types, but things to consider:
What gets measured gets done.
Using data in today’s businesses is crucial to evaluate success and gather insights needed for a sustainable company. Identifying what is working and what is not is one of the invaluable management practices that can decrease costs, determine the progress a business is making, and compare it to organizational goals. By establishing clear operational metrics and evaluate performance, companies have the advantage of using what is crucial to stay competitive in the market, and that’s data.
Since every business is different, it is essential to establish specific metrics and OKRs to measure, follow, calculate and evaluate.
When identifying the key metrics you should consider the following parameters
Turning the datasets into a business dashboard can effectively track the right values and offer a comprehensive application to the entire business system.
System Lead Time (Cycle Time)
Customer Lead Time
Failure vs Value Demand
System / Process Up Time
Service Level Expectation / Result
Outage Time to Resolution
The remote:af Operations teaming pattern is effective for Platform Operations teams but has a broader organisational purpose covering customer and enterprise operations.
DevOps is a specific pattern developed for the integration of development and operations teams in technology. DevOps is ideally suited to parts of the organisation where change is a constant but as we move through the product lifecycle then the need for dedicated operational capability emerges. DevOps is not an appropriate pattern for a legacy platform that is due to be decommissioned or a product with a declining revenue stream where margin is the focus.
As a product, platform or service moves through the product lifecycle the Operations characteristics change:
Team Structure: Development Approach – Early product lifecycle Development only, looking to determine if we have a product or not. Support is limited bare bones only. Build tend to support as a way to learn and iteratively develop. As the volume of support increases, the capability of this model to meet demand is limited and process development to capture support requirements will need to be developed.
Team Structure: DevOps approach – Customer base requires formal support processes (traditionally L1 and L2 at minimum). Dev Team provides more formal support of the product in parallel to dev requirements. As the customer base grows, support demand also increases.
Recommended use: Late Introduction to a mid Growth phase
Optimised DevOps approach – Product Build & Maintain within a single team. Support Segmented with the team and team members dedicated to supporting on a rolling basis
Team Structure: Development & Operational team approach – Dedicated Dev Team and Ops teams supporting customer volume. Drive for efficiency and reducing the number of support requests through automation and customer self-serve. Support undertaking Incident analysis and Problem analysis
Regarding Hybrid Dev/Ops teams and Dedicated Ops teams’ rather than Dedicated Dev and Ops depends on the perspective we take on DevOps vs SRE vs ITIL/ITSM Level 3 Problem Management, but these hybrid teams exist and are supported by remote:af. These models try to overcome the same problem and we can see SRE as a role and practice that your Problem management Operations team aim to do in ITIL Problem Management. In this way SRE is a highly functioning, highly effective Problem Management Team.
DevOps has people building the product looking for effective improvements to minimise product support. SRE has a dedicated slice of capacity to Operational support tasks (50% as a guide) and the rest spent on operational efficiency and improvement activities (automation, process improvement, root cause resolution), which is that same as a ITIL/ITSM Problem Management role.
Team Structure: Development & Tiered Operational team approach – Customer base and support demand have outgrown single operational team. Layered support can be traditional (iTIL) or split based on customer need/product/location etc. Focus on formal workflow and reducing handoffs between teams