> Basically, my job requires using a lot of tools and technology and processes created by other people, but none of those tools are easy to use or well documented.
When I first moved into management roles I didn’t fully understand how much of my job would be simply saying “no” to a constant stream of engineers wanting to write or rewrite custom tools, libraries, frameworks and platforms when otherwise sufficiently good alternatives already existed. Not all engineers, but once you get into a big enough organization there are a lot of engineers who want to do meta-work and rework things instead of actually shipping things.
The worst offender I worked for had meta-tools on top of everything. You couldn’t use GitHub, Slack, or even our cloud platform without first learning how to navigate all of the custom tools and bots that had been put together to gate access to everything and make it work. And like you said, it was poorly documented. It turned into little fiefdoms where you had to know who to talk to if you wanted to get past the systems to get things done.
This can all be avoided with good management at an organizational level, but of course some managers want to get in on the situation because it puts them in a perceived stronger position in the company if their team is at the center of everything.
> You couldn’t use GitHub, Slack, or even our cloud platform without first learning how to navigate all of the custom tools and bots that had been put together to gate access to everything and make it work.
First time in a really big org and I can see this as well. The worst part is trying to tie someone down to explain how to use their custom tool or bot or even entire systems. How do I use that custom BI tool that you setup ... oh no-one wants to even send me an email reply when I ask a simple question about these things.
The way most stuff gets done in these orgs is various maverick people who find some way to work around all this crap. The problem is you have to have political clout to do that most employees don't have that.
I think these "meta-tool" are initially well intentioned but as you say they become empire building tools.
Worst still is that the teams that build them often leave or are disbanded. Then no one is responsible and no one wants to touch them and they sit in this weird limbo state.
When I first moved into management roles I didn’t fully understand how much of my job would be simply saying “no” to a constant stream of engineers wanting to write or rewrite custom tools, libraries, frameworks and platforms when otherwise sufficiently good alternatives already existed. Not all engineers, but once you get into a big enough organization there are a lot of engineers who want to do meta-work and rework things instead of actually shipping things.
The worst offender I worked for had meta-tools on top of everything. You couldn’t use GitHub, Slack, or even our cloud platform without first learning how to navigate all of the custom tools and bots that had been put together to gate access to everything and make it work. And like you said, it was poorly documented. It turned into little fiefdoms where you had to know who to talk to if you wanted to get past the systems to get things done.
This can all be avoided with good management at an organizational level, but of course some managers want to get in on the situation because it puts them in a perceived stronger position in the company if their team is at the center of everything.