Platform Team Pattern

Platform teams are made up of developers that are all working on the same platform (e.g. iOS, Android, Node, etc.) using the same technology, tools, and have one type of delivery artifact.  Examples of delivery artifacts include an app (for an iOS platform team), a microservice (for a Node Server team), or a web app.

Platform Team Pattern Diagram

Pro – Easier to staff

Platform teams are typically the easiest to understand (everybody is working on Android or everybody is working microservices in node, etc.).  Since the tech stack is very explicit, it’s also easier to recruit (e.g. everyone can phone screen in theory).

Pro – Technology alignment

When you’re working in one tech stack, it’s easier to cross train, easier to interview (everyone has the same background knowledge), and easier to cover from a staffing perspective.

Pro – Knowledge sharing / Training / Mentoring

One tech stack means everyone should be able to share knowledge that is relevant to the rest of the team.  Training (both in house, personal, and external) is easier to think about because again, it applies to everyone.

Mentoring is usually a bit easier, as the team will likely have people that have more expertise and they can help teach the folks with less expertise.  Sure, that’s true for nearly anything, but one tech stack helps with limiting the tech expertise needed.

Pro – Developer morale

In my experience, this is the team pattern that developers advocate for most often.  There’s a lot of reasons to it (identified above), but I think it’s also a “these are folks that are doing what I’m doing” thing as well.

Con – Product Parity Is Harder

Typically, platform-oriented teams have the most issues with product parity.  If you’re releasing across web/mobile and also are sticking with native, you’ll have at least three types of platform teams (web, Android, iOS).  Usually there are platform differences – definitely in the case of web vs. mobile, but also frequently in the case of Android vs. iOS. You’ll have to talk through if you want those differences, and if you want to solve it in platform-agnostic way or a platform-oriented way.  All of which requires thinking about the product you’ll deliver, and how it’ll impact the documentation needs for any of your support teams. 

Con – Easy Miscommunication Across Platforms

If you have multiple teams working on different platforms, you shift the burden about talking about the platform differences to your product and/or technical leads.  Will product stories be written differently depending on the platform?  Will different product owners write the stories differently (likely) and then not coordinate (maybe)?  You’re likely increasing your external “relations” (if not outright dependencies) .  Do you plan on delivering both platforms to market at the same time?  Does product parity matter from a sales perspective?  What about from a support / help desk perspective?  Documentation may increase as well.