In the hiking/backpacking world most people are familiar with the Ten Essentials - a short list of things you should always take with you when you're hiking or traveling in the outdoors. Many outdoor organizations have their own version of the list, some with fewer than 10, some with more, but each with a set of things that they consider crucial to having a safe and enjoyable experience in the outdoors. The point of the list isn't to be an exhaustive list of survival gear but simply to provide a common starting point that'll help keep people safe in most situations.
When you're new to hiking this list is very helpful (and arguably very necessary). As you gain more experience you start to develop a natural intuition for what you need on any given trip. And yet it's still helpful to review the list from time to time to make sure you haven't lost sight of something important.
Although there are myriad development methodologies that espouse values common to their particular approach (e.g. agile, extreme programming, test driven development) I am not aware of a similarly universal “ten essentials” type of list for software development.
When I took on the role of leading our Engineering team, I wanted to define a set of values that captured the way that we develop software. A short list that would be easy to refer to, that could help each engineer approach technical decisions and stay true to one of our corporate values of “We strive to be exponentially better.” A set of “essentials” that captured the things we value most on our team - enabling everyone on the team to benefit and learn from them (no matter where they are in their career as a software developer).
Our goal was not to define a comprehensive list of steps to follow, or come up with unique values that’d only ever be seen within our walls. Rather, the goal was more about quantifying and documenting some of the engineering ideals and intuitions we want to hold to when it comes to developing and shipping high quality software. These values would help keep us accountable as engineers to the work we do, as well as to help us make the right kinds of tradeoffs when considering "fast vs. good." Or in terms of one of our corporate values, what are practical ways we can be "exponentially better" as an engineering team?
One concept that anchored what we were after was the idea of "catchphrases" as described in the book Culture Code. We have an existing set of corporate values, so this wasn't about trying to define a new/different direction for the company, but rather be a rallying cry of sorts for the engineering team. I shared an initial Slack message with the whole engineering team outlining what I was trying to do and tossed out a few values I'd been thinking of. What followed over the next several weeks was a lively discussion about how to make my suggestions align with our actual values and how to make them succinct enough to work. Additionally, we had to filter out a lot of good ideas without filtering out the values that they represented (in other words, for any idea that didn't make the cut, could we still see it represented in one or more of the other values?).
We landed on 4 values that I think accomplish all of this. Each is just a few words, but collectively they speak to a broader set of ideals. They’re drawn from our personal values and experiences within the software development industry. Put another way, they’re not particularly novel - but they do represent the core of what we want to prioritize when developing software.
This covers a lot of our bases when it comes to one of the fundamentals of shipping high quality software - QA. Testing isn’t something that only our test engineers do, it’s incumbent on every engineer to make sure the software they write works the way that it’s supposed to.
One of our corporate core values is “do it right the first time.” As we see with our next Engineering Value, this doesn’t mean we don’t expect to make mistakes, but rather that when we say something is done that we’ve validated that it in fact works as expected. Or as Lisa Simpson so eloquently captures it: “I think we should do a test.”
We know that we’ll make mistakes. Another core value as a company is “surface the bad news quickly.” While many mistakes and attempts during the course of development don’t rise to the level of what we’d consider “bad news,” if we don't react quickly when something doesn’t work as expected, those mistakes can become "bad news". When (not if) something doesn’t work as expected, we should quickly try something else.
Perhaps more important with this value is thinking about how we approach large projects. Instead of taking on all of the complexity that’s needed to deliver something to production, how can we validate the general approach in an iterative manner?
There’s an almost limitless variety of features you could add to any product or project. What’s often more valuable is figuring out what’s NOT needed and only building what IS needed. On the surface that seems obvious, but this value helps us avoiding building things that we may need in the future. At a corporate level we talk a lot about understanding “the fierce urgency of now” vs. “the tyranny of the urgent”.
The most expensive thing you can do as a startup is to add a product feature. I think most leaders have no idea how much a new product feature costs!
I really like the idea of empowering teams to act like an “owner” or “stakeholder,” and this captures that idea. Remembering that we’re part of a team, all dependent on one another, is more holistic than a collection of individuals acting like an owner.
The most literal example I’ve pointed to around this value is in the sport of crew - it took every single one of the Boys in the Boat to successfully row their way to Olympic gold in 1936. Or to paraphrase another one of our corporate values, they invested in doing what was necessary to succeed.
In thinking through how to make these more visible I considered several options. We're not a sports team, so using them as a catchphrase we actually say out loud a lot doesn't fit well. We're a mostly remote team, so plastering them all over the office walls wouldn't do much either.
Instead I opted to spend a little time each week with a regular Slack post in our Engineering team channel that I call "Wednesday Note" where I cover a variety of topics that are relevant/useful for the team (things they should know, things I've done, key development cycle updates, etc.). One of the sections I include in this weekly note is a section titled "Things to Value." I pick one of our four values each week and then either link to some related content or share some of my thoughts about that value.
Since starting this I’ve linked to everything from technical blog posts, entrepreneurship/business articles and the Simpsons, and I have drawn from my own experiences and thoughts (some of which I’ve linked to above). One of my favorite ways to reinforce these values is by pointing to something that’s happened recently on the team as a concrete example of how we’ve demonstrated a particular value. There’s nothing magical about the things that I’ve shared - but I’ve found it helpful to keep them at the forefront of our collective team consciousness.
Since backpacking is a favorite hobby of mine, I regularly consume a lot of related content. I do this in part because I just enjoy it, but it also reminds me of the actual essentials of the craft, which helps me enjoy my time outdoors with a reasonable level of confidence that I’ll be able to do it again the next time.
Similarly, I'm also always evaluating things we're doing as a team, trying to keep an unbiased eye out for anything we should start or stop doing. While we might evolve our values over time, what's more important is that we're being intentional about how we approach our work. After all, making changes as needed is consistent with our value of "successive refinement" - so I think it's safe to say we're right on the mark (for now).