Table XI

How we keep up with changing mobile development technologies

We’re experts at mobile development technologies, but the definition of “mobile” changes constantly. Because mobile usage is growing so fast and there are new tools and frameworks for building mobile apps every week, we have to be constantly finding, testing and adopting new skills and tools just to keep up.

That’s why we’ve made learning and teaching an important part of how we operate as a team.

I’ve written before about how much the tools and processes for our mobile team changed in the four years we’ve been around, but the truth is that they’re still changing. There are new tools and design patterns for structuring apps coming out all the time, a lot of which we want to try out. In the past year, we took React Native (a new cross-platform framework by Facebook) for a spin and really liked where it was going. Keeping up with what’s out there lets us give our partners the latest and greatest, and to do that efficiently we need everyone on our team to be looking out for cool things they want to bring to the group for testing.

Why diverse backgrounds help us catch up changing mobile development technologies

Our mobile team is a big group of mutts. IMHO, it’s why we’re so great — having minds coming from different areas gives us more insights. It also means we’re constantly learning and teaching each other, so everyone can benefit from everyone else’s perspective and move forward as one team.

When you blend Quinn's Android experience with Yana’s design experience, John’s Ruby experience, Dan's pretty-much-everything experience and my iOS experience, it gives us a knowledge base that helps tremendously when we’re testing something new or trying to solve a problem. And then we have a few switch hitters from the web development team who join in on certain projects and give us that desktop perspective.

When we evaluate a technology, we try to give everyone a crack at it, because a new framework or tool might resonate totally different across backgrounds. If someone who’s very fluent in Ruby can lean in and say, “You know, actually this feels kind of similar to this,” we get to a solution so much faster. They can teach all of us from their experience, so we’re never starting from zero with a new technology.

How we find and test new mobile tools

Like a lot of shops, we use Slack quite a bit, and our mobile channel is where we dump anything that we’re excited about —  interesting articles, new tools, questions, answers. Sometimes it’s a mobile-related article, sometimes it’s an architecture like ReSwift.

Here are a few places we’re regularly finding great stuff:

Our standup meetings are, surprisingly, where we do a lot of our knowledge sharing. We have a team standup for two hours every other week. Other practice groups allocate their standup time in a variety of ways, we’ve found that using at least one of those hours to try out new tech works best for us.

Because we're still a relatively small team, we don't have to formalize everything, so there are a lot of little one-off conversations between people working on a project. But for bigger changes or new technologies, we like to formally address them in standup. Ideas usually come from Slack, or from a monthly survey we send out asking if there’s anything cool we should be thinking about using. If there is, we'll take a look at it offline, and then if it's worthy of a conversation, we'll take a quick dive into the technology and look at some code and gauge everybody's gut feeling. If we think it's something we want to give a try, we’ll set up a plan to test it more. If there’s time, sometimes we’ll even do a quick spike test in standup.

At this point, we’re all so excited about teaching new technologies that people will kind of hold onto the cool things they find, so when we get to standup they can take over the screen and start teaching. It’s great, because we now have this large chunk of time to test ways to improve our process, so we don’t get lost going deep on new technologies on a day-to-day basis.

How we teach and learn from other teams

We already have people with a lot of different backgrounds, but there’s still plenty we can learn from our devops, design and web development teams. We also want them to know what’s going on with us. Table XI uses weekly lunch and learns to make sure everyone in the company has a chance to see what individual teams are doing. Hosting these lunch and learns every so often helps us show what we’re up to and teach people outside our practice group something new.

We’re also improving how the mobile practice operates by using our monthly survey to gauge morale and identify problems. The idea is that if there's a bottleneck or something people are struggling with, we’ll catch it in the survey. If it wasn’t addressed already, we can correct it. Eventually we’ll roll these results into a mobile scorecard, so it’s part of a formal assessment of how the mobile team is doing. We’ve actually been sharing our ideas on how the scorecard could work amongst the other practice groups, to both gather feedback as well as provide ideas.