I had a recent conversation with an engineer. He initially asked for feedback on a presentation he’d done during our SDETs meeting. He presented the data loading tool he and his teammate had created, and he did a great job in that demo.
I do love a demo.
I asked him about next steps though, trying to lean into some higher level discussions I’d had with others about his team. This particular engineer is part of a two man crew dedicated to load testing system at the Credit Union, and has been for a long time.
The system is written using a load testing framework that the vendor is deprecating. His partner and him are considered ‘the experts’ at using that framework at our organization, and are entirely siloed from everyone else.
Even if they could convince management to cough up to add heads to the team, that added body wouldn’t add value until a year or more of working in the framework they’ve created.
I described his silo as an “Ivory Tower.”
He responded “It doesn’t feel like a tower… more like a dungeon”
Engineers design systems to do a job within the constraints provided.
Give engineers a tough technical requirement and add the expectation they’ll run it with no help, and you end up with a monster.
A monster that’s scary as hell to everyone else, but entices you to stick around with:
- Job security in a volatile field.
- A sense of expertise in a tech environment that’s constantly changing.
- A sense of ownership in what you’re doing and building.
The monster might say: “It’s not really a dungeon. It’s a gated community.”
I’d say it’s an abusive relationship.
I recall my time at {Redacted} here. One of the developers there has been working on the same product there for well over 8 years.
He’s good at his job. A highly capable developer. He likes the company, and likes the people there.
They can’t risk having him do anything new at all though. He’s stuck.
When I left, he was leading two teams (mostly by example), both working on the same product, doing the same thing he was doing 8 years ago.
Worst still, the product is largely a commodity nowadays.
There are major platforms written here that will do what his product does, and do it faster, and with an actual support model if something goes sideways.
He forgot that his value was in the expertise, rather than the product.
{Redacted} is a good company, but it’s damned hard to see where he’ll go from there.
“Just try to keep an idea that load testing should be a product… rather than a person.”
That was the message I gave my Credit Union engineer, and I find it true about all engineers. It’s a message that engineers specifically need to know.
You are not your product.
Your value is not connected to your product’s value.
You’re more important than that.
Make sure you treat yourself accordingly, and more specifically, make sure you design systems to treat you accordingly.
Christopher Brown's - Blog 