View a tl;dr on Substack.
For a tech company, engineering culture is integral to the lifeblood of the organization. These cultural norms have both short and long term impacts, and starts forming at the early stages of organizational growth.
I’ve worked on two extremes of engineering culture:
In an organization where technical excellence is revered: There was a strong focus on writing scalable and maintainable code, sometimes at the expense of velocity. Engineers had authority over product decisions. Features that required unsustainable workarounds were often reworked or scrapped entirely. This resulted in a codebase that was extremely robust and a generally happier engineering team. However, product development was noticeably hindered by the focus on technical excellence.
In an organization where velocity is king: The company was made up of many small teams that operated like individual startups. While this was exhilarating in many ways, maintainability was often deprioritized for the sake of velocity. This resulted in a flaky codebase with poor dev tooling.
At my current startup, I have significant authority over both product and engineering. which means that I’m in a unique position to establish a cohesive engineering culture within the company.
So the question is - what’s the most optimal culture for the company to thrive?
While I don’t have the definitive answer, what I do know is that there is no one-size-fits-all culture that reigns supreme over the rest.
Culture evolves as the company grows. When the product is in its infancy, speed is of utmost importance. The goal of the organization is to move as fast as possible to achieve product market fit. This is the time to move fast and break things. During this stage, it’s okay to have “hacks” to achieve some product objective if it means a faster time to market.
However, this is not an excuse to be sloppy. It’s important to understand the shortcuts that were taken and compile a list of items that should be revisited if the product grows past infancy.
I also believe that product infancy is the only time where sloppiness is acceptable. In my opinion, engineering excellence paves the way to a scalable product and a happy organization. As the product matures, it’s important to create an environment where code quality is prioritized. This means:
- Structuring incentives to promote code quality and encourage development of internal tooling
- Consciously cataloguing and addressing technical debt
- Communicating with product / design to create a feature roadmap that is synergistic with engineering excellence
Having a team that is focused on writing high-quality code means that the product is resistant to breakage. Moreover, high technical standards pave the way to better internal tooling and decreased developer mental load, ultimately leading to a happier workforce.
The alternative perspective is that an organization should optimize for user impact. At the end of the day, code is written to solve a user problem, and the quality of that code is sometimes uncorrelated with the user’s quality of experience.
I would push back on this perspective on several fronts:
- Poor code quality ultimately means increased downtime and higher probability of bugs, leading to poorer user experience
- The organization also needs to serve its employees. Higher quality code and better internal tooling translates to happier and more productive developers
However, I do recognize that there is a spectrum of ideal engineering cultures, where one end optimizes for technical excellence and the other prioritizes user impact. The true ideal varies depending on the organization and the product that it serves, but understanding the trade-offs is a pre-requisite to establishing a culture that serves all stakeholders of the company.
Top comments (0)