As our organization grows, we’ve discovered that it’s hard to scale mobile capabilities across the engineering group. As a scaling strategy, we decided to try embedding mobile developers within product teams. This is the story of our experiences with three experiments.
At the time of writing, we have north of 100 engineers organized into stable teams. Each team is responsible for some part of our product or infrastructure (e.g. Web Dashboard, Publishing, Billing, Analytics, etc).
Our Mobile team works on native iOS and Android apps that include features across several of these product teams. For example, features owned by the Publishing team on the Hootsuite web dashboard would be built and maintained on our iOS and Android apps by the Mobile team.
There is an expectation from our customers that (in most cases) we provide a comparable native mobile experience for the functionality that exists in our web products. An issue that we have run into is that the number of native mobile app developers is only about one sixth of the total number of engineers, thus the Mobile team’s backlog grows much faster and the team feels that it is constantly playing catchup. Because building native mobile apps is such a specialized skill, it’s also hard to hire mobile engineers at a pace that allows the team to keep up.
To alleviate this problem, we ran three experiments to grow native mobile expertise in our non-mobile feature teams. Training some of the engineers on these teams who are interested in native mobile app development is a good compromise to hiring, because existing engineers are already familiar with our products, our technical stack, and our culture.
If these experiments prove successful, we envision having native iOS and Android engineers working on teams that are responsible for a set of product features like message publishing or engagement streams. For example, the Publishing team is responsible for back-end as well as customer-facing functionality related to publishing messages on the Hootsuite web dashboard, it makes sense that the team would also own publishing-related functionality on native mobile apps. The core mobile team will maintain the platform that other product teams will build upon and stay responsible for the overall quality and architecture of the apps.
Experiment #1: Big Nerd Ranch
The experiment was to send two of our Publishing team engineers to a one-week beginner Android and iOS bootcamps at Big Nerd Ranch.
The experience at Big Nerd Ranch is intended to be distraction-free, fully immersive group training. Classes run for about 8 hours a day with additional instructor office hours in the evenings. Our colleagues who participated in this experience were highly motivated and deeply immersed in learning the fundamentals of Android and iOS. One of the participants, Dave Russell, said that “not having other work issues that [he] needed to address allowed [him] to really dig into the Android system.”
The beginner courses at the Big Nerd Ranch, assume almost no prerequisites besides having strong motivation and desire to learn. Our engineers found themselves looking for more advanced programming. From their experience, attending instructor office hours, as well as independent after-hours study time, proved very useful to learning about more advanced iOS or Android topics. Luckily, the instructors were experts in their fields and were able to provide a wealth of knowledge and resources beyond of what was covered in class.
Results of Experiment #1
Overall, the experiment has shown promise, as both of the engineers have grown to be quite effective and are making important contributions to Hootsuite iOS and Android apps. That said, the costs of travelling and tuition were considerable and would not scale well with larger number of participants.
Additionally, this was a general education, whereas something customized to our Mobile team standards and processes would cut down on time to get familiar with the way we build and test our native mobile apps. It took a few months for both engineers to settle into their new roles and start working on the native mobile apps almost exclusively.
Experiment #2: Android Study Group
The outcomes of our first experiment generated even more interest across the engineering team. Since our Android team was much smaller than our iOS team, a group of engineers from different product teams interested in learning Android decided to register for Programming Mobile Applications for Android Handheld Systems on Coursera. The course is comprised of two parts, and runs for a total of eight weeks. The course is intended as an introduction to Android development and assumes some experience with developing for other platforms.
Taking online courses by yourself can be challenging, especially when you have a full-time job. It takes serious personal discipline and dedication to get through it and retain some valuable knowledge in the end. To keep each other accountable and on-track, registrants decided to organize an Android Study Group.
The group met every Thursday after 5PM for the duration of the course (8 weeks) to share learning progress, get some help, or show off any personal projects. To leverage the expertise of our Android team, every week the group asked one of them to be available to answer questions and share examples from the Hootsuite Android app that related to the topic of the week. This proved to be hugely beneficial, as it provided real-world examples of the functionality presented in the course. Talking to experienced Android engineers also provided practical insights into the tricks, tradeoffs, and pitfalls they deal with on a daily basis. Through this process, the group also gained exposure to Hootsuite’s Android app architecture and codebase.
Results of Experiment #2
At the end of the eight weeks, the group definitely felt more knowledgeable about Android architecture and some peculiarities related to developing native Android apps. The extracurricular nature of the course was not overly conducive to getting deep knowledge and experience with Android, however it provided a clarifying glimpse into the world of Android and has helped the participants to decide whether they’re interested in the platform.
The experiment had limited success on its own, since it did not produce engineers that were ready to work on our Android app, but it has served as an important stepping stone to further, more engaged training.
Experiment #3: In-house Group Training
Some of our engineers had already gone through a two-week immersive training for Scala, which proved to be very effective in accelerating our move to a Service Oriented Architecture. Organizing something similar for Android (and later iOS) seemed like the next logical step in our quest for expanding native mobile expertise. A cross-team group of 5 participants was identified based on their interest in the Android platform, and whether their team would be taking on mobile work in the near future.
Our training partner this time was Steamclock Software. Steamclock builds custom apps for Android, iOS, and the web, and also offers on-demand training workshops for software engineers. The course that Hootsuite engineers participated in was a five-day-long beginner Android course, which took place at Hootsuite’s headquarters from 9 to 5 every day. There was a lot of material to cover in 40 hours and the course definitely seemed rushed. Steamclock, however, did provide a very dynamic learning environment by having two experienced Android developers trade places in front of the classroom to talk about topics that each was more experienced with. Each day also devoted a few hours to lab time, where students had a chance to experiment with what they were learning.
Even though all of the members of the training cohort already had some basic experience with Android, either through participating in Android Study Group or through independent learning, none had worked with the Android platform full time for any considerable length of time, and it was greatly valuable to be fully immersed in Android and not have to worry about usual work responsibilities.
Once the group training was completed, all participants were given an introduction into the Android app’s codebase and the tools and processes employed by the team. This follow-up “internal training” allowed participants to learn enough from the core Android team to begin contributing to the app’s codebase. Several of these engineers have already started picking up smaller tickets from Android team’s backlog to get more familiar with the codebase and eventually all participants will work on native mobile functionality that is relevant to their team’s feature set.
Results of Experiment #3
Going through the in-house group training had made all of the participants more confident and experienced Android developers. At the time of writing, however, most have still not had a chance to work on the Hootsuite app due to other priorities, so the full verdict of this experiment is still out.
One of the more evident drawbacks seems to be the shortage of time. One work week is not enough to become proficient with Android platform. In addition, many of the participants had also participated in the Study Group experiment and found a lot of overlap with the basics that they had already learned. Good developers are quite used to learning, and it appears that online courses in combination with a Study Group is a very suitable format for learning the basics. On the other hand, in-house training with a professional instructor is a much more valuable investment for acquiring deeper, more advanced knowledge.
We are certainly still evolving towards full self-sufficiency for all product teams. In the future, each of these teams will own a set of features and infrastructure, from low level services to the Hootsuite web dashboard to native mobile apps. At that point, every product team will have the ability to ship their features in native mobile apps as well as on the web dashboard. The core mobile team would support this effort by serving as a Center of Excellence for mobile application development. We envision this core team will build and maintain core libraries and SDKs that will serve as platforms for other product teams to build upon.
We don’t expect that our transformation will be quick, and we are realistic that we might never get to a perfect realization of this vision. Nevertheless, we are quite optimistic that continuing to experiment and move in this direction will help us improve product continuity across platforms and also increase the speed of our decision making and execution.
- Big Nerd Ranch and Steamclock Software for teaching us
- Coursera for providing great and free learning resources
- Hootsuite core mobile teams for their knowledge and patience
- All participants in the training experiments for sharing their feedback and ideas
- All training organizers at Hootsuite
- Jeff Stautz, Paul Cowles, Lars Vedo, Noel Pullen for their ideas and editing
About the Author
Denis is a Software Engineer at Hootsuite. He primarily works on the Hootsuite Mobile Web app as well as the RESTful API used by the native mobile apps. He has recently participated in the Android training and is looking forward to work more on the native Android app. Follow Denis on Twitter @dgolovan