Engineering Principles
In the last year, I had the pleasure to work in multiple great teams. Each one was unique and faced different challenges. But the below-listed 5 simple principles boosted the productivity of all of them.
Principles:
-
Focus on Customers:
- Focus on solving actual customers’ problems
- Don’t do literally what they ask for but enable them to get their jobs done
- Say No to stuff that does not matter yet
-
Experiment and Move Fast:
- Release prototypes to customers to get their feedback
- Continuously, keep finding the smallest increment of value and delivering it
- Think big and wild, try things and see what sticks
- Get to doing as soon as possible
- Better to ask for forgiveness than permission
-
Simplify Everything:
- Simplify solutions conceptually to make it easy to explain them
- Simplify code to make it easy to understand it and change it
- Simplify operations of deployed systems to reduce maintenance burden
- Perfect is the enemy of good
-
Automate Everything:
- to minimize errors; e.g. automatic tests, automated builds and deployments
- to avoid repetitive work; e.g. automate common tasks such as builds and releases
- to avoid redundant work; e.g. leverage AI-powered tools instead of manual labour
- But don’t overengineer — simplify and build for the now
-
Ensure Reproducibility:
- What works for one works for others
- What works for devs works for customers
- What does not work for customers fails for devs
The principles are engineering focused but are pretty universal and can be applied to other domains as well. They are really about increasing: (i) your adequacy, (ii) your efficiency.
By adequacy, I mean the measure of being grounded to reality (in oppose to living in a wonderful illusionary world). It is making sure that you are solving the right problem needed by your customers. We can also call it a market-product alignment.
Efficiency is pretty straightforward. Once we know our model of the problem space is adequate, we need to execute in the most efficient way. The solution should: (a) solve the problem, and (b) should not overthink it. We can also call it a product-solution alignment.
Note: These are somewhat very “raw” and unstructured thoughts. Capturing it here so I can get to it later.
Comments