Why we abstracted Continuous Coordination:
When I started Steady I deliberately assembled a team of remote work experts. Folks from companies like Gitlab and Basecamp. The initial goal: make a piece of software that “solves the async problem.”
But we realized pretty quickly that in order to fully solve the problem, you have to have more than a piece of software. You have to have a philosophy of work.
Most collaboration software is ultimately a CRUD database and some forms. You can organize those forms into an interface that has opinions – to try and “nudge” people toward working a certain kind of way.
But if they don’t buy into the underlying philosophy they won’t get the full value out of it.
We also realized that Steady, at its most successful, will remain one of several tools companies will use to collaborate. While we have strong opinions about the best way to do it, ultimately we care about helping teams solve the problem.
So we’ve open sourced the philosophy.
It’s not a white paper. It’s not very prescriptive, on purpose. It won’t tell you how to draw an org map. It won’t say teams of 5 people are best.
What it attempts to do is condense the best thinking on coordinating teams, based on decades of experience, into a set of overarching principles.
Principles you can implement regardless of which software you use.
Assuming you buy into the ideas of Continuous Coordination, we of course believe Steady is the best tool for implementing it. Because it was built explicitly for that purpose.
But I’d love to fast forward 10 years and see a world full of software platforms that have their own take on implementing Continuous Coordination. I’d love to see teams all over the world who have baked these ideas into their DNA.
Steady is how we make money. But Continuous Coordination is how we’re trying to make modern work work for everyone.
