Hidden Work
Hey!
Welcome back to another week of musings.
Was this forwarded to you? [You can subscribe here](https://buttondown.com/osukaa)!
Things I enjoyed in the past week
There has been a lot of news around the "Shai-Hulud" supply chain attack on NPM.
Related, Obsidian's Less is safer: how Obsidian reduces the risk of supply chain attacks.
Are You Accumulating Career Debt? Interesting thought of feeling like falling behind, even while being good at your job, and getting paid well.
During a recent project, I became aware that the platform was not covering all the customer use cases, and people had built parallel tooling to maintain a stable platform for their work.
In recent years, due to layoffs and team re-organization the platform became understaffed, which meant even less people to help make a better platform for all. What this also meant, is that when new teams come and try to change something they see under performing it will break someone's workflow.
Acknowledge your customer needs
I started spelunking, and digging through history and available internal wiki pages, once people leave, sometimes the platform might archive their content, which can make research harder.
However, at some point, the team changed focus, and this led to a halt in all new features, prompting people to start building parallel tooling. Another case was that the platform was meant to ratify a "golden path", which didn't acknowledge the reality of the time. This meant that most applications or teams were not ready, so instead, they decided to build this alternate tooling to keep being productive.
Production Pressure
One of the main reasons that this tooling exists, as opposed to being features captured in the platform, is that people want to be unblocked to deliver their work, which is what they're tracked against.
That means that there's little to no incentive to create tickets and wait for them to be delivered on the platform. It also means that the teams are "siloed" in that respect; they might not be aware of other teams having the same issues or even if they have any issues at all.
These are the gaps where staff engineers are expected to provide a more global view, outside of pure execution of the teams.
Provide a path to productivity
When creating a new platform, you have to start from current requirements and centralize them to build forward, or provide the idealized workflow but allow teams ways to customize for their current needs and keep pushing them towards the ideal.
During that discovery you meet in the middle, and some things are better managed by teams in their custom tools, and some might be better to make more generalized in the platform.
Cost of Maintenance
If you want to clear something like this, parallel tooling, you need to make leadership aware of its existence, as well as how much time is being invested in maintaining it.
Having leadership acknowledge this and give the time and investment to remove it is a good indication of a more efficient process. Once we have the plan and backing, we can move forward towards removing it.
Otherwise, both the platform and each team will be investing time in maintaining their workflows. While platform releases are being made, they may break the workflow of teams, and they need to keep their tooling working.
Change is Hard
As with any with change, people would be hard to convince to remove the tool that makes them productive, or keeps them delivering their tickets.
If you've read books like Switch*, you'll know that establishing a mental framework is crucial for teams to transition away from their current tooling and adopt new ways of working. So a lot of patience and working with teams will go a long way towards a more productive state.
Your turn!
Have you ever had to deal with trying to adopt a tool or platform only to notice that people have built their own parallel tooling to stay productive? Let me know your thoughts by replying to this email!
Happy coding!
website | twitter | github | linkedin | mastodon | among others