Category: Google

The Fat Torso

~ avichal ~ Leave a comment

The Internet’s potential to enable new businesses by building for customers in the Long Tail is well-documented. However, for many Internet businesses, the Fat Torso is now more important.

As the Internet has scaled, we have seen the emergence of markets with Fat Torso and successful businesses that first target the Fat Torso of customers.

The Shape of Markets

Markets can have a big head, fat torso, or long tail. Offline businesses tend to have a fat head because there are real economies of scale. For example, the top five automotive manufacturers own about 50% of the global market and the top 15 own about 90% of the market. Internet businesses such as YouTube have both a fat head and a long tail uniquely enabled by the Internet.

As the Internet has matured, many markets have grown to also have “fat torsos.” These Fat Torso markets are often fantastic markets for startups to enter and the right entry point is through the Fat Torso.

What is the Torso?

Customers in the torso are between the head and the tail. They make decisions quickly and generate significant revenue or engagement per customer. Customers in the torso generate more value for your business (revenue or engagement) than tail customers, i.e. the area under the curve is larger. Unlike customers in the head who often make unreasonable demands because they are used to being catered to and having market dominance, torso companies will make feature requests that apply to many customers. Torso companies are hungry to compete with head companies and will try new solutions in order to gain an edge against their bigger competitors.

What is a Fat Torso?

Not all markets have “fat” torsos. If the torso is “fat,” there are many customers who meet the torso criteria (who spend lots of money and move quickly). Thus you can scale your business quickly: lots of customers * high revenue per customer (and they move quickly).

Go To Market: Torso First

The Fat Torso is the best place for startups to prove their business model. Often the go-to-market:

  1. Prove the model with the fat torso customers – torso customers move quickly, offer significant value to your business, are eager to scale their businesses, and do not have significant leverage over you to make unreasonable demands.
  2. Scale to support the head – now that you have some scale, you can negotiate with larger customers or partners. Your company has the runway to wait out the long time horizons that large customers require.
  3. Build self-service tools to serve the long tail – these customers offer significant revenue at scale but require a significant investment of self-service tools. They serve as a moat around your business if you can get them onboarded. Now that you have the customers they aspire to be (torso customers)

Examples

  • Online Ads — target sophisticated online advertisers such as game developers who scale ad spend quickly to $10 million+. Targeting smaller businesses in the tail requires hand-holding, self-service tools, and they will not scale ad spend over time. After you have the torso advertisers, convince large advertisers such as brand advertisers to use test budget and build out self-service tools for the tail.
  • SAAS — start by targeting companies large enough to give their employees autonomy to make purchasing decisions (say 100-1000 people). Avoid Fortune 1000 companies and avoid two-person startups. After you have many companies from 100-1000 people using your product, you can start moving up stream to enterprises and then build self-serve tools for startups.
  • E-Commerce Marketplace — find sellers who can use your platform as part of their existing full time business. At the same time, find buyers who will buy more frequently on your platform not just once per year. Etsy is a good example. It has many suppliers supplement their income substantially via Etsy and Etsy’s customer base appears to have a fat torso with 60% of customers buying only once per year. Over time you may be able to scale to head sellers like Nike or Dell. This is the path eBay took after scaling its core business by first working with sellers who made a living on the eBay platform.

The Torso First approach not the right fit for every market since not all markets have a Fat Torso. However, it is an increasingly common theme in businesses that scale to $100M+ in revenue, both because the markets that have Fat Torsos are great markets and because businesses that scale often use this strategy to scale quickly.

We discussed very similar ideas in some meetings at Facebook. I’m not sure who came up with these insights exactly, so thanks to everyone involved in helping form the ideas: Andrew “Boz” Bosworth, Alex Himel, Pratiti Raychoudhary, and Jon Lax.

Product Reviews

~ avichal ~ 1 Comment

I’ve been fortunate to work with exceptional product leaders at Google and Facebook. This distills some of the best practices I’ve learned around product reviews. 

Purpose: These thoughts are targeted at product managers (PMs), product leaders at larger companies, and CEOs of startups. This document outlines 1/the goals of a product review, 2/common mistakes, and 3/the logistics before, during, and after a review.

I use CEO or founder as a proxy for “decision maker.” For product-oriented companies under 500 people they are likely the same. At larger sizes, responsibilities often recurse down to a VP as the Decision Maker.

0. Why do product reviews?
Product reviews are a process through which a company can scale product development, and are useful for both teams and leaders. Product reviews allow teams to have ownership over product decisions and a clear, predictable way to move forward through strategic and operational roadblocks. They are a useful tool when a CEO can no longer be involved in parallel work streams in real-time. In my experience, this will happen around 20 employees — when it’s hard for one person to be both the full time PM for the product and the CEO at once — and are a staple process as a company grows from 20 to 20,000+ employees.

1. The Goal of a Product Review

There are three flavors of reviews:

  • I. Input/Discussion — The goal is to get input early in the ideation/development of a product. The questions on which you want input and the type of input you want should be clear. It is better to get the CEO/founder to weigh in rather than spend 3 months on something and then realize it is totally out of whack with her vision, that some other team is already doing it, that the company tried something similar before and the founder has context, etc. It’s good to get in front of her as soon as you have a good idea of what the team is trying to accomplish and get her input.
  • II. Unblocking a decision – The goal is to make a strategic decision. If multiple paths forward are plausible and reasonable people disagree about the right path, go to the CEO to make a call. In most companies, the CEO has more context than anyone else about what’s going on, more data intuition than anyone else at the company because of historically accumulated knowledge, and is phenomenal at asking the right questions. The CEO is the ultimate arbiter between teams and can unblock while optimizing for the company. Over time teams can build ways to formalize these decisions, but early on someone needs to make a call.
  • III. CEO priority – The goal is to build and ship a product with the CEO deeply involved in the process. This is a rare third form of review which is a bit more like a team scrum, with the CEO co-PMing with the product manager. This happens at every company. These are projects that are pre-launch, new products, or initiatives that are critical but struggling. The CEO will get involved because she has strong intuitions about what a team needs to build in a strategically critical area. She wants to understand what’s happening the same way any PM member would and help guide the team to build the right product. It’s not uncommon to go in every week to the CEO as the product gets built. After launch, the team should be on its own trajectory, and the team falls into the normal iteration cycle + product review cadence with review types I-II.

2. Common Mistakes

  • Reviews as updates – The most common mistake when asking for review time is to just offer an update. This is often conflated with a discussion style review (type I). Type I reviews have clear questions where the team needs input and will require the CEO to actively engage. Updates are information flowing from the team to the CEO and do not require active engagement. Teams should rarely burn a CEO’s time to do an update. Ten people in a room for thirty minutes = five hours wasted. Send updates over email and if the CEO has questions, get in a room to talk through it. This serves the dual purpose of forcing documentation that can be shared broadly.
  • Reviews as exposure/reward – Do not use reviews as an opportunity to give people exposure or as a reward. Teams should be 100% focused on winning and a review has a clear goal to unblock the team on its path to winning. For example, this may mean that a more senior product manager actually presents for the room or the most senior designer represents the entire design team’s work. Find other ways to give exposure and reward people.
  • Surprises during/after the review – everyone who will be impacted by the decision made should have context that this review is happening and has had a chance to weigh in with their perspective. This requires understanding not just the decision to be made but the implications/consequences of the decision. Not everyone has to agree with how to make the trade-off, but it is a big failure on the product manager if someone in the room is surprised with the content of the review or if someone who should have been involved in the decision is surprised when they hear the outcome.

3. Review Logistics
A. Before the review

  • An efficient approach is to have every team in the company have a standing block of time to go to the CEO during the week. This is efficient because a team knows they can go in every week if needed. If not, they give up the time a few days in advance so other teams who need extra time can use it.
  • Create a document or a deck with mocks, and send it the morning of the day before the review. So if you’re going in on Thursday afternoon, the CEO gets the document to read on Wednesday morning. The questions you want to discuss are called out clearly. The day before the review or the morning of the review, the CEO may respond with questions she’d like to talk through in the review. This gives the team time to get data or converge as a team on an opinion before the meeting.
  • Try to create standard formats/templates that are shared across teams. Uniformity across conversations makes it much easier for people to come up to speed on the content.
  • Anyone who has depth of information/context should be in the room – product managers, designers, analysts, marketing, user research, engineering, sales, marketing, legal, etc. The attendees will change depending on the decision to be made and should be determined and communicated in advance of the review so everyone can prepare for a successful review. Don’t have people who want to “stay in the loop” or “hear about it firsthand” in the room. If you’re not actively contributing to the discussion, you shouldn’t be in the room.
  • If you anticipate the meeting will take 30 min, block 45 min and shoot to be done at the 30 min mark. This also gives some buffer and prevents a domino effect since a CEO’s day is often back-to-back.

B. During the review

  • Everyone should have read the document beforehand and the meeting should start with a discussion on the open questions. Most of the time in a good review should be on productive discussion.
  • If you must present a deck, shoot for six slides per thirty minutes. Do not schedule content to fill the time and move through the presentation 3x faster than normal. If the CEO has a question or needs clarification, she will ask. The most productive use of time is to discuss and decide.
  • A great CEO focuses almost entirely on high level questions for most things that are brought to her. She wants to understand the goal and if the team is solving the right problem. This means she will look for a clear articulation of the problem you’re solving, data to back up that this is a real problem, a clear articulation of how to measure success, etc. Historical trust with her helps.
  • If there are known truisms inside the company, she will call them out if you violate them. For example, in many consumer apps, more information density means every metric will go up. So in areas where we want users to take some action and she sees a bunch of whitespace, that’s going to get called out. Another example is that certain design patterns may have become core to the product and often it’s better for the entire system to maintain these. So if you add too much complexity to the system by creating multiple ways to do something, a good CEO will ask why you are introducing new ways to solve this problem instead of using existing design patterns.
  • A good CEO avoids micromanaging (other than CEO-pri things). Likely if you’re getting micromanaged, it’s because the team is broken and the CEO will work through her directs to fix the team and perhaps move people between teams. After seeing this a couple of times, you realize that good CEOs aren’t interested in design specifics on most things because it’s not scalable. Hiring great people, having good processes, and giving people autonomy scales far better. A good CEO moves people and risks thrash to get the best people on the most important problems. She doesn’t care about who owns what, because it’s all one company, and all that matters is the company’s success. This is at odds with how many people think about their jobs and careers, and takes some adjustment.
  • She isn’t afraid to call out organizational issues. For example, if a design solution seems suboptimal, she may probe and then ask if we’re doing this because it’s too painful to work with some other team or if this is really the best way to do it. Good executives will back-channel information to their CEO as well so she has additional context and can make moves as necessary. It’s awesome to know a great CEO won’t hold back on organizational/political issues and wants the company to globally do the right thing.
  • She shares context across groups by calling out why she thinks something is the case, not just what she thinks is true. This is useful because she sees information across teams in a way no one else does.
  • Good CEOs are extremely logical and operates from first principles. This means that if you go in again in a week, she will give you the same answers as last week because the answers are derived. If there is no logical reason for something (she just has a strong intuition), she will make that explicit. This is unlike a lot of leaders who conflate what they believe emotionally with what they know rationally. It makes great CEOs very predictable, which allows the company to scale.
  • Other times, she will have very strong intuition about key pieces of product strategy. This is informed by historical information/experience that something will or won’t work. These are almost always strategic calls – for example, what the default privacy model of a social product should be – not something at the pixel level. In these situations it’s best to take the feedback and decide if you agree/disagree. Ultimately code and data win. If the team disagrees with her intuition, they should find a way to test the CEO’s intuition and the team’s intuition and validate (maybe a user study, maybe a small test, maybe confirming the historical data she has in mind).
  • If the CEO asks for something, you are on the hook to deliver a follow up, even if all it does is prove her wrong.
  • Great leaders are comfortable with silence. They will sit silently to think through something before articulating what they believe and why. This can feel like an eternity and be very uncomfortable for new people. A good CEO will take this time because she’s trying to think through why she believes something so she can articulate the principles, not just the intuition.
  • CEOs have to be good at demonstrating positivity when things are going well. Many CEOs’ and founders’ natural inclination is to be critical and point out what can be done better (e.g. the countless stories about Elon Musk or Steve Jobs). This leaves people feeling like they are constantly failing because they receive little positive reinforcement and makes it challenging to calibrate when things are truly not going well. If the team is not doing the right things, great CEOs do not hold back. She makes it clear what she thinks this is a mistake and why. She does not do this in a personal way and focuses on the outcome.
  • Curveballs happen (this should happen in < 10% of reviews) when the team is solving the wrong problem. This could be because of information asymmetry or it could be because of a communication breakdown. For example, the team thought the CEO wanted us to solve X but she was simply using X as an example and wanted us to think about the generalized version of X.

C. After the review:

  • CEOs rely on senior people to interpret for the team. After every review, the team should debrief without the CEO, and the senior people in the room should interpret what happened. For example, the PM and designer on the team incorrectly thought they were being asked to change the design of X (interpretation #1). The senior person in the debrief clarified that the decision maker was really saying that the team had introduced a new way to perform X in the app, when there was already another way to do X. While the new approach maybe good, two different ways to do the same action will erode the system over time, and the decision maker was calling out this principle. So the team should go think hard about whether a new way to do X is good, or if we should just do X the same way it’s done in the other part of the app (interpretation #2). Interpretation #1 and #2 are very different and would send the team in very different directions.
  • CEOs rely on their executives to make people shifts. For example, maybe an engineer is too junior for the problem they’re being asked to solve. The CEO shouldn’t throw this person under the bus in a meeting, but will work through the leadership for the group who is in the review, get the engineer additional support and if it doesn’t get the team where it needs to be, work through her management chain to get someone more experienced on the team. All of this will happen behind the scenes. A good CEO helps people save face in public because good junior people who trust their management chain eventually become great, loyal senior people.
  • CEOs rely most often on PMs to collect and synthesize notes from everyone and circulate them to everyone impacted by the discussion — the team, engineers, partner teams, marketing, sales, etc. Writing things down removes ambiguity, keeps everyone informed, and allows people who weren’t in the room to ask for clarification. These notes should be sent out the day of the review so the context is fresh in everyone’s heads and any ambiguity is resolved quickly.
  • CEOs rely on product managers to schedule more time for subsequent follow ups. CEOs tend to have great memories because they live and breathe their product. No PM wants to get an email four weeks later asking what happened with the open questions from the review last month. That reflects extremely poorly on the PM (and the team).

Many of these principles will scale to other, non-product types of reviews, but some of these observations may not carry to all cultures or types of companies.

Thanks to Dan Siroker, Yin Yin Wu, Andrew Bosworth, Zohar Yardeni, Alex Himel, Pratiti Raychoudry, and Hema Budaraju for their feedback.

Cultural Competence

~ avichal ~ 9 Comments

What is Cultural Competence?

Core competence is a factor that cannot be easily replicated and gives the business a competitive advantage in delivering their product or service to customers. Core competencies are how a business does something.

Cultural Competence is the lens through which opportunities are identified and evaluated. Cultural competencies are how a business figures out what to do. [1]

Implications

Every business, no matter the size, has cultural competencies.

  • Cultural competencies are a reflection of the founders’ personalities. It’s no coincidence that Google was started and led by Ph.Ds, Apple by a designer-perfectionist, and Amazon by a quant from a hedge fund.
  • Cultural competencies are directionally set as you go from 0-20 people. If you achieve product-market fit, you will only deepen your cultural competencies. You can inject new culture via new (strong) leadership, but the existing leadership has to be receptive. The larger the organization, the harder this is.
  • Product market fit is easier to achieve if you work with your cultural competencies, not against them. Often times when a company builds the wrong product, the market they are pursuing does not align with their cultural competencies.
  • If you understand your cultural competencies, filtering potential opportunities becomes much easier. Be honest about whether or not the market you are pursuing can be won given your cultural competencies.
  • Don’t emulate another company’s cultural competencies, as many do against Apple. Pursue a market through your own cultural competencies to create a differentiated (and more successful) offering, as Amazon has done with Kindle Fire.

How do Cultural Competencies develop?

Cultural competencies are an emergent property of people in an organization. It starts with founders who pursue ideas and markets they understand. If they get traction, they hire a team that thinks about the opportunity similarly (belief in the vision). If they achieve product market fit, they hire more people. These people then pursue scaling a business in the way that has worked best thus far, reinforcing the cultural competencies and world view. This yields more revenue, which results in more people hired to support that core business. At each iteration, the new hires cause a deepening of existing cultural competencies.

An example: Amazon vs. Google

Amazon and Google share core competencies. They’re focused on large data problems, machine learning, exploiting massive infrastructure, experiment driven monetization, and more. They have non-overlapping core competencies, as well. Amazon has phenomenal customer support and logistics, while Google has deep expertise in search and performance-based advertising.

Given their similar core competencies, no one should be surprised that Google and Amazon both pursue the smartphone and tablet markets. However, their approaches are dramatically different because of their different cultural competencies.

Google’s cultural competence sees the world as signal and noise that must be filtered. A minority of the signal is commercially useful, and Google monetizes the shit out of it. This is how they manage to make money on search, email, and maps when few others can.

Amazon’s cultural competence sees the world as a series of transactions on which it can build a platform. Amazon pursues opportunities that will facilitate repeated transactions and then builds the platform to own all of these transactions. The Kindle was made to drive the sale of digital books. Free Shipping and Amazon Prime are levers to drive more sales on Amazon. It’s all about increasing and owning transactions.

How Cultural Competence Skews Perspective

For Google, Android is the key to owning mobile search and ads. Google’s cultural competence perceives Android as a moat for Google’s castle — search and ads. For Amazon, Android is about selling more video content, pushing Amazon Prime (which results in more sales on Amazon.com), and the Amazon Android Market (a digital goods store). Amazon’s cultural competence sees Android as a platform to enable more commerce and monetize directly.

Same platform, yet dramatically different perspectives, and ultimately different ways to extract value out of the ecosystem.

How Cultural Competence Impacts Product Success

It is not a surprise that Google makes a small amount of money directly from Android. Google’s cultural competence does not align with what the market demands from a direct monetization product — Google Wallet, Checkout, and the Play Market are examples of how Google fails because their cultural competence prevents them from building the right product.

For example, Google has rich analytics in the Android Developer Console and has search baked into the core Android experience. Given their cultural competence, it makes sense Google would prioritize these features. At the same time, the platform has no subscription billing and has yet to create a seamless integration of apps and content, 9 years after iTunes revolutionized digital content delivery. Google’s cultural lens has led them to either build the wrong product or be unable to come to a decision about what the right product is for a direct monetization market.

Meanwhile, Amazon has had no problem defining a transaction platform because of their cultural competence, and they execute on this market opportunity efficiently because their core competence is building transaction based products. Amazon has demonstrated this in multiple markets.[2]

Google’s lack of direct monetization from Android is not a surprise. Apple’s lack of monetization via iAds is not a surprise. Amazon’s lack of monetization through auctions is not a surprise. [3]

Credits

Thanks to Elad Gil, Curtis Spencer, Aditya Koolwal, Dan Siroker and Yin Yin Wu for reading drafts and providing input.

Appendix


1 – I just created the term “cultural competence” to apply to something that people have talked about informally for a long time, so the definition will likely evolve. The concept itself has been floating around in lots of brains for a long time. Edit: Turns out it’s been used in the HR world to mean something different (see comments below). So the definition in this post is more of a “secondary definition” than an “invention”


2 – Another Amazon vs Google example
Hosting platforms are another great example of how cultural competence skews outcomes. Amazon looked at Amazon Web Services the way they look at their retail site. Find the simplest set of things people will buy, then broadening out to related offerings. They manage inventory, demand, and have efficient pricing. Amazon figured out what developers wanted (S3 and EC2), sold it to them, and then expanded the offerings.

Google’s cultural lens skewed their perspective towards thinking that what developers want is the most efficient way to manage large amounts of data and not worry about scaling. Most businesses don’t have Google scale problems and don’t want Google’s internal platform approach to manage their non-Google problems. They need something that works with existing (open source) systems and leaves them the freedom to customize infrastructure. Google tried to apply it’s cultural lens to a market, rather than find a market where it’s cultural competence would give it a competitive advantage.

Hosting is fundamentally a retail problem, not a signal vs. noise problem. Amazon Web Services does $1 Billion in revenue and Google has been tweaking App Engine for years. This is a prime example of how to filter opportunities and pursue ones that align with your cultural competence.

3 – Examples of Cultural Competence Failure
Companies that have a strong cultural lens will stay focused and thrive. Those that dilute their cultural competence die because they lose a very important filter for which ideas to pursue and how. Companies that try to build outside their cultural competence tend to fail as well.

  • Apple – Apple’s cultural competence is finding large industries full of geeky products and Apple’s core competence is building simple, cool status symbols in their place. Laptops, desktops, phones, and music players are all examples. Ping (their music social network), MobileMe, Pages/Keynote/Numbers, and iTunes are great examples of where if the product succeeds by piggybacking on their hardware business, not because it’s a great in its own right.
  • Facebook – Facebook’s cultural competencies lie in identifying opportunities to enable sharing. Every software, app, or platform upgrade is about fostering more connections and data flow between people. Facebook sees markets as an opportunity to get users to share more, find out more about their friends/connections, and elicit relationships (family, friends, worked with, who likes whom) that were previously unknown. When they try to extend this into another area, like daily deals, they don’t do well. Daily deals are not about the relationships between peers, they’re mostly about Facebook’s relationships with merchants.
  • eBay – has core competencies in peer-to-peer transactions (sometimes with goods changing hands). eBay’s cultural competence is around bringing groups of people together into a marketplace and getting them to trust each other and the marketplace. When they diverged from this (Skype, StumbleUpon) they failed. When Skype and StumbleUpon spun out from this cultural lens, they thrived. When eBay applied their cultural competence to Paypal, it worked beautifully because Paypal is fundamentally a trust network.
  • HP – has core competencies in manufacturing, distribution, and enterprise sales. What is their cultural lens? How does HP decide what opportunities to pursue and how to leverage its core competencies? They’ve floundered on this for quite some time.
  • Microsoft – has core competencies around desktop software, business applications, and selling through enterprise distribution channels. Their cultural competence has always been finding ways to make businesses more efficient with their PCs. They make a healthy profit in their servers and tools division since this aligns nicely with their cultural lens. Every time they stray away from this cultural competence, they struggle. Signal vs Noise businesses (Bing) burn cash and Entertainment (Zune, Xbox) operates at break even.

Good resumes vs. Great resumes

~ avichal ~ 2 Comments

Below are three traits I’ve noticed all great resumes exhibit. This is not an exhaustive list and applies to the for-profit and non-profit sectors. Academia, art/music, and other fields likely exhibit other dynamics. I’m hoping to be helpful by sharing some tips I haven’t seen mentioned before.

Great resumes:

  1. Quantify accomplishments
  2. Focus on skills acquired and required, not activity
  3. Think about a career stepwise

1. Quantify accomplishments

Quantifying accomplishments allows others to understand impact and demonstrates that you measure things. People who are in the mindset of measuring are the ones who improve most over time. And if you aren’t measuring yourself, then you probably aren’t measuring other day-to-day things like your team’s progress or your employees’ progress. Using numbers is a nice way to have the data stand out from the surrounding text and save space.

2. Focus on skills acquired and required, not activity

Most people talk about what they did instead of what they had to learn and how they learned it. Great companies look for someone who will excel at the required job, but who can grow into a larger role as well. Since there is rarely a perfect candidate, finding someone who can do 85% of a role and can grow into the other 15% is often the best hiring strategy. The best indicator of how you will grow is how you have already grown.

3. Think about a career stepwise

The jobs you’ve held should be the steps to reaching your dreams and ambitions. The best candidates think of the job for which they’ve applied as a stepping stone to these goals. Show how each position you’ve held built on the previous positions and it should be clear very quickly to someone scanning your resume that you’ve purposefully developed skills and progressed over a career.

You should also project this forward. Why is the job you’re applying for a natural extension of what you’re currently doing?

Examples

Not Great:

  • Work with a team to provide reliable tracking of users (Flurry, Mixpanel and custom tracking tools) and to analyze customer behavior through frequent analysis of usage statistics and power users.

Better:

  • Implemented user-metrics tracking that resulted in 50% faster resolution of support issues and a 25% drop in in-bound customer support requests.
  • Analyzed customer behavior to proactively identify power users, resulting in 10% faster conversion of free users to paid and was part of an effort that increased sales $250,000/year.

Not Great:

    Some University (Sweden), Bachelor, Software Technology Programme, 2009

  • Awarded President’s Scholarship
  • Bachelor Thesis: Comparative Analysis of Development Frameworks

Better:

    Some University (Sweden), Bachelor, Software Technology Programme, 2009

  • Awarded 100% scholarship, offered to 5 students per year
  • Bachelor Thesis: Comparative Analysis of Web Development Frameworks, available at: http://www.someURL.com

Not Great:

  • Developed websites for clients. Included database design and implementation, use of the Model-View-Controller methodology and creation of unit tests. Involved extensive use of PHP / CakePHP and MySQL, HTML, CSS, XML, Ajax and JavaScript.

Better:

  • Designed, architected, and developed websites for 12 clients in 6 months.
  • Learned Model-View-Controller paradigm using CakePHP, MySQL, HTML, CSS, and Javascript in 2 weeks to launch our first client’s website.
  • Developed a custom unit testing framework in 1 month which resulted in a 25% reduction in bugs per client over the life of a project.

Not Great:

  • Led several projects and initiatives involving the automation of previously manually tested functionality and migration of data to a database.

Better:

  • Led team that automated testing tasks that previously took 50 hours per launch, saving 5000 hours/year.
  • Promoted to database administration team after 6 months. Self-learned SQL and helped migration to scalable database systems that could handle 10x more load.

Not thinking about a career stepwise:

  • Company1  – Premiere Field Engineer (Sept 2009 – Sept 2011)
    • Engineered some project and worked on a team that did something
  • Self Employed – Independent Consultant (Sept 2007 –  Sept 2009)
    • Technical consulting in IT and security projects
    • Trainer in courses for MCSE and MCSA
  • Company3 – Trainer & Engineer (June 2004 – June 2007)
    • Trainer for Microsoft certified Systems Engineering courses
  • Self Employed – Independent Consultant and Engineer (June 2002 – June 2004)
    • Security Consultant
    • Trainer and Consultant with deployment software

Stepwise positioning, with a clear building and career progression:

  • Company1  – Premiere Field Engineer (Sept 2009 – Sept 2011)
    • Engineered some project and worked on a team that did something
    • Led Europe’s leading IT support company in initiatives to educate and train 450 support staff in Microsoft technologies
  • Self Employed – Independent Consultant (Sept 2007 –  Sept 2009)
    • Started consulting business to train others for MCSE, MCT, MCSA
    • Consulted 45 companies on best practices for IT, security, & Citrix projects with an average class size of 23 trainees
  • Company3 – Trainer & Engineer (June 2004 – June 2007)
    • Earned MCSE, MCT, MCSA certifications
    • Promoted to train others in the company on Microsoft certifications
    • Developed xyz things for the company
  • Self Employed – Independent Consultant and Engineer (June 2002 – June 2004)
    • Security consultant focused on training new engineers on best practices for building secure software

Focus on building 10x teams, not on hiring 10x developers

~ avichal ~ 148 Comments

There are a lot of posts out there about identifying and hiring 10x engineers. And a lot of discussion about whether or not these people even exist. At Spool, we’ve taken a very different approach. We focused on building a 10x team.

We believe that the effort spent trying to hire five 10x developers is better spent building one 10x team.

10x matters because of the Economics of Superstars

The “Economics of Superstars” observes that in some industries, marginally more talented people/groups generate exponentially more value [0]

The Economics of Superstars phenomenon requires a distribution channel to move a large volume of goods. For superstar athletes, television enables endorsements and merchandise sales. For software developers, the Internet enables scalable distribution of digital goods.

Finding a way to be 10x better than median can now generate exponentially more value for people who make digital goods.

In software, the superstar is the team, not the individual

In the Economics of Superstars, if an individual has tremendous control over the outcome (points scored in a basketball game), that individual is the beneficiary. So Kobe gets a big chunk of the value he generates for the team, stadium, and advertisers.

Software development, however, is more like rowing. It’s a team sport that requires skill and synchronization. This applies at all scales. On a three-person boat, one person out of sync will stall your boat. As you get bigger, no single developer can impact your team’s performance, so again synchronization is key.

Making your team as efficient as possible is what determines long-term success. [1]

A bunch of 10x people != A 10x team

Most hiring processes assume that if you find a great developer and put them on a great team, the individual and team will do well. Good teams try to nail down “culture fit” but this is usually only based on whether the candidate gets along with the team.

Throwing together a bunch of great developers who get along does not make for a 10x team.

How to Think About Building a 10x Team

Building a 10x team is a different task than trying to make an existing team 10x more efficient. The hardest part about building a 10x team is that who you need next is a moving target because it’s a function of who is already on the team.

The following are the top three non-technical questions we (Spool) ask ourselves when considering a candidate:

  • Does this person extend the team’s one strategic advantage? Successful startups do NOT have world class design, engineering, sales, and marketing all at once. They tend to be phenomenal at one thing and competent at the rest. Eventually they upgrade talent for “the rest.” For example, Zynga first nailed virality with crappy graphics, then later upgraded their art teams.
  • Is there enough shared culture? – Communication overhead will cripple most teams. Hiring people with a common culture is the simplest way to solve this problem. For example, alums of a university tend to use the same  jargon, think similarly, know the same programming languages, etc.. They will communicate naturally and are free to focus on higher order problems. It’s not a surprise that Paypal was mostly UIUC, for example. At Spool we’ve consciously hired mostly Stanford alums because Curtis and I are Stanford grads. Update: I apologize if I gave the impression that we don’t value diversity. As you can read in the comments, we’ve gone out of our way to build a diverse team. But there are many things that don’t impact your success early that you can short-circuit by picking people who have a similar enough background. Goldilocks Principle ftw 🙂
  • Does this person make other people better? A friend once told me that the best hire he made was a mistake. Had he properly screened this candidate’s technical ability, he wouldn’t have hired the candidate. But it turned out this engineer was so driven that he immediately made everyone else on the team more driven. Just by hiring him, the team became more productive, which far outweighed that individual being an average engineer. It’s sometimes worth trading off some technical ability to get a multiplier for your whole team.

What sorts of people make other people better?

When we were building Spool’s founding team, we looked for people who were technically solid but especially good at making other people around them better. The following are the types of people we identified that do this. There are probably others.

  • The Lead Engineer  sets the technical standard. She will conduct the hardest interviews and will generally work technical magic. She will raise everyone’s technical bar. This is usually what someone says when they mean 10x developer.
  • The Hustler will bend the rules a little when need be, find loopholes in a system, find people you need to find, hack together systems to extract data, and set the standard for just getting things done. She challenges everyone’s thinking about how to get things done.
  • The Little Engine That Could refuses to lose. She manages to do great things through sheer determination. Sometimes she will tell you about this in an interview, but many times you will need to dig into someone’s background to get a read on this. She makes everyone else more driven, focused, and makes them believe great things are possible.
  • The Teacher soaks up and disseminates information. A teacher is constantly learning new technologies or synthesizing large amounts of information. She then distills the critical points and actively shares them with others. She makes everyone more productive almost immediately. This adds up tremendously over the years.
  • The Anti-Pinochio  is willing to call b.s. on anyone, including the CEO. She is great at spotting b.s. and willing to ask questions of anyone. This keeps a team honest and a company transparent. This is different from being an asshole or a heretic.
  • The Energizer Bunny throws herself into a task fully and doesn’t have an off switch. She gets everyone to give 100% and is so enthused that everyone else becomes enthused. She sets the bar for effort and make everyone want to work harder just so they don’t disappoint her. This extends outside work too. She’ll be the first person at the party, the last one to leave, and will make everyone have more fun every day. Happy, enthusiastic teams are productive teams.
  • The Heart – this is the person on the team that everyone misses when she’s not around. She’ll bring cookies in for the office, she will remember birthdays, she will make people feel better when they’re down, and she will make people do great things because she’s just so lovable. People want to come to work to see this person everyday. Just having people look forward to showing up every day is a huge productivity boost.
In the following diagram, each color is a team-member rated from 1-10 on these characteristics. You can see that there’s a big hole with no color. I would gladly say no to a traditional 10x engineer to get one person with tremendous grit/determination on this team.

These personalities all play off each other. For example, a Teacher loves working with an Energizer Bunny because there is someone around to soak up all of that knowledge she shares. Or a Hustler and Lead Engineer can combine to uncover a new distribution channel because they iterate fast and are ruthless. As a result of having these people, you get massive productivity gains from complementary personalities and abilities. Combine these with your favorite/appropriate software development methodologies and you’ve got a killer team.

I’m sure there are other people who have techniques for building 10x teams. And the dynamics of what makes for a great team are going to be different across industries and stages of company. If you’re reading this and have thoughts, please do leave a comment. I’d love to incorporate it into our hiring practices.

Footnotes

Thanks to Curtis Spencer, Christine Tieu, Aditya Koolwal, Chandra Patni, Daniel Witte, Shazad Mohamed, Blake Scholl for reading drafts of this and providing input.

[0] – More on the Economics of Superstars

For example, Kobe Bryant is in the 99.999th percentile of ability, while the median NBA player is in the 99.99th percentile. For that small percentile improvement in ability, Kobe Bryant generates millions more in ticket sales, merchandise, concessions, and tv advertising for his team. This pattern repeats every where and is starting to appear with software development teams and startups. If you’re good, you can be Facebook, Google, Dropbox, etc. If you’re not, you can’t get a series A to get off the ground.


[1] Evidence building 10x teams matters more than finding 10x individuals

[2] – “Crazy” offers from Google/Twitter/Facebook/etc.

Historically, engineer/product manager/designer salaries have been relatively constrained (red line below). This is because we lacked an efficient distribution mechanism to take advantage of their special talents, so teams had to be very large to achieve scale and no individual could easily have massive impact.

But we are experiencing the beginnings of a world where the Economics of Superstars applies for small 10x teams because a small team can use Internet distribution as leverage. What is really interesting is that retention packages now are not about the individual. They are about keeping 10x teams together. The people who are really getting great retention bonuses are the people who make 10x teams possible. They are either the leaders in a product or engineering organization that know how to build 10x organizations, or they are the employees who make everyone around them better, or they are key employees whose departure would be seen as a signal that the team is no longer a 10x team. These packages are also a defensive move to prevent competitors from acquiring the building blocks that enable 10x teams. Losing key members of a team will result in other members leaving, and will enable the competitor to aggregate a team that operates like a 10x team. It’s not about the individual; it’s about team dynamics.

Another example from Google is how well they reward great teams and keep them together. Google’s Founder Awards disproportionately reward the best teams internally for exceptional accomplishments.

It seems like we’re moving to a world where a great team of developers can make $300k+/year each. But not by just walking in the front door — it really messes with team dynamics and manager-employee dynamics to hire people with those sorts of salaries. But rewarding a team and keeping great teams together is much easier to justify.

How the Economics of Superstars will play out for 10x Teams

[3] – More on Talent Acquisitions: Talent acquisitions are like record contracts

Startups eliminate the guess work that a large organization has in identifying teams with 10x ability. The startup ecosystem is as close to a meritocracy as we have — no bureaucracy, no legal department, no recruiting pipeline, minimal funding required to get started, etc. If a five-person team manages to build something and get any traction, they’ve accomplished something tremendous.

Identifying startups with 10x teams, is like a scout going through YouTube to find the next great band. If you find raw talent and give it the right platform (publicity, marketing, new instruments), you can turn that talent into something huge. Industries that have recognized their industry operates under the economics of superstars take these bets regularly – think about the English Premiere League, NBA, music industry, film industry, publishing industry, etc. If a bet pays off, you get Ronaldinho or The Beatles. Would you have given the following talented band $1 million/year and have full rights to all of the revenue they generated?

The Beatles before they were The Beatles

(This is The Beatles before they were The Beatles)

Again, because software is complex and you need teams to execute, the value aggregates in the team, not the individual. You rarely see Google hiring random individuals for $2.5 million over 4 years. Google, Facebook, Twitter, Groupon, etc. are paying to keep teams together and working on the things they’ve developed expertise in. These acquirers understand that it’s about finding 10x teams and giving them the resources of a bigger company. $10 million for four people over 4 years is worth it for many acquirers, because the incoming team has to be marginally better and the result will be exponential value generated for the acquiring company .

Amazon owning app distribution is irrelevant

~ avichal ~ 10 Comments

Some people are writing about how Amazon is going to steal Android app market distribution away from Google. Not only is this statement incorrect, but it is a clear misunderstanding of how Google and Amazon think about Android. I’ve worked at both Google and Amazon, and have written apps for both iOS and Android, so I’m going to chime in.

Amazon won’t own the app market

Amazon is going to be one tablet manufacturer and maybe one phone manufacturer. Even if Amazon owns 20% of all Android devices, they will have the same share as Samsung and less share than HTC and Motorola have in phones (see below). Or, let’s be generous and assume that Amazon manages to sell the same number of total tablets as the iPad — 40 million by Apple’s count for both iPad + iPad2. That total number of Amazon tablets is as many Android phones as are currently being activated every quarter. Let’s get real: Amazon will not have the leverage to do any serious damage to Google’s hold on the pre-installed App Market bundled with Android (which powers both tablets and phones).

Android Manufacturer Market Share

Google does not care about app sales

Even if Amazon does own the app store, thinking about app sales is a failed attempt to apply Apple’s iOS model to a totally different ecosystem. Android does not work like iOS because Google has different priorities than Apple. Google is a search company. Owning the platform is Google’s way of making sure they own search — both on the web and for apps. Google makes over $30 billion in revenue from search. The revenue that flows through the app market to Apple is about $1 billion ($3B in sales, $1B flows to Apple). Google does not care about facilitating app sales because they can make 15-30x the money from search.

Furthermore, Google clearly believes that the web will win out in the long term and native apps are a stop-gap, so they are skating to where the puck will be — open and web based. Google saw this with AOL and hand curated directories like Yahoo in Internet 1.0 and is betting history will repeat itself. Even if apps stick around, Google wants to own search on top of the apps just like they do on the web and they’ll monetize the hell out of that. Google does not care about owning Android or the app market for app sales. They want to own search.

Amazon does not care about app sales

Kindle Fire is about selling more digital content and facilitating e-commerce. Apps happen to be one type of digital content, but they’re far from the focal point for Amazon. Amazon is the world’s biggest online retailer. They want you to buy stuff on Amazon.com. From free shipping, to Amazon Prime, to Kindle 1.0 it’s always been about getting you to spend more money on Amazon. Tablet users love to buy stuff online. The Kindle Fire is about facilitating old school e-commerce. Owning 20% of app sales is lame. Owning 20% of e-commerce on tablets is what Amazon is salivating over. Instant Video and having an App Market are nice secondary revenue streams, but a drop in the bucket to what Amazon does in it’s core commerce business. Amazon would make the Kindle Fire if they were guaranteed to make $0 on app sales because they will make billions on increased commerce.

Amazon “owning” app distribution is not only wrong, it’s irrelevant. It misses the point of Android and is a fundamental misunderstanding of Google and Amazon.

Camping Out for MacWorld

~ avichal ~ 1 Comment

On January 8th, 2007, a group of young product managers from Google camped out on the sidewalk in San Francisco to ensure their spots in the main room for Steve Jobs’s keynote at MacWorld 2007.

What follows is a transcript of the night’s events, with photographic evidence.

December 7, 2006 (3:30 PM) – At a monthly meeting of Associate Product Managers and former Associate Product Managers (now Product Managers) a debate rages about whether anyone in their right mind would actually camp out for MacWorld. Jeff Bartelma, a PM on Google Book Search, has already committed to spending the night. Clay Bavor, PM on Google Base, and Avichal Garg, PM on Ads Quality, follow suit. Nick Baum (PM on Google Reader), Clay Bavor, Diana Ly (PM for the Associates program), and Avichal Garg become unofficial organizers of the camp out event.

Early January – Rose Yao, PM on Google’s Mac Initiatives, convinces her engineering team to join in the camp out.

Google Mac Team

(The Google Mac Products Team)

January 8, 2007 (3:00 PM) – The day of the campout! Rose Yao IMs Avichal Garg asking if we should bring tents and asks if we need a permit to sleep out on the sidewalk. Avichal Garg responds, “huh? permit?” and claims ignorance when it is suggested he should be organizing this camp out event.

January 8, 2007 (5:00 PM) – Avichal Garg goes home to pack a night’s worth of belongings. Realizing he has no need for anything beyond his laptop, he takes a nap.

January 8, 2007 (6:30 PM) – Frances Haughen, PM on AdWords, Avichal, and Aneto Okonkwo, PM on Google’s logging infrastructure, discuss how arriving in San Francisco by 8PM is a must to pick up badges that night; otherwise they may lose their spots in line the next morning.

January 8, 2007 (7:00 PM) – Frances describes how clutches can fail in manual transmission cars and the symptoms of such a failure. She mentions her car has been exhibiting some of these symptoms for several weeks and that she is planning to take it in for a checkup tomorrow.

January 8, 2007 (7:30 PM) – The clutch goes out.

January 8, 2007 (7:40 PM) – Aneto and Frances debate whether or not it is in fact the clutch or if France’s car ran out of gas. Aneto explains the detailed workings of an internal combustion engine while Frances provides irrefutable emperical evidence that her car still has gas by turning it on. The car does turn on but does not move forward. Avichal ignores them both and thanks God he brought his Edge card so he can have Internet access on his laptop.

January 8, 2007 (7:43 PM) – Dan Siroker, a PM on AdWords, drives past a stranded car on Highway 101 and wonders if they might need help. He considers pulling over to help them, but recently having seen “Signs” by M. Night Shyamalan is afraid. Instead, he curses at them for slowing down traffic and potentially preventing him from getting to San Francisco by 8PM.

January 8, 2007 (7:45 PM) – Frances calls AAA and they “will send someone immediately” because she is on an extremely dangerous shoulder on 101. At approximately the same time, Clay calls Avichal asking where he is. Avichal says, “On 101, just hanging out.” Clay laughes but doesn’t get the joke until Avichal explains.

January 8, 2007 (7:51 PM) – Clay devises a plan to get Frances, Aneto, and Avichal their entry passes for MacWorld before registration closes at 8PM. He will have other Googlers impersonate them: Clay will be “Avi-hkhaahl” – a Hebrew interpretation of his Hindi name, Ben Lewis will be Aneto, and Rose will be Frances. Avichal is skeptical that 2 White men and an Asian woman will pass for a Nigerian (Aneto), an Indian (Avichal), and a 6′ tall Sweedish woman (Frances), but trusts Clay and co. will be successful. It turns out that MacWorld registration involves neither security nor ID checking, as badges for all 3 stranded PMs are secured easily.

January 8, 2007 (8:00 PM) – A California State Highway Police Officer shows up and sees if we need help. Frances turns on the car and it lurches forward 20 feet before dying again. The CHP is kind enough to stay with them until a tow truck arrives.

January 8, 2007 (8:10 PM) – The group of PMs and Engineers who now have their badges debate whether or not to start camping out and be first in line for the keynote. They decide that no one will really start camping out that early and instead opt to get food and drinks at a nearby pub.

January 8, 2007 (9:40 PM) – All PMs and Engineers meet up at Moscone Center West to start the campout to find that 3 crazy Apple fans are now first in line. They are simultaneously annoyed, amused, and grateful they won’t have to deal with bloggers interviewing them all night and asking why they are motivated enough to be first in line. Enrique Munoz Torres, a PM on Book Search, drives up on a motorcycle shortly thereafter, does not say a word, drops off a case of beer, and rides away.

Our Campsite

(The Google Campsite Outside MacWorld)

January 8, 2007 (10:00 PM) – 2 really attractive women walk by the campsite and ask what is going on. Nick and Avichal claim they thought this line was for Justin Timberlake tickets. The women laugh and walk away; Nick and Avichal debate whether the women were laughing with them or at them.

January 8, 2007 (11:00 PM) – The world’s most hardcore Apple fan comes by for a photo-op. No, seriously. Notice his tatoo. He had an LED belt that flashed “Thank you Steve!”

Uber Apple Fan

(The World’s Most Hardcore Apple Fanatic)

January 9, 2007 (midnight – 2AM) – Numerous “reporters” and amateur film makers stop by to interview the people first in line. The first-in-liners bask in their new found fame while the second-in-liners enjoy some beer.

January 9, 2007 (2:30 AM) – Shirin Oskooi, PM on Google Calendar, and Avichal go to Denny’s so Avichal can charge his laptop. Shirin is convinced that Azekial, a homeless man she and Avichal once hung out with in San Francisco, is eating at this very Denny’s.

January 9, 2007 (2:30 AM – 5:30AM) – Almost everyone sleeps. Nick and Avichal continue their debate about whether the women were laughing at them or with them.

Mac Team Sleeping

(Googlers Sleep in a Giant Clown Car-esque Tent)

January 9, 2007 (5:30 AM) – TV reporters start to wake up the campers with their annoyingly bright lights and “Live Local News at 5:30 before anyone in their right mind should be up!” interviews of the first-in-liners.

Outside MacWorld (in the morning)

(Campers Are to the Far Left)

January 9, 2007 (6:00 AM) – The campers commemorate the occassion with a group picture.

Group Photo

January 9 (8:00 AM) – All attendees are herded like animals into a giant holding pen. The campers are convinced that their commitment will result in a great seat in the main room. They are disappointed to learn that anyone with a premium pass (all 1000+ of them) will be seated before them and thus they will not have a good seat afterall. In fact, the room this year is much larger and likely there will not be an overflow room at all.

Inside the waiting room for MacWorld

(The Holding Pen)

January 9 (8:30 AM) – In a sleepy haze, Avichal finds the conference organizers and suggests they use a quality based model analogous to the Google advertising auction that takes into account not only the amount paid per seat but the amount of time invested as a proxy for user loyalty. He claims such a system would result in a more fair distribution of attendees in the main room and would generate both short term revenue while generating long term loyalty in the Apple user base, and compelling more users to camp out for even longer, thereby generating even more buzz and press around MacWorld.

January 9 (8:45 AM) – MacWorld organizers tell Avichal to get back in line before they throw him out. He gets them to agree to consider his ideas for next year’s MacWorld.

January 9 (9:00 AM) – Steve Jobs unveils the iPhone, one of the best designed products of the last decade. He is in his element. As one executive at Google put it, “Being invited to go on stage with Steve is like the kiss of death.” All you can hope is that you walk on, get off the stage as quickly as possible, and pray no one remembers you were there. If people remember you were there you know you royally screwed up.

January 9 (Noon) – PMs and Engineers return to Google in Mountain View for meetings and work, exhausted but satisfied they saw Steve in person this year.