How we Work

Asynchronously

We have people working all sorts of different hours and from all sorts of different places at SALT. That alone makes it hard to enforce a lot of tightly-coupled workflows during the day (that’s a feature not a bug). Most of the work you do at SALT shouldn’t require you to be in constant communication throughout the entire day with someone.

It’s far better for everyone’s concentration and sanity if you collaborate as though most things will get answered eventually, but not necessarily right this second. Your first choice of action should be to post a message, a todo, or a document about what you need to explain or need to know. Others can read it on their schedule, when the natural lulls of the day allow it, rather than being interrupted right in their peak flow time.

Don’t take that as gospel, though. Sometimes you really DO need to tightly collaborate with someone for an extended period of time, and that’s fine. We have pings, hangouts, screensharing, or even in-person collaboration for when nothing else will do (But most of the time something else will).

All that being said, you should still ensure that there is ample overlap with the people you work with most of the time. While most roadblocks can just as well be cleared in 15-30-60 minutes, they become real annoying if it’s a one-day turn-around every time.

In certain departments, like Support and Ops, it’s even more important that people are dependently available when they say they will be. That work has a lot of interrupt-based jobs that simply needs to be done right here, right now. So what applies to almost all work for design and programming and QA may well apply a little less frequently there.

In self-sufficient, independent teams

Organizational theory is thick with descriptions of the trade-offs between functional and project company structures. We seek to be more project than functional. This means a single project team should be able to go from idea to deploy as independently as possible.

Thus, the fewer departments a team has to pass through on their road to rolling out a new feature, the better. We should be working on opening all these natural road blocks that form by default when you have awesome, strong departments, such as SIP, mobile, Ops, QA, and so forth.

For example, a team working on a new scheduling feature should be able to test and integrate their work with the native apps without involving mobile, unless something special is needed. Mobile shouldn’t need a special heads up, and thus interruption and mental overhead or even guilt from lack of participation.

Similarly, a native feature that requires an API change should be carried out by that native team directly.

When we need to use the staging database, that should be self-service too. Have a script anyone can run to restore it. Don’t require going to ops and waiting around for someone to do it for us.

None of this means we can’t talk together or ask experts with more experience or expertise for their advice. It just means it shouldn’t be a required, necessary step to make SALT better.

As soon as organizational bottlenecks form, like a slew of features waiting for “the mobile integration”, we’re dragged towards more micro and detailed schedule management. It becomes a critical path with dependencies and making sure team Z is available just at the right moment for team A, such that nobody is blocked. That’s a poor fit for our organizational aspirations, so we have to work to counter that.

With managers of one

Managing at SALT is part-time occupation, next to being involved with doing the work itself. This means we rely on everyone at SALT to do a lot of self-management. People who do this well qualify as managers of one, and we strive for everyone senior or above to embody this principle fully.

That means setting your own direction when one isn’t given. Determining what needs to be done, and doing it, without waiting for someone to tell you to. A manager of one will spend their time well when left to their own devices. There’s always more work to be done, always more initiatives to kick off, always more improvement to be had.