Wasn’t I here yesterday?
One question every startup asks themselves is “Is this the most important thing I could be doing?” This is equally true of corporates as well, but as a startup, the answer to this question sometimes feels like it changes 30 times a day.
Sometimes that might be because the role is changing – one minute a journalist is calling, so the most important thing you’re doing is PR. Then you’re coding – so what’s the priority feature or bug to fix? Maybe it’s talking to investors, so you want to get more metrics and information to help those conversations.
The challenge is when these tasks take more than a few minutes to do. Recording better metrics may take a couple of days (or more) to work out what to measure, put them in place, extract the information, analyse and understand it and then reiterate until its good enough (it’s never perfect in a startup). While you’re doing that, there’s a new bug, a new user request, a new API feature required.
In fact, I think that question is not nuanced enough. Switching from most important thing to most important thing is actually costing you your most critical resource – Time. There’s never enough of it, so why burn it in the switching cost incurred in halting what you’re doing, changing gears and getting back up to speed?
Because we’re a team of two trying to cover everything, the reality is that there are many equally important things that need to be done covering a range of roles. Picking between them can often be as arbitrary as “”l’ll be fined if I don’t” (for an accounting thing) or as basic as “I can’t decide, so I’ll do what I like best”. The one I frequently find most dangerous is “I just read this, it’s a good idea and front of mind.”
To keep your sanity I find it helpful to try keep these things in mind:
- We cannot do everything we want to do.
- Some important things will go undone.
- Priorities may change, but unless it’s suddenly become Timely and Important, sticking the current task out is probably a better use of time.
- I won’t feel guilty about not doing something I don’t have time to do. I’m already working 7 days a week, if it can’t be done, it can’t be done.
- I’m a rational and thoughtful person, one week ago I felt this current task was the most important thing to be doing – what’s changed? What new information has come to light that makes me want to second guess myself?
Of course priorities do change, so how do you spread yourself without incurring massive switching cost? Aside from the Timely and Important things (like a journalist interview, some accounting tasks, some bug fixes) which always butt in from time to time, what I find really useful is to think of things in cycles.
So we’ll do a “User Retention Cycle” and try to focus on sets of features and related tasks that improve user retention. It could be a “User Acquisition Cycle”, “Technical Debt Pay Off” cycle – whatever. What matters is that we constrain one to two weeks around a set of issues which let us push things forward without incurring huge switching costs. By the end of the cycle, other things will pop up and becoming a higher priority – but staying it until the end (within reason) is better than leaving something unfinished and incurring switching debt.
So when do you switch?
- Measure the sunk cost – if you’ve spent a week in a cycle and two days will finish it out, is it better to just deliver than flit off to some other priority?
- Recognise that a lot of tasks are see-saws (for example, a focus on User Retention seems to inevitably raise User Acquistion again and vice versa). Pushing one end will make the other pop up in priority. Are you pushing a see-saw (in which case finish pushing the current end down before jumping to the other end) or is this a different problem you’re seeing that is genuinely critical?
- Switch when failure to switch will cause a terminal event – the other task is Timely and Important (it brutally matters that it’s done NOW).
Another thing we’ve settled into is “doing time” and “thinking time” – weeks are for doing, weekends for thinking. It helps separate that shiny new slide from the see-saw you’re on right now. It makes Monday a good time to review the new ideas, review the current cycle, adjust priorities and put our heads back down for the week or two ahead after we’ve opened out and explored things a bit more on the weekends.
When you have a remote team like Alex and I, the other important thing is to be clear on emails. What’s just an “Idea” or “FYI” Vs. “we need to do this now”? In the past we’ve wasted time debating something which wasn’t ever intended to be an idea for now, just a “this is interesting keep it in mind for the future”.
There are times when you have to switch. When you do, make sure that the cost of that switch is part of the equation and you’re not just jumping from priority to priority, but that you’re also thinking about the debt you’ve already incurred on the task at hand.
Highlights
- New release pushed
- General feeling that things are improving.
Lessons Learnt
- More people are paying attention to what you write and say (including this blog) than I thought! This is a good lesson though, nothing bad.
Goal this week
- Chinese New Year (year of Rabbit) starts this week, so things will be a little quieter here while Alex travels home to family etc.
- User discovery features.
Thanks for sharing! Some are really helpful to me. I was always wondering how could trunk.ly be built by a team of two.I am now working on a "small" project with five other people (one in Germany, one in Hongkong and the other two in different cities in China, myself is in Sweden). Nobody has quited their jobs, yet. But I wish we can work for ourselves soon. Even if it fails, I will still learn a lot. Also I really don’t have any clues on those work other than development, can a project succeed without all other part like PR, SEO?Hope answering this post won’t cost you too much to switch:)All the best.Zhe
well said, Tim. Great to read you, here
Very insightful comments Tim, I’m guessing they came to you over the weekend
I especially like the idea of cycles – it’s not too far off the software development paradigm of sprints. Putting your head down and focusing on one set of tasks for a period of time not only enhances productivity but gives that sense of accomplishment that can be elusive if you constantly are chasing a wide range of disparate tasks.I also think it pays not to think too much. Once a course of action is set, even if just for a cycle, believing in that course of action is crucial. Pay attention to big warning signs sure, but it can be dangerously unproductive to second guess why you’re focusing on a set of tasks.Look forward to more updates & insights
Thanks for the comment Adam, we do a lot of sprints as developers, so I guess it was born out of that a bit. And yes, they did come to me over a weekend – it’s why I (generally) try to do these posts on a Monday morning first thing, it helps clear my head.I agree with you about second guessing being dangerously unproductive. Too much information can be dangerous, it’s far to easy to end up in "analysis paralysis" rather than backing your gut and moving forward.A lot of the time as a startup, the battle is to keep moving – your big advantage is the ability to turn on a dime, you lose that if you over-think things.