Our Lean Management Process for Startups
Yup, you read that right, management process and startups in the same title! I can hear some of you cringe and scream that you got into startups to escape from those management processes… Well, this post isn’t going to be shy or ashamed about those words, simply because they’re important for success!
Seems like everything about startups these days has to be lean. So lean, so agile, sometimes so distributed, that we easily fall into a chaos of miscommunication and wasted effort. I guess chaos is expected when a team grows (or shrinks) so fast, everyone does everything, and there are constant emergencies. But being lean does not mean having no process! It’s quite the opposite actually: it’s about having a process that favors short, measurable iterations and experiments to eliminate waste. So why can’t we be lean with management processes and how we plan work?
At Unito we’re putting in place a system with the goal of keeping the chaos under control. The idea is to set a focused pace of execution, while keeping the process as lightweight as possible. It’s evolving quickly as we try different tweaks, but I thought I’d share the high level view here.
This system was cobbled together from things like Get Things Done, Rockefeller Habits, Asana’s Areas of Responsibility,Scrum software development, and Holacracy. There’s nothing fundamentally new here, just a recipe that works for a small startup like us. We implement it using Asana, but really any tool you trust and have the discipline to use should work.
The system works on 4 different levels
- Define a timeline of measurable company goals
- Distribute responsibility & authority
- Plan sprints across company
- Share daily accomplishments and goals
The highest level has the widest scope, and each level below narrows down that scope into specific action items. Every level gives a context to plan the next level and provides clarity and visibility to the entire company. The general idea is that everything we plan and do, every day, should be both visible, and traceable back up the chain to answer the question: why am I doing this? Picture it as an inverted pyramid:
Let’s dive into each of these chunks, but not too deep. I’ll probably cover each in more depth in separate posts.
We’re keeping this one pretty simple right now: a list of one or two measurable objectives:
- Per month, for the next three months
- Per quarter, for the following 1-2 quarters
- Per year, for the following 2-3 years
I think limiting it to one or two objectives per phase is really critical. Personally, I tend to break things down way too much here. The challenge is to find one metric or milestone that encompasses every effort and every member in the team. Something the whole company can aim for and celebrate. It could be raising some financing, launching a feature, reaching a number of active users, etc.
Areas of Responsibility
AoRs are already pretty well described by Asana
. I also suggest you have a look at this video
where they show a glimpse of their own AoR breakdown.
A key point: giving responsibility has to come hand-in-hand with giving authority. When someone owns an AoR they also own the final call on any decision that falls within this area. This is hard for startup founders (it is for me), but I don’t believe people will take true responsibility for a decision without feeling like they made the decision.
Sprints are taken straight out of Scrum methodologies
, but don’t let the word sprint
hide the fact that a startup is an ultra-marathon
! The goal of the sprints is to set a pace for the week, stay focused during that week, and keep everyone informed of what others are doing.
A sprint is a list of action items that the entire company aims to accomplish within one week. We found one week was right for our stage, and lets us stay agile: we try not to change what’s in sprint midway, it’s hard but we try. The list combines every aspect of the business, from development, to finance, to marketing, to legal. So unlike scrum, this is a company sprint, not a product sprint only. We spend Monday mornings on sprint planning, and the lunch to review them together.
The key point here is that the weekly sprint is planned by individuals always in the context of the company goals and their own AoRs.
Finally, the last level is to plan what you aim to accomplish each day, GTD-style
! The daily plan should, as much as possible, only contain stuff that is part of the current week’s sprint. This makes everyone think twice before tackling something that is not directly tied to moving the company towards its goals.
And to force ourselves to go through this daily thinking process, we do a public daily scrum
in a dedicated chat room. Everyone, every day, pastes the list of accomplishments from yesterday, and their objectives for today. They don’t even need to post it at the same time of the day either, which is great for distributed or part time team members.
I find this adds a really healthy dose of transparency and honesty. Hung-over and don’t expect to get much done? Well, you’ll feel inclined to say so in the channel, simply to give a context for the list of braindead stuff you plan today.
Plus bonus: we sometimes use those daily scrum lists to add other things that are important to us as a team and that keep us a tight group. For example, we’re currently preparing for Montreal’s half marathon and keep records of our training runs on the scrum! Adds fun and team spirit to the working day.
I feel like this is all very superficial, but hopefully the big picture is clear. I’ll link up more detailed posts for each individual layer as they arrive, and I’ll include some concrete examples, most likely in Asana because that’s what we use. I love how that tool lets me model all four layers, and have tasks flow through the layers all the way down to my personal task list, keeping context along the way and cutting down on email and copy-pasting.