Engineering principles make a software company identity. Principles guide engineering teams to deliver business outcomes at scale. They are blueprints to actions and behaviors. Engineering leaders can lean on these principles to establish guidelines for good behaviors and actions. Although engineering principles differ from one organization to another, organizations can apply the following principles.
Ship Frequently
Delivering value depends on the agility of the team. We deliver tangible outcomes on a regular cadence. We want to enable a fast feedback loop with the customer. We have a bias for action to deliver business value. Thus, we ship frequently and responsibly. Though, we never compromise quality.
Conduct Incident Debrief
We learn from our mistakes. When an incident occurs, it deserves an incident debrief meeting. The intent is to uncover a class of defects that stop us from delivering robust and reliable services. We want to analyze incidents in detail and implement procedures to prevent future occurrences. We conduct meetings blame-free.
Design in Public
We use the collective intelligence of our engineering team. We have a great pool of talent with different expertise. Designing in public gives opportunity to polish our design by constructive feedback. Capitalizing expertise ultimately helps us to deliver better software. We learn from our peers and clear out potential problems.
Hire, Grow and Retain The Best
We want to hire the best talent, set them up for success, and provide an environment to retain them. In Steve Jobs’s words, “Go after the cream of the cream. A small team of A+ players can run circles around a giant team of B and C players”. Hiring is the beginning. We help engineers to grow and give them opportunities. We provide fast feedback and accommodate needs where possible.
Review all Code
We ensure consistency in our code, improve our implementation, learn from each other, strive for quality by reviewing code. Scripts, patches, and project code should go through a code review process regardless of their size or purpose. A portion of production incidents come from small yet critical changes. We want to transfer knowledge as well as share expertise.
Build CI/CD Pipelines
We enable ourselves to release frequently and confidently with continuous integration and deployment. We add necessary testing and coverage to find defects and bugs before they hit production. Automating the process helps us deliver value at scale.
Run What You Build
We are accountable for the services and systems we build. We think about the observability of the components from day one. Accountability push engineers to release services responsibly. On the flip side, it gives teams autonomy and decentralization. Each team can build as many services/systems and then run them.
Write Definition of Done
Definition of Done(DoD) can require different things depending on the work. Some work is longer such as initiatives. Some are small such as a task. In both cases, writing the definition of done gives us clear goals and a finish line regardless of the size of the work. DoD ensures expectations and prevents jobs to linger without ever completing. For initiatives, scope creeping can occur in the absence of DoD.
References
Blog: Is ‘you build it, you run it’s living up to the hype?
Article: Attracting and retaining the right talent