Locksmith: Why, and How
From an internal wiki, dated July 2017
Locksmith exists. Let's set some fundamentals.
Why
This project is bedrock, here defined as something solid and predictable, upon which one can confidently build something interesting, without the ground shifting unexpectedly.
This project is bedrock for:
... our customers and their businesses. By relying on Locksmith's solidity and predictability, they are freed from a certain set of problems, so that they can better focus on the interesting aspects of their own business.
... us, as a team/group/unit. By operating Locksmith in a solid and predictable manner, we are freed to work on interesting aspects of the project, heading for new and better futures, or to work on interesting new projects.
... you, as an individual human. By having solid and predictable responsibilities to Locksmith, you are freed to devote more of your energies to whatever is interesting in your life.
My goal for this project is to get us each closer to what we are each uniquely built/equipped/excited to handle.
How
Trust is first. I trust you to own your responsibilities. I trust you to manage your resources (time/brain/etc) in a way that lets you fulfill your responsibilities well. I trust you to communicate, to make sure that I know the relevant parts of your state/status, so that I can help you. I trust you to trust me to do all those things as well.
Trust takes care of the "solid" part of the bedrock definition. To take care of the "predictable" part, these are the rules:
Use mentions (e.g.
@isaac), guarantee that you're consistently receiving yours, and always respond to a mention, for the sake of the mentioner and also for posterity.In explicit terms: An acknowledgement represents a transfer of responsibility. If I mention you, I'm asking you to take responsibility for something, even if it's just ownership of information. Until you respond, I am holding that responsibility for you, in escrow, and I make room for it in the back of my head so that I don't forget to make sure that you receive it. Your acknowledgment, when you choose to deliver it, represents your acceptance of responsibility. Literally, you have taken receipt of the information, and are giving me a receipt for it.
This leaves room for you to choose when to acknowledge. If you see an alert fly by, addressed to you, but you're not in a space (mentally or physically or whatever) to properly process/handle/receive the information, don't respond. This leaves the responsibility with the sender, for the time being (which means they can nag you if need be). When you can process/handle/receive the information, do so, and respond to the mention.
Respond to every single mention. Literally. This is to establish zero ambiguity around which messages warrant a reaction, and which do not. (This means that everyone should be intentional about when mentions are used, for they are tools in their own right.)
Comments and reactions (which is a thing in GitHub and Slack) are both fine. The point is to acknowledge that you saw the thing.
Hint: Try to keep your usernames consistent across GitHub, Slack, and Trello. It's not super important, but it (a) helps with the whole muscle memory thing, and (b) might make it easier for Slack to highlight your mentions in the #locksmith-logs channel. ;)
Intercom
It's for conversations. Each Intercom conversation should be treated like an in-person conversation: with respect for states and needs of everyone involved.
Guarantee a 24-hour response time, by having one teammate at a time responsible for it. Schedule that responsibility flexibly, but with absolute clarity.
This does not mean you must respond to all incoming messages. Be aware of who else is working on support, and let the normal cadence of conversation-handling hold. You're responsible for the final defense of timeliness, that's all.
In practice, this means watching the "All" queue, and making sure that all messages received within the last 24 hours receive a real, considerate, human response.
This is a response time policy, not a resolve time policy. Don't stress over it. :) The responses can be as simple as "Hey, I hear you, and x will be getting back to you today with an update."
This is partly to guarantee that customers receive consistent, responsive empathy. It is also to guarantee that pressing issues can and do surface - actively paying attention to response time gives you a chance to call for reinforcements if need be.
Conversations are alive, they have rhythm and a next step. Close them when that stops being the case. If there are actionables or long-term followups, take it to Trello.
For a conversation in which everyone is currently online and participating, do not allow surprising radio silence from your end. If you have to step away, set expectations for the other participant(s).
Trello
It's for actionables that are not conversations. The test: Do we care if a thing gets done? If so, it goes in Trello.
If a task is important, it must have an owner who can be responsible for it. In Trello, that takes the form of card membership. If you're a member of the card, you're the/an owner.
Keep your cards placed accurately and honestly. "Active" should really mean "Active". If you're an owner on something in "Done, but needs customer followup", get it to "Done" as soon as possible.
Slack
It's for our conversations. :)
Err towards using the shared channels whenever possible, especially for problem-solving. Everything in those is searchable, and that is useful.
I feel lucky and proud - it is a massive privilege to be doing what we're doing, and I aim to execute incredibly well, to drive health and freedom and impact along the way. Thank you for being a part of this. :) ❤️ 🆙
Last updated