Without writing lines of code, how do you – as an Individual Contributor – become someone who influences the opinions of multiple cohorts of people at once?
How can you communicate with your exec sponsors, peers and junior engineers and ensure that your vision for the future is reaching your audiences, without spending your days trying to get face-to-face time with each of them?
Once you’ve had your “big idea that you need to convey to everyone” it’s daunting think of the time and effort that would be required from you to meet everyone face-to-face and then repeatedly (and reliably) convey this idea to the in order to reach a common understanding. It’s also high stakes – there’s lot riding on your personal brand and it’s likely to be intimidating and on both sides. Documentation is the way forward. Not technical documentation per se, but artefacts such as guidelines, best practices, decision trees and even full-on white papers.
As an individual your reach might be limited to when and where you are present, but as an author of content you’re able to change hearts and minds while you sleep and reach your audience with your message in a format that endures, at a time and pace that is convenient for them.
In this talk I’m reflecting on my 2 year journey as a Staff Engineer, and how a mix of documentation and working groups has been a surprisingly effective strategy for influencing the opinions of the individual engineers as well as the non-technical stakeholders. We’ll talk about the principles I use to determine ‘good’ and ‘useful’ documentation, some key guardrails to keep your content approachable, and the risks of falling to the dark side – using documentation as ‘proof of work’ or creating the dreaded wall of text.
