During my time at Seraphin and Canyon, I found that defining and communicating core principles strenghtened the firepower of our engineering team. Nothing surprising to that 😅. Still, I believe there are a few tips & tricks one can apply to get principles right and ensure they're not left to rot in the dust of a forgotten Notion page.

Principles are a commonly agreed list of prescriptions that will drive the behaviour and output of the team. They define what's acceptable and what not. They capture in a concise and explicit way the scale of values that is specific to the team, and the trade-offs that the team is hence making across values.

The word specific is important here. As engineers, we can rely on a huge body of best practices that are all principles in themselves. KISS, DRY, YAGNI...these are all powerful principles every engineer should have in mind regardless of their team, just because they are good professionals. What makes your team engineering principles valuable is how you choose to emphasise one or the other principle (you cannot have all of them, and you should ideally rank them).

Having these principles helps align the performance of the whole team and establish a common framework and vocabulary for judging the quality of behaviours and outputs.

In practice, besides the strategic alignment that it creates within the team (and with newcomers at onboarding), I have found that engineering principles are an efficient way to accelerate debates (thanks to first-principles thinking). They also provide a very welcome source of authority when one needs to be direct and efficient in making feedback / PR reviews. You can say "Can you check this part of your code against our YAGNI principle?". No need to spend time giving more specific feedback, since the mention of the principle already carries with it a whole context and background known by all. Name-dropping principles like that also helps reinforcing them along the way.

I've also found it valuable to focus principles on behaviours that can be improved, so they act as gentle guardrail to steer the team to a better version of itself.

I'm ashamed to say I use authoritative arguments sometimes

Principles must be formulated in a way that makes them easily absorbable by the team. Therefore:

A good rule of thumb for formulation: your whole list of principles should fit on a beautiful poster that you could hang on the walls of your office in a non-remote world.

It is tempting to use principles as a bucket to throw all guidelines at the team. However, here is what principles are likely not:

Once you've defined principles with your team, make sure that these are relentlessly exposed to everyone. I have found that the following worked well:

Basically, try to evangelize and reinforce principles at every occasion. You'll know you are in good shape when devs start dropping principles explicitly during peer programming sessions or discussions on specs or course of action.

With that being said, here's an example we used at Canyon. These principles are extremely focused on speed of delivery, because that is what mattered most to the entire company at the time. Also, they are intended at a senior team that has already absorbed a ton of content-related best practices before.

As you can see, these principles talk a lot about the process, but they don't exactly define it: we leave this to the playbooks. One could argue that explicitly naming kanban columns in these principles is already too detailed - I leave it up for debate. Note that here there is only one specific deep-dive which is on E2E visibility, that I have extracted in a dedicated blog post on the topic.

The engineering principles from Canyon, focused on delivery

All these reflections are based on my humble personal experience managing teams of developers in 0-to-1 and 1-to-Series A startups, plus a trove of readings and podcasts along the way. I think the principles outlined in this article (principles about principles - this is getting a bit meta 👾) still apply at scale, with a few tweaks:

I'm still relatively early in my engineering career, and looking forward to taking a step back in a few years after more experiences from the battlefield. Hopefully these tips with help you as much as they helped me. Thanks for reading and don't hesitate to reach out to me on Twitter. Also, if you are a CTO, EM or tech leader at large, do check out RM-RF, my Substack about crazy dev stories. Cheers!

Source: Thomasvds.com

Powered by NewsAPI.org