By reading this article you'll learn that: not everything that appears as pep talk is a brainwash, you can be a Moses (& carve some stone tablets) for your team, why 10 commandments are better than "Chairman's Mao Little Red Book", where's the border between good & bad principles, where do the values come from (& whether they can be imposed) ...
Utterly pragmatic creatures known as engineers are by definition allergic to any kind of activities they classify as "brainwash". This category is quite wide: all sorts of pep talks, motivational speeches, noble ideas/values behind work, deeper message or meaning (of the product built) - very few seem to care about such "mumbo-jumbo", in fact for many of us it acts more like a deterrent (or even worse) than an attractor.
That's why we (in the best case), pass indifferently by topics like a mission statement, strategy brief, core values or principles.
Which is the major mistake (IMHO).
All these terms (each of them has a slightly different meaning & applicability) play a very important role - they do align people on common goals, strategies, motivations, success factors, values to live by, etc. They enable us to stay coherent, eliminate the dissonance, reduce frustrations & disappointments, increase the satisfaction from cooperation that appears (in the end) to be much more fruitful than we've initially expected.
Principles in everyday work
Well-formed principles (not many, 5-10 are usually enough) can stand for very complex frameworks of work. Instead of formulating very complicated decisive engines ("what to do if X, what to do if Y") or creating bottlenecks ("each decision has to be approved by our sage, Mr. XYZ who knows all the shit in the org"), it's much smarter to shape set of principles which do back up each decision. How? It's simple:
In case of a debate/clash of will ...
- if fact stands against the opinion, it's the fact that always wins
- but if fact stands against the fact or opinion vs the opinion, the one that "wins" is the one who's backed up by one of the principles
Simple, yet EXTREMELY effective.
Always look for substantive justification that can be derived from one of the principles - if there's none, probably you're doing something wrong ...
Principles in building engineering culture
As engineering culture is built on every day's attitude and behaviors, no wonder in that principles are the foundation of engineering culture.
Consistent, widely respected behaviors are not only an inspiration - based on my own experience, they actually empower more junior people to make their own decisions independently: they feel more confident as soon as they realize their ideas/solutions are backed up by crystal clear, commonly embraced engineering principle(s).
Good, bad (& the ugly)
Not all values are good, cheap bullshit may leak in (if not watched carefully for). "Highest quality for our users", "customer always comes first", "we love teamwork", etc. - these sound great, but are far too generic, while in the same time they don't even sound 100% honest!
- "highest quality?" really? even keeping in mind the skyrocketing price of delta unit (of quality) above some threshold?
- "customer always comes first?" even if the price is the burn-out & entropy of your whole engineering team? really?
Good values need either to fit the "hedgehog concept" (in other words: stand as an unique differentiator for your organization, elevate you to being the best in something - you can read more about that in "Good to Great" by Jim Collins) ...
OR
... match current specifics (/needs/challenges) of your company - e.g. address its very specific concerns.
Some examples of proper principles that come to my mind:
- "Every slice of business logic is accessible (by an interactive application) via the API-exposed service" -> to force key architecture principle (see famous Bezos's API memo)
- "Speed above everything: all of our UI views have to fully loaded in less than 100ms" -> works perfectly if followed literally, e.g. more sophisticated solutions really get dropped just to get load time lower, beyond the threshold
- "We do acknowledge the fact that our codebase lacks proper automated tests, but each new & revisited (modified/extended) functionality chunk will get full coverage" -> clear rule, no ambiguity due to potential, subjective interpretation
- "We put a limit of max 2 parallel, on-going experiments on our team; experiment is not considered concluded until learning notes are published for whole company to benefit from" - again, disciplined delivery, privilege (team can pick an experiment) & obligation (lessons learned have to be documented), etc.
- "We break our work-items into chunks not larger than 2 working days - each of them has to be integrated into the trunk (with production-level quality) at least once per 2 days" -> very useful when aiming for Continuous Delivery and/or when struggling with task granularity
- "Each team member working on the task (incl. developer, QA, etc.) has to be able to answer up to 5 levels of 'Why' questions regarding each particular task" -> to make sure that engineers truly embrace the domain, product & its applicability across the domain.
etc.
The source
OK, but where do these come from? Can I just "invent" the principles I like (personally)? Can these be imposed/forced by the top management across whole organization?
Actually, it's not that easy - the best scenario is always when principles are born "in the wild" first & then are noted down as the side effect of the fact that they are already used (/followed/quoted) on the daily basis.
However, it IS possible to start with the principles/values "pre-designed" initially IF & ONLY IF the leaders truly embrace them and make (out of themselves) living examples of using those in practice. What I mean is an almost-textbook example of leading by example -> if highly-esteemed leaders do refer to imposed principles on the daily basis, their credibility serves as a foundation for wider adoption (of those principles).
