Egoless engineering
I often ask questions I already know the answer to. I'll start discussions for things I already have a pretty good idea of the solution for. I trust others with tasks that I'm sure I could do a great job on.
At the start of my career, my ego was absolutely my worst quality. I had to be right, every time. I had to “win” every disagreement. I suspect it was big-fish-small-pond syndrome. Through learning to disagree with my peers and friends in healthy ways, I've mostly ditched that. No longer do I care about being right. I instead care that things are done in a way that improves the organisation, the code, and employee happiness1.
My approach to staff engineering borrows heavily from facilitation, and open source communities.
Facilitators guide groups. They might be experts in the field, they might know nothing about the field that the first paragraph on Wikipedia couldn't tell you. Whenever there's a group of people with diverse experiences and interests, there will be disagreements. Different ideas on how to solve problems, or different levels of concern for problems. Facilitators aim to take this collective knowledge and experience and turn them into something productive.
As an engineer facilitator, most of the discussions end up being quite technical. Sometimes there’s disagreements on what libraries or practices the teams align on, sometimes there’s disagreements on how things should be implemented and who is responsible.
Since I've spent a lot of time coding, I have opinions on these things. But my role is not to lay down the law of my opinion. It's to ask, to question, and make sure the discussion goes somewhere useful. Oftentimes I will start a discussion where the outcome isn't what I would personally want. But it should be what the organisation needs.
That doesn't mean I sit there silently, though. If I see a problem, then I can raise it if no one else does. I do get hands-on, if something has been burning without anyone stepping up. I am not getting hands-on so that I claim the glory, but simply because I want problems to be fixed.
Like most roles I have had, the goal is to make myself unnecessary for as many things as possible. I am one person, therefore I can't be in every discussion, every pull request, or every meeting. Nor do I want to be. But I can try to establish healthy ways of working, which then propagate onwards.
As much as I am an advocate for the company, I'm also an advocate for the individuals. Personal well-being should take priority over work, every time, with no exception2. If I spot a peer is overworking, I gently nudge them towards a healthier balance.
I take joy from things being done well, by people who enjoy what they're doing. If I can lift people up so that they can do both, I have succeeded in my role as “Tech Enabler”3. A funny title, that. Google couldn't suggest a better one, but “enabler” has overlap with “facilitator”. That's the core of what I do: enable through facilitation, support, and guidance.
As a stretch goal, I'd hope that society improves too.
Overworking founder? Completed it mate. Overworking employee? Completed it mate.
If you've read this blog before and thought “that's a strange name”, you're right. It's meant to be self depreciating.