My path from someone who barely knew Android exists, to a Head of Development in a Google Certified Agency.

Five Android Team celebrating the Google Agency Program Certification (early 2018)

My journey as a professional developer started eight years ago, and it’s actually a funny story. It all started with an interview at the local software company:

The Interviewer: “Hey, have you heard about this new operating system for mobile phones Google is currently working on? It’s called Android.”

Me: *looking at my current dummy phone* – “No, not really…”

The Interviewer: “Doesn’t matter, you start on Monday.”

And just like that, I became an Android developer. It was something I knew almost nothing about but had a solid grasp of OOP and Java, so it was easy to pick up Android specific stuff. I also got a mentor. This guy had only one month of experience working with Android, but it was easier to navigate through the new platform in a team with somebody, rather than being alone.

After two weeks of onboarding and learning about Android I was assigned my first project – a Java backend project meant to support some iOS app for Switzerland based client. I was a bit surprised if not shocked I was supposed to build something completely different I was promised to.

After I successfully delivered my first backend project, I was finally given the opportunity to work on a real Android app, adding a gallery feature to an existing news reader app.

For the next few years, I continued to work as both a backend and an Android developer. In retrospective, it helped me a lot to get the full grasp of the whole ecosystem of the mobile app development, to learn about being both backend and frontend developer, and how to get the most out of those situations.

Joining Five

I joined Five three years after my first job as a mid-senior Android developer. My title was earned mostly because I had three years of experience on a platform that was around for four years. In other words, I was nowhere close to a real senior developer.

Soon I started working on a project for a New York-based company called Squarespace. My job was to help out creating their new Android app – Squarespace Note. I joined the team of highly skilled designers and developers, so it was the first time I experienced what it means to work in a very organized group, with proper guidelines and processes on how to move things forward.

In a very short time I learned how to properly use Gitflow, how to improve code quality through pull requests, correctly set up your CI/CD, and how can team meetings help to figure out the best way for the team to build Android apps, just by discussing wins & fails on other projects. At the same time, it made me realize how much I have to learn about software engineering, how much time I’ve lost by trying to learn everything on my own, and how important is the concept of a team.

Forming Our First Team

During the first year on my new job, there weren’t any notions of our team revolving around a specific platform. Five is an agency, most of us used to work independently, with our style of coding, merely merging everything to master branch when done with a task. On the Android side, there were only three of us: two experienced developers (including myself), and one intern.

In the summer of 2014, we were overwhelmed with projects, and at the same time, wanted to take in more students for our summer internship. When we learned that the two of us were supposed to mentor six students, we realized it would be impossible to do it ad-hoc. So, we decided to come up with a mentoring plan: figuring out what things we want to teach them, how to track their progress, but also how to let them contribute to our real projects.

It was the spark that made us realize we need to form a real team and figure out processes that will help us move things forward. So, we decided to define several things we believed it would assist us in guiding and mentoring these young people.

1. Tech Stack

The first thing we asked ourselves was: “What do we want to teach these young people?”. Since we both did things differently, we decided to put our heads together and come up with the list of stuff we thought we used adequately. Some of the things that made on that list were architecting the app by splitting things in UI, and business layers (MVP/MVVM  wasn’t a thing back then), dependency injection via Dagger 1.0, and the EventBus was the hottest thing ever (yes, I know…).

When the students arrived, we took turns every week and had short presentations about these things: how we used them on existing projects and what problems are they solving. A situation like that pushed us to become more proficient with these libraries, to be able to teach it properly to younger members.

2. The Code Review Process

The Code Review was probably the most significant thing we changed in our daily operation. Since we knew we wouldn’t be able to work closely with each of our interns, but we also wanted to be able to track the code they’re producing and give them feedback on it, we introduced the Gitflow in our process. Not only it helped our usual method of developing features, it let us review intern’s code incrementally, apart from master branch, making everyone feel more comfortable when pushing code to the repository.

The second great thing about introducing code review in our small team was the opportunity for everyone to see comments we left to the author of the pull request. We didn’t have to explain the same thing multiple times, leaving us more time to teach them other concepts and ideas about Android platform.

And the last thing was how it makes easier to figure out guidelines, spread it among team members, and ensures everyone understands and follow them. It also offered an opportunity for everyone to suggest improvements to them, creating an excellent team cohesion in the process.

3. Meaningful Team Meetings

Like most of the developers out there, I’m not a fan of having a bunch of meetings throughout my day, which usually wholly ruins my productivity. However, as our discussions on pull requests went from “Name this variable like this, and “rename the class to that” to “Does this belong in this class? Maybe this Activity shouldn’t do this much, so we need to add a layer in our architecture”, we realized we need some time to talk about our team: how to improve things in general, what are the pain points on all of our projects, and how can we address them. So, we decided to have a scheduled meeting every week for 30 minutes, to talk about the things currently going on in our team.

Typical daily meeting at Five

To make these meetings work and be useful, several things needed to be addressed.

  1. First, someone needs to own the meeting, preferably a Team Lead. His primary task is to make sure these meetings take place, at a regular time and to manage discussions if they stray too far from original idea.
  2. Second, every meeting should have an agenda describing what is going to be discussed there.  For example, if there’s a need to address some new library or architecture, someone should prepare a small presentation or do a short proof of concept which the rest of them can then discuss and see how it fits into our everyday work.
  3. Third, after some conclusion has been made at a team meeting, the owner of the meeting should make sure that someone takes ownership of those action points and follow up when necessary. For example, when Google announced a new version of the OS, we immediately agreed we need to make sure all of our apps will work when compiled and run against that new version, but we also assigned that task to a person to make sure someone will try it out.

Technical Growth

As soon as we put all these new things into our process, we experienced a huge boost in our knowledge, our code quality rose (you really start thinking differently of how you code when you know your code will be reviewed by 5 other people), and we were inclined to even more to research other cool new things and propose improvements to our tech stack.

During the next several months we grew our team to about ten people, so we felt the need for some hierarchy. We needed to manage our processes, to document them, and to better drive our initiatives and research. After a few talks with our management, the two of us who initially started the whole thing, split into two roles.

The first one was the role of Tech Lead, taken by Tomislav Homan, who was responsible for compiling our ways of work in our official guidelines (link), drive the research of new things we could add to our tech stack, and everything else that had to deal with Android as a platform.

I was appointed as a Team Lead and was responsible for our team meetings, working closely with our HR to hire the right people, to have regular 1:1 with my team members and to work with management to ensure we have enough people to deliver projects on time and with the desired level of quality.

This division of responsibilities and well-defined set of expectation gave another boost to our growth. Our research and technical growth became more streamlined, we were able to assess new technologies faster, and since we had guidelines and agreement on how we build things, it became much easier to switch people from one project to another.

Also, code review time dropped since we didn’t have to bother with checking how variables were named, or if the MVP is implemented how it’s supposed to be, so we could concentrate more on checking if the business logic was adequately covered.

On the other hand, having dedicated time to focus on ourselves and having regular 1:1 conversations helped the overall satisfaction among the people. It was easier for the company to learn about people’s aspirations and desires for growth, and enable them to get the experience or education needed to reach the next level, but also to communicate what we expect from them to be promoted clearly.

During the whole 2016, we were working on our biggest and most successful project to date – Rosetta Stone. Although I wasn’t actively coding on that project, I was reviewing every pull request there made by six other team members working on it. After we published the first version of it which proved to be a huge success, I had several revelations which made me incredibly proud, but also a bit jealous.

Rosetta Stone team at Five (2016)

The whole project was carried out mostly by people we brought in when they were students for their internship close to their graduation. Since I was mentoring them, this made me immensely proud, but I also realized these people managed to learn the same amount of technical stuff I spent over six years researching on my own, in a short time. I even felt a bit jealous, but it also reinforced my belief in just how important the concept of the team is.

Help Your Team Realize Their Full Potential

“Although my role was officially called “Team Lead”, I never considered myself a true leader. Instead, I felt I worked the best when I support other people, let them know they can count on me and that I really care for them.”

Real support is not something that comes quickly, but it instead takes a long time to earn trust and build a special relationship with each team member.

Soon I realized this role wasn’t just an 8-hour a day job for me. I caught myself spending Saturday mornings code reviewing our projects, staying in office till late doing some LAN parties, organizing team outings and dinners, and even spending some vacation days together with my team hanging out by the sea.

Lan Parties at Five (2016)

The day soldiers stop bringing you their problems is the day you have stopped leading them. They have either lost confidence that you can help them or concluded that you do not care. Either case is a failure of leadership.

— Collin Powell

These kinds of things helped me connect with each team member. At some point, I could tell just by the quality of pull request that something is happening with my team members and that we needed to talk. It also made it easier to have one on one conversations and helped us being honest with each other when communicating problems, giving feedback on our current work and how can be both improve in our day-to-day work. Once you’ get to know the people you’re leading really, it becomes easier to plan their development path.

So, What’s The Secret to a Successful Development Team?

During the last several years I was asked that a lot. How did I manage to get everyone to work as a team and to be so responsible despite being so young?

  1. Show your people you trust them and give them the opportunity to show responsibility and take ownership. This usually means creating a controlled environment where young people can assume the lead position, make decisions and let them fail in a way where they can learn from their failure. This could be a lead position on a project that is well defined and rather small in scope, where even someone inexperienced can quickly grasp the “big picture”. The main thing is to communicate expectations, responsibilities, and deliverables. It usually helps to have things written for them to be able to check if they’re on track. Also, give them feedback regularly on what they did well or what they need to improve.
  2. Insist on your code review process. I heard so many times that company doesn’t want its developers to do code reviews since it’s just a waste of time and they should concentrate on building features instead. I just cannot emphasize enough how crucial code reviews were for us when making a team with future in mind. Granted, we could deliver some projects faster and probably with the same amount of quality, but I firmly believe we wouldn’t be able to provide the projects we’re working on today where 5-6 developers must work as one to reduce friction, ensure code consistency and high quality.
  3. Talk to each other. Let your people know exactly what you think of them, and ask the same in return. Encourage them to give constructive feedback to each other, and follow up on any action points that came up.

But the more I think about it, there is no secret. There is honestly nothing revolutionary I did there. Just a lot of small things which in time grew into something bigger. And that’s the beauty of it. Just because something seems low and it won’t have any immediate impact, it doesn’t mean it’s not essential in the long run.

Letting Things Go

During the last few months, I’ve been transitioning into a role of Head of Development, trying to spread good practices I’ve learned while leading Android team, across and between all of our development teams. I left the Android team in the hands of a new Team Lead, the same kid who joined Five as a student five years ago, wanting to learn something fresh during the summer break. It’s been gratifying to see people you worked hard to raise as an engineer are now building a new generation of exceptional engineers, the same way you were doing all these years. I have no doubt in my mind he’ll do a way better job than I did.