Really interested to know what everyone else has tried, what worked and what didn't!
https://www.dotmesh.com/blog/edge-of-chaos/ is my blog post explaining more about what I mean.
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...
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.
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.
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!
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.
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)
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.
