[This is the third and last of a series on getting your start up to go fast. See the first post to learn where these notes came from.]
Going Fast notes on Operations
Don’t allow process creep. As part of maintaining a fast production culture, you should actively prevent too many processes from getting put in place.
No QA department.
10 at 10 meetings. Have a 10-minute, standing-up meeting at 10 am where everyone on the team reviews what they’ve accomplished yesterday and what they’re planning to do today. This is a quick way to sync people surface any conflicts early in the day before too much work is done.
Spend less than 5% of the minutes you’re working per week on meetings. It can be done, and your communication will be much crisper and clearer if you hold yourself to this standard.
Engineering Task Blast. An engineer presents a task he/she needs to accomplish to the other engineers on the team. Everyone writes down how long they think it will take. Everyone shares their number and then talk about how the engineer might do the task it faster. They agree at the end how long it should take, and then the engineer is held accountable by their peers.
Don’t create silos. Whenever an organization creates “engineers” or “marketing” silos, it slows the company’s progress down. Only allow cross functional meetings.
Establish a cadence of work. Regular releases, weekly milestones, daily short meetings, monthly major releases, regular user testing and review of the report, after work drinks, etc. Get in a grove with your team, your product and your users.
Drive batch size down. “Continuous releases” or at least several times per day or at least once per day, has many advantages. You can course correct easily based on user feedback. You can avoid introducing drama and disruption to your team. Makes it hard for your competitors to keep up. Makes it easy for users to see constant improvement. (Google has small daily releases, medium releases every week, and large releases every 5 weeks. They assumed 5 weeks was enough for almost anything, and that has proven to be true.)
Measure the right things and elevate those to everyone’s view. As a manager you should obsess about choosing the right metrics to measure, how you’re presenting what you’re measuring (meetings, daily email stats reports, flat panels on the wall with real time data, private emails) and then how you reward people for accomplishments publicly.
Quick, cheap, early user feedback. Put up design mocks on forums. Put up a video of what you think it will do and ask for feedback. One CEO told me the best thing he did in 2009 was implement a weekly program of buying 5 tests of his product by target users from http://www.usertesting.com and then reviewing the resulting videos on Friday afternoons.
Transparency. Having all goals and data available throughout the company allows good people at every level to make the right decisions faster. You must make it really easy and really clear (and perhaps fun!) for people to get the data they need to make decisions.
Small teams. Google constantly breaks teams down into no more than 7 people. Amazon has “Pizza box teams” which is defined as a group that only needs one large pizza to have dinner. Over 300 Pizza Box Teams touch Amazon’s home page.
Communicate priorities. Create a spreadsheet that everyone on the team easily has access to that shows all the major things that need to be done in priority order with the name of the person to do them and the date they are to be done. In meetings, argue over this list.
Create the perception of competition to motivate all external relationships. Getting other organizations and people outside your company to move quickly (VC’s, clients, distribution partners, potential employees, users) is very difficult. The main lever you have is to always make it clear to them that there is time urgency and competition for whatever they think they may want from you. That’s the most repeatable and universally effective lever you have.
3 thoughts on “Going Fast Part III: Operations”
I am really surprised you would suggest having 0 QA. Explaining this would be useful.
Pingback: Going Fast, Part 1: Planning Notes & List of Resources « Ooga Labs
@Anonymous: You don’t need a QA department if you have “Quick, cheap, early user feedback.” Releasing and iterating often keeps the feedback loop tight, without the overheard of a separate QA department.