My partner and I had a hellish move recently. We were lucky in that our landlords are nice, reasonable people, and unlucky in that they were quite disorganized and hadn’t done everything they needed to, like ordering furniture and thoroughly cleaning up after the last tenant.
So as this played out, living in a hotel, in a new (to me) country, trying to juggle his new job, my existing job, and the absolute chaos of everything, our differences started to play out.
My partner, a software engineer, said “they should do these things.” I, an engineering director, started to develop a risk mitigation strategy.
Let’s talk about automation. This seems like an out of place thing in this series. Predictable! Prioritized! Connected! Accountable! These are all fuzzy people things. Automated sounds like… more fun? Like Proper Developer Work?
Automation is like documentation, but developers might actually write it.
Without automation:
It’s easy to have random esoteric things that few people know how to do.
It’s harder for others to take over process like builds.
A lot of time is spent on manual processes that are straightforward to reproduce (e.g. basic QA).
Either bugs are missed because this is inconsistent.
…or at takes time that could be better used elsewhere – e.g. more complex scenario testing for QA professionals.
What can we automate?
Automate builds. Seriously. If you commit to predictable releases, you will end up investing in automation to maintain that process – otherwise it’s too painful. This includes things like scripting translations etc. There’s a chicken and egg problem there, where push back on regular releases can be lack of automation. But I’ve found there are few things more motivating for motivation than regular releases.
Write tests. I can’t believe I’m still trying to convince people tests are important in 2017. One of my current work hobbies is noticing GitHub threads with clear testing instructions for reviewers and commenting “this would make a good automated test”. Other common GitHub comments from me: “can you add some tests, please?” And “I like these tests.”
Add linting. I believe in Styleguides. The main purpose of styleguides is this: we have a style guide so that we never need to discuss it again. I once witnessed a centithread argument about whether it should be var == thing or thing == var. Who has time for that kind of nonsense?! Have a style guide, automate it so that Android Studio or XCode apply it automatically, and your code review system shows any deviations – so that your reviewers don’t have to. Code review – done well – is a great collaboration tool. In a dysfunctional environment, it’s the first place conflict will show up. One positive (but insufficient) step towards productive code review is eliminating nonsense arguments about spacing etc.
Tooling on mobile is still behind, but it’s getting better. Things can be a bit more painful to setup, but if you make the time it pays off.
Part of it is having that time. When everything is so frantic, there’s no time to automate painful things to make them less painful.
The anti-pattern of automation is over automation. I’m sure you’ve worked with people – or been that person – who crafts some elaborate system that only they can use to address some minor problem (that only they can see).
Pragmatically with automation, taking the most painful or tedious, hard to socialise parts and making things better is the place to start.
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.
Clear on priorities: When you ask people what is most important and why, they can answer.
Problem: Leadership is often dominated by iOS users, so Android can feel like an afterthought.
If you ask a person on your team what your top priority is as a team, can they tell you?
Can they tell you why?
Can they talk about how their work fits into it?
…or if it doesn’t?
Do your actions, and the actions of leadership around you align with that top priority?
Do your team priorities align with your company priorities?
The challenge of team priorities is often not deciding what they should be, but deciding what should come first, and being consistent in your actions so that they align with that.
Let’s break it down.
What should your priorities be?
A sustainable product has both growth and retention.
Because mobile is growing and desktop is declining, your mobile experience (this includes the web, too, not just native) needs to effectively onboard new users.
The era of “there’s an app for that” is over. Of course there’s an app for that, but does that app merit the space it takes up on my phone?
The users who install your app on their device and use it every day are your engaged users. They’ve made it past onboarding, they’ve figured out what it’s for – how do you maintain that engagement?
Is there anything broken that might drive people away?
Different products have different priorities, but it’s important to consider both your new user experience and your existing user experience. Over time, to be sustainable, you have to balance both. If you onboard people into a bad experience and drive them away, you’ll never get them back. But you do need to focus on your onboarding experience in order to grow.
There are two apps I’ve abandoned For Cause. Nike Fuel and Duolingo. Note they are both gamification apps. The same thing happened on both of them – they lost my streak. The Nikefuel was a hardware failure, and Duolingo poor saving of state after an unexpected internet disconnection.
Actually another example of that is WordPress, years ago, before I worked at Automattic. I lost a blogpost on my iPad. I was taking notes during a talk, so there was no way to get it back. I stopped using the app to write and switched to the notes app (and later Simplenote).
People complain, a lot. Technology is fallible. But whatever your product, you need to understand what is your UX catastrophe. For a writing app, it’s content loss. For a gamification app, I would say it’s unfair losing.
What should come first?
What comes first is a balance between company, team, and the various possible focuses. New users? Existing users? Money? Or growth?
There can only be one top priority. But, that doesn’t mean that the team only works on one thing. Every team has to balance maintenance and feature work. But you need to carve out the space for your top priority to succeed. You usually can’t say no to everything other than number 1, but you need to say no enough that number 1 happens.
How do you communicate your priorities?
Priorities need to be communicated frequently, and with reasons and progress. You communicate priorities when you say no to things, and you communicate priorities in how you spend your time.
I like to use data to tell a story. If you can measure something, then you can use that measurement as an indicator of success. But since you manage what you measure, you need to be careful that you consider the experience holistically – looking at multiple metrics make it less likely that something will be gamed.
The current top priority of my team is a project we’ll call “Open Sesame”. We communicate why this is a priority using two main pieces of data:
User success rate with this action.
Support volume from users trying to achieve this action.
These two numbers show up every time we discuss it. They show up in our bi-monthly “what are we doing” post. They show up in our “what this project is” posts, and I bring them up every time we talk about this project.
Usertesting videos of users struggling to complete this action round out the numbers, and help engineers empathize with the problem, and the people it affects.
Aligning your actions with priorities
I started managing a designer this year for the first time ever. And like, I have no idea how to manage a designer, so unsurprisingly I screwed up a bit at first. And the way that I screwed up was that I was periodically asking him to weigh in on certain things that I thought were small, as he tried to make progress on the highest priority project for the team.
It turns out, the things I thought were the design equivalent of code review were… a lot more work than I ever imagined. So as I paid attention I realized that the design things that seemed “small” were really much more involved that I had imagined. Also, eventually he told me that this was stressing him out. We aligned his work better and let things that aren’t our top priority wait, for now.
One thing that can be a challenge for mobile teams in particular, is that right now Android is the largest and the growth platform.
Depending on what you’re building and your market, Android might not be your biggest platform, but it’s definitely an important one. However tech company leadership is often dominated by iOS users. If you talk about how Android is important, but only file iOS bugs, people will get the message that iOS is more important, whatever it is that you say.
Predictable. The team has a regular cadence. They can set goals and expectations around deadlines.
Challenge: Shipping compiled code.
Most advice about improving team velocity talks about continuous delivery. Ship constantly! As many times a day as you call! Roll back if you need to! Tell us about that time you broke prod! YOLO!
Here’s a fun story about a simple mistake on an iOS build. An early build of the – much anticipated – GMail for iOS broke notifications, popped up error messages constantly, and had to be pulled from the store. I worked next to that team at the time (had worked on that team, even), and I remember it, viscerally.
That was 2011, and things have improved since then. We have better Continuous Integration, and we know which build is signed with what certificate. The app store has improved, too, and wait times are shorter. You can expedite an emergency bug fix. Google Play even has staged rollout (how did we live without that?) although iTunes still doesn’t. You cannot rollback an app in the iTunes store, or on Google Play.
With auto-update, it’s easy to think that everyone gets the latest version. This is not true. People can turn it off, be selective about what they update, or go several days without connecting to WiFi. We have to remember that the typical tech worker on their high end device with fast internet at work and at home downloading the latest new shiney is not our typical user.
The worst case scenario has got less bad, but ultimately, remains the same. There is no “lol that time I broke prod for 2 minutes!” story. There is a frantic patch and test and release and impatient waiting and in the time that takes, the vitriolic reviews from users you would never otherwise hear from. Reviews that insult everyone on the team and suggest you all need to be fired (genuine paraphrasing from reviews I have read about things I have worked on).
One small mistake. Several hours to fix. Months of trying to rebuild your star rating.
A regular release cycle is the core of a predictable mobile team.
However this is not just about the decision to release on whatever cadence – but everything that goes into it.
How do you build confidence in that release?
What is your automated testing like? This will catch bugs as you write them.
Do you have manual QA? Is it thorough? Do you ever find bugs that should be caught in QA? This will catch bugs after you wrote them, but you want to be confident they are caught before you release them. It’s great for discovering weird User Experience edge cases that happen with humans (but not so much with automatons). Tell them ahead of time what’s coming up so they can think about how to test it (and look out for it).
Do you have internal users? Do they actually use the app and tell you about their experience?
Do you have beta users? Do you communicate with them?
Can you commit to the release train?
The thing that will most easily derail your release cycle is trying to stick things into it because you don’t want them to wait until the next release. This is why an effective release cycle is 1) short and 2) rigid.
Short because people are more willing to wait if they don’t have to wait long.
Rigid because patching things in and hoping for the best will result in a delayed and buggy release. You might get away with that once or twice, but not every time, and ultimately breaking those rules undermines them.
Finally, you also have to be willing to kick things off the release train. Feature flags help with this, but ultimately you need to be willing to say about the feature that’s causing problems in the alpha (and FSM-forbid, the beta) this is not ready to launch yet; it will have to wait until the next one.
Perceived Velocity
A common complaint about mobile teams is that they are slower. Mainly this is not about how the writing of code is slower, but that the releasing it to the world is. Even with a rigid two week release cycle, code can be around for up to a month before it goes out in the world. A PR review takes a little longer, it misses the train and voila… two more weeks to go.
A regular release cycle means you can communicate when those changes will be out in the world. A regular release cycle means that leadership (and users!) see improvements regularly, even if it’s not their pet one – yet. They know it’s coming.
Deadlines Goals
I don’t really believe in deadlines. I believe in prioritization, scope, and regular releases.
But I do believe in goals. An effective team can set themselves goals – and meet them.
It’s hard to achieve goals surrounded by chaos, which is why the rhythm of a regular release cycle helps.
Beyond that, prioritizing – what is most important and why? And scoping – what is a unit of measurable improvement? Go a long way.
These are not rocket science. But they require much of the same discipline required to make release cycles regular. A commitment to the realistic, and a willingness to say no.
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.
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.
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.
I’m working on a talk about running effective mobile engineering teams – I’d love to know what questions you have about this, what you worry about when it comes to mobile teams in your organization, and what you’ve found most helpful to communicate about them. Comments or email or DMs on Twitter welcome!
Title: YOLO Releases Considered Harmful – Running An Effective Mobile Engineering Team
Organisations often worry about their mobile teams. Sometimes they are a bit separate. There’s often this inexplicable hostility to mentions of “React Native”. Why do bug fixes take so long to get to production, and what are all these certificates for, anyway?
In this talk we’ll cover the realities of shipping compiled code, the woes of the app stores, and the infrastructure challenges we haven’t figured out yet. You’ll leave with a better understanding of the realities your mobile teams may be struggling with, and some strategies for how to help them – and your organisation – build an effective mobile team that ships regularly. And yes, you’ll finally understand the React Native argument, too.
The harsh truth is that no-one cares about your idea the way you do.
I tell you this, not to be mean, nor to suggest your idea is not brilliant, or that you are somehow lacking in your communication of it… just because if you think that someone else is going to fill in when you’re lacking, you’ll be disappointed.
There’s a lot of great ideas that don’t come to fruition because the person who came up with them is not pushing them forward. Seriously, one of my friends is an idea machine, but she lacks follow through. This post is the result of a conversation where she admitted, that she thought she’d come up with this idea, connect some people, and those people would take over and make it happen.
You don’t need me to tell you this: that project has not yet got off the ground.
Another friend, who describes himself as a “spark lighter” (love this) and I interrogated her ideas of “leadership”, and it seemed like she was confusing leadership with effectiveness.
Here’s what I think leadership is: it’s being able to articulate a vision. But more importantly, it’s putting in the blood, sweat and tears that are needed to make that vision a reality. It’s accepting that the only person who is passionate enough to take what you’re doing to the next level is you. Ironically, this is the only way (I’ve found) to get people on board and helping you.
Being effective helps (doesn’t it always?), but it’s not necessary. The real challenge of leadership is not managing todo lists, staying on top of email, or mastering interpersonal-communication. It’s putting yourself out there – believing in something enough that you invest yourself in it, and don’t let up until you make it happen. Honestly, I don’t understand how a person who won’t do that for their own idea can think someone else will.
If you want to be more effective, read 7 Habits. If you want to be a leader, recognize that it’s not making lists – it’s doing something. So, pick an idea that has the potential to keep you up at night… and start making it reality.
This is where I live. In this space between what I could achieve in a given day, or week, or month… and what in my imagination I’m capable of.
Of course in my imagination I never kick back and watch a movie with my friend and a bottle of wine (honestly, this rarely happens in reality either… probably why I felt so horrible this morning). I never get burnt out from training hard and sleep for 10 hours straight. I never say “You know, I’m not having a great week but one thing I could control is my hair” and bunk off the things I should be doing to get a haircut. I never get so overwhelmed by “the list” that I have to take time to breathe deeply and try and decide what my priority one is. I never stare at the blank page where I’m supposed to be outlining the plan for my upcoming talk and feel completely and utterly uninspired. In my imagination, I don’t get things to nearly finished, get interrupted and struggle to come back to them.
Other people don’t feature much in my imagination. Whilst I like working with others and I’m pretty social, there’s such a huge overhead and level of unpredictability when other people are involved. I struggle with this because it’s impossible to predict and hard to plan for. Because everyone manages their schedule and their list differently, it’s difficult to know when you should remind someone and when that would imply that they’re disorganized.
I’m the same, as usual when I’m a little stressed out the first thing to go is my email. So if you’ve sent me something that is urgent, or very quick to reply to, you’ll probably have a response. If not – I’m going to level with you here – it could be a while. And so there will be a disconnect if someone has sent me something they perceive to be urgent, but didn’t seem that way to me.
It’s not even February, but my inbox is out of control. I’m so behind on “the list” I can’t get a handle on what needs to be done anymore.
What do I need? A couple of days by myself to pull myself and my organizational system together.
I’m not going to get this.
So what’s the alternative?
Saying no.
To the endless demands that show up in my inbox, I’m sorry but I’m at capacity right now. I expect to get back to you mid-February.
To other things, too. What more can I eliminate? How can I better manage my interactions with others so that they are not time-sensitive? What’s the time commitment above which I should delegate (below which the delegation is more effort than I save)?
Other people are better at this, and I keep finding myself in situations where they say no and it falls on me or a commitment is broken (as was the case this morning). I need to balance my need to be firmer, with the fact that I hate to let people down.
Cookie Consent
We use cookies to improve your experience on our site. By using our site, you consent to cookies.
