I've tried a lot of roles, professionally, but I seem to excel at and find myself gravitating toward "Founding Engineer" roles. I'm that first hire or technical cofounder hardcore generalist with a high tolerance for risk and chaos, who can wrangle just enough order from that chaos to go from zero to one and be set up for much more.

In The 5 stages of CTO & the CTO Career Chasm, Marcelo Calbucci references the five stages of CTO from Chris Yeh and Reid Hoffman’s book Blitzscaling. I believe I have strong mastery of the "Family CTO" role, and also do well as the "Tribe CTO". I'm not currently in a CTO role, but my current role is an excellent opportunity to do some very intentional growth mindset focus work, to develop those key specific knowledge and skills that I have identified that will help me be a great Village CTO.

These are some engineering principles and values that are important to me, personally. My hope is to find these in -- or, sometimes, introduce these into -- the engineering and engineering leadership communities in which I participate. Also, important disclaimer: These are my personal values, and at are not necessarily those of my employer. I don't speak for my employer, and aligning one's own principles and values with the principles and values of any given employer is arguably always going to be a bit of a work in progress, in any case.

Probably more importantly, these principles themselves are a work in progress. I will continue to refine and adapt these based on what I learn, in perpetuity. I’m always curious and willing to learn, and for that same reason I’m more than willing to publicly publish and share these, and I ask for your feedback. If you see something here I can improve, or something I'm missing - please, by all means, reach out!

Finally, I won't claim any of these are really truly original - I picked ALL of them up, at least in concept, from listening to and observing folks more capable than myself, and it's certainly plausible there are one or more of these that I've indeed inadvertently plagerized. Any such plagerization is purely unintentional, and I am more than happy to fix that attribution whenever I can, as well as dig deeper. If you recognize something here but don't see a reference to the original - please let me know.

A principle is a framework for exercising judgement, and provides useful constraint while still supporting a high degree of empowerment. In contrast, a rule is typically an explicit dogmatic constraint that removes the need for judgment, and is often disempowering. Sometimes the only difference is subtle framing, or voice. For example, this value principle COULD have been stated as a rule, in the active voice: “Always use principles instead of rules”. That, however, wouldn’t allow for the reality that rules DO exist, and are often clearer or more efficient than the underlying principle. Rules exist, but principles are generally better.

In communication, and especially in code, despite some overlap, the nuanced differences between simple and clever are critical. Outwardly, they often appear the same, but they can also frequently work against each other, and the difference is often in the eye of the beholder. Opt for simple.

One powerful effect of this principle is to help manage WIP (Work In Progress), where it applies to the state of concrete deliverables, like features and stories. WIP is not inherently 'bad', but choosing to be intentional by seeking ways to minimize WIP in aggregate brings focus and clarity. The uncertainty embodied by a Work In Progress "rolls up", and inversely, the certainty represented by "done" also rolls up -- it's much easier to visualize the overall state of a product or a service when the constituent components are either done or not, than when they are "in progress".

You can use any new tools, techniques, and technology that you want. As long as you have a plan to bring the rest of the team along with you.

The People that create the systems are uniquely prepared to understand how they operate. And vice-versa.

"What came before" got us where we are today. You don’t have to like it and you MOST DEFINITELY don’t have to keep it, but if it exists before this very moment, it's legacy, and by definition it captures past thinking. It's really easy to see the terrible parts, because those stand out and still cause pain, and many great parts have almost certainly slipped seamlessly and silently from memory into obscurity, the moment the pain that they resolved went away. By the same token, understanding that what you build now is going to live for a very long time gives you an opportunity to demonstrate some positive intent to your future self, coworkers, and customers.

In lieu of either begging for forgiveness or asking for permission, state what you intend to do to potentially interested parties, solicit for and listen to any input, and then take the action or make your decision. The opportunity to react will be greatly appreciated by those with a genuine vested interest, but without the downside and friction of deferring your decisions to others’ judgment or authority.

Building in public builds trust. Closely related to signaling intent, building in public provides an opportunity for a broad range of stakeholders and other interested parties to provide feedback. While you don’t have to incorporate or even respond to the feedback, listening and making a good-faith effort to understand will almost always have an outsized payoff - we all have something to learn, whether that’s from a customer, a co-worker, someone elsewhere in the organization, or even a competitor. This principle applies broadly beyond software, and includes documentation, culture, and even personal and professional development.

Often the very best time to address deficiencies is the moment you discover them. This applies well beyond code, and also includes docs, access permissions, configuration, and communication. The best way to “Address” an error is usually to take the pause to fix it right then, but where that’s not practical, it’s still crucial to immediately share the discovery, and create a plan to address it.

Stated as a much more familiar rule: Don’t Fight the Framework. The nuance here is that frameworks aren’t static, and our objectives are important. Sometimes - if we have cause to believe the framework will, eventually, bend to our will, it MAY be worth it to “fight” it, where the costs are well understood and clearly worth it, AND the expected outcome of the fight is validated learning that informs our future success. The best example of something like this is Open Banking, as a “fledgling juggernaut” - currently the banking industry’s “frameworks” don’t align cleanly with Open Banking, and won’t for a while, but are clearly crucial to the future. On the other hand, if it looks more like we’re just trying to shave corners off of a square peg so that we can fit it into a round hole: Stop. Don’t fight that framework.

Move deliberately, without hesistation. There's a huge difference between a well-oiled machine with a strong bias for action versus reckless thrashing with no regard for the future. To an observer, that difference is usually blatently obvious in both real-time AND in outcomes, but it's much harder to see when you're inside the machine. It's OK - crucial even - to take a brief pause to think, signal intent, listen to others, plan, and take deliberate action, even when you need to do so urgently. Embrace Crawl, Walk, Run, and doing things the hard way to learn how to do them smoothly and quickly. While crawling and walking, ruthlessly seek opportunites for simplification and automation. At the same time, don't overthink it, either - even in the Crawl, Walk, Run model, the first step to is to decide to do SOMETHING, and then start doing it. Pro tip: If you ever want to physically feel the difference between moving with a sense of purpose and recklessly going as fast as you can - try each approach while shaving.

Where outcomes are not critical or are well-understood, it’s very efficient to rely on process, as well as rote, habit, and muscle memory. Where outcomes ARE critical or out-of-process - you can get most of the efficiency benefit without the risk, just by bringing the action under consideration to the forefront of your conscious mind by doing a buddy-check, saying it out loud, writing it down, or at least pausing, thinking, and taking a breath. Do that, and then take the action, deliberately and mindfully with your full attention. A typical example is live-editing a production configuration, or responding to a hostile emails. A handy corollary to this concept is to write a checklist for any such action with more than one or two steps, and then the ‘deliberate action’ is partially pre-empted by the creation of the checklist itself, as well as efficiently executed by applying any additional ‘deliberate action checks’ to each step in a cookie-cutter fashion.

These aren't "principles", per se, at least not yet, but worth thinking about how they fit into the principles above

Detail TBD - Still working on this one.

This is almost certainly a big part of "Slow is Smooth and Smooth is Fast", but it's also bigger than that and deserves some detail. Somewhere. Problably not in this README.

Similar in nature to "Crawl, Walk, Run" this one is possibly a PART of "Slow is Smooth and Smooth is Fast", but probably not as closely related. I get a lot of mileage out of it as a learning technique, so I should probably write about it and link to it from here.

• Failing to plan is planning to fail - Alan Lakein
• A goal without a plan is just a wish - Antoine de Saint-Exupéry
• Plans are useless, but planning is essential - Dwight D. Eisenhower
• Everybody has a plan 'till they get punched in the mouth - Mike Tyson
• No plan survives first contact with the enemy - Helmuth von Moltke the Elder
• Counterpoint? Or related but orthognal concept?: A good plan violently executed now is better than a perfect plan executed next week.

This saying is really the bare minimum, or a prerequisite of "Clean As You Go" - where "Clean As You Go" would be applied to gradually reduce tech debt, "Don't Put it Down, Put it Away" is intended to avoid certain kinds of tech debt and other waste in the first place - when you're done with something (even if it's imperfect), don't expect to pick it up again in the near term.

Essentially the same idea as "Don't Put it Down, Put it Away" - and the trick in both cases is not to let perfectionism and scope creep get in the way of declaring victory, finishing, and putting it away.

Note: Does this roll up into "Build in Public"? The most relevant work product artifact is working code in production. Everything else is overhead. Some overhead in the form of other deliverables and written artifacts may be necessary for principle, legal, or other reasons, and may indeed be necessary to GET working code into production, but if there's no eventual working code in production: those turn to waste. By demoing frequently and broadly, and by eating our down dogfood, we emphasize this intent to go to production, tighten feedback loops, and reduce wasted overhead.

This is the wrong document for these, and I'll move them when I find a better place. Clearly these are also a work in progress.

Never miss an opporunity to celebrate a win. I don't know what the right ratio is between celebratory feedback and course-correcting feedback, but make it higher. Relatedly, celebrate in public, but keep corrective feedback and discussions private. Use judgement to decide public or private setting for puzzling or neutral feedback and related discussions. But PUBLICLY CELEBRATE ALL THE WINS.