Shaping Reality
Hey!
Welcome back to another week of musings.
I hope you had a restorative weekend. This week, we had the Daylight Savings Time change in California.
Was this forwarded to you? You can subscribe here!
Things I discovered in the past week
- I found Obsidian's CEO, Steph Ango's blog post on how he uses Obisidian insightful, as I'm going back to Obsidian after using Reflect for less than a year.
- I recently was researching into zero-trust systems, and came across this concept of SPIFFE. It's an interesting idea for identity management, and I still need to read more about it.
Over the years, two thoughts have stayed in the back of my mind and have shaped how I approach my work.
One is the idea of radiating intent, as opposed to the typical advice of "It’s better to beg forgiveness than ask permission." In many cases, radiating intent helps you get help from others, as you're making them aware of what you're looking to work on or fix.
The other quote is "...Life can be much broader, once you discover one simple fact, and that is that everything around you that you call life was made up by people that were no smarter than you. And you can change it, you can influence it, you can build your own things that other people can use. Once you learn that, you’ll never be the same again." by Steve Jobs. While the quote is much broader, it applies to day-to-day work. We come across many instances where solutions are low-hanging fruit or various people want to get it fixed, but no coordination has happened.
Talk to each other
As a staff engineer, I meet with several people throughout a given week but also talk with them through Slack or email, which gives me a more global view of the teams and their work.
I often encounter two or more teams trying to solve the same core problem but with solutions local to their context. In those cases, my role is to make people talk to each other and to talk with leadership. So, several teams might not be incentivized to solve the same problem because that might mean a critical project will be blocked from a solution.
In this case, I meet with the teams and devise a "why" for them to work together or why they need to wait for one of the teams to unblock them, especially if I believe that long-term would be a better aspect.
The incentives are there for other teams, and there may be enough breathing room to wait. All that needed to happen was for the teams to talk to each other. Over time, I've learned how to gauge the difference.
Show, don't tell
I've also found that sometimes, it's essential to show a proof-of-concept (POC) instead of just talking or repeating a message.
I've realized that sometimes it's hard to visualize an idea, and the best approach is to show a working example. These might not always work. Your workplace might be more bureaucratic and have many checks and balances to put things into a working environment for testing, etc.
Important but not urgent
In other cases where radiating intent is essential, when trying to fix all necessary but not urgent projects. Your company might call them long-term architecture, or they might be sleeping in a backlog of some team or only in the mind of some lead engineer.
In these cases, I gather involved people and develop small enough tasks that can be merged with ongoing projects without slowing them down, or create a compelling reason that would allow me to allocate enough people and time to fix it. Sadly, in most cases, there are big reasons why it hasn't gotten out of backlog hell, but this is where we can change the version we're telling about it.
A thing about optics
In the past, I used to tell peers and managers that managing optics was a critical aspect of projects.
Over time, saying it was more like hiding things or deceiving. At the same time, I didn't use it with the intent that it might have come across as such. I now tell people that we should look for compelling whys or make a deliberate effort in small steps to change the team's reality slowly.
Your turn!
Have you considered how particular messages came across or whether a team was not addressing a concern because it was to make a concrete concept? Let me know your thoughts by replying to this email!
Happy coding!
website | twitter | github | linkedin | mastodon | among others