Tag: mobile

  • Phase 1 of Hiring, Getting from 0-30

    Phase 1 of Hiring, Getting from 0-30

    Towards the end of 2017, we reopened hiring on the mobile team at Automattic which had been shut since the start of the year as we got things in order. I think of this as phase 1 of hiring on the team – nailing the basics of the process, and making some progress with diversity numbers.

    An up front note about diversity: Diversity is more than gender, and gender is not binary. However whilst acknowledging the limitations and flaws, we can use gender as metric as to how our hiring process is doing with respect to inclusion. We can use it as an indicator for diversity at every phase in the process, and use that to identify where we can improve the process for everyone.

    For reference, I was the first woman on the team, which was ~24 people when I joined at the end of 2016. When we opened hiring, there were two women, although both in leadership positions – this helps a lot.

    The TL;DR of how our funnel looked at the end of phase 1 is this. You can see that using our raw (and flawed) metric, the diversity improves at every step in the process. This makes sense given that data shows women hold themselves to higher standards when applying for jobs.

    Q4 20173 people
    Q1 20185 people
    Q2 20182 people
    Q3 20185 people
    Q4 20181 person

    Revamping the Process

    Whilst we didn’t change any of the steps in the process, we did revisit each one and improve it.

    • We revisited our job postings to appeal to a broader spectrum of people, emphasising impact and collaboration. The job postings now score 95 and 96 in Textio.
    • We diligently posted a hiring stats update each month (the way we review all our projects on the team regularly!), breaking down progress at each step of the process. Monthly was a good cadence for this – it allowed us enough data to make good decisions, but short enough timeframes to meaningfully iterate.
    • We standardized code tests with checklists of what we were looking for, what was necessary, what was nice to have. This also helps us give better feedback.
    • At Automattic, everyone who is hired does a (paid) trial project where we work together to determine mutual fit. We treated our trial projects as a pre-onboarding. Every new hire has completed a shippable feature and has meaningful interactions with at least three people on the team.
    • Previously, onboarding had been inconsistent and hit-or-miss. We got serious about onboarding, identifying good first projects and teams, and working to make sure every new hire felt welcome and set up to succeed.

    Successes

    • 31% of our new hires are women.
    • We added teammates in six new countries: Chile, Turkey, Germany, Serbia, Hong Kong, and Ireland.
    • 63% of new hires speak English as a second language.
    • We added three languages to the ten already spoken on the team (helpful for internationalization!): Hebrew, Serbian, and Polish.
    • Outreach:
      • WordCamps – we presented at WordCamps in Montevideo, Montreal, and Taipei, as well as WCEU and WCUS.
      • People from the team also presented at various local meet-ups and ThatConference.
      • We hosted a Women’s Brunch at 360AnDev.
      • I did my usual slate of presentations and started writing for Quartz.
      • Eli (the new mobile lead) and I did a webinar with Women Who Code in both English and Spanish!
      • I did an interview with GitPrime about our hiring and onboarding process, and Amanda followed up by sharing her own experience.

    Areas for Improvement

    Whilst we’re pleased with the progress we made in phase 1, it’s clear we have more work to do. 2019 marks the start of phase 2, where we will be focusing on:

    • Racial diversity.
    • Under-represented geographies based on our user base: APAC and Brazil in particular.
    • LGBT.
    • Gender diversity.

    We’re also keen to take advantage of the openness that working in Open Source allows – so we’re supporting our teammates in sharing more about their work online and IRL at events.

    If you liked this post, you might also like being part of our team: we’re hiring.


  • The State of WordPress Mobile

    Slides from my WCEU talk on the WordPress mobile apps, you can see the full version with speaker notes here. It’s a recap of what shipped in 2017 and explores our themes for 2018.

    Mega thanks to my colleague Matt Miklic who made the deck.

  • One Year as 📱👑

    One Year as 📱👑

    One year ago today, I tweeted:

    Three weeks after that, when my support rotation ended…

    As I recall, my friend James described it as “the most low key new job tweet”. I pointed out the extremely descriptive emoji for my job title, and he said “I felt both enlightened and informed”.

    I think he was being sarcastic.

    I hear the thing to do is to write one of those omg I have a new job and I’m so excited posts but that’s not my style. Not that I wasn’t excited – I was, I still am – but it always seems a bit dangerous to be excited in public about something I haven’t proved I can do yet.

    In the final year of my undergrad, I was a teaching assistant. I remember this dude from my course – I don’t think I knew his name at the time, and if I did it’s long forgotten now – said “why are you a TA?”

    Just the usual drive by misogyny, I guess. But it’s the kind of question I worry about, the kind that I don’t want to invite (where invite is… showing up and doing my job?) until I have a good answer for it myself.

    And the timing. I was coming into this out of a failed startup. I’d taken ~6 weeks between finishing my job search and starting, and gone all the way to Tuvalu to escape everything. I was still kinda wrung out from that experience. The US election results came in, and the world seemed to be ending. I finally believed Brexit would happen. It didn’t seem like a time to be excited about things at all, let alone in public.

    Anyway, I started with three weeks in support. This was eye-opening, as I saw the ways in which the app was confusing and failing our users. The queue was embarrassingly long, I worked on better FAQ answers, trying to get better, faster, answers to the people who had a simple question that they should never have needed to ask at all. It is weird, and more than a bit intimidating, to start in a job that I didn’t apply for and didn’t think I would be good at. But perhaps that’s the point – I learned a lot.

    My job title was emoji for a reason. A way to own my responsibilities, but in a cute, not-too-threatening way. Finished in support, I am the 📱👑. There were three teams, with three leads. I was somehow responsible for all of it. I spent a lot of time listening, making sense of things. I knew people were nervous about change, so worked to be accessible and transparent. Trying to turn a disconnected non-team into a high performing one. My first two weeks as 📱👑, I did a 1:1 with every person on the team, and flew from Buenos Aires to Philadelphia for WCUS where I met Matt (the CEO, who had recruited me) and one of the team leads for the first time. The lead – Will – and I ran user tests together. Saw in real life some of those things I saw in support.

    I took all this information and tried to figure out where to start. What is a symptom, and what is a cause? 

    Some time in December, I cried and allowed myself to question if I had made the right decision.

    I put that question in a box and kept going.

    • We clarified the purpose of each project and started talking about timeframes.
    • We started doing daily standups.
    • We revamped our bi-weekly updates (now with more emoji).
    • We defined new projects that put user benefit at the centre.
    • We took a hard look at the ways we were failing users.
    • We shipped something.
    • We started talking about user empathy – we challenged ourselves to use the app as a user would.
    • An engineer got so annoyed by a piece of terrible UX we called “the seven item monstrocity”, he prototyped a new media picker experience over a weekend.
    • We changed up team leadership to have five teams, including a design team.
    • We set better standards around clarity, feedback, and 1:1s.
    • We thought about on-boarding, and defined a process for it.
    • We shipped again.
    • We worked to make the leads a team.
    • We were moved out to become our own division, with me reporting to Matt.
    • We failed. But this time we talked about it.
    • We shipped more.
    • We worked to be more accountable – to each other, and the wider organisation.
    • We kept shipping.
    • We revamped our hiring process, and opened it up again.
    • Ship. Ship. Ship.

    At some point… we became a team. When we got together at the Grand Meetup, it was really noticeable. We did an exercise called “Plusses and Deltas”, the plusses were things we had worked so hard on. The deltas included things that really showed how far we’d come.

    Our design lead wrote about the process of building the design team, and I love it because it captures something of the hard work, and where we are now compared to where we started.

    For me, I learned how to onboard and ramp up new managers. I levelled up my communication and coaching. I invested in getting better at product. I conducted interviews via text for the first time. I made ever more elaborate spreadsheets as I got further away from writing code. I got better at setting an example then letting things go. I reached new limits of how much I can get done in a week. I made hard decisions, and I had hard conversations, and I got better at both of them. I experienced that when you help a manager level up, a team levels up, and it was amazing. I built relationships with my peers and appreciated the difference that makes. 

    The past year has been brutal. Exhausting, challenging… I’ve had my share of moments of doubt. But I work with people I really like, at the intersection of things (mobile, writing, open source) that I love. I wouldn’t change it for anything… so bring it on, year two.

     

  • Running an Effective Mobile Team, Part 6: Encouraging Accountability

    Running an Effective Mobile Team, Part 6: Encouraging Accountability


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

    Problem: 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.

    Accountability comes last, because it builds on everything else.

    • Being erratic undermines accountability – the chaos can always be blamed.
    • Lack of prioritisation undermines accountability – who is to say what was most important?
    • On a disconnected non-team – who even is accountable? And for what?
    • The less a team is automated, the more crucial but repetitive things can fall through the cracks.

    If you want to hold someone accountable, assuming you’re not a sociopath, it needs to be clear what you’re holding them accountable for. But you individually holding people accountable doesn’t scale. In a healthy team, people will hold themselves accountable to their team.

    I want to tell you a story about the worst manager I ever had. He hid deadlines, concealed missing deadlines, until eventually – unsurprisingly – the team and product was killed. One time I told him I was worried because we’d missed a deadline, and his response was “what deadline? There was no deadline.”

    He made it impossible for other people to know what was going on, because he discouraged all communication that wasn’t to him. No-one on the team could really hold anyone else accountable because no-one knew what was going on. It was kind of farcical. The best way to know there was a deadline, is that when they happened the tech lead would disappear. One time he disappeared for three days to search for his cat.

    Anyway we had this meeting, a post mortem, about why the team was a disaster and couldn’t ship anything. This tech lead made subtle digs at another guy on the team, and then said something super inappropriate and unfair to me. Everyone sat there in silence, and later people in that meeting told me how appalled they were. Another woman on the team said it was the first thing she had seen happen at work, that was blatantly happening to a woman because she was a woman.

    My manager was in that meeting, but he didn’t handle it. I told him I was not OK with it, expecting him to do something about that. And he told me I should handle it myself.

    This is probably what we should expect from a guy who dealt with deadlines by pretending they didn’t exist. Note: he didn’t say this about any of the minor complaints I’d had about this guy. Those he took under advisement. But when it was that inappropriate. It was on me.

    Anyway, I got this dude 1:1 and I told him… well I told him everything he’d done to annoy me in the previous six months, why what he’d just done was completely messed up, and my conclusion: he had no leadership skills.

    You might be surprised to learn this did not go well.

    Now in my defence: I was right. This guy spent 4 months reinventing how to build an android app, and 8 months doing “UI polish” before shipping. The project he led was a disaster and when that was clear… he spent three days SEARCHING FOR HIS CAT.

    Someone really needed to tell him that he was doing terribly at his job – but I was not the right person to do that. Firstly, I was a ball of rage. But secondly, I was trying to hold him accountable for something he hadn’t agreed to be accountable for – on a team that had no culture or norms of accountability. And I was starting not with a small thing, but with a major crisis thing.

    This is not how you start building a culture of accountability. It’s not when you go “wow! I do not want to deal with that.” You start smaller.

    First up: you hold yourself accountable.

    Second: you encourage people to own up, and create space for them to do so.

    Third: you create ways that team members can hold each other accountable.

    How do you hold yourself accountable?

    When we move into leadership, it’s really easy for our work to become less visible. The output is the team, no longer individual. Good leadership and management are both a lot of work, but often it’s nebulous and harder to surface. If our work is too visible, then it’s pretty likely we are not doing what we should be, or that we are taking too much credit for the work of the entire team.

    Often we demonstrate accountability 1:1. We set 1:1 meetings, and we show up to them. We listen to what people say, and follow up on it – even if we can’t fix the problems right now. Now my work is more meta, I write an internal blog post every week where I share what I’ve spent time on and sometimes the less concrete things that I’m just thinking about. When I was a manager of ICs, I used to post my standup every day same as everyone else. Sometimes it’s just “1:1s” “code review”, but I find being transparent about how I spend my time goes a long way – even if my outputs are not as clear anymore.

    How do you encourage people to hold themselves accountable?

    You can’t make someone hold themselves accountable, but you can encourage accountability. I think standup is a great tool for this. I love written standups in Slack – because is doesn’t depend on everyone being around at once – my team is distributed across Europe, Asia, North and South America – but even for teams all in once place, people start at different times. Standup forces someone to start their day with some kind of intention about what they hope to achieve. As it’s written down, people can scroll back if things don’t go to plan or if they forget what they thought was important when they started in the morning.

    You can invite accountability by asking people to share what they hope to get done over a given period – and giving them the opportunity to surface when things don’t go to plan. You can also invite accountability by asking questions before giving feedback or assigning blame. It’s much more powerful when someone owns up to what they need to do better, than when you tell them.

    How can team members hold each other accountable?

    Code review – done well – is such a good entry point into peer accountability. Because this is when people look at each other’s work, and ask hard questions, and give feedback. How do you get accountability outside of code review? A lot of that is about encouraging a non-judgemental space, where people can be open about what hasn’t gone to plan. There is nothing more toxic to a culture of accountability than blame – only when people feel like they can own up to each other will they be able to ask questions of each other without judgement or fear of seeming judgemental.

  • Running an Effective Mobile Team, Part 5: Automating Things

    Running an Effective Mobile Team, Part 5: Automating Things

    Robot-clip-art-book-covers-feJCV3-clipart.png
    Credit: Wikimedia

    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.

    Read the final part, on accountability.

  • Running an Effective Mobile Team, Part 4: Building Connections

    Running an Effective Mobile Team, Part 4: Building Connections

    Ghosts-Cute-Funny-Fun-Ghost-Toys-Plastic-Fig-1124534.jpg
    Credit: Max Pixel

    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.

  • Running an Effective Mobile Engineering Team, Part 3: Setting Priorities

    Running an Effective Mobile Engineering Team, Part 3: Setting Priorities

    priority
    Credit: The Blue Diamond Gallery

    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.

    Mobile-stats-vs-desktop-users-global.png
    Source: Mobile Marketing Statistics compilation

     

    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.

    US App downloads Nomura.png
    Source: ReCode

    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:

    1. User success rate with this action.
    2. 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.

    meeker-2016-ios-android.jpg
    Source: The Verge

    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.

    Read the next part, on building connections.

  • Running an Effective Mobile Team, Part 2: Creating Predictability

    Running an Effective Mobile Team, Part 2: Creating Predictability

    Wood Train Love Toys Affection Romance
    Credit: Max Pixel

    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.

    Read the next part, on setting priorities.

  • Running an Effective Mobile Team, Part 1

    Running an Effective Mobile Team, Part 1

    Shopping Cart Shopping Cat Figures Curious Danbo
    Credit : Max Pixel

    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.