Engineering Values
One of our main philosophical ideals at Neighborhoods.com Engineering is to empower every engineer in our organization. Not only do we believe that this makes our brilliant band of creative problem solvers happy, but we also consider it imperative to our ability to be able to assess, trial, and adopt the ever changing number of things that live in the vast landscape of modern software engineering. We strongly believe that this is what allows us to excel in the market.
This goal however introduced an interesting challenge as we grew. As engineers continued to join our team, questions naturally arose as to which design to choose as a solution for a particular problem. A simple (but very naive and essentially meaningless) answer to that abstract question is
Make the right decision.
This is a scenario that every growing engineering team faces, and it has a surplus of ongoing conversations on tech blogs. It essentially boils down to something like this:
At ten engineers the right decision is usually easily defined by verbal consensus (everyone just figures it out), but after an org grows past that point, and continues to grow, the answer to what a right decision is becomes much more difficult to derive.
We realized that this was significantly impeding our ability to empower our team.
Engineers slowed down their pace of innovation while seeking out what the right decision was. We realized that trying to come to a consensus at our ever increasing team size no longer scaled. It became evident that we needed to uncover the philosophic rubric that was implicitly at the heart of how we as individuals made technical decisions. Furthermore, we realized that once we discovered what that was, it needed to be codified.
It was a hard problem. There was a lot of ambiguity as to exactly what our end result would be and what shape it would take. The process was long, spanning over several months, but in the end it was extremely revealing. It forced us to dig into our internal methodologies for how we made technical decisions as individuals. It forced us to ask ourselves
What is important to me when making any technical decision?
If you have never gone through this exercise I highly recommend trying it — especially with a multi-disciplinary group.
In our journey, it brought to light that we all shared very similar sentiments that spanned drastically different discipline domains, each individual had a particular shade on common ideas that addressed something particular about the domain in which they operated on a daily basis. However, the themes all had strong commonalities, and over the course of several months we challenged each other to get to the heart of what was important and shared amongst us.
In the end we arrived at the following.
We value…
Ease of Change
Because nothing is permanent, my work must have clear boundaries, narrow scope and minimal complexity.
The Agile Manifesto and The Unix Philosophy
I believe that these principles are paramount in writing good code, having healthy relationships with my team, and constantly seeking to improve our products and processes.
The Best Solution
My success depends on our success. The best solution is the one that is best for the team.
Skepticism of our Work
I know that mistakes are normal and common. I assume my work is broken until I prove otherwise.
Experimentation
I must have a constant sense of curiosity and adaptability for improving myself, my work, our products, and my team. This requires me to fail fast and fail often to learn new things.
The Pit of Success
Because others will share in my work, I must ensure that the work I produce guides my team toward good practices by making bad practices difficult.
Ownership
I must take pride in my work and nurture it to ensure the success of my team and our company. Outstanding craftsmanship is vital to me.
Today every engineer is able to use this language to help guide not only their own decisions, but technical conversations with groups of other engineers or stakeholders as well. It serves as a common vocabulary, and a set of questions that every technical decision must be able to answer.
It frees and empowers us to use anything that can uphold these values in order to accomplish a goal. It gives us a compass to know in what direction the right decision is without prescribing a rigid set of specific boundaries in how an objective is executed.
Our goal remains, and will always remain, to empower and free our engineers to solve important, difficult, and new problems. As an engineer at Neighborhoods.com today I am very proud and strongly believe that we are the closest to this ideal that we have ever been.
However, it all rests upon this philosophical foundation, our common vocabulary that describes and guides us to what it is that we as a team value as a right decision. It is the stewardship of every teammate to diligently uphold our values.
We are very passionate about these attributes being an indivisible package. If you are smart and kind and find that our Engineering Values are congruent with yours, we really want to hear from you.
