A shared vision
One of the most challenging aspects of leading software engineers is achieving a consensus. This is true everywhere I've had experience, and with any scale and any cohort and on any subject.
A consensus is important for practical things such as team harmony, code consistency and quality of output but it is especially important for ephemeral topics such as "strategy" or "best practices."
The trouble is that much of the "wisdom" and "knowledge" held, internalised and enshrined by engineers is accumulated not by a teachable linear path but by an inefficient process of osmosis from the industry zeitgeist making it quite impossible to replicate. Being impossible to replicate makes it difficult to teach, as it robs you of some of the resources you'd use to convert and convince others.
This experience you have - the lessons learnt or the things that have read which 'resonated' with you during your time as software engineer - are the treasures amidst the strata of your career, and the things that further influence your thought processes and decision making. They are the things which make you a leader, instead of just a good coder, and it's those things that we want to extract, distil, critically evaluate and then disseminate.
There's a problem with knowledge transfer that can be alleviated by better identifying what to share, but transferring the wisdom - the opinions and interpretations of an individual - is another challenge of its own.
Codified Wisdom
Enter then, our Engineering Guidelines. These are the output of a concerted effort to codify and document the wisdom of individuals, identify common themes, name them and prioritise them in accordance with our business strategy.
The goal of our Engineering Guidelines is to persist and achieve consistency over a longer time period, and scale better and reach further than any individual could on their own.
The source of truth for our guidelines is their written form - a collection of documents in our Wiki - but we can remix and reformat the content as appropriate for different scenarios, whether that be a workshop, presentation or release checklist.
The most important part of these guidelines is that they're documented, explained and evidenced. This means that they can be tracked, challenged, evolved and extended as requirements, technologies and trends also evolve over the course of time.
Top comments (0)