Running an Effective Mobile Team, Part 4: Building Connections

Connected: People work together and take an interest in each other (this doesn’t mean everyone has to be friends – but they are friendly).

Problem: We lack a clear model for mobile infrastructure. This leads to discussions like whether to have a mobile team or pods.

Regardless of what your “mobile teams” look like – product pods? A small team that focuses on mobile? Some new configuration that hasn’t been Think Pieced on Medium yet? You have a challenge of connection.

In a dedicated mobile team, how do mobile engineers connect with the engineers working on front end features? Or the engineers developing the API? Was the API written with mobile in mind? Or does it… work on someone else’s machine?

Often the answer to this is to have product pods. Which is great – people have been known to build an API that actually works well for mobile this way. But a good app is not just a collection of features. It’s an architected thing that has components that are shared throughout – some notion of user identity, a networking layer, a database. Ideally it follows some standard patterns that are – gasp – possible to write unit and integration tests for. It’s also going to need to be mindful of memory management – mobile is a constrained experience not just by screen size.

There’s a joke about micro services. It goes:

“I’ve split the application up into seven micro services”
“So you have seven teams that hate each other?”
“How did you know?!”

Now this isn’t a good way to run any team. But there is no micro services architecture for mobile. Regardless of your configuration, people are going to have to – revolutionary idea – talk to each other. When you organise teams to better facilitate some kind of communication, you make the other kind harder.

Since there is no micro services architecture for mobile, there is no way for one team’s architectural decisions not to affect the rest of the people working on mobile. Bonus! We are still evolving our patterns and standards for architecting mobile applications. There’s not currently the concept of a “mobile infrastructure engineer”, and great mobile engineers are usually more product focused. How’s that move to VIPER going? What percentage of your iOS app is now in Swift? How’s that networking layer written 4 years ago or so holding up?

Let me guess: behind schedule / around half / err… not so well.

OK, but we can’t make people like each other, so now what?

Align Incentives

The best way to get two teams to fight is to give them conflicting incentives. Incentivise one team to Ship Maximum Features As Fast As You Can and another team to Maintain Zero Crashes, sit back with the popcorn and watch the show.

If you incentivise one team to move metrics around user engagement and happiness, and another team to maintain sustainable execution… well it will probably be less like robot wars and more like a functional work environment.

Invest in Infrastructure

If your app is badly architected, everyone will pay for that every day. If your networking code is a mess, it will bleed through your entire application. Invest in the things that make everyone more productive and guess what? Everyone will be more productive! These things are often harder to explain to product and business, but every team should have some maintenance time – be strategic about how you use it.

Build a Team

The easiest way to build relationships quickly is to unite against a common enemy. This is a short term strategy and not conducive to long – or medium term – good work environments. Your team is not just the one denoted by the org chart. A team is a group of people who work together to achieve a shared goal. Ignore the org chart for a moment, and think about something you’re trying to achieve. Who is on your team? Who do you need on your team to be successful? Reach out to them.

Read the next part, on automation.