Proposed team values

I've been involved in quite a bit of hiring as our company continues to grow. I'm always looking through engineering CV's. If someone looks interesting, I'll spend a few minutes looking through previous employers. If it's a company I'm unfamiliar with I might check out the website.  

It's not uncommon to find companies referring to their values. I think it was Amazon that popularized this practice, and it seems like many of these "value-driven" companies seem to share at least some of Amazon's 14 principles. ATA shares a couple of them.

I've noticed that Amazon also seems to update their principles over time, as well. I'm pretty sure the last time I looked, I hadn't seen "Strive to be Earth's Best Employer" or "Success and Scale Bring Broad Responsibility" on the list...

As our company grows, and new challenges are presented, I'm reflecting on which new values might now be beneficial for us to adopt – and which old values might be worth deprecating.

In a sense, it brings to my mind Nietzsche's "revaluation of all values", an early and important concept. In brief, this concept was about how moralities emerge based on the needs of a society at a given time, yet can then persist for much longer, eventually becoming more harmful than good.

So while Nietzsche's work might not have been intended for software development, I still believe that it's a good practice to do a regular self-evaluation every so often to make sure that ones beliefs, values, behaviours, and rituals are serving our best interest.

In that regard, there are three values that I've been giving thought to, especially in the era of remote engineering teams:

Be Prepared

This is one that I can't recall seeing anywhere else, but it seems absolutely ripe to me. This speaks to meetings, communications, change management, but it also speaks to system stability, reliability, and fault-tolerance. No need to be overly-prepared, and I'm certainly not proposing scoping up or over-engineering – just adopting a second-order thought process that considers the context in which your code, system, or communication will live.

Stay Nimble

This also works through several lenses. As an engineer, prefer code that can easily be tested, extended, and removed, and prioritize deliverables that will result in a shorter feedback loop. As someone who is establishing a project roadmap, create plans that iteratively and quickly prove value to reduce risk and preserve the ability to adapt to changing requirements. As an organization, capitalize on market opportunities when they are presented, which is simply not possible if department planning is an annual affaire.

The largest gains appear when all levels of the organization demonstrate this value in tandem. I try to avoid using the word "agile" as it has become loaded, but I think "nimble" really conveys the importance, and the book Team Topologies does an excellent job elaborating on this approach.

Execute with Urgency

I've had to come back to this post to add this one. It came out of a conversation with one of our senior engineers. When someone demonstrates urgency, it's a motivator for the whole team. Demonstrating urgency means there is an understanding regarding why a task is top priority, and how it fits into the sprint.

It's worth noting that this does not necessitate sloppy work. It's the manner in how the work is delivered.