Running an Effective Mobile Team, Part 1

When talking about team effectiveness, the first thing to consider is what an effective team looks like.

Predictable. The team has a regular cadence. They can set goals and expectations around deadlines.

Clear on priorities. When you ask people what is most important and why, they can answer.

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

Automated. Time has been invested to automate repetitive tasks, reducing the number and amount of time spent on “team chores”.

Accountable. People can have expectations of each other. This includes leadership.

What constraints do we have on mobile that effect these things?

• We ship compiled code. No backseys.
• Leadership is often dominated by iOS users, so Android can feel like an afterthought.
• We lack a clear model for mobile infrastructure. This is one of the things that makes the question of whether to have a mobile team or pods hard.
• Testing infrastructure is behind. Android was untestable by design. Still find things like jacoco (test coverage) doesn’t work with expresso (UI testing) out of the box. As apps got bigger, we need to consider architecture in a way we didn’t have to before.
• Often these things result in mobile being a bit disconnected. Server side changes can break clients, and then mobile teams take the heat from users and leadership. This can lead to resentment, which makes accountability hard.

Often people look to technical solutions for this. They think that the mobile team could move faster if they just adopted some latest new shiney, like, say, ReactNative.

But…

• We still have to ship that code. Adding more dependencies means you have to debug them (and increases build times).
• We still have to have the app infrastructure… UI code is just a small part of the problem.
• That UI code still has to look right and perform well on both platforms.
• We still have the same problems with testing, but now the CI server takes even longer.
• Teams will resist accountability for a strategy that they don’t buy into.

I’m kinda hating on React Native here. For some teams it makes sense. Artsy wrote about how they use it for an API driven iOS app, which was interesting. So basically if your app mainly displays content. It may not make sense if you:

• Need a great offline experience.
• Interact heavily with platform APIs (e.g. media etc).
• Have reasons to really care about good performance. E.g. text editing, or large amounts of data (notably all the issues here are performance issues that don’t arise natively using standard good practises).

Whilst the Artsy article made a decent case for iOS in certain circumstances, it’s not a good case study for a genuinely x-platform experience.

In the long run, we hope to extend this way of working as we start work on a React Native Android client.

…

To really shine with React Native, you need native experience. JavaScript has not eaten everything yet. However, you don’t need a team of native experts. For example, we expect to be able to get quite far with Android support based on our work in React Native, but to make it amazing, we will need someone with history and context in the space.

Android has some different performance issues, so I wasn’t surprised to see this comment in an otherwise glowing report about ReactNative on iOS.

Unfortunately Android devices have much greater variance in performance and tend to trail significantly behind iOS. We were able to get our app running fairly quickly, but the performance — specifically on touch events was not at an acceptable level even on higher end devices. In addition at that early stage there was still a lot missing in the React Native Android feature-set that would have made getting our prototype to production level more time consuming than our iOS effort.

So if React Native isn’t the answer, what is?

The issues facing most mobile teams are not technical, they are personal. If you are the size of Facebook or Google, you can afford to try and create technical solutions to social problems. The rest of us can’t.

This series continues next week – we’ll cover creating predictability on a mobile team.