
Ask HN: How can you avoid chaos in your startup? - acsowerby
Given how easy it is for a startup to descend into chaos, we&#x27;ve been working at my startup, Dotmesh, on how to avoid this happening.<p>Really interested to know what everyone else has tried, what worked and what didn&#x27;t!<p>https:&#x2F;&#x2F;www.dotmesh.com&#x2F;blog&#x2F;edge-of-chaos&#x2F; is my blog post explaining more about what I mean.
======
hluska
I have two answers. The first is rather snarky and the second is rather
idealistic. My experience indicates the first is more accurate, but I'm a
sample of one (and not a particularly successful sample of one to boot).

1.) By nature, startups are chaotic and if you try to remove all chaos, there
is a very good chance that you will handcuff people to such a point that they
can't handle chaos.

To accomplish this, I like to select early employees based on an aptitude or
interest in chaos. I look for evidence that my early employees are self
motivated and capable of both making decisions with imperfect information and
learning new things quickly. In my role, I like to make sure that I write down
as many of my decisions possible and the criteria that I used to arrive at
those decisions. And, in a leadership role, I like to remind my team that
things will be chaotic and that I'll document my decisions to show them
general principles, but if things are chaotic and you don't know what to do,
use your best judgment, use my principles and our mission to inform that best
judgment and know that I'll support you.

2.) In startups, you have to learn how to separate useful chaos from company
killing chaos. It's useful chaos if you release an early version and receive
feedback from a majority of your users stating they'd happily pay $xxx a month
if you had features a, b and c. It's company killing chaos if a senior
engineer has to talk to fifteen people to get permission to spend $15 on a
build tool that will save her five hours a week forever (I'm not exaggerating
much).

The way around this one seems to be relentless delegation, which requires the
same sorts of selection as in my snarkier answer. This path is also very
complicated for first time founders who don't quite know what they don't know.
It is very complicated to delegate something away, realize that it's a
valuable task for you to perform and then try to take it back...

~~~
acsowerby
Haha, not snarky at all, I think the original question was maybe not phrased
quite right. What I meant was "how do you successfully operate within a
startup environment which is inherently more chaotic than an established
business". But it's a bit long :)

I think you're smart to look for employees who are happy with a bit more chaos
than usual. I think it's Simon Wardley that characterises such people as
"pioneers" as opposed to "settlers" or "town planners".

I also really like the attitude of "use your judgement and I will support your
decision", it's so valuable and often rare that people do this. Too many
people are control freaks and believe only they can/should make the decisions,
however small. Even worse when you let people make decisions and then
undermine them!

Interested to know how you record and share your decisions - sounds like a
really good practice.

------
muzani
I take a military analogy to it. War is probably the most chaotic situation
anywhere. And to cater for it, they develop a lot of discipline, starting with
formations and strict routine.

The key is to create a bubble of control. Once you control a zone, once you
form a secure perimeter, it's much easier to control the rest.

This zone of security is most easily done with Agile. Agile lets you control
that sprint. Agile lets you gain more control over a large project, sprint by
sprint.

A lot of people abuse agile. They forget that it's a way of ensuring control.
These people overextend and they lose it.

Routines and SOPs are also really good. A lot of companies trust their
developers completely. After all, they hire the smartest people they know.

But just because they're smart, it doesn't mean they know what to do. A SOP
keeps people moving in formation. If you know where everyone is, you can
secure a huge perimeter. If people have full freedom, they will often break
formation because they don't see the big picture.

Communication is absolutely vital. Whether in war or software, sometimes you
don't even know where you are. Sometimes you don't know when someone is
crossing into another person's zone. It's also important that these people
don't simply communicate to one another, or just to their team leader. It
creates a bottleneck, a point of failure. This is where project management
apps like Jira and Slack come in.

It's also vital that you know your environment. You should know what you're
getting into. This is where system analysts, business logic, and similar
experts come in. They are there to scout things out before the grunts move in.
The project manager may tell people where to go, but the system analysts tell
them what is safe.

In general, I think that if you believe a project is completely safe, you
simply don't know enough about it. You should be well aware of the chaos and
have a plan for it.

~~~
acsowerby
This analogy seems really strong. I don't know much about war though so I
might miss some of the nuances!

The bubble of control sounds like a great way to visualise what you need focus
on (reminds me of the "circle of control" from the book "Seven habits of
highly effective people").

"develop a lot of discipline, starting with formations and strict routine".
This makes a lot of sense and completely fits with the other analogies I use
(like playing jazz, football and running an agile team). It reinforces my
belief that you need to have well-practised skills for _how_ to do things so
that all your focus can be placed on _what_ to do.

I also really agree with the point on communication. It's a key feedback loop
and helps people to synchronise and keep their context up to date. I like to
set this up via repeating events so that it's never too long between syncs.

I never thought before about having people separate from the direction-setter
(leader, project manager) who would recce for safety purposes. I'll have to
mull on that a while!

Thanks!

~~~
muzani
Oh yeah the recon and support teams are some of the best tools we've had for
reducing risk.

At the very least it highlights high priority obstacles, like whether an API
is running properly or able to do what it should. And system analysts are
awesome for making sure a sales team doesn't overpromise.

Support teams are great too. Like if you have a huge, expensive, time
constrained project involving a technology like Firebase, it would be worth it
to have a Firebase expert sit around the office to ask questions to. It's
often more cost effective than throwing more programmers at the problem. At
some point, extra programmers just conflict with one another, but support
won't.

------
acsowerby
Here's a clickable version of the link BTW [https://www.dotmesh.com/blog/edge-
of-chaos/](https://www.dotmesh.com/blog/edge-of-chaos/)

~~~
matt_the_bass
I’m curious what the purpose of your blog post is. Is it a message to
potential employees, customers, investors, someone else?

I don’t mean “what is that post talking about”, more what was your intended
ROI on it?

Would you be willing to inform on that point?

(Please don’t take this as a critique, I’m curious and hoping to learn
something)

~~~
acsowerby
Hey Matt,

No worries, I always try to assume that people are well intentioned with their
questions until there's undeniable evidence otherwise!

I didn't have any specific ROI in mind, I just wanted to get the thoughts out
of my head and onto "paper", and hopefully help out anyone who finds they have
the same challenges. Also, if I'm re-inventing the wheel or missing other
obvious ways of doing things, that would be interesting too.

Sorry it's not any deeper than that! :)

Alice.

~~~
matt_the_bass
Hi Alice thanks for the reply.

<unsolicited advice from random internet person> You might wish to consider
what message these types of postings give to your (potential) customers,
investors, employees, etc. They can be used as a queue to them. I’m not saying
your post is good or bad message. Just that everything under your company’s
banner sends a message. Some company leaders have separate personal and
company blogs. </unsolicited advice from random internet person>

------
tmaly
I think establishing some basic business processes even if they are just
checklists, would be a great start.

~~~
acsowerby
Yes! Checklists are so lightweight and deliver a ton of value. I heard this
advice somewhere else a long time ago and it's perennially useful.

