Feature Team Pattern

A feature team typically is composed of a Product Owner (in an Agile shop), along with developers working on multiple platforms focused on delivering product features.  This is more common in a business that’s trying to deliver and maintain feature parity across web and mobile at the same time. These are the two major patterns I’ve seen:

Pro – Feature Parity & Product Consistency

Feature parity tends to be a strong desire from a market perspective (e.g. your mobile users can do the same on iOS and Android).  One team implementing and coordinating the work for a feature on all platforms makes it easier to maintain feature parity.

Product consistency is also easier because as features are implemented in the product, they go into all platforms at the same time, which makes it  easier for Product/Design/Test to help drive consistency in the app.

Pro – Less cross platform communication across teams

Feature teams should be setup to be independent and equipped to solve their problems with as few external dependencies as possible.  Since you should have all the developers you need to ship to all platforms on one team, this removes a lot of external communication.  Less communication enables faster decisions and quicker execution.

Con – Harder to staff / Developer Morale

Feature teams can be a harder sell for developers because they’re going to work with several people that aren’t on their platform, plus there may be more cross platform discussion.  In some outfits, there will be the trend to use a cross platform or hybrid technology (e.g. React Native vs iOS/Android) and use one code base for both platforms. Given the effort that developers have to invest a serious amount of time to get good on their platform (the language, the SDK, and idioms, etc.) it becomes easier for them to find another job (market demand is extremely high) than to pivot toward a hybrid technology.  If the ecosystem supports more hybrid choices (e.g. JavaScript or .Net as examples) then those developers are usually less resistant (they’re more committed to the ecosystem than the platform).

Con – Requires strong Product leadership

You can easily argue that all products require strong product leadership (you’d be right), but when delivering across multiple platforms, it requires strong product choices to make sure you’re deliver smartly to your consumers.  In the Platform Team case, it’s easier to align your choices to “what’s expected on this platform” (e.g. let’s just use the HIG), but that become more complicated when you have to make decisions across three disparate platforms (e.g. should this feature be more like web or more like iOS?).

Con – Increase test demands on the team

One of the bigger cons is that the testing effort increases as the number of platforms increase — even if you’re in a hybrid use case.  If you have a team composed strictly of developers (this is almost same as a Platform Team from this perspective), then Alice and Bob should write all the unit, integration, and UI tests needed — on their platform. However, if you have dedicated QA developer like Charlie, he may have to write tests on both platforms.  

Emphasizing team delivery vs. individual delivery is a way to overcome this, but depending on the staffing mix, it’s easily possible to have developers swamp the QA developers on a team, which can get tough fast.    

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.

Teams are People, Not Resources

I work with people

It’s not uncommon to run across folks that still use the language of “resources” when talking about people or teams. I think this language emphasizes the wrong philosophy. Optimistically this is just an engrained speech pattern in people that have been working for a long time, but I think it’s something that can change (like most habits) if focused effort is put into it.

Resources is a “nice” term when you don’t have to care about feelings, people, life, problems, or other things that are inherent in working with people.

You don’t have to care about:

  • their mom having a broken leg and needs help for a couple of weeks and they don’t have enough PTO
  • their partner having a medical issue post delivery and having to look after a new baby and their spouse
  • their child being hospitalized for three weeks and not having a medical solution
  • child care when their a single parent and their kid is sick
  • their 13 year old dog suddenly having a cancer diagnosis and being told they don’t have more than a day or two

All of those things have happened to people I have worked with over the years. Those things happen to people, not resources. At the heart of it, nearly everyone I’ve worked with has been a decent human being, deserves to be trusted, and offers something unique to the team.

None of those situations describe resources.

I think it’s as much a habitual pattern that reflects on a culture more than any one person choosing to dehumanize people. Human Resources lays people off; Human Resources talks about policies that can get you fired. People Operations focuses on effective teams, how you recruit and retain, and how people work together.

It’s a choice – I choose to work with people.

I work with People

For the past 20 years, I’ve said I work with people instead of people working for me. I’ve been a lead, manager, director, etc. and I’ve worked for my fair share of bosses. I’ve worked for small R&D teams, large contracts, startups, and large Fortune 50 firms. At any size, I believe that putting the emphasis on “with” versus “for” promotes a better philosophy about the way I want to work. Imagine meeting the kid of a colleague and saying the following statements:

“Your dad works for me.“

This implies:

  • I’m his boss
  • I supervise him and tell him what to work on
  • I determine what’s important
  • He needs my permission to work on things.
  • He needs me to determine the problems he can work on.

“I work with your mom.“

  • We are a team
  • We both have work to do to solve ourproblem.
  • She doesn’t need my permission to identify ourproblems.
  • She doesn’t need my permission to determine a solution.

The “with” statements are at the heart of sustainable teams that are based on respect — that’s where I want to work.