social media

We all know Instagram, and how it quickly skyrocketed in just a year after its founding. If you don’t know just yet, here’s the gist: Facebook bought Instagram for $1B, which is one of the major milestones of the startup. From then on, its users rapidly grew from 30 million monthly active users to 200 million when it was acquired in 2012. Today, Instagram now has over 700 million active users.

One of the geniuses behind the platform and its success, was its co-founder and CTO, Mike Krieger. He started as a first time manager, who now leads a multi-layered organization of specialized engineers. Krieger has established his own milestones when he expanded his engineering team from six generalist developers to 300 of the best ones in the field.

Krieger made it all happen in just seven years, while also working for Instagram. Some people might say it’s impossible. For a young leader and entrepreneur, many people were impressed for his staggering accomplishments. In this interview, Krieger shares how he made it all happen, and what are the things he would change, if he can go back to 2010.

His insights can help startups in their transition from an early to a more mature team. Krieger reveals how to build a sturdy system for continuous improvement and innovation.

Build a Team that will Match Your Needs

Like any other projects, you need to collect what you need, and make sure you have an ample supply before you start anything. For startups, particularly, focus, energy, and problem-solving abilities are the main fundamental components. Krieger said that at this point, you don’t need specialized engineers, instead, a few generalists. Generalists excel at the early stage, where their abilities and traits can be the critical elements to your startup’s launcher to its next phase.

1. Shaving the yak

Yak shaving is a popular expression in leadership. Krieger defines what he knows about when to shave the yak, which plays a significant role in the primitive stage of a startup. He says, “Sometimes programming means solving super complex technical problems. But a lot of times, you end up with a long string of tasks that are necessary to get where you’re going, i.e. ‘I need to get this iPhone app running on my device, which means I need to generate this provisioning profile, which means I need to set up for this account, and on and on.’ In the end, you’re shaving a yak to accomplish that original action — you’re so detached from it.”

Your team of generalists must be people who are willing to learn. They must be inclined in following the threads you’ve set until the end. The kind of people for this position must be ready to do and learn the tasks on hand, even if it’s outside their job description. Generalists, most importantly, must be prepared in the execution of these tasks.

According to Krieger, here are the questions you need to ask your prospective generalists during the interview:

• Talk to them about a recent side-project or work project; what “yaks” did they have to shave before getting started on the real stuff?

• Ask them about a time when they’ve taken a project across multiple disciplines, even ones they weren’t familiar with before starting on the project.

2. Know when the yak isn’t worth saving

“People can get addicted to yak shaving,” says Krieger. When time is the most valuable element in the early stage of an engineering startup, the best generalists know when to stop the yak shaving.

Krieger recalls the time when Instagram was on it’s earliest days, he says one of his best pieces of advice is to “monitor everything.”

“Finally, I was like, ‘I’ve got to get back to building the product. I’m going to settle for a slightly less good alerting solution that’s not quite as flexible, which I know I can get done today, and then move on,” Krieger talking about spending four to five hours when he was trying to implement Nagios, a leading infrastructure monitoring service.

There will be times when you want to build something yourself. However, in some cases, a good solution already exists. “Early on, we thought, ‘Well, we could figure out how to do our own push notifications. But Urban Airship is right here.’”

When building a startup, you need to put pride aside, and focus on the goals. “The goal is not to set up Nagios or Munin. The goal is to ship software so that you can get people using it.”There’s an efficient way to identify who are the yak-shaving addicts:

There were times when Krieger and his team of engineers spend a few hours working on a project like a simple mobile app, where they were given full access to the Instagram team if they have questions. “It helped spot the pragmatic engineers from the ones who (no joke) spent two out of the four hours setting up their editor environment,” he says. The key is to know where they used their time wisely.

3. Action-oriented focus

Making an action is important, but knowing how to prioritize your actions plays a more significant role. It’s impossible to do all things at once. Thus, knowing your primary, secondary, and tertiary steps is necessary. To do it, you must have an efficient recording system to be able to elaborate your goals. Although, this system doesn’t need to be technical, or tremendously detailed, you still need one. During the early days of Instagram, Krieger and and his team recorded their actions in a themed organized, rolling Google Doc.

“One of our themes was being the fastest photo-sharing app in the world. What are we working toward within that time? Next, we wanted to make the photos look incredible, way beyond what you’d expect from a cell phone. What are we doing on that? Anything that didn’t fit into those things went by the wayside. And you want engineers who are okay with that.”

The Google Doc was the best tool for organizing and monitoring the tasks for the whole team. It’s simple, and viable, which tracked each member if they rolled up to the organization’s goals and tasks. The doc was divided into days, and under the days are themes. Missed tasks were moved the next day, and high priority tasks were labeled. This way, nothing gets lost, and people can easily inquire about the tasks. Each member was able to focus on the next goal, and they can prepare for what’s next.

This system was vital for Krieger when he built an early team, whom can roll on this kind of system, while focusing on the bombarding tasks. It contributed to the company’s success, and it helped avoid hiring people who work on their own but fail to focus on the prioritized goals. The system has helped the team pay attention to the company-wide execution plan, and prevented wasting of time from choosing to work on unimportant tasks.

To identify the people who are capable of action-oriented focus, ask this question:

• Tell us about a time when you were particularly proud of the balance you struck between feature completeness, polish, and timing. “The answer to look for is one that’s nuanced rather than absolutism,” says Krieger. “I.e.. ‘We only ship when it’s ready’ or ‘We hit every deadline.’ I’ve heard both.”

Gathering Passionate and Flexible Generalists

Startups have a big advantage to think and hire outside the box. When talking about Shayne Sweeney, the first engineering hire of Krieger’s Cofounder Kevin Systrom’s, he said, that the benefits of hiring embodied Shayne. “He never finished college. He was a totally self-taught programmer. We met him because we were incubated at Dogpatch Labs over on Pier 38, and he had the desk across from us. But he embodied the startup ethos of ‘I have an idea, and I will learn anything to make it happen.’”

Observation is the answer when looking for such team members. As from Krieger’s experience, you will uncover that kind of drive within a person, generally by identifying a part of the prospective member’s personality trait – he must be naturally curious. You will learn more about a person by noticing the hints of inquisitiveness during the initial conversation. “The candidates we got excited about being the ones who would say, ‘This week I was really interested in the game Go, so I built a Go prototype and learned this thing.’ Rather than, ‘Well, the company I work at uses React, so I’m using React.’”

Using some strategic questions, you can identify the curiosity of a person. “I like to ask, especially at the early stage, ‘What are the side projects you’re excited about? When was the last time you went down the rabbit hole on a particular project? What did you learn?’” says Krieger.

“When people’s eyes light up and something excites them, you’ve hit on passion and not just a vocation. You need passion early on, because the work will definitely not fall into a small box.”

When choosing people, flexibility is crucial as well. Meaning, you may not hire the best, and most skilled candidate, but being okay with that.

“We interviewed a guy I knew, who was one of the best iOS engineers I’ve ever met. But in our conversations, he basically said, ‘Just so you know, I refuse to do server-side work. I think it’s a waste of my time.’ And that’s a valid opinion,” says Krieger.

At that time, Instagram were not looking for highly specialized members. “We didn’t want people who would hit a wall and then say, ‘Hey, I need server-side work here.’”

“I remember talking to Kevin Rose about Digg, and he said one of the biggest mistakes they made early on was recruiting engineers who were too finely matched to the technology that they were using,” says Krieger.

Hiring people who can juggle different tasks keep early engineering Orgs thriving. “That’s a problem for two reasons. One, you’re going to eventually want to evolve your technology. And two, if people tie their own job security to, say, staying on PHP, you’ll end up making the wrong technology choices.”

Krieger suggests that, contrary to several tech literatures which say that companies need diversity in their members, for startups, it may not be applicable during the early stages. Although, gathering a diverse team is still a priority, it falls to the bottom of the list.

“We didn’t put enough of an emphasis on hiring a diverse team in the early stages,” says Krieger. The control in diversity during the early stage made it difficult for Krieger to bring in women, and engineers with minorities on their background to the company has grown. “If you’re interviewing your first female engineer, and she shows up and thinks, ‘Wow, this team is huge and all guys,’ that just makes the barrier even higher. That really does happen, and if you can avoid that, you’re in much better shape.”

However, building a diverse team early will allow you to reap the results of a virtuous cycle. “Once a couple of women had joined the team, we were excited to bring on many more women much more easily,” says Krieger. “From doing events to interviewing to writing, tech blogs and just being visible, it catalyzed a stronger team.”

Check out this interesting video featuring Instagram founders,  Mike Krieger and Kevin Systrom:

Knowing that You Still Need to Specialize

After Instagram has been acquired by Facebook in 2012, the 13-person company led by Krieger and Systrom could recruit both independently and from Facebook’s boot camp. With the increasing demand for growth and features, the company felt the need to specialize. They needed to bring in people with namely, career iOS and Android engineers who can make the product become better than ever.

It’s a common phase in every startup. The signs that confirm you need to move in this direction include:

• You’re inventing something that goes beyond the abilities typically offered by the platforms you’re working within.
• You start moving into new markets that require highly-tuned code. In Instagram’s case, this was making video work well in emerging markets.
• Your codebase has scaled and needs technical leads to shepherd future growth.

However, specialization doesn’t mean letting go of all of the flexibility, or putting up hard walls. “The fact that your early generalists have broad awareness makes them far better engineers,” says Krieger.

Take his first hire, Shayne. “At one point we were trying to make our test cycle faster. Building and deploying was taking a long time. The solution ended up being an infrastructure one, which required a bunch of Python scripting. Instead of dragging in somebody from the infrastructure team, I just said, ‘Shayne, you know end-to-end stuff. You’re going to come up with those ideas and you’re going to create the MacBuildServer at your desk.’”