❯Schrödinger's Engineer and the Illusion of Experience
Experience is sought for, but also not.
It is no longer a question of imitation, nor of reduplication, nor even of parody. It is rather a question of substituting signs of the real for the real itself.—Jean Baudrillard
Put it simply, a Schrödinger's engineer is an engineer whose experience is considered both indispensable and irrelevant at the same time.
Working in engineering is becoming a simulation built on an increasing sequence of abstractions. We can identify at least a few:
- Stage 1: Early computing. Code directly manipulates the machine (Assembly, C). The code is a faithful reflection of what the hardware is actually doing.
- Stage 2: High-level languages and frameworks. We abstract away memory management and hardware specifics. It’s helpful, but we are beginning to hide the "real" machine.
- Stage 3: Cloud computing, serverless, and Kubernetes. The "server" no longer exists as a physical entity you can touch; it’s an abstracted pool of ephemeral resources.
- Stage 4: AI layers, modern tech stacks, endless "services". The industry now interacts entirely with symbols of symbols. Engineers build systems to orchestrate abstractions that manage other abstractions.
The symptom we observe nowadays, is that the industry believes it needs the latest framework, a highly specific cloud architecture, or an engineer certified in a hyper-niche tool (with minimum 12 years of experience), because it is worshiping the sign (the trend, the tool, the credential) rather than the substance.
[ Modern "Signs" ] [ Real Requirements ]
- "Agile Velocity" Metrics - Ability to plan work
- Real-time Dashboards - Measuring vanity metrics?
- Self-Service Analytics - Clear problem definition
- Multi-Cloud Redundancy - Low cost of maintenance
- "We need GrapQL" - First focus on basics
- Security buzzwords - DevOps best practices
Words such as "Security", "Costs", "Agile" and "Self-Service" are swung around in meetings to quickly knock down real concerns with a catchy phrase. Why trying to be "agile" (whatever that means) if you can't even define a clear plan and a timeline. You can't really talk about "security" without establishing foundational technologies such as source control or defining IAM roles. But buzzwords often prevail over less attractive but necessary technicalities.
Hyper Collaboration
Aside technical requirements there is a growing trend of hiring for "likability" and "personality". I consider this symptomatic of a need that affects modern companies, that of staying relevant in a quickly evolving social and technological landscape. In cases like these, when the floor you're stepping on feels like quicksand, people and businesses shift their behavior towards trend chasing and gut feelings, instead of taking a step back to observe and study, which feels like a waste of time.
Yielding to our instinct is at the very least not optimal. First, real experience often brings skepticism of novelty. An experienced engineer asks: "What problem is this technology solving?", "Is this a basis we can build on for the next 5 years?" To a rigid corporate structure, these valid engineering questions sound like "pushback" or "lack of alignment." They hire for experience but fire for the autonomy that comes with it. Being likable won't matter if the bridge collapses. The price of likability is to heavy of a price to pay.
I want to underline that I'm not suggesting closing yourself in a mental box and being uncollaborative as a course of action. Rather, I'm pointing to a trend that places greater weight on likability than on many other characteristics typically associated with a well-rounded individual.
Then there's what I call, hyper-collaboration. You must be more than just easy to work with, you must be a "personality" and spread yourself around the office in an almost obsessive manner. But a busy engineer hardly has the time to do that. Issue tracker tickets are broken down in a dozen subtasks to give management the illusion of control, creating a complex web of tasks that's handled by 5 different people. Clearly we're collaborating right? But that only ends up slowing down the project and creating frictions among team members. There's a reason why people say "there's only one chef in the kitchen".
Conclusion
Companies pay a premium for veterans, not to leverage their wisdom, but increasingly, to satisfy their feeling of safety. They make seniors work with hands tied behind their backs, walking pre-established path, blinding themselves to the fact that the path was mapped by amateurs. In other words companies claim they want experienced people for the solutions they can offer, but at the same time they already have the solution in mind, and that can't be discussed.
Management is made of mere mortals just like you and me. I know much of management is not blind to the simulation, they do understand they are contributing to create difficult situations and frictions or at the very least, they are not making things easier even when they could. To be real, there are cases where also management has its hands tied. They respond to a different set of pressure levers. But I think that's hardly an excuse for constantly selling vacuous slogans.
If a company has already presupposed the solution, they do not need experience. Until organizations realize that true seniority is defined by the license to say "no," the hiring market will remain an expensive theater where wisdom is bought at a premium, only to be locked in a room and ignored.