Organizations generally have high level tenets around which culture is shaped and decisions are guided. However, these tenets are generally too high level and provide little insight as to how a team should be run at a more granular level, and equally as important, how individuals operate.

“Operating Principles” attempts to fill this gap by organizing a list of guiding principles that have helped provide clarity on how to deal with various situations, and I am convinced that writing them down on paper will further reinforce the consistent application of such principles across a variety of situations.

It also serves the dual purpose of helping others with whom I collaborate understand the manner in which I tend to operate, in order to settle disagreements and resolve conflicts more easily. I don't claim to be perfect in my application of these principles, but strive to do better everyday. 😊

I hope these will help others as they have helped me in the past.

Here is the list.

1. Meta
2. Top Principles
3. Thinking
4. Work and Culture
5. Software Systems
6. Process and Organization
7. People and Leadership
8. Quotes

1. Conflicts or logical inconsistencies between these principles are reconciled case-by-case.
2. This list should be revised periodically through cycles of aim-plan-act-review.

1. Everything we do at work should revolve around one focus - getting results.
2. Don’t underestimate the importance of knowledge preservation, expansion and organization.
3. Time is valuable and we should strive to not waste anyone’s time, including our own.
4. Constant vigilance, memento mori.
5. Above all else, prioritize people.

1. If in doubt, start from First Principles to fill in the missing gaps in our understanding.
2. Strive to get to a level where we can operate at the highest levels of
   1. Graham’s hierarchy
   2. Maslow’s hierarchy
   3. Bloom’s taxonomy
3. Models simplify at the cost of encapsulating details - it may be necessary to lift the hood.
4. Prefer (at least) second-order thinking by default.
5. Do a worst case scenario analysis to understand the bottom line of a decision.
6. Taking risks is not the same thing as recklessness - it requires doing our homework.
7. Working backwards can often help instate temporal clarity.
8. In face of fear, if something isn’t an Act of God, it’s most likely not deadly.
9. When confronted with complexity, see if any philosophical razors can be of assistance.
10. Allay uncertainty through mitigation strategies and assigning a margin of safety.
11. Argumentum ad antiquitatem is neither an explanation nor a valid justification.
12. One should not engage in ad hominem arguments as the refutations are irrelevant.
13. Ipse dixit is a barrier at work and should be avoided.
14. Unless ceteris paribus is guaranteed, one should not assume it.
15. Unless there is evidence of the contrary, correlation does not imply causation.
16. Consequentialist thinking can save time in the long run.
17. The most effective solution to any problem is prevention.
18. Pragmatism over idealism.
19. Outstanding execution over an outstanding idea.
20. Unless complexity can be justified under intense scrutiny, prefer simplicity.
21. Attaining simplicity is exceedingly complex, but it is generally worth it.
22. Meritocracy over autocracy or democracy.
23. Function over form unless function derives from, or is tied to form.
24. However much time and effort we think we need to master something, we need to at least double the amount of actual practice.
25. The keys to scaling up a project and its operations
    1. Configuration
    2. Organization
    3. Timing

1. Lack of knowledge and experience can be remedied by doing our due diligence.
2. Everything we do at work is a work artifact (e.g. email, meetings, code reviews, diagrams, etc.)
3. The bar should be equally high among all work artifacts, not just those that require precision.
4. What we don’t say, write or do is often as important as what we do commit to action.
5. Intent and tone are more important than the words used to convey them.
6. Build respect by caring for others’ welfare through consistent, concrete actions over time.
7. Trust is built by making promises and keeping them consistently over time.
8. Be radically transparent and open about each others’ shortcomings and mistakes.
9. Courtesy and decorum are not valid reasons to avoid radical honesty.
10. Nothing matters more than seeking the truth.
11. Autonomy and self-sufficiency are key to operational efficiency, but trust must be earned.
12. Prefer explicit over implicit; specific over vague.
13. We should benchmark our progress against ourselves; not against other people.
14. Prefer communicating at higher level abstractions and trust teammates to figure details out.
15. Trust, but verify. That’s why audits and spot checks are necessary.
16. The ability to share knowledge is one of the greatest gifts from technology, let's do more of it.
17. The “why” is as important as the “how” - both should be treated with an equal level of rigour.
18. Strive to be non-ambiguous with the use of language.
19. We are accountable not only to external customers, but also internal customers.
20. Be proactive, not reactive.
21. Prefer writing before speaking, and if there’s a choice, over.
22. Teamwork above solo strength.
23. Be obsessed with quality - test and double check rigorously.
24. Cutting corners just delays the problem and is usually not worth it.
25. Do not underestimate the impact and importance of presentation.
26. Pointing out each others’ mistakes is nothing personal. The objectives of doing so include:
    1. Raising awareness of the problem (or dispel one’s misunderstanding);
    2. Getting alignment across stakeholders;
    3. Proposing a solution;
    4. Determining how to rectify and execute.
27. Reserve facetime as a last resort for one of the following occasions
    1. We are working on a project where details need to be communicated;
    2. Sharing something important that’s difficult to do so through writing;
    3. There’s a dependency you own that’s blocking the progress of a project;
    4. When one is in desperate need of help after exhausting all means of research;
    5. One needs help under a time crunch.
28. Things to avoid at work
    1. Ghosting others who have a hard dependency on our work or what we own;
    2. Writing that’s unclear, unambiguous, not proof read for accuracy;
    3. Repeated actions that reflect “that’s not my job”;
    4. Code review comments focused on style, syntax preferences;
    5. Lack of empathy.
29. Emails, texting, speaking have different rules regarding etiquette.
30. Adding an emoji after a message (1) lightens the mood; (2) doubles as a read receipt.
31. Ensure the use of terminology and jargon is consistent among the group.
32. Results loop: Goal > Reason > Viability > Plan > Execute > Clean up > Reflection
33. Regular weekly reflections can help make sense of chaos and deal with overwhelm.
34. When everything went perfectly but we still failed, to understand why, reflect upon
    1. Environment (uncontrollable factors)
    2. Timing (great execution, bad timing)
    3. People (lack of excitement, unified spirit to push through)
    4. Fundamentals (mismatch in ability and goals)
    5. Leverage (not possible without catalysts and help)
    6. Inception (whole project wasn't necessary)
    7. Aptitude (mismatch in talent with challenges)
    8. Unknowns (gaps in understanding of world tied to project)
    9. Uninformed (parts of whole landscape missing from our radar)
35. Balance between doing our due diligence and analysis paralysis.
36. Pushing through isn't the only solution. Circumvention can be useful too.
37. Technical solutions aren't necessarily the best path forward.
38. Defining work not done is often as important as work to do.
39. The best way to multitask is to not - complete a workstream before switching to the next.
40. When reaching out, prefer talking to teammates one-on-one instead of in a group.
41. Be curious and keep learning. Learn what? Anything that allows you to create.
42. If you could choose between learning and doing
    1. If there are time constraints, that choice is gone - choose doing.
    2. Otherwise, learn so we can execute better and take more things into consideration.
    3. Best yet is if we can learn by doing something new.
43. Approach problems systematically.
    1. Always prefer a fix that minimizes or reduces manual effort and scales.
    2. If the timing isn’t right, at least create a complete solution and document it to action later.
44. Root cause problems. Instead of top down, try bottom up. Don’t settle until we reach a real understanding of the problem.
45. Three things to avoid talking about
    1. Religion
    2. Politics
    3. Talking about people behind their backs
46. Before handing over something, three questions to ask
    1. If we ourselves consume this work artifact one year from now, can we understand it?
    2. Did we gather all the facts and exhaust all options? (Is it comprehensive?)
    3. Is it in a state that someone doesn't have to tidy up before consuming this work artifact?

1. Avoid adopting tools we don’t understand. If we’d like to adopt them, understand them.
2. Resist giving in to the Shiny Object Syndrome - novelty does not justify adoption.
3. Spend the most time in the bottom three rungs of the code review pyramid
   1. Mental Alignment
   2. Correct Solution
   3. Design Discussion
4. The definition of good code (the most important first)
   1. It’s correct
   2. It’s secure
   3. It’s readable
   4. It’s extensible
5. Beware of red herrings when doing data analysis.
6. DRY is not always the best policy - the pros and cons of duplication must be weighed case-by-case.
7. Code Reviews are often more important than writing code.
8. Review code as if we were doing the task ourselves.
9. Inaccurate documentation is worse than no documentation.
10. If we can’t describe the problem and solution(s) clearly in words, desist from writing code.
11. Tidy up now, because it’s now or never with software.
12. A dedicated operational squad may be necessary to alleviate systemic issues.
13. Do not forget the value of teammates in these roles
    1. Technical Writers
    2. QA
    3. Scrum Masters
    4. Product Owners
    5. Servant Leaders
14. Take our time choosing names.
15. Don’t trust inputs arriving from beyond the bounds of a system - always validate.
16. Technical decisions should be reviewed against these architectural characteristics
    1. Availability (how long the system will need to be available)
    2. Continuity (disaster recovery capability)
    3. Performance (e.g. stress testing, peak analysis, frequency of functions used, capacity, response times)
    4. Recoverability (e.g. in case of disaster - how quickly do systems need to recover, backup strategy, duplicated hardware, etc.)
    5. Reliability/safety (fail-safe / mission criticality, financial cost of systems failing, etc.)
    6. Robustness (handle error and boundary conditions if internet connection goes down, power outage, hardware failure, etc.)
    7. Scalability (how the system handles requests as users / requests increases)
    8. Configurability (how easily software's configuration is changeable)
    9. Extensibility (plug and play architecture)
    10. Installability (ease of installation on platforms)
    11. Leverage-ability/reuse (reuse common components across multiple products/platforms)
    12. Localization (support for multiple languages, locales, reports, currency, units of measure)
    13. Maintainability (ease of enhancing the system, adding changes, making edits, etc.)
    14. Portability (concerns vis-à-vis running on multiple platforms)
    15. Supportability (technical support, logging, traceability of stack, ease of debugging errors, etc.)
    16. Upgradeability (how easy it is to upgrade the application / tech we use)
    17. Accessibility (tailoring UX for customers with disabilities like SDH, colour blindness etc.)
    18. Archivability (what data needs to be archived or deleted after a period of time according to the data retention policy, data classification)
    19. Authentication (security requirements to check authenticity of user identity)
    20. Authorization (principle of least privilege in manage our resources, least access by external customers)
    21. Legal (legislative constraints, e.g. GDPR, data protection laws, regulations regarding deployment or how the application needs to be built)
    22. Privacy (encrypting transactions from even internal administrators and employees)
    23. Security (encryption at rest, in transit, remote user access, etc.)
    24. Usability (UX studies with focus groups, ease of use of our application)
17. The Gang of Four's Design Patterns can be applied outside of object-oriented contexts.
18. Configuration and infrastructure should be treated with the same rigour as code.
19. Third party libraries come at the cost of bundle size and encapsulated complexity. Avoid unless necessary.
20. “Merging code” is not “done”. Consider the remaining work that still remains
    1. Ensure tech debt is reasonably addressed to prevent tech debt accumulating
    2. QA check specific to feature / bug fix
    3. Regression checks if change sufficiently large
    4. Writing integration tests / Visual regression tests
    5. Deploying changes to Prod
    6. Feature gating and dial up / release process
    7. Updating relevant documentation
    8. Updating runbooks
    9. Updating ops metrics / business metrics dashboards
    10. Monitoring ops metrics / business metrics for anomalies after dial up
    11. Experiment analysis and dial up conclusion
21. Resist the temptation to code until requirements are 100% clear.
    1. This doesn't block work on the parts are clear as long as they are sufficiently isolated from the unclear.
    2. Implement in a way that allows for flexibility to change. Abstractions, composition, SOLID, interfaces can help.
    3. Execute in a way that allows to defer important architectural decisions until we have more information.
22. We share the responsibility for work artifacts, designs, code changes, contracts we approve.
23. Minimize unnecessary dependencies - they are hard to manage and even harder to remove.
24. Organization engineering has a huge impact on the architecture - always keep Conway's Law in mind.
25. Enforcing the Principle of Least Privilege internally is a mechanism to reduce manual errors, not a sign of distrust.

1. Add at least 30% padding to time estimates.
2. If estimates involve configuration, accept it's impossible to estimate.
3. Backlogs need to be groomed daily to prioritize, add details, dedupe and close out tasks.
4. A Scrum team requires a Product Owner and Scrum Master, no exceptions.
5. Writing the AC, implementation and QA should be done separately to avoid bias.
6. Start with relative points and work backwards to figure out time-points mapping.
7. Velocity varies based on team members, nature of tasks, holidays, KTLO, etc.
8. Task updates should be shared daily to uncover blockers quickly.
9. Four documents form the core of the Scrum practice - omit at our own risk
   1. Definition of Ready
   2. Definition of Done
   3. Team Norms
   4. RAID log
10. We should add tasks for 80% of a cadence; leave room to deal with “other stuff”.
11. Resist the temptation to work on items outside of what’s planned (unless they’re done).
12. Desk checks are essential to make the Dev-QA cycle go faster.
13. Encourage cross pollination by allowing members to self-assign tasks.
14. Avoid project based execution, because it festers the growth of silos.
15. If a task can’t be finished within a cadence, break it down so that it can.
16. Be inclusive in the meeting invite list, but encourage teammates to reject irrelevant ones.
17. Recurring issues should be pointed out even at the expense of repeating ad nauseam.
18. A good moderator plays a key role in helping to ward off ignoratio elenchi.
19. Always assign a scribe in a meeting to take notes so absentees can review them.
20. Apply triple the vigilance when a project starts - decisions made then are often hard to reverse.
21. Prefer rules-based governance over deferring to individuals’ standards.
22. Split our time 80:20 between short term and long term initiatives.
23. Organization and management need design reviews, just like software systems.
24. Flat hierarchies promote collaboration; nested hierarchies introduce barriers.
25. Reject all meetings
    1. Without a prepared agenda;
    2. Without at least 2 business days to review said agenda in advance;
    3. That invitees cannot meaningfully add value to;
    4. That are too long or too short.
26. Balance between the short, medium and long term. Examples include
    1. Short: Sprint planning, execution, scope management, technical work
    2. Medium: Architecture, team process, retros, fixing ops inefficiencies, process issues
    3. Long: Extra curricular learning, codification of principles, axioms, exploring disciplines
27. There should be at least two Subject Matter Experts per knowledge domain.
28. Processes and mechanisms over manual intervention.
29. Never underestimate the importance of an organization scheme.
30. Organization is a prerequisite to any process reforms.
31. Establish checks and balances to govern how we work.
32. Prefer a T-shaped over I-shaped operational style and avoid silos.
33. Schedule regular reviews and after incidents to reflect and revise our SOPs.
34. Reserve at least 10% of headcount perennially for OE/EE initiatives. (Oncall doesn't count.)
35. Defining an "eye for quality" - Calibration to match the right configuration that appeals to most.
36. Organization is the basis for KTLO and improved efficiency.
    1. All businesses are based on organization “let’s make it easier and faster for others to access these resources".
37. Hire the right people. Define “the right people”? Hunger and empathy.

1. What leaders should strive to do
   1. Elucidate and embellish upon a vision that inspires.
   2. Instate clarity (remove uncertainty) when ambiguity is present.
   3. Commit to delivering value by solving real problems.
   4. Force multiply and empowering the team to grow.
   5. Define and revise operating philosophy and values regularly.
   6. Create an environment that allows the team to flourish.
   7. Encourage a culture of experimentation and risk taking.
   8. Apply core principles consistently to adjudicate problems.
   9. Build and maintain harmony with internal and external stakeholders.
   10. Promote diversity and inclusion (not just ethnically, but different personalities).
   11. Establish mechanisms to maintain a prioritized list of work.
   12. Invest in minimizing drudgery at work.
   13. Promote a culture of growth and continual learning, actively invest in individual growth.
   14. Be proactive, not reactive; stay ahead, not behind.
2. Laissez-faire is not the same thing as extricating oneself from the day-to-day as a leader.
3. “Years of experience” or “seniority” is not an accurate indicator of ability.
4. Leaders should ensure a balance between individual aspirations and business goals.
5. Ideas can come from anywhere, but require leadership support to manifest into reality.
6. Use metrics to track key performance indicators with the team (e.g. SLAs, happiness).
7. “Let me know if I can help” is generally not enough, proactive outreach is necessary.
8. Personality tests are helpful to help match opportunities with aptitudes.
   1. High Five Test
   2. 16 personalities
9. Feedback should be meaningful, specific and lead to SMART goals to rectify.
10. In case of ambiguity, provide a chance for interview candidates to produce proof of ability.
11. Err on the side of rejection if data collected during an interview is inconclusive. (Or gather more data.)
12. Lead with empathy and aspire to become servant leaders.
13. We should pay extra attention to continually raise the hiring bar.
14. An interviewing template / rubric can help with a consistent understanding of “The Bar”.
15. Be nice to each other, it's usually worth it.
16. Don’t wait for people to come to us with problems, approach our teams.
17. The team should not depend on a leader to function, but they should be better off in the presence of that leader.
18. Carry out regular retrospectives on different aspects of operations to review each pillar separately, then holistically as an entity.
19. Leaders should have unique personality traits, skills or charm that can win over people’s hearts.
20. Stay connected to the technical details, but don’t lose sight of the big picture

1. “Premature organization is the root of all evil.” - Donald Knuth
2. “Il semble que la perfection soit atteinte non quand il n'y a plus rien à ajouter, mais quand il n'y a plus rien à retrancher.” - Antoine de Saint-Exupéry
3. “I think it's far more important to write well than most people realize. Writing doesn't just communicate ideas; it generates them. If you're bad at writing and don't like to do it, you'll miss out on most of the ideas writing would have generated.” - Paul Graham

1. Mental Models
2. Fundamentals of Software Architecture: An Engineering Approach (Mark Richards, Neal Ford)
3. Code review pyramid
4. The definition of good code
5. Fallacies
6. Graham’s hierarchy
7. Maslow’s hierarchy
8. Bloom’s taxonomy
9. Principles (Ray Dalio)
10. The Zen of Python
11. The Gang of Four's Design Patterns
12. High Five Test
13. 16 personalities

1. Code Review Guidlines from Michael Lynch (Part 1, Part 2, Code author tips)
2. Google's Code Review Guidelines (Speed, Standards, Cliffnotes)
3. Code Reviews at Google, Dr. McKayla
4. Software estimations are hard