CIOs take note: Platform engineering teams are the future core of IT orgs

IT leaders say there are many considerations to take into account if you want to build highly effective teams.

Bring the right skills onboard

As a baseline, every platform engineering team needs to hire people who have strong communication skills, are technically proficient in software development, hardware and data, have excellent analytical and problem solving skills, and are familiar with platform engineering tools, says Atkinson. While BSH structures its large teams around specific job functions, each member of the USPTO’s nine-person platform engineering team brings a diverse skill set. “We don’t have specific roles per se,” Simms says, although he does look for a mix of core skills such as cloud and database, or data architect experience. “If we say this person is a data architect, then they’re pigeonholed. We want them to be able to pick up work others on the team are doing as well.”

However, those baseline capabilities, if not the named roles, are still critical. “Building the right team is key to success in driving critical outcomes, but the teams need to understand the specifics of each cloud infrastructure and its unique environment,” says Genpact’s Srivastava.

Simms also looks for skill sets that will prepare the organization for the future, including AI, ML, and chaos engineering. Currently, the USPTO’s platform engineering team is actively testing an AI capability that can detect performance constraints and address them by allocating more storage, for example, or adding more CPU or memory resources, or moving data from one repository to another.

“AI is 100% disrupting platform engineering,” Srivastava says, so it’s important to have the skills in place to exploit that. “As an example, infrastructure, storage, user authentication, and rules creation can all be pre-automated, which results in significant productivity improvements.”

Develop strong team culture where failure is an option

You can’t have a successful platform engineering team without building the right culture, says Jamie Holcombe, USPTO CIO. “If you don’t inspire the right behavior then you’ll get people who point at each other when something goes wrong.” And don’t withhold information, he adds. When something bad happens, expose it right away so others can learn from it — or provide solutions. There may be someone on another team who has seen the issue before and has a fix. “But if you’re not open and transparent, you won’t get speed to resolution,” he says. 

CIOs should also allow platform engineering team members to learn by failing at a small scale. To provide those opportunities, leaders need to break big projects into small chunks. “If you give an immature team a complex task, that’s the leader’s fault,” Holcombe says.

Building high performing teams starts with training, Menekli says. “We trained our platform engineering teams on what operational excellence and cost optimization mean. Then we trained the application teams to bring them onboard as well.”

Form collaborative partnerships with the business

Collaboration is essential to support the product groups that platform engineering teams serve. While the USPTO has some 200 applications for the most critical ones that are large, complex, and have a lot of releases, Simms assigns a team member to attend the product team’s scrum meetings and stand-ups. “They work alongside those teams to make sure their needs are understood, and to enable developer self-service capabilities,” he says.

Menekli adds that some members of BSH’s three platform engineering teams, which provide services for SAP, cloud, and workplace applications, are embedded into the product groups to provide architecture, security, technical, and operational governance guidance. “We also guide them on cost optimization,” he says.

PwC took a slightly different approach. “Platform engineering teams can be embedded within the IT department, but we believe the tasks should be directly integrated with the product development teams,” says Atkinson. “This allows for close collaboration with software developers, system architects, and operations teams, integrating performance considerations throughout the software development lifecycle and IT operations.”

Platform engineering vs. product groups

One big decision when setting up platform engineering teams lies in deciding who ultimately has end-to-end responsibility for the product. “Do application teams get the full end-to-end responsibility or do you cut it up, give some of it to the platform teams, and maintain a balance between economies of scale and agile? This was the debate we had three years ago,” Menekli says. “If you do the former, you have bigger agility and flexibility in application development, but maybe a multiplication of platforms. At the extreme, there can be no platform engineering team and everyone has full authority over their platform.”

But with the current focus on budgets, economies of scale, and governance, having platform teams share end-to-end responsibility by closely collaborating with the product teams wins out. “Budgets are not growing in real money terms,” he says. That’s why platform engineering teams are important.”

Srivastava adds that another challenge is the ability to customize the specific nuances of each product. “What has worked for us is a hybrid model with hub-and-spoke configuration that keeps 80% standard and 20% for customization,” he says.

Before migrating to platform engineering, the USPTO had traditional project management teams. “Everyone was trying to get as many projects as they could do,” Holcombe says. “It was very waterfall-esque — very distinct and stovepiped. No one wanted to optimize on operations and maintenance.” Now there are product lines that run a service for critical things like patents, trademarks, and software that supports core areas such as HR and finance.

“Those product teams are the ultimate decision makers,” he says. If they want to go elsewhere for infrastructure services, they can. But if a product group leaves, he says, you have to spread that infrastructure cost across a smaller base. “So we’ve created an incentive for platform engineering to be competitive,” he adds.

IT executives say for the most part their platform engineering teams are still maturing, and they have a few lessons learned to share as they continue to move forward:

Communication is key. “Lack of communication and collaboration can hinder productivity and result in misalignment between teams,” Atkinson says.

Do what it takes to get the right skill sets in place. “Smart hiring and upskilling current team members are both necessary to handle the challenges and demands of platform engineering,” he adds.

Embed engineers where the need is highest. In large organizations with many products, you can’t embed platform engineers in every development team, says Holcombe, so focus on the ones that are the most critical to the business.

Scale up, then expand out. Platform engineering principles can be applied to other functions in an organization that have technical complexity, says Gartner’s Blosen. “One example would be low-code application platforms, which are provided in a self-service, easy-to-use manner for business users to deliver technology capabilities without understanding the underlying complexity.” That’s something Simms says the USPTO is considering as it expands the scope of its teams. BSH has already implemented a platform team to support an RPA platform that services business users. “We manage the platform and do the technical governance, but all of the application development and operation is done by the business department,” Menekli says. 

Don’t skimp on automation and tooling. “Failing to invest can result in manual and time-consuming processes, impacting efficiency,” Atkinson says.

Ignore security and compliance at your peril. Prioritize these functions to avoid exposing the platform to vulnerabilities and legal risks, says Atkinson.

Position teams to take advantage of AI. Simms says the USPTO has brought on skills needed to experiment with new AI-based capabilities that include predictive analysis and automation. His team is also testing an AI capability that can recognize performance constraints and address them. But while ML is proven, Menekli cautions not to let teams jump into newer technologies such as gen AI without thinking it through. “It’s expensive to use, so you need a good business case that’s valid not only for AI but any other new software that would bring new capability,” he says.

Change is the only constant. In the coming years, Menekli expects BSH’s product teams, which support the consumer journey, enterprise apps, manufacturing, and product digitization, to move out of IT and into the business. “The more business developers and analysts come into play, the less architectural and security thinking they’ll have,” he says. “The value proposition of IT will move into providing scalable, reliable platform services as well as IT expertise into those product teams.”

There’ll still be IT members on those teams, he says — they need to be the guide for business technologists — but the rest of them will be part of the business departments. “Current cost and delivery pressure on IT is making the long-used factory approach unsustainable,” he adds. “The new generation of workers also comes with a skillset that can be used to develop their solutions, and add AI and easy-to-use tools like low code and no code. Every company has to use all their employees to produce digital, one way or another.”