Springest communication Rules of Engagement in Holacracy

This is a copy of our internal Rules of Engagement, updated when our Communication Clarity role updates them internally in our helpdesk system. You can read more about communication, rules, policies and processes in this article.

PS: as a customer, partner, employee, parent, husband, friend, pet or child of a Springeteer, you can not derive rights from these rules ;)

— Updated: 9 April 2019

The rules of the tools

1. Sputr: Scan (and read what’s interesting ;)) all posts (not replies per se), within 2 business days.
2. Asana: Read and respond to all inbox items, within 2 business days.
3. Slack: Respond to direct messages and mentions of your (user)name within a few hours, @here / @channel you should also read in your role’s channels.
   Don’t ask someone if you can ask them a question and don’t spend extra lines saying “Hello” (goes for Asana too): just say it, preferably in 1 go, not in several messages! And say what you link to, not just <link> “what do you think?”.This way, somebody can actually act right away instead of waiting for your actual need.
   It’s not needed to follow all Slack channels, especially not the team-specific ones, and only use the #general channel if you’re sure it interests everyone (and use #random for fun stuff). Only use @here or @channel when it’s really needed that everyone sees your post.
4. E-mail: Never e-mail another Springeteer, unless you’re communicating with the outside world.
   Respond to mail within 2 business days. Preferably, respond within 2 hours with an estimate of when you can actually process the mail, so the customer feels heard quickly.
5. Gmail 🔗: never use your Springest (or other) Gmail to e-mail with the outside world. Only use tools that have shared mailboxes, like Help Scout (for almost everything), Recruitee (for recruitment), Pipelinedeals (via Gmail but always Bcc)
6. Real life 🔗: Respond to face to face (or phone) requests immediately, but be modest in using them and ask via Slack first if person can be interrupted, especially if (s)he) wears headphones or seems focussed. Try not to talk from a distance: walk to the person and stand or sit at their desk to have your conversation.
7. Real life foreigners 🇳🇱 🇫🇷 🇩🇪 🇬🇧: if a person not speaking your native language is within hearing distance and the talk might interest them, switch to English.
8. Slack or Asana?🔗
9. If you are in hurry (quicker than 2 days) or you just need a clarification: Slack. If it’s not urgent or big, make an Asana, but if it’s urgent and big > Asana so it’s more structured and easier to find back for others.
10. If a customer is waiting, Asana is too slow, as every response can take 2 days (ping pong).
11. 🔗For next actions: always prefer Asana and if you are in a hurry, copy paste the URL it to Slack incl. a few words of what you need so someone knows before they click.
    Read these articles on how to formulate tasks so the reader spends less time figuring it out, and you get your needs filled faster: 7 Ways to Write Better Action Items, How to write the perfect task to move work forward. A few Springest-specific pointers:
12. Always include all info needed to understand the task, in the task. I.e. don’t just paste a link elsewhere. It’s easier for you to copy paste the relevant part cuz you’re already there.
13. If you refer to a customer email, don’t link to the email because not everyone will have access to it. Rather, paste the relevant context in the task as text or screenshot (and block personal data as always)
14. Make it immediately actionable, don’t just assign an idea or a few words and don’t reassign something back to someone without changing the task name to something proper.
15. 🔗Paper trail: when you complete a task or say something like “I’ve made this into a project / task”, always leave a “paper trail” of what you did and where to find it with a direct link. Otherwise people have to search extra, or make assumptions about what happened, which decreases clarity and gives room for mistakes.
    Also, don’t use repeating tasks, but rather keep it in one task and move the due date when it’s done.
16. Appreciating = Communicating. Let people know you have read their Sputr-posts by liking it or commenting to it, same for :heart: in Asana and reactions in Slack :)
17. Remote working: be prepared to be a bit more responsive to requests on Slack, because people can’t reach you in real life. And keep your phone close :)

But but it’s too much!!! Nah… We can always revisit these rules, and should discuss these things in our FTHM. It’s essential to keep your communication channels clean so we can depend on each other. It’s not acceptable to say “if I don’t respond you should just ask me on another channel”, because that creates the expectation that we could just drop our inbox and wait for something to catch fire before we respond.

Clarity in communication🔗

Clarity is the most valuable thing in communication, because it saves time directly, as well as indirectly by making better decisions. Your 10 extra seconds for creating clarity saves 10 seconds * X persons * X interactions needed to clarif, so yes it is worth the extra effort. Some rules of thumb that can help you increase clarity:

When you’re asking / initiating / talking:

• Ask one question at a time: if you add related stuff, you increase the chance that people only respond to part of your request.
• Ask a specific person: if you don’t know who to address, then that should be your one and only question. If you ask a channel, you will receive multiple
• Ask in private: if you know the person, don’t ask a channel / group, to decrease the chance of someone hijacking the conversation or creating unclarity by adding heir own tensions or opinions.
• When unclear, increase the bandwidth: the more asynchronous your communication is (think e-mail vs. chat) and the less senses are involved (think text vs speech vs seeing each other), the lower the “bandwidth”. When you you want to increase clarity, you often need more bandwidth to increase the chance of understanding each other. Eg. if you’re unclear about a task in Asana, ask clarification on Slack or face to face, then add it back in Asana.

When you’re responding / listening / receiving:

• Don’t answer if you don’t care from a role you have. If you want to process your tension / idea / improvement anyway, give it to the role / person who does care because they’re accountable for it and they can better gather all input and combine it.
• Don’t answer if you’re not sure: it will only increase other’s unclarity if you do. If there are no answers, make clear that you just have a hunch and try to help by pointing to another role who might know.
• Answer privately: even if asked in a channel, and especially when you’re not sure, answer privately so that you don’t confuse others who want to respond.
• Give one answer at a time: or if you need more answers, separate them clearly by stating to which question you’re answering.

Communication with the outside world

Be sure to also check out our Communication tone of voice and style guide.

We want to be fast for great customer happiness. Because of our different target groups, we have support requests coming in from many sides (mediapartners, providers, users, suppliers, Go clients) and very often they mix, because it’s our role to connect those groups… So, to make sure we still delight them with our snappy and friendly response, some pointers:

1. Our first response: should be within 2 working hours.
2. Our resolution time: within 24 working hours. This is very hard if an external party is involved, but in those cases you can call Pending resolved too: as soon as the request has been processed and sent to an external party, and the support requester has been notified within 24 hours, we’re cool/.
3. You touch it, you own it🔗: if you are working in a mailbox and are not accountable for solving the user’s problem, you are responsible for making sure someone else takes care of first response within 2 hours. So you’ll probably have to ask someone in Slack or face to face, to take on the ticket. If not, you dropped the ball and that is very risky (since nobody seems to be at fault, but the customer is being screwed).
4. You touch it, you create clarity and stay accountable: often, you need more time to resolve an issue, or you’re waiting for someone else to fix it. You should tell the user when you expect a solution (by which day) and then get back to the user on that day. If it’s not fixed then, you apologize and you give a new estimate, if possible with an explanation why your first estimate was off.
5. You move it, you (un)assign it: if you have to move the ticket to another mailbox, or if you have to make a new ticket cuz it’s an incoming call or chat, you make sure you unassign yourself from it and either assign someone you pinged, or unassign so it’s visible in Unassigned in the other mailbox. Also make sure the ticket is Active when you assign it to someone else or move it to anther mailbox.
6. You touch it, you don’t disappoint the user: if you suspect we cannot achieve 1. and / or 2., you have to tell the user that a delay is to be expected. In case the person who is accountable isn’t there, can’t fix it soon, or of course in case an external party is involved in which case 2. is happening still.

And, depending on your roles there might be other Rules of Engagement applicable:

• Rules of Engagement: Inbox
• Rules of Engagement: Inbound
• Rules of Engagement: Booking Requests
• 1. Rules of Engagement: Learning Advice

So are we not human anymore?

We are still be human, and if you’re really busy (behind on communication) for a few days, just share that with whoever depends on you so they know. It’s perfectly acceptable to respond to an incoming task or question with “No time for this in the coming days, let me know if there’s tension with that!”.

Also: if you’re really busy I think you can still scan your inbox at the beginning of your day for 10 minutes to make sure there’s no 5 second answers you can give to help your colleague progress her task. You can just skip the rest and mark the as upcoming actions, this is basic GTD: separating processing from doing. And just ask one of our David Allen roles if you need a helping hand with GTD :)

With all our communication channels exploding, and more tools replacing even more tools, I thought it might be good to share what we expect of everyone, communication-tool-wise :)