This started out as a Twitter thread.

#OneEstimate, or, why your estimates suck and why your stand-ups are boring.

Estimates have a pretty bad reputation at this point, at least in certain circles. (I am sure there is a much wider circle of Agile legionnaires or whatever they call themselves, shouting about how you must estimate every story using only powers of 7 or something, so that management can make plans stretching out to 2031. Fortunately, I don’t talk to those people.)

I agree with most of the arguments put forth by the #NoEstimates crowd and friends. However, while I find estimates pretty much useless for planning and prediction, I do find them useful for discussing a piece of work, with the goal of trying to understand a few things:

1. Do we all agree what we’re working on?
2. Do we vaguely agree on an approach?
3. Can anyone see a simpler way to solve this?
4. Is there anything we don’t know or understand very well?
5. Are there compromises we can make to do less work?

And so, I like estimating, I just don’t like estimates.

In failing to build a company, I have learned many things. Core to all of them is that a company is not a product. Ideas change, products change, people change. We “pivot”, rapidly, relentlessly, sometimes ruthlessly.

Managed well, change is a catalyst. Managed badly, it can be catastrophic.

In this series, I try to explain the various ways in which I failed to understand this, and how I would endeavour to do better next time. You may notice that the style of these posts is more instructive than usual. Remember that these are mostly addressed to my future self, and as such, I am telling myself what to do; you, my dear completionist, can do whatever you want.

I am a millennial, and therefore I want to be friends with all my co-workers. I thrive in a place where we can play a game of table tennis in the break room, talk about listening to covers of metal songs by angry Finns playing the cello, or simply grab a beer (and talk incessantly about beer, because nerdery is not limited to computers). Since working from home, I really appreciate a chat over coffee, even if it is through a screen.

At Prodo, we used to play Dungeons & Dragons every Tuesday night. It was a wonderful way to bond with my team and get to know each other.

And yet, it strikes me now that perhaps I could have seen it as a warning sign, because it was the work event I looked forward to the most.

I worked with lovely people who I consider friends, even if we don’t talk too often nowadays. It turns out that doesn’t make a company.

Perhaps if I’d invested that energy into pair-programming more with the developers, or trying to push for a product that customers loved, things might have gone better.

Friendship is excellent, but don’t mistake it for doing a good job; we can do that and still clock out at 5pm every day. We don’t need to drink together to be able to work together on system architecture, or a sales strategy.

Though, of course, it helps.

Thanks for all the fish

This is the last article in the series, at least for now. I hope you found it informative and at least a little entertaining.

If you do have any feedback, or just want to say hi, please drop me a comment, a tweet, or an email. Details are at the bottom of every post on the website (so click through if you’re reading this in a feed reader).

Cheers all. I found this very fun to write.

1. Introduction
2. Focus on the problem, not the solution
3. If the company goals change, the company should probably change too
4. "Do research" is not a corporate strategy
5. Your corporate values transcend your product vision
6. Trust your gut, understand your heart, and open your mind
7. Go to therapy with your co-founders
8. Explore the terrain first
9. Unless someone cares, don't waste your time
10. Code is a liability; ship without coding, if possible
11. Do less, and do it better
12. Agile methods are tools to try more ideas in less time
13. Until you have traction, money is a trap
14. If you don’t know how to do it, that’s your biggest problem
15. Roles can be fluid, but they must be defined
16. Camaraderie is helpful, but no substitute for working together

In failing to build a company, I have learned many things. Core to all of them is that a company is not a product. Ideas change, products change, people change. We “pivot”, rapidly, relentlessly, sometimes ruthlessly.

Managed well, change is a catalyst. Managed badly, it can be catastrophic.

In this series, I try to explain the various ways in which I failed to understand this, and how I would endeavour to do better next time. You may notice that the style of these posts is more instructive than usual. Remember that these are mostly addressed to my future self, and as such, I am telling myself what to do; you, my dear knowledge aggregator, can do whatever you want.

When you start a company, the first thing you do is give yourself a ridiculously overblown job title. “Chief Technology Officer”, you call yourself, ignoring the fact that you’re a chief of 1 person—yourself, you don’t know what your technology is yet, and you don’t have the first clue about being any kind of company “officer”.

The title is important, because you’re communicating to the outside world that you, in fact, represent the company; you don’t just work there.

However, this is an external-facing title. Internally, roles are more nebulous. Perhaps one day, you’re the programmer, and the next, you’re the accountant. Congratulations: you’re now a generalist. This is an incredibly valuable set of skills you’re learning; rejoice!

Of course, you won’t stay the accountant for long. You’ll probably outsource that work anyway, but it makes sense to do it first so you can understand the job.

Some roles aren’t so clear-cut. Who decides the roadmap? Well, you’re the CTO; surely this is your job?

However, this can go badly. What if the CEO expected to have final say over what comes next? After all, they’re the one talking to potential customers… probably.

Roles are fluid, but they’re also a source of pride and privilege for the people taking them on. We don’t expect them to change without our knowledge. You signed up to start a company because we thought it was intriguing, challenging, joyful, purposeful… if you wanted to be told what to do and receive a high salary for doing it, you’d go get a regular job.

Just like everything else, the key to a harmonious relationship is to regularly have open conversations about roles and responsibilities, explicitly recognise changes, and write them down. This includes roles that no one is taking on right now: if you need a website but no one has time to make one, make sure everyone is aware of that.

An unmentioned change is still a change, except that it’s going to cause havoc when you least expect it.

More in the series

1. Introduction
2. Focus on the problem, not the solution
3. If the company goals change, the company should probably change too
4. "Do research" is not a corporate strategy
5. Your corporate values transcend your product vision
6. Trust your gut, understand your heart, and open your mind
7. Go to therapy with your co-founders
8. Explore the terrain first
9. Unless someone cares, don't waste your time
10. Code is a liability; ship without coding, if possible
11. Do less, and do it better
12. Agile methods are tools to try more ideas in less time
13. Until you have traction, money is a trap
14. If you don’t know how to do it, that’s your biggest problem
15. Roles can be fluid, but they must be defined
16. Camaraderie is helpful, but no substitute for working together

In failing to build a company, I have learned many things. Core to all of them is that a company is not a product. Ideas change, products change, people change. We “pivot”, rapidly, relentlessly, sometimes ruthlessly.

Managed well, change is a catalyst. Managed badly, it can be catastrophic.

In this series, I try to explain the various ways in which I failed to understand this, and how I would endeavour to do better next time. You may notice that the style of these posts is more instructive than usual. Remember that these are mostly addressed to my future self, and as such, I am telling myself what to do; you, my dear complex individual, can do whatever you want.

When you’re small, you don’t have traction, you’re making sales calls, and you have a problem, $Y$, you don’t know how to solve, it’s totally understandable to say, “I’m busy and this is not my expertise. It’s time to hire someone to take this on.” After all, you’re the expert in $X$; stands to reason that an expert in $Y$ would get this done faster.

Don’t. Do it yourself first, badly. If it goes well, you’ll have a new appreciation for the solution space and a much better idea of who to hire (or where to outsource). If it doesn’t, you can abandon the plan without much cost.

It’s expensive to hire (recruiters cost a bomb, job ads are tough to write well, and a multi-stage interview process can take weeks), and it’s costly to let someone go because they’re not working out. It takes time to make that decision, during which you’re not focused on your real problem, and you’re paying that person to do the wrong thing.

If you can do the job badly and still make a sale, it’s useful; go get a professional to do the next version.

This doesn’t scale. That’s OK; you’re not scaling right now, you’re figuring out what your product is.

More in the series

1. Introduction
2. Focus on the problem, not the solution
3. If the company goals change, the company should probably change too
4. "Do research" is not a corporate strategy
5. Your corporate values transcend your product vision
6. Trust your gut, understand your heart, and open your mind
7. Go to therapy with your co-founders
8. Explore the terrain first
9. Unless someone cares, don't waste your time
10. Code is a liability; ship without coding, if possible
11. Do less, and do it better
12. Agile methods are tools to try more ideas in less time
13. Until you have traction, money is a trap
14. If you don’t know how to do it, that’s your biggest problem
15. Roles can be fluid, but they must be defined
16. Camaraderie is helpful, but no substitute for working together

In failing to build a company, I have learned many things. Core to all of them is that a company is not a product. Ideas change, products change, people change. We “pivot”, rapidly, relentlessly, sometimes ruthlessly.

Managed well, change is a catalyst. Managed badly, it can be catastrophic.

In this series, I try to explain the various ways in which I failed to understand this, and how I would endeavour to do better next time. You may notice that the style of these posts is more instructive than usual. Remember that these are mostly addressed to my future self, and as such, I am telling myself what to do; you, my dear reader of blogs, can do whatever you want.

It seems that more and more startups raise money before producing, well, anything. Mine included.

We raised a significant amount of cash from angel investors within a few months of starting, thanks to some incredible work by our CEO. It was enough to pay ourselves a reasonable salary, rent an office, and hire a few people.

I have no proof, of course, but I believe it was this act that led to our downfall.

Now, of course, the money wasn’t the issue. The issue is that we spent it. We hired people without knowing what it was that we were making, including an ML specialist before we needed any real ML (as opposed to something “good enough to prove the point”), and a web developer before we really needed a web interface.

And so, we got some ML, and a web app, long before we knew what our customers wanted. This caused us to double down on these, treating them as the result rather than the mechanism.

If you don’t have investment, you have to make money through sales. While having the money in the bank meant we could quit our jobs, I think in our case, it would have been far healthier to act as if we had only enough for our own salaries, and knock on some (metaphorical) doors, delivering demonstrations, talks, and consulting until we got someone to pay some money. That would have enabled us to figure out what it is that people actually wanted.

We had the runway to do a bunch of programming, rather than talk to people, and so we did. If you don’t have money, you need to deliver.

This is not to say you shouldn’t go out and raise money, if you think that’s necessary or useful. Go for it. I recommend it, in fact; if your project is uninvestable for some reason, better to find out sooner rather than later.

And then take most of that money, lock it in a box, and put a sign above it saying, “to be opened when we have a clue what we’re doing”.

More in the series

1. Introduction
2. Focus on the problem, not the solution
3. If the company goals change, the company should probably change too
4. "Do research" is not a corporate strategy
5. Your corporate values transcend your product vision
6. Trust your gut, understand your heart, and open your mind
7. Go to therapy with your co-founders
8. Explore the terrain first
9. Unless someone cares, don't waste your time
10. Code is a liability; ship without coding, if possible
11. Do less, and do it better
12. Agile methods are tools to try more ideas in less time
13. Until you have traction, money is a trap
14. If you don’t know how to do it, that’s your biggest problem
15. Roles can be fluid, but they must be defined
16. Camaraderie is helpful, but no substitute for working together