How to Structure a Platform Team – An Illustrative Model

Platform teams are an integral part of an IT solution delivery organization.  Every IT organization has a way of structuring its platform team based on its context and multiple considerations, including alignment with the Development or Operations of other units, position in the reporting hierarchy, business portfolio alignment – common vs. federated setup, etc.  However, one thing that is likely to be common across these structures for platform teams is that it is a common service provider to the Dev and Ops teams. It is most likely a 'horizontal' team providing tooling support, frameworks, platforms, and even standards and benchmarks for the solution delivery and operations teams.

This article describes an illustrative model to structure the platform team and outlines the team's responsibilities, metrics, and approach to Governance.

Team Structure and Responsibilities

The platform team plays a crucial role in servicing requests from the product, application, and operations teams.  The team has certain responsibilities that are aimed at providing timely services to meet the IT goals and business priorities.  Here are the key aspects of the structure and responsibilities of the platform team in this illustrative model.

• The platform team will have persistent team members with a combination of skills related to technology architecture, databases, testing, automation tools, security, and so on.
• The team will be responsible for providing common services to multiple products, application development, and operations teams.
• There could be multiple platform teams or sub-teams within a platform team – typically one or more for each of the following areas:
  • Architecture runway maintenance
  • DevOps Tooling Support
  • DB Support
  • Security – E.g., vulnerability analysis, pen testing
  • Cloud migration support
• The team could also own certain environments and provide services such as penetration testing,  performance testing, or other non-functional testing.
• The Kanban approach would be an effective way of working for the team to deliver their services to the internal teams.

The following chart depicts this illustrative model.  The Enterprise Architecture team helps the platform team with inputs to align with the planned technology roadmap. The Governance group ensures alignment with the goals and priorities of the enterprise and provides strategic direction and support.

As illustrated below, the platform team could have multiple sub-teams to provide specialized solutions and services.

Product / Work Backlog

The platform team's backlog is different from that of an application team.  It will have new items for 'development' in the context of the platform and work items related to existing services and solutions.  As can be seen, almost all of the backlog items are technical in nature and focus on areas such as migration or a technology upgrade, or tooling support. The backlog of the team could include items such as:

• Epics for large migration  (Cloud, technology, Database).
• Tech stories for architecture enhancement/maintenance across products.
• Tech stories for Database Administration and maintenance across products.
• Tech stories for common DevOps tooling and support across applications.
• Product/application-specific performance testing requirements.
• Tech stories for common security analysis and testing.
• Work items and 'tickets' related to an already provided service.

Product Owner

The Product Owner (PO) role is special in the context of the platform team.  The PO typically would be from the technology organization.  While they will focus on tech epics, they will always keep the business needs, epics, and roadmap in consideration while prioritizing the tech stories.  

The PO role could be played by the Enterprise Architect, Tech Lead or Design Lead, or other identified Tech Subject Matter Expert, depending on the tech stories.  There could be a separate PO for each platform team, depending on the scope of their work. E.g., a DBA could be the PO for the DB migration/maintenance team.

The PO will periodically sync up with the product, application development, and operations teams to understand their support requirements and consolidate these appropriately to define epics and stories for the platform teams.  The PO will also keep a tab on the tech trends and leverage industry data in defining epics and stories for new services or enhancement to existing solutions and services of the platform team.

Metrics 

The platform team in this illustrative model delivers services to the internal teams.  Therefore the typical measurements that are relevant to a service delivery team would apply to the platform team as well.  The measures would be around the quality of service, speed, service level agreements, and so on.

Given the nature of work and the services delivered by the platform teams, there could be a set of metrics that are specific to the platform teams.  Here are some examples:

• Story lead time: average time for a story from backlog to production release.
• Tech Debt reduction percentage.
• Average issue resolution time.
• Number and frequency of security incidents attributable to platforms.
• Automation/DevOps implementation maturity in the individual product or application teams.
• Satisfaction index from product teams, application teams, operations, and identified business stakeholders.

Sync up With Dev and Other Teams

As the platform team plays a pivotal role in delivering technology services to the internal teams, it often assumes an integrator's responsibility – that is, the product team takes a consolidated view of the different tech services requested by the other teams and tries to provide integrated services and optimize resources needed to provide those services.  Therefore it Is essential for the platform team to sync up with other teams on a periodic basis to understand their current needs and future challenges.

Here are some examples of the sync-up events that a platform team in this illustrative model would consider.

• Sync up sessions with product and application teams.
• Sync up sessions with the other platform teams.
• Tech work prioritization sessions with the other platform teams involving Scrum Masters, Product Owners, and Tech Leads of product teams.
• Catch up with enterprise architects.
• Sync up with the enterprise cyber security team.
• Sessions with identified business stakeholders – e.g., Portfolio Leadership, Line of Business Head.

Governance

Governance is a key component of the platform team model to provide guidance and make sure that the team delivers to the best of its capabilities.   Governance ensures that funds allocated to the platform team are utilized effectively, and the services provided by the team align with business priorities and meet the expectations of the teams consuming their services.

Here is a brief outline of the Governance structure of the illustrative platform team model.

• Who is involved: The following roles are involved in the Governance of the platform team.
• Identified business stakeholders, Enterprise Architects, Identified Tech Leads, Enterprise DBA, Security Leads, identified Product Owners, and Scrum Masters.
• What is reviewed: The governance body reviews the key aspects of the services of the platform team on a periodic basis, provides strategic guidance, and suggests course corrections were found necessary. Typically the following aspects are discussed.
  • Progress against planned technical capabilities, enhancement, and delivery milestones.
  • Funds/resource utilization
  • Planned tech upgrades/migration (architecture, platform, cloud)
  • Key observations in Audit reports.
  • Security, observations, and recommendations made by the cyber security team and the resulting action plan.
  • Key feedback and action from team retrospectives.
• What is measured (Metrics):  As part of Governance, the team reviews the key metrics indicating service quality and delivery effectiveness.  Here is a sample list of the metrics used in this illustrative model:
  • Compliance metrics
  • DevOps maturity
  • Tech Debt Reduction
  • Automation percentage
  • Mean time to deliver service – across different categories of services provided.
• Frequency: The Governance review could happen every quarter on a cadence.  It could also be conducted on the completion of key milestones.

Other Considerations

• Single point of reference: This illustrative model uses its JIRA Board as the primary source of information for planning, status reporting, and action tracking.
• Transparency: The team maintains full transparency of its work, challenges, resolutions, and plan of work by making these visible to the identified stakeholders.
• Empowerment: The organization in this illustrative model fosters a culture of empowerment and innovation.  The teams harvest creative ideas from their members by seeking their feedback and suggestions on a regular basis.
• Learning: Continuous learning is crucial for the platform teams to bring solutions and services aligned with business needs and technology trends.  The team promotes continuous learning by providing ample opportunities for its team members through internal learning interventions and external training programs.

For the team to keep pace with rapidly changing technology and provide state-of-the-art tools and solutions, the team implements a structured program to scan and understand technology trends, market solutions, and platforms.  Using this understanding, the team designs its next set of solutions and services.

Conclusion

Platform teams play a key role in an enterprise to provide technology services to the IT organization. The structure of the platform team could vary from one organization to the other. The aspects discussed above in this article are relevant to the typical platform team structure.