It's not exactly news that we do things a little bit differently at DNSimple. We're unique in a lot of ways when it comes our workflows, responsibilities, hours, and teamwork. We've beaten the subject of remote work to death so far, we've discussed our emoji-scale peer reviews, we've recapped our meetups, and we've talked about how we hired someone to do Operations work and had them (me) pivot to UX design.
Let's keep it going by talking about some other stuff we do a little differently at DNSimple by diving in to our Standard Operating Procedures. SOPs are some of the required tasks that each team member at DNSimple is responsible for outside of the day-to-day tasks that we were brought on to do. Our SOPs were introduced during our latest meetup as a way to clearly define all of our responsibilities, but the biggest benefit is to have a wiki page anyone can go to for actionable steps they can take to perform these tasks in case they don't know how. This is helpful because as DNSimple has grown, our policies and the things we do grow with it, sometimes you lose track of how to contribute somewhere, and as a result you might feel like you're not being helpful or otherwise productive by dedicating your time to these tasks.
What are they?
First and foremost, if you've spoken with us in the past, one of the big ones is customer support. As you may or may not know, all customer support requests at DNSimple are handled by the members of our team. Marketers, developers, operators, all the way to the CEO answer each and every support request we receive personally. This means that any time you get a response from us, it's from someone that works closely with our technology every single day.
It's been working pretty well for us and our customers thus far. However, by developing Standard Operating Procedures, we were hoping to get all of the team members more involved. In the past, we suffered from a select few responding to the majority of support requests. The reason behind this, is because the more support requests you deal with, the easier they become. This leads to some people having the answers right off the top of their heads, while it may take hours of investigation for someone else. Another challenge may be if English is not your first language, formulating responses for complicated solutions can sometimes be a struggle. Lastly, not every single one of our company policies is written down somewhere—there are some "unspoken rules" that we have at DNSimple (the SOPs will surely help us with that too), so it can be hard to answer a customer without the help of Anthony or Simone.
Hopefully, with clearly defined Standard Operating Procedures, we can make it more accessible for all members of our team to contribute to the various areas of DNSimple. With SOPs we define expectations, where to look for help, and support etiquette when taking over a ticket someone else may have been working on.
Indeed! This very blog post is the result of a new SOP we defined at DNSimple somewhat recently. Aside from wanting to tell you all our stories, each team member must contribute at least one blog post per month. The idea behind this is to try and keep our customers as informed as possible, share cool things we've learned, and practice our individual writing skills. So far, I think we've been successful in this. If you follow our blog, hopefully you've been enjoying the content we've been producing. On Tuesdays we try to post technical blogs, such as Ruby Coercion Protocols, Tales of a Chef Workflow: Packaging, or Announcing the DNSimple Platform Developer Preview. Fridays are reserved for more "light-hearted" posts, or posts not directly related to programming, but broader concepts, remote work, or meetup recaps.
There are several other SOPs, in addition to the two I've already described. For the sake of brevity, there's really no need to dive too deeply into them. The important thing to note is that for each of these, we have created guides and steps for the team to follow in case anyone ever finds themselves lacking the prerequisite knowledge or guidance to approach a certain task. Some examples of other SOPs are meeting attendance (all team members are expected to attend meetings they are invited to, or to notify the team if they cannot attend), participation in peer reviews, Availability tracking (keeping the team updated with regard to vacation or personal days), and the on-call rotation (follow-the-sun weekly pager rotation). These are just some examples of a list containing (as of now) 27 SOPs for the DNSimple team, we hope that as time progresses the list continues to be improved and expanded upon.
Why do you do all this stuff?
We're a close-knit team of 12 at DNSimple. We like to motivate each other, push each other, and help each other grow. Doing these tasks in-house and with regularity enforces several things that benefit all of us as team members and as people. Speaking with our customers allows us to feel their pain, and we use that pain moving forward to make our application better and easier to use every day. Talking about what we're up to in the blog helps us stop and take a second to think, "this was really cool, maybe someone else could benefit from this knowledge". Adhering to the SOPs we decided on as a team holds us each accountable, and gives us things to think about outside of the scope of our current job. It allows team members to be involved in multiple areas of the business, which is beneficial for everyone.
It's true that we don't necessarily have to do these things, or that we could potentially outsource some of it and leave our developer's time to develop and our operator's time to operate. But I don't think anybody here necessarily wants that. We see these tasks as an opportunity to grow or (in some cases) give back. Sometimes it's hard to know how each of us doing something (or not doing something) might influence the team, and I think SOPs are a great way for us to stay on track, hold ourselves accountable, and improve our business for a future generation of DNSimplers.