Platform Team Pattern
Table of Contents
Pro - Easier to staff
Platform teams are typically the easiest to understand (everybody is working on Android, or everybody is working on microservices in node, etc.). Since the tech stack is very explicit, recruiting is more manageable (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, interview (everyone has the same background knowledge), and cover from a staffing perspective.
Pro - Knowledge sharing / Training / Mentoring
One tech stack means everyone should be able to share knowledge relevant to the rest of the team. Training (in-house, personal, and external) is easier to think about because it applies to everyone.
Mentoring is usually a bit easier, as the team will likely have people with more expertise, and they can help teach those with less expertise. Sure, that’s true for nearly anything, but one tech stack helps limit the expertise needed.
Pro - Developer morale
In my experience, this is the team pattern that developers advocate for most often. There are many reasons for it (identified above), but I think it’s also a “these are folks that are doing what I’m doing” thing.
Con - Product Parity Is Harder
If you’re releasing across web/mobile and 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 them in a platform-agnostic or platform-oriented way. Typically, platform-oriented teams have the most issues with product parity. All of which requires thinking about the product you’ll deliver and how it’ll impact the documentation needs of your support teams.
Con - Easy Miscommunication Across Platforms
If multiple teams work on different platforms, you shift the burden of talking about the platform differences to your product and 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 probably increasing your external “relations” (if not outright dependencies). Do you plan on delivering both platforms to the market simultaneously? Does product parity matter from a sales perspective? What about from a support/help desk perspective? Documentation may increase as well.
Frank Blecha Newsletter
Join the newsletter to receive the latest updates in your inbox.