From Android Contractor to CTO: My Story As An Engineer

In August 2012, my cofounders and I decided to pull the plug on Fancite, the startup I had been working on for over a year and half. Making that call was one of the toughest things I’ve had to do.

The days that followed were highly existential. Initially, I was relieved and excited about doing something new, however as a few days passed my (perceived) reality hit me: “I wasted all that time building something that achieved nothing.”

I remember being filled with thoughts of embarrassment and a sense of purposelessness. What I worked on for so long and hard didn’t achieve the outcome I was looking for and that was hard for me to accept.

One of the inspirations that I found as I was building Fancite was the approach Joel and Leo were taking at Buffer. I read every blog post that Joel had written as he was documenting his experiences building Buffer. As the product evolved, I felt like I was part of their journey. We used Buffer at Fancite so not only was it an incredibly useful tool for us, but I grew passionate about their vision. When I left Fancite, I wanted to help out in any way I could.

I emailed Joel the same day my cofounders and I parted ways. I talked about how inspirational his blog posts have been for my startup journey, the struggles I faced in making the call, and asked if there was any way I could help Buffer grow. Joel responded and we connected over common failed startup experiences.

At the time, Buffer was in need of revamping the Android app. I hadn’t done Android in over 3 years and when I had, I released a couple of pet projects with the first Android SDK (1.5). Though I didn’t have much practical Android experience or consider myself a mobile developer, I wasn’t too concerned about that. I found a product that I believed in and a team that seemed to know how to get things done, and I wanted to help them grow. With that attitude, I was ecstatic when Joel invited me to join the team as a contractor to start helping out on the Buffer Android app in October 2012.

The real work starts after launch

It took me a few days to get into the groove of Android again. The biggest challenge was design, which was never my strong suite, and it showed in the early versions. With the help of Tom’s visual eye I shipped the completely rewritten Android app within a month of joining the team.

To my surprise, we took a big hit in the Android ratings after that initial launch. A complete rewrite meant the app looked and worked differently. Our original Android users were not expecting a complete revamp and many of them weren’t happy with the update. The blame was on me as I had introduced many unforeseen device-specific crashes due to Android fragmentation. The ratings slumped from 3.7 to 3.4. I worked quickly to reverse that trend.

Buffer has an amazing user community, and many of them helped me get the app to a solid and stable position. The Android fragmentation was the toughest part for me to debug. Since I didn’t have different devices to test them on, I couldn’t reproduce them. Luckily, with some helpful users, I would send out custom builds with a shot-in-the-dark fix to see if that would help. With this iterative approach, I started seeing a positive trend with each new release. Our users loved the custom builds too!

With ratings heading back in a positive direction, I then focused on improving the app in December and January (2013) with new features like photo sharing, sharing from various other apps, native retweets, and more. By January, we bumped our ratings up from 3.4 to 4.3.

Thrown into the deep end

Joel had called me in late January and mentioned that Tom, the Buffer CTO, was leaving Buffer. He mentioned that it would be great if I stepped up and helped out on the web side. I was nervous, especially since I had barely touched the web and API side of things. What an experience.

After the call, in a bit of a daze, I immediately moved to clone the web repo and tried to understand how the architecture worked by delving into the code. Joel had given me access to all the parts of AWS and MongoHQ and other services that I would need (which was pretty much everything).

That same day, we had scheduled server upgrades on our database and I jumped on a call with MongoHQ to get things in order. I had previous experience scaling MongoDB at Fancite and so luckily it wasn’t all completely new to me.

The moment they had started the upgrade, our site went down. The database replica-set change ended up triggering a bug in our database drivers and the entire platform stopped working.

The first day I moved to the web side, with Joel and Matt (who had started two weeks prior) as the only resources, we were thrown in the deep end to sort everything out and get us back online. I was grateful to take the experiences I had at Fancite and Kno and apply them to this situation.

This was a defining moment for me in realizing that my previous startup experiences had helped me become a better engineer in crisis—I wouldn’t have been in a position to get us back online without them. Within 15 minutes, I diagnosed what the issue was and upgraded our drivers throughout the system.

We’ve had many more of those crises along the way since then, including our hacking incident in October. Incidents like down time or security breaches are never any fun when they happen, but they’re really moments where everything is tested and true understanding occurs. I probably wouldn’t have learned as quickly and thoroughly had I not been thrown into the deep end early on.

Moving to CTO

The days after Tom left, and with Joel’s help, I had more time to learn about how everything works on the web site and start contributing. At the same time, we were also building out our internal metrics/growth framework and so every day was different, but exciting. Each day I learned new things about how a feature was implemented or how our architecture works. I also helped Joel with interviews and hiring on the engineering side.

A few months later, in April, Joel had jumped on a hangout with Carolyn and myself and invited us to move to Chief Happiness and Chief Technology roles. I really couldn’t believe it. I thought back to my original motivation of why I first wanted to work for Buffer. That motivation was still true in that moment—to lend a helping hand in building something that people enjoy using. It was such an incredible honor to be asked to help lead the building of Buffer.

It has now been just over a year since I moved to the CTO role. This has been the first time I’ve been involved with and led hiring (something I hope to touch upon in a future blog post). It has been incredibly rewarding working with and helping to build this team. The scope of our team was captured in our last team retreat in Cape Town last month.

The reason this past year has been so fulfilling is not because I’m in a CTO role, but rather because working with this team is so much fun and I’m able to contribute to a product that makes people happy. I’m sure I’d feel just as fulfilled if I were still an Android contractor at Buffer.

Have you gone through a similar experience of shutting down something you were working on? I’d love to hear from you! I’m at @sunils34.

Interested in playing a role in helping Buffer grow? We’re hiring!

Photo credit: Andy Yates