Being in control versus being a control freak in a lean startup

by Jennifer Hepworth

I’ve been thinking a lot recently about the notion of control. I’m generally a person who feels most comfortable in the driving seat, having decided on a destination, figured out the best way to get there and chosen the sound track. This attitude has gotten me a lot of places, and I think a strong sense of personal responsibility for outcomes is an important quality and a Good Thing.

However.

There’s a line. On one side of the line is being in control and on the other is being a control freak. I’m not saying I’ve been there and made large and messy mistakes and learned the hard way that control-freakery must be avoided, but I’m fortunate enough to have met some very smart people with relevant things to say on the topic which will hopefully prevent me from heading down that path.

1. Great entrepreneurs know what they’re bad at, and hire awesome people to do it for them (Mike Cassidy).

In some ways, Steve Jobs was the consummate control freak (just check out Apple’s wheels within wheels org chart), and he certainly liked being in control. However, though he was clear on the engineering goals he set for his products (extend the battery life! EXTEND THE GOD DAMNED BATTERY LIFE!!!!!) he didn’t care how those goals were achieved. Despite being able to code, his gift was in marketing and design and from the very start of his career he left the engineering to other more capable people, like Steve Wozniak.

2. Take on the tasks dictated by your comparative advantage (Jeffery Bussgang)

This is subtly different advice from point 1. There’s a chance you already know what you suck at, in which case you may follow point 1. and stop reading now. However, just in case you’re one of the tiny number of people who are demonstrably great at everything, or a member of the far larger group of people who believe they’re great at everything, read on. Say you’re better than everyone in your company at identifying new product features, UX design, marketing and sales. First, I would say someone’s done a pretty crappy job at hiring. Second, I would say IT DOESN’T MATTER. It only matters where your relative strength lies. If you’re great at everything, but really really great at sales, you should devote as much of your time to this as possible, off-loading those tasks where you don’t have a comparative advantage to someone else. In a world of finite resources (in this case your time), you maximize your productivity by focusing your efforts on those areas where you’re, you know, most productive.

A few days ago we had a great class with a successful entrepreneur and class guest who readily admits to falling victim to some aspects of control-freakery (though let’s call him a Hero CEO out of respect). In 2010, with a decent sales model and a customer lifetime value easily in excess of 3x the cost of customer acquisition, he was reticent about accepting an unsolicited offer of additional funding from one of their investors to ramp up their sales force. The reason? He felt uncomfortable with the loss of control which inevitably comes as you grow your organization (in his case, to a VP of Sales). He did end up taking the funding, and the company has grown successfully a result, but the fact that decision was delayed and an opportunity could have been missed provides a salutary lesson to anyone who catches themselves trying to dip their fingers too deep into too many pies.

Easier said than done, but maybe next time I’m driving I’ll let someone else chose the radio station.

Read More

Creating Culture Through Prototype Development

by Aunim Hossain

Baller.  You’ve spent months running around, talking to everyone you know (or don’t know), attending conferences, scouring the online job resources…all with the goal of building your dream team that will take this from a great idea to a company that will change the world.  And you rocked it.  You have the team you need: one product manager (you), three developers with front-end and back-end skills, and one artist/UI guru. 

You feel like you’ve arrived.  You say to yourself, “now, it’s all about getting it done, but that should be pretty simple with the team of ninjas I assembled, right?”  But this is where many promising founders stumble.  Even with the right team in place, success is not guaranteed.  While there are many variables that determine success, one of the most important variables that founders can control (and often don’t) is building the right culture. 

Culture is created through the processes that founders and the team members put in place to complete tasks.  As those tasks are completed, the team figures out which processes work and which should be revised.  When a particular process becomes second nature for the team to complete a certain task, it has effectively become culture.  As founders, it is our job to guide the creation of the best processes and make sure that the processes that become culture are the right ones for the team. 

In this post, I hope to start a list of the best processes that have come to define the culture of our team.  In this first try, I’ll talk about our experiences with communication and time management.

So tell me what you want, what you really really want… 

Oh those Spice Girls were sages.  And it makes sense that they knew what they were talking about when it comes to communication: they were a startup had to manage a team of five divas.  In our startup, with my own team of seven divas, we thought that putting everyone in a room together would ensure strong levels of communication.  But several major problems from spec misunderstandings, to code deployment issues, to artist delays continued to creep into our work hours.  In the end, we figured out that the fundamental issue was a lack of communication.  Although we’re still working a lot of these issues out, here are a few processes that we’ve put in place that will hopefully create a culture of over-communication within our team:

Create a Backlog of Detailed Specs:  As the product person, my ultimate goal is to take the idea that is trapped in my head and make it real.  But because I need help from other people to make this happen, my first task is to take the idea that is in my head and put it in the heads of everyone on the team.  Now before we figure out how to really do mind-melds, we have to rely on specs.  So make your specs as detailed as possible.  Don’t assume that your team will fill in the details, because where there is uncertainty, there is room for miscommunication.  Also, if there is a feature that is important in the future, don’t wait to write the spec.  It is critical to build a long backlog of specs so that the team knows where the product is going and they can build functionality to be flexible and accommodate what’s coming next. 

Daily Scrums:  Although we started this practice on our first day and most teams use this process, I know that it has been instrumental to our team’s cohesiveness.  Functionally, a Scrum for us is a daily team meeting that lasts only 30 minutes (everyone is standing up so that it’s clear that the meeting will be short).  One by one, each person has the floor and talks about what they worked on yesterday, what they are working on today, and any questions that they have for other people.  After setting it up, our team started using it for functions that I had not thought about before I saw it happening.  For example, we use it as our daily deliverable when I am able to see where we are at on the code and art.  Other team members use it as a way to make sure they are on the right track when solving a problem.  Other team members use it as a way to look at the big picture of what we’re doing and get pumped up about our progress. 

Other Practices: We set up skype chat for each of the team members so that communication lasts all day.  Often, there is a tremendous amount of collaboration that happens in a seemingly silent office.  We also set up a wiki that documents, in a central place, the components of each of our Sprints, and what everyone is responsible for.  It is a constantly evolving document that is primarily updated by me, but it is very helpful in understanding what people are working on in the long term and where there may be gaps. 

In the end, as we set up all of these processes, the most important lesson that I have learned is that great communication starts at the top.  Unless you demonstrate that you are communicating yourself, your team members will likely not communicate either.  For example, if you say that everyone on the team should email whenever they have questions, it will probably take several emails from you before the team buys in and takes it from there. 

Time is on my side, yes it is…

In this section, we learn from the Rolling Stones.  It’s an ageless, optimistic message that runs in contrast to the typical entrepreneur’s mindset, that stresses impatience (and the cornerstone of lean methodology).  Now, I definitely agree with this mindset: we can’t just sit on our ideas while someone is out there hustling with a similar one; we can’t just keep working on prototypes without getting them out to users who can teach us; we can’t go back and spend days cleaning up code when there is so much to be done with our existing code base.  I agree with all of that.  What I don’t agree with, however, is the mentality that time is the enemy.  As a founder, it is important to frame time as our friend.

This is an important lesson for me because I was always under the impression that, by setting stretch deadlines, I could get more out of me and more out of the team.  By framing our work as a race against time, we could encourage hard work and higher performance.  However, this view has only served to make us look at the short-term goals and lose track of the long-term needs of the company.  With time as the enemy, we introduced all-nighters, hardcoding, a lack of flexibility, low morale, and stress into our processes.  By doing so, we ended up being more behind in reaching our goals.  Thus, these processes below ensure that we all look at time as our friend in product development:

Balance Speed vs. Scalability of the Code: When your team is “costing out” features (determining how much development time, cost, and art is needed for a feature), it is important to tease out the real tradeoffs between getting done on time and the corners that will need to be cut.  For the product person, it makes sense to include the entire wish list in the spec, but you should be aware of what tasks are vital and which can be pushed.  As an engineer, it is vital that you understand which shortcuts can be used now to meet this deadline, and which shortcuts don’t make sense because it’ll take more time to revisit three deadlines down the line.  It’s very hard for everyone to understand these tradeoffs, especially early on in the development cycle. 

Therefore, I believe that it is important to set easy deadlines with several days of cushion for the first few sprints.  This will give the team the flexibility to focus on building scalable code early and establish understandings of the tradeoffs that they will have to make later.  Technical debt is inevitable, but it should be avoided early because it compounds.  As the team learns more about how they work together and about where the product is going, the deadlines can become tighter.  But early on, focus on the scalability vs. speed.

Establish Best Practices…before you need them:  When you believe that time is on your side, you can spend some time thinking about what processes you will likely need in the future and build to them now.  By doing so, the team can learn how to use them before they are really in a jam.  On our team, we set up bug tracking through Bugzilla, subversion hosting and deployment through Beanstalk, and other systems before we had bugs and multiple developers in the code.  By doing so, we were able to create a plan for scaling so that when we hired people, they could get ramped up quickly.  Indeed, if you can take the time to look ahead and plan for the future, you can save a lot of time today.

Now, there are only a few lessons that I have learned as we tried to create a culture through the prototype development process.  In your comments, please feel free to comment on these processes, but also feel free add your own best practices.  I’m looking forward to reading them.

Read More

Crossing T’s and Dotting I’s: Which Should be Done First?

By Mosbah Kahaleh

In the process of learning and practicing entrepreneurship, I have been wrestling with the question on whether entrepreneurs should start with good ideas and then build teams around them, or if they should start building the ‘right’ team that will eventually find the right idea. In the context of lean start-ups methodology, my hypothesis is that the later approach (i.e. starting with teams) is more consistent with the lean startup methodology. 

The rationale behind the hypothesis is the following: when entrepreneurs start with ideas or industries, they tend to build teams with relevant experience or skill set related to an industry or technology that their idea is based on. Their main objective is to find people who are excited about their idea and can contribute value in transforming that idea to reality. In so doing, however, these entrepreneurs are building up higher transaction costs if they choose to pivot to new industry or technology that would require a new set of people. Conversely, when entrepreneurs start with the ‘right’ co-founding team, who has complementary characteristics, they open themselves to be more agile, lean and feedback-driven as they have little attachment to any specific idea, and thus capable of “achieving failure” that will lead them forward. 

An example that comes to mind is Communispace, founded by Diane Hessan, which was recently acquired by Omnicom for about $100M. When starting her company, Diane found the smartest people in her previous employer, motivated them, and said ‘let’s come up with the next idea.’ ”The group then brainstormed ideas tried and failed and pivoted many times along the way until they reached the functionality of Communispace in the shape as we know it today.

Contrast that example with the story of Dropbox. Drew saw a need based on a personal experience during a bus trip, and then he went on to execute on his vision resolving his problem, which turned out to be an important problem for many people. As Drew went on to execute on his idea, there were relatively very few pivots along the way. Drew had created his version of ‘reality distortion’ and delivered a product that “just works.” Not only there were few pivots, but also, as we learned in the case, the team has chosen not to listen to customer demands about additional features. Or in Drew’s words, “We have features that our power users have been requesting from the beginning that we still haven’t added… We need to keep it simple.”

Both of these examples highlighted two successful startups, one started with a team while the other started with an idea. So the hypothesis doesn’t suggest which approach (team or idea first) is better, rather it suggests which approach encourages lean startup methodology. 

However, starting with teams might influence the success outcome especially in a world where most starts fail because of co-founders problems. So if co-founders get along and have the complementary skills they also increase their chances of success. So one way to reduce risks of entrepreneurship is trying to find founder-cofounder fit (FCF) before even starting to find the product-market fit (PMF).

Read More