Below is an article originally written by Chuck Groom at PowerToFly Partner VTS, and published on October 8, 2018. Go to VTS' page on PowerToFly to see their open positions and learn more.

At VTS, the engineering team worked diligently to distill the attributes that define our culture and make work meaningful. The resulting engineering values provide a solid foundation for our team and are a deep source of pride and identity. The process of how we crafted our values is as important as the values themselves; the bottom-up collaborative approach gave the team buy-in and ownership.

How we crafted our values is as important as the values themselves

In this post, I will first present the VTS engineering values. I'll then discuss why values matter and what makes for useful values, both in the context of general values and engineering-focused values. Finally, I'll step through the unique process we adopted and some lessons learned.

The VTS Engineering Values

These values represent us as an engineering team. We adhere to them through storm and clear skies alike. They are intended to help us make decisions as well as to remind ourselves of the team that we wish to be

1. We are people first: We foster psychological safety by ensuring everyone feels welcome and encouraged to share their ideas and skills. We provide a space that is accepting and inclusive of all identities and backgrounds.
2. We are students and teachers: We make time for learning experiences, and we share them with our teammates and the community. Lunch and learns, group code review, and pairing are all part of our toolbox.
3. We are all owners: We think about testing up front. We leave things better than we found them, even if that product, feature, class, test or component is another team's responsibility. We monitor usage, performance, and security to know that our code is working as intended, and see it over the finish line.
4. We make mistakes together: Through honest reflection we can turn mistakes into learning experiences and prevent them in the future. This gives us room to experiment and fail in a blameless culture but keeps us accountable for the resolution.
5. We ask why a lot: We thoughtfully consider our technical, product, and process decisions from the start and as we go. If they're not helping, they're hurting.
6. We strive for simplicity: We aim to build a sustainable platform that we can continue to extend and maintain. Simple solutions aren't easy, but they're worth it.
7. We ship product, not code: Our decision making is heavily influenced by business and customer concerns. We're not just building a codebase, we're solving our customers' problems.
8. We thrive on feedback: Meaningful feedback is a gift and opportunity to grow. We build strong teams and rely on that trust to deliver it. We speak the plain truth to each other staying genuine, transparent, and straightforward.

Let's Absorb Those for a Moment

I'm blown away by the values that emerged; they're deeply humanistic, they ring true, and they're from engineers for engineers.

I couldn't have written these. My fellow managers would have emphasized different things (sorry, friends!). Many engineers would have gone off in the weeds. This was a true team effort that distilled and sharpened; and it's absolutely inspiring.

Why Values? Why Engineering Values?

Let's take a big step back, and ask: why go through the effort of crafting values? This was a fad that led to the kind of mealy-mouthed statements that we snicker at, right?

While poorly written values may be feel-good drivel, I'd argue that an authentic exercise of seeking a common set of core values and principles lays a bedrock foundation of culture. Values are a tool that informs who is hired and promoted, how to give feedback, and how to communicate. Useful values do the following:

• Express opinions and pick a side. A good value draws a line in the sand and is not universal. Say what you will about its merits, but Facebook's "Move Fast and Break Things" expresses a strong opinion (action matters more than stability) and is specific (e.g. you wouldn't hear this at a medical device company). Meaningful values have real teeth and establish principles that constrain behavior and risk alienating people who disagree.
• Describe the team at its best. Values capture the essential, authentic essence of what a team is most proud of being. There will be a mix of some values that are anchored in current culture ("we already do this good thing, let's do more of that"), and others that are more aspirational ("if we did this thing, we'd be better"). If there are too many aspirational values things may not seem rooted in reality; but there needs to be a push to challenge the status quo and to be better.
• Are worded in a human-friendly way. The specific phrases and language should be used in everyday conversation. They should avoid corporate-speak and sound common-sense.
• Avoid the bland and generic. For example, sentiments like "We Respect Employees" and "Integrity" are pleasant but pointless because everyone ought to be promoting these. You can spot the sad result of watered-down compromises and groupthink a mile away.

You can have both company-wide values and engineering-team values. Engineering values are specific to the daily work of solving problems with software, and get into the details of how we expect to do work. For example:

• How do we think about tech debt?
• What is the testing culture and expectations for who-checks-what?
• How to resolve the tension between shipping quickly vs. shipping quality?
• What are the unusual rituals or processes that make us unique?
• How do we insist on operational excellence while avoiding burn-out?
• Do we promote or reject a hero culture?
• What is our culture for engaging in debate and resolving disagreements?

See the excellent article Make Your Values Mean Something from the Harvard Business Review (2002).

The Engineering Values Process at VTS

In 2015, VTS went through a deliberate engineering team feedback process to dig into "what qualities make a good engineer at VTS?" The resulting values were solid; but they became a bit out-of-date.

We decided to take a stab at updating our engineering values, as 5–10 short phrases with a bit of explanation text. While this process was kicked off by engineering management, we were well aware at the outset that:

1. The values won't be seen as legitimate unless they come from all of engineering (programmers, QA, and managers). Everyone is a stakeholder and has an opportunity for meaningful input.
2. The process must not get stalled by endless meetings.
3. We want to capture "sharp" opinions, and not land in the gray middle ground of averaging out everyone's ideas.

That's a tough set of criteria! True consensus with a large group can take forever. A democratic voting process moves quickly, but often favors the loudest voice or lands in the middle. We landed on a weird hybrid democratic-consensus model that just happened to work. I won't lie; this took a ton of quiet background coordination, and we relied heavily on the fact that everyone brought so much goodwill and positive energy to the table. This could easily have been disrupted if folks had been cynical or political.

Step 1: Engineering Breakout Groups (Democratic; Dot-voting)

We assigned all engineers (including QA) to breakout groups of 5–6 people. Managers were assigned to their own, separate breakout group.

People were given plenty of heads-up and encouragement to think about values ahead of time, and to come to the meeting prepared. For each group, we tapped one person on the shoulder and asked them to run their session as the logistical time-keeper and secretary. The format was:

• Discuss engineering values and how these will be used.
• Everyone writes down values they find important as raw, short phrases.
• Each person shares the 2 values they thought are most important.
• Put all values on a board, with grouping of common themes.
• Dot-vote to pick the top-10 values from the group.

At the end of the meeting, the group choose person as their delegate to the follow-up "Engineering Values Working Group."

Step 2: Working Group Draft (Consensus)

The working group (Alex W.; the other Alex W.; Dan; Ian; and Maddie — you rock!) met multiple times over a 3 week period to discuss the raw inputs, and discern common themes to distill into a set of 5–10 values. They engaged deeply to find common themes, without diluting the original intent.

Did I say "deeply?". This group dug in and committed completely.

They tackled this in multiple passes. In the first sessions, they grouped values and fleshed them out until they could agree that they had found broad but specific coverage. Later, they word-smithed these into clear phrases. For this later phase, their approach was to have everyone try their hand at writing independently, then when they met they would and pick-and-choose the phasing that seemed most apropos.

Note that engineering management had one person (Dan — thanks a ton!) who was a delegate. It was critical to include the manager perspective, too; not to drive the process, but because management has a point of view in the what matters for team values that ought to be included, and is a stakeholder too.

In one fascinating exchange, Dan was asked to bring higher-level leadership feedback the group. While the working group was open to the general idea of receiving input, they vigorously maintained ownership, and molded those ideas into a form everyone could agree on.

Lesson learned: once you have set smart and committed people on a path, honor that path and trust them to do the right thing.

Step 3: Team Feedback (Advisory)

The ultimate result of the working group sessions was a short, rich Google doc. This was shared with the entire engineering team as a "request for comments" with suggestion-mode enabled. People had a week to give their feedback, and then it was presented at the engineering all-hands.

The group received a ton of feedback. The comment threads allowed discussions that helped to flush some hard topics out into the open. One that stood out to me was a discussion of our testing culture, and test driven development (TDD) in particular. We want to say it's a value, but tests can be inconsistent and this seems more aspirational than actual. Is there enough leadership support for engineers to give testing the attention we say it deserves? This discussion is values at work, because it was forcing us to face some hard questions that we'd been sweeping under the rug. (For the record, where we landed is: yes, leadership should do a better job supporting teams in giving them the time they need to do upfront testing and TDD, and it's absolutely where we'd want folks to go).

Step 4: Final Version (Allows for Future Updates)

The working group met for a final time to incorporate the feedback into the working version that we're using today. We were careful to set the expectation with the team that this is a living document, and we'll update it regularly going forward. It's better to get something good out there than struggle to be absolutely perfect.

Some Lessons Learned

1. Trust that earnest and hard-working people will land at a good place.
2. The values that emerge from a bottoms-up process may be different than anyone will predict, but they'll be authentic to the team.
3. The engineering values process may take a lot more work than anyone anticipates — especially on the mundane logistical and getting-the-ball-rolling side of things.
4. Allow leadership visibility and input, but let the group retain ownership.

Now What?

Now that we have our values… what do we do with them?

As it turns out, values are tremendously useful!

• We are revising our engineering jobs ladder using these values.
• Engineers are citing values on a daily basis to give constructive criticism to one another, in pull requests, and (gulp) to push feedback upwards to their managers.
• Recruiting is sharing these values with candidates as a tool to convey our DNA, and candidates are loving it.
• HR will use these values as the framework for our semi-annual 360 review process.