I almost titled this post “If You Give a Developer Source Control,” a play on the popular children’s book “If You Give a Mouse a Cookie.” If you are not familiar with the book, it is a circular tale that illustrates a slippery slope where, if you give a mouse a cookie, he’s going to ask for some milk to go with it, and once you give him the milk, he will keep asking for something related until you end up back at the cookie. It is a simple children’s story, but the cycle it portrays is much like the many cycles we see in the software development industry, such as the constant cycle between centralized and distributed computing. So, if you give a developer source control, she will ask for build automation to go with it. That seems like an obvious next step. In fact, we can look back at The Joel Test, published what seems like so long ago in the year 2000, and see that build automation is the second item, just below source control. Fast forward to now, and our definition of build automation may have evolved. However, unfortunately, many organizations are still finding reasons to deny giving the mouse the milk to go with his cookie or the developer the build automation to go with her source control.  

It is certainly not for the industry’s lack of trying. From agile with its origins in finding “better ways of developing software” to DevOps, focusing on breaking down the silos between development and operations, we have seen many movements and trends that focus on better software development practices and improving the developer experience. Yet, despite these efforts, the 2020 State of DevOps report tells us that only 42% of organizations are at a low level of DevOps evolution, and 62% are at a high level of evolution have CI/CD workflows. In this same report, the Platform Model, or Platform Team, is introduced as “A new–ish approach to scaling DevOps” and is promoted as one of the key ways that highly evolved firms have been successful in their DevOps evolution. 

In this “new-ish approach,” is the platform team the right solution 
to let developers have their milk with their cookies? 

While every organization is different, there is no one size fits all cookie, I mean answer. We will explore that question by first defining what exactly a platform team is, then identifying some considerations for whether it might be suitable for your organization. Finally, we will wrap up by providing a few suggestions for where you might want to focus if you decide to pursue the platform team approach. 

What is a platform team? 

The platform team, sometimes referred to as a platform engineering team or a platform model, takes the idea of a product team and applies it to its internal developer experience. Hence, it helps to define the platform team by first understanding that the customer of the platform team is not an external party but instead the company’s development teams. Thus, the product that the platform team is responsible for delivering is a platform for those developers. Alright, so I admit, that is a bit like using a word to define itself, but since the definition of a platform can vary, think of the product (of the platform team) as any set of internal tools, workflows, scripts, automations, etc. that enable developer self-service across the organization. And ultimately empower developers to meet their customer demands faster and more efficiently without having to manage or understand all the underlying complexities that may exist in the platform. One final critical defining factor with a platform team is that the team is non-fungible. There is no definitive end date or milestone where the product ships and then the team disbands. As development tools are constantly changing, the platform team should always keep up with its customer’s demands and improve the platform. 

How do I know if I need a platform team? 

With the definition out of the way, how do you know if a platform team is a worthwhile endeavor for your organization? Imagine pitching a new product team to leadership to build a product that did not directly tie to the company’s strategic mission, no defined ending milestone, and no immediate customer-facing ROI. Yeah, you wouldn’t do that. Before you run off to pitch the platform team concept, here are some questions or considerations that you should make to help frame the value to the organization. 

• What is your organization’s current developer experience? Conduct some surveys and interviews to get honest feedback from your existing developers. If you have developers leaving your organization, conduct exit interviews. Turnover is expensive, as is attracting new talent. If your product is losing customers, you would want to get to the bottom of why. Do the same with your developers and make a list of opportunities to improve the developer experience. 
• Look at how your organization is performing on the 4-key metrics and identify where you have the opportunity to improve. The 4-key metrics, as defined in Accelerate: The Science of Lean Software and DevOps, are arguably the best research-backed, real-world way to measure the effectiveness of your organization’s software delivery capabilities that directly impact overall business performance. If you do not currently measure these, you can probably get a decent baseline by interviewing some of your development and operations teams. If you already measure these, then you are ahead of the game. However, it would help if you still interviewed these teams to identify opportunities for improvement and get to the bottom of discrepancies across groups. 
• Does your organization already have an existing team of architects, an architectural review committee, a change approval board, or some other group of senior technical individuals who are not aligned with an individual product team? If so, you may already have the right people on the team to build your platform team. Take some time to evaluate what these individuals/teams are doing to provide value to the organization. Unfortunately, I see many organizations where these individuals and teams are bottlenecks because they insist on owning specific processes and tools, or their primary job seems to be telling development teams what they cannot do. Consider that these team members should empower your development team’s iteration speed, provide solutions to common problems, and generally empower your development teams to self-serve. After all, these individuals are in their role because they have been identified as top technical performers. 

Where do I start with my platform team? 

Suppose you followed through on some of the above items or just skipped them altogether because you were already convinced that your organization needed a platform team. In that case, you likely have many ideas on how a platform team could be valuable to your organization but may not know where to start. Once again, there is no one size fits all approach I can give you here, but the following are some ideas for where you might start. 

• Measure the 4-key metrics. It is a great idea to start here because it will give you a great way to measure the platform team’s value as they roll out their product. 
• Provide continuous integration/continuous delivery (CI/CD) capabilities, or as I referred to this earlier as build automation, to your developers. Or, as you most likely already have some CI/CD capabilities, start expanding the level of self-service that your development teams have with your CI/CD platform. 
• Pick a common problem, like observability, and provide a universal solution. For example, a good observability stack includes capabilities like logging, monitoring, and alerting. Start small, use the 80/20 rule to prioritize features, and then measure adoption and get feedback often. 
• Make security and compliance easier. It is likely that you already have some processes for ensuring that your software is secure. Whether this includes steps like manual code reviews, penetration testing, code analysis, or security scanning software, look for opportunities where your development teams do not understand the rules and governance or are facing bottlenecks waiting on support from other teams to implement capabilities. 
• Consider how your developers must interact with infrastructure, whether development, testing, or other environments, and what barriers they face in that process. Then, look for ways to make this process less painful. 
• Do not neglect training. Sometimes the best way to make teams more efficient is to educate them on using the tools and capabilities you already have. Educating and training your organization’s developers should be an essential part of the platform team’s job. 

What do you think? 

Are your developers still asking for milk to go with their cookies? Is the platform team a must-adopt approach for your organization? At UDig, we have worked with organizations at all levels of maturity. As a result, we know that there is always an opportunity to improve your software engineering capabilities, whether that comes through adopting a platform team approach or through simpler, more incremental investments. If you would like to discuss implementing a platform team or other ways to improve your organization’s software development capabilities, please reach out via the UDig website or LinkedIn; we would love to talk.