Engineering principles: putting our values into practice
VP of Engineering, Ilya Kozlov, shares the logic and value behind our engineering principles. Get a glimpse at how these principles help our engineers grow and take ownership of their delivery.
Why have engineering principles?
At Taxfix, everything starts with our values: Deliver, Trust, Develop, and Understand. Everyone, regardless of what role they play in the company, has a shared understanding of these values. Engineering principles realize our values in concrete concepts and guide everyone in a fair and structured way. The goal is to make our team as autonomous as possible — in discovery, decision making, delivery, and growth.
Principles are a road map for new joiners to quickly get up to speed on how we do things here. They provide a playbook for actions and how to approach new challenges. For example, if two different people face the same problem in a similar context, their solutions will be roughly the same because they were led by the same guidelines. Our principles also act as a benchmark for feedback and development. Behind every principle is a set of expectations for our engineers’ behavior, which provides direction for self-improvement.
How did we go about forming these principles?
Although values are an integral part of daily life, it was not always clear how to put these into action. Our engineers wanted more specific examples of how to live these values in practice.
We realized that we needed an engineering playbook that detailed exactly what we valued and what we expected from the team. We came together for a first brainstorming session — Juan Ramirez, our engineering manager in Madrid, Alex De Leon, our CTO, and myself. Together we identified a few key areas to work on but quickly discovered our view wasn’t complete. We needed to hear every voice in the engineering organization.
Through a series of workshops over the next few months, we discussed ideas, challenged each other, and pulled in references from some of the market’s leading engineering cultures. The result was a structure of eight value-driven engineering principles supported by best practice examples.
What do engineering principles mean in practice?
Here’s a glimpse at a few of our engineering principles:
Deliver
Under the value Deliver, we have a principle of Internal Open Source. This means that anyone can contribute to any application or service, also known as weak code ownership. Internal Open Source helps us deliver because when the code base is shared, you effectively don’t have dependencies.
One major issue many companies struggle with is dependency. If a team wants to deliver a new feature, they often need to build something in their own service and then reach out to another team and wait for all the pieces to come together. Usually, the bigger you are as a company, the more complicated this problem becomes. You’re essentially blocked by dependencies. Here we’re running in cross-functional teams and we use one language almost everywhere, JavaScript. This enables anyone to go to a specific service in the company and make a change there. There’s no need to wait — you can implement it yourself.
Trust
Under our Trust value, we have the principle of We are One Team. This means we optimize for the output of the team and the organization, not the individual. An individual can surely achieve the result they are after, but at what cost to the rest of the organization? If you only have your own goal in mind, the entire company will not be efficient. So, we’re trying to find ways to achieve better results by using a combination of expertise, backgrounds, and perspectives. There are no “one-person” jobs, only collaborations.
Develop
Within our value Develop, we included the principle of We Learn from Each Other. Besides standard learning initiatives, like attending meetups and visiting conferences, we want to encourage knowledge sharing between team members. What we’re trying to achieve here is matching different skillsets within our teams. If, for example, there is a front-end engineer who wants to transition into full-stack, then we match them with a back-end engineer. We pair these two together so they can grow as a team and as individuals through driving new projects outside their typical expertise.
Understand
The last example I would like to give relates to our Understand value — Create and Share Context. This principle goes beyond just documentation; it’s a two-way street. We expect our team to create context for others. On top of this, they should be proactive about reading and digesting the context they receive. When applied to pull requests, for example, people don’t always know your context or what you’re trying to achieve in your team. If you’re collaborating and trying to change someone else’s repository, you have to give as much context as possible. You need to explain your intention, any compromises you’ve made, a timeline, and how this change connects to bigger changes down the line. We don’t believe in right or wrong decisions. We only believe in decisions that are made in the right context or in missing context.
Interested in joining our Engineering team? Check out our open positions.
