Team Principles

As part of being in the SRE team, you should learn, understand, experience, and practice the following principles. They should be a part of every interaction with your fellow colleagues and with external teams.

Work as a team to solve issues for our customers

• We, the SRE team at TableCheck, endeavor to

• treat our customers with respect,

  • always put the team’s success before our own,

  • use public channels only for communications with customers,

  • document every system a customer could interact with - code is NOT documentation,

  • understand that input and credit on a project is shared between all team members equally,

  • trust our team members for advice, and to act on that advice

  • simplify customer red-tape and processes as much as possible by using tools such as Jira,

  • record customer interactions in tools such as Jira and directly talk about customer issues so that the rest of the team has a clear picture

Everything can be distilled into a ticket

1. No work is done without a ticket

2. Side-channel requests must be redirected to tickets, even if they're small

   • Exploratory work related to what you're doing, but not part of the ticket is okay, but it must be time-boxed. If there is merit in pursuing it, and you cannot finish such work within 2-4 hours, then create a new ticket with the goal and your findings so far. Follow up by talking about it with the group at the next standup.

3. See Rule 1.

Work in public

No member of the SRE team should ever work on a project without discussing it with the team, especially on projects that affect our customers. See the above point about “always put the team’s success before our own” and “vow to use public channels only for communications with customers”.

It does not matter whether the work affects only the SRE team or a specific customer or subset of customers, every piece of work must be built in public. It doesn’t matter if the work is a customer request, infrastructure request, 20% time, or any other type of work that could be thought of. It must be done in a manner which communicates the work, and the learnings, to the team.

Building in public is

• using Jira to track progress and provide updates on your work,

• using Confluence to write plans and documentation for specific components,

• constantly engaging your team to work together on the project - not just engaging them at the end when it’s finalized

• providing updates on your work, if you didn’t get to finish something before the end of the day, communicate. We don’t get the benefit of working 24 hour days, and other team members in different time zones can benefit from this information.

Building in public is not

• refusing feedback or hiding a piece of work until it’s finalized

• directly engaging customers and completing work on their projects without discussing it with the team

• mentioning the work in passing or just that you are “working on it”

Understand that mistakes happen

In all fields, and not just fields such as SRE and DevOps, there are always going to be mistakes. We’re all human. Don’t blame people for mistakes, and don’t ask them or tell them to take the fall. You make, and will continue to make, mistakes too.

Focus on rectifying the issue, as a team.

Bias for action and experience

Speed matters in business. Speed matters for our customers. Many decisions and actions are reversible and do not need extensive study. Trust your team to give you good advice and act on that advice.

Perfect is the enemy of done.

• Always ask for advice.

• Your fellow team members are right, a lot. You will often find that if you ignore advice, you will end up going back to what they suggested in the first place.

• Use the daily time you have with senior engineers and your manager. They can provide direct insight which can guide your decisions.

• Don’t be afraid to jump into a huddle to make a quick decision on a technical change.

• Never hide a decision.

Build with the tools you have

It usually takes strong judgment and good instincts in order to find, experiment with, build upon, and finally bring a vendor to production.

• We, the SRE team at TableCheck, endeavor to

• use existing tooling to solve your our first before picking another tool,

  • understand that if a tool doesn’t fit, to select another one from the box (preferably from the same vendor),

  • avoid building custom solutions to commonly solved problems,

  • engage in healthy vendor selection processes involving the entire team, and our customers.