Consensus as Staff Engineer
Hey!
Welcome back to another week of musings. I hope you had a good rest during this weekend.
Was this forwarded to you? You can subscribe here!
Things I discovered in the past week
- I've been looking for good material on "wide events," as some people in my current organization have been asking why logs are not good enough. Regardless of my problem, I found this great article that provides a good primer.
- I like mechanical keyboards and seeing other people's offices, so I enjoyed this video by Taeha Types. It shows his current office setup (even though it felt like half ads).
As a staff engineer for a medium-sized organization at my current company, I get pulled into multiple meetings where teams debate ways to build things, prioritization, tech debt, etc.
I also notice that in some cases, teams tend to choose the option that will allow them the least dependence on other teams, and rightfully so. It's hard not deliver something because someone else's backlog is prioritized differently. But it has happened that these choices come back to us in a mid/long-term future where we need to re-visit a decision, rewrite a piece of software, etc. We need to balance long-term vision with short-term choices and deliverables to keep our promises but not stray so far away that we end up with a big ball of mud.
Keep team success top of mind!
As individual contributors (ICs), we're often in a different position from management regarding closeness to the teams executing the work.
This fact makes us closer to advocating for tech debt, team practices, and technologies. The company I work for is relatively old, so we had a cloud journey; at the time, the choice was made to keep managing our database clusters; over time, the overhead of managing the less critical databases was leaving our DBAs without much time for the most critical ones. We had to choose to move some of the databases to cloud-managed services, spend a few months sitting down with teams, find a good starting point, explain why it mattered to us, what benefits it would bring us, etc. Over time, that decision paid off, as we freed more time from the DBAs to focus on other tasks.
Difference from management
I'm not talking about decision by consensus (which is hard to do well, if at all possible). I'm more talking about rallying people around what we should care about as an organization or team.
This differs from management because they generally drive consensus around the product work or projects that would make the company more successful. As staff engineers, we need to drive consensus on things like the technology stack, practices we should adopt, tech debt, rewrites, etc. This might imply talking with teams beyond your immediate scope.
Write to scale
Over time, you'll notice that to drive consensus, you have to repeat yourself repeatedly with other ICs and managers, directors, and leadership.
You always need to adjust the message, as leadership cares about different things than teams on the ground. But in general, one good way to scale your message is to write it down, either in a "blog post" or in things like decisions records or presentations. This helps by sharing the piece or referring people to this past decision in new conversations. In general, repetition is key! So keep that in mind whenever you embark in a new journey.
Your turn!
How you drive consensus with your current teammates? Have you had to drive consensus with leadership as well? How did that go? Let me know by replying to this email!
Happy coding!
website | twitter | github | linkedin | mastodon | among others