So you’ve hired the top app development team and as a result, your products are impactful and the company has grown exponentially. As you grow and the teams get bigger, you find that it’s become more difficult to get the job done as seamlessly as you once did.
The aforementioned scenario isn’t an anomaly, but rather common in engineering teams during hypergrowth times.
The bigger you are, the more barriers you have to navigate, making it challenging to move toward your goal swiftly and efficiently. Additionally, multiple divisions, departments, and groups make it easier for app development teams to suffer from the silo effect—the kind that destroys communication, collaboration, and productivity and lead to product flaws and schedule delays. It’s critical at this make-it-or-break-it point that teams remain high-performing–delivering high-quality products and continuously reducing the time from idea to production.
How can organizations win during these exciting but tumultuous times without tearing their engineering teams apart?
It all comes down to a strong engineering culture with a value system that encourages specific habits and behaviors. Below are seven principles innovative companies follow to lead their engineering teams to greatness:
1. Build what the users want, not what the business needs
It’s easy for app development teams to build solutions based on what the business needs, and oftentimes, mobile apps are seen as a box that needs to be checked off as part of the overall mobile strategy. But, top mobile app developers that leave that comfort zone to gain a deep understanding of who will be using the product and what their goals are end up with more successful solutions.
At Y Media Labs, for instance, “wherever the geography area in which our solutions are going to be deployed, we try to mimic [the users’] network conditions,” says Vivek Rajanna, senior vice president of engineering, “and then we also try to concentrate on the devices that are more popular in those parts of environment.” For example, you can’t just test a Galaxy and assume it will work the same way for all users of Android devices.
2. Develop a healthy codebase
Consider this concept: you’ll be able to go a lot faster if you’re healthy. Think about your codebase in the same way. How do you keep it healthy so that when you’re pushed to go as fast as you can, you’ll have a map that allows you to find the quickest route?
In general, the average mobile developer will spend more time reading than writing code, and that is exactly why it’s essential that you maintain a clean codebase that is easy to understand, maintain, and extend on. John Terenzio, a former engineering manager at Airbnb wrote about how chaotic it was when he joined the company in 2012. In order to scale effectively, the company transitioned to writing code in a more maintainable way, Terenzio says:
“Code conformity relates both to syntactic/textual style and to applying conventions and best practices when writing code. It has been said many times before, but if you have a codebase where you can open up a file and tell which person on your team wrote it, that’s a very bad sign. Formulating a standard way of writing code and getting everyone on board has been highly beneficial for us.”
When everyone on the team is writing code in a more-or-less identical manner, each person on the team should be able to maintain their team member’s code with close to
the same level of effort. To achieve code conformity, consider using style guides to settle on the most arbitrary rules, like using tabs or spaces for indentation characters.
Once a style guide has been created and is followed, consider what’s called “pairing.”
Phil Calçado who worked on the engineering team at SoundCloud from 2011 to 2015 wrote about how the company required every line of code to be reviewed by another developer. Lastly, don’t forget to test everything. Sometimes it’s not even about testing the code itself, but rather, creating a culture where testing and double-checking is second nature to everyone.
3. Reduce cycle times by breaking up teams
It’s true that smaller teams are nimble, agile, and have a magic-like quality that is the envy of larger, slower-moving entities. The solution? Divide and conquer. App development teams should be broken up into groups, with each focused on a particular goal. In doing so, teams are given more autonomy and dependencies on other teams and systems are reduced.
In an interview with acmqueue, Werner Vogels, CTO of Amazon, spoke about the challenges of too-big teams:
“The many things that you would like to see happening in a good software environment couldn’t be done anymore; there were many complex pieces of software combined into a single system. It couldn’t evolve anymore. The parts that needed to scale independently were tied into sharing resources with other unknown code paths. There was no isolation and, as a result, no clear ownership… The services model has been a key enabler in creating teams that can innovate quickly with a strong customer focus. Each service has a team associated with it, and that team is completely responsible for the service—from scoping out the functionality, to architecting it, to building it, and operating it.”
At Spotify, teams are called squads and squads are put into groups called tribes. At Airbnb, teams are generally made up of 10 people or less. Mike Curtis, VP of engineering at Airbnb, wrote on Medium back in 2014 that often, teams are comprised of engineers, product managers, designers, and data scientists. Members from different teams often partner with one another, and collaboration between functions is encouraged within the culture. Each team owns its own piece of the business and defines its own goals, using the overall company strategy as a compass. This kind of set-up eliminates the need for teams to have dependencies on other teams and systems for decision-making.
4. Make sure teams get regular ‘tune-ups’
To maintain a well-oiled machine, tune-ups are necessary. In much the same way, app development teams should make it a point to set aside time each week or month to review their inefficiencies and adjust accordingly.
Using a concept known as a retrospective, which is is simply defined as, “looking back on or dealing with past events or situations” tools can be used to determine what went right and what went wrong on a project.
These tools can uncover hidden problems with your technology, your methodology, and even reveal people-related issues on your team. It can determine where the team might be wasting time and areas that could be automated to amp up team efficiency.
5. Don’t follow technology trends
Technology advances quickly, and as product evolves over time, so does the software architecture. When developing a mobile app, decisions should be made based on requirements and goals–not technology trends.
Marek Kirejczyk, a lead blockchain developer at Ambrosus, wrote in 2016 that “teams bring doom on themselves” when they let hype driven development, or HDD, take over. That is when an app development team picks the “newest, hottest technology” to use on a project.
The bottom line here is that whatever problems your clients are asking you to solve, don’t let them persuade you toward a solution based on whatever hype is out there. Sure, your customers should be dictating the problem, but never the solution.