In enterprise engineering, the skills that get you hired and promoted are not always the ones that keep systems running. This article explores the divide between signal-based hiring practices and substance-based effectiveness—and the long-term risks of confusing the two.
There’s a disconnect in enterprise systems and software that’s formed where studying the things that make you good at it is a whole different curriculum than studying the things that convince employers that you’re good at it, and they both eat into each other and are even mutually exclusive at times.
As far as I can tell, it boils down to the differences inherent between signal-based credentialing systems (what employers use to judge candidates) and substance-based mastery (what actually makes someone effective at building or maintaining enterprise systems).
Both forces shape the industry, but they operate on different principles and serve different goals:
- Employers are often optimizing for risk mitigation and hiring filters.
- Practitioners must keep optimizing for employability if they do not wish to become hobbyists.
These lead to conflicting incentives. To get hired, candidates must signal: certifications, buzzwords, linkedin polish, LeetCode. At the same time, to be good at enterprise systems and software (to stay hired), candidates must internalize system design, legacy code navigation, ops intuition, architecture over years.
On the employer end, there is gatekeeping via simplified evaluation. Enterprise employers often rely on proxies like AWS certifications, Kubernetes familiarity, “years of experience”, behavioural scripts, and even into the technical interviews will rely on patterns and paradigms in code that would be viewed as overly academic when included in a pull request to their own software repositories or on arbitrary design principles that they would not allow to be applied in their environment.
These are not designed to measure what actually matters (e.g., can you debug a distributed queue under failure? Can you derive meaning from a runtime exception during an outage?). The evaluation layer is shallow, so the “curriculum to pass it” is shallow too.
Enterprise work itself is messy and contextual. Most real enterprise systems are old, under-documented, or built in ways that resist textbook solutions. Truthfully, the “textbook solution” is often a bad idea due to the level of overhead or complexity that comes with it, and businesses tend to punish it when introduced — and even if they didn’t, the translation of business requirements to technical specifications or the daily operational constraints of the business mandate those solutions to not be used in a pure sense. Those patterns are used as rules of thumb for academic value but don’t make it into most enterprise solutions for high-performing businesses with high-performing engineering teams.
What makes you good at these things involves slow, painful accumulation of intuition—often the opposite of what looks impressive on a résumé. You might spend months or even years learning why not to use the shiny new tool everyone is talking about — and then you’re in the strange position of deciding whether to say that or not, as the business hires the “proponents of the shiny” and tends to skim over the detractors as “left behind in the times” until they notice there’s a problem with “the shiny” that’s causing a headache or that the people not using it are far more effective at their jobs. Not always, but often. The engineering crowd is probably more guilty of this than even the business is due to total saturation of engineering communities that want to be hirable and have a tool and practice-based approach to that. Even when the shiny is broken, some companies and engineering cultures will still insist on using it, falsely believing it to be a fundamental practice. This gets fuzzchasers promoted before the success of the fuzz is evaluated, and it doesn’t work well for businesses’ bottom lines.
Time invested is also zero sum. You can’t simultaneously “grind AWS certs and DevOps interview prep” while also building deep expertise in, say, a complex legacy financial ERP system. The signal competes with the substance. Worse, the “credential signaling system” actually penalizes time spent on real work if it’s in “boring” areas that may even be critical to their business operations and engineering environments. This has the unfortunate side effect of punishing engineers for doing work critical to the business.
These dynamics result in misaligned incentives in the career ladder, unfortunately. Internal promotions reward stability, tribal knowledge, quiet risk management, and social primate hierarchies. External hiring favors novelty, market buzz, and visible signals. So you end up with two conflicting latters:
- Internal mastery that doesn’t travel well.
- External signaling that may not help you in real enterprise maintenance.
To recap, there’s a curriculum for being competent, and a curriculum for appearing competent, and they’re shaped by fundamentally different pressures– one from real system complexity, the other from hiring filters. They’re often mutually exclusive because the first demands depth, and the second rewards breadth and polish. It’s strength or beauty, far removed from wisdom.
So, what’s the collateral impact of this? An overwhelming number of senior engineers and technical leaders even fall for this trap, where many professionals internalize the signal-based values that reward them with career opportunities to the point that they can no longer recognize or respect the other track of substance well anymore.
Career survival rewards signals as a culture problem. Even engineers are subject to performance reviews, job hopping, internal politics — so signals like “shiny” tech stack experience, visible impact (even if shallow), conference talks, open source commits, or buzzword compliance take priority. These advance careers faster than “unsexy but critical” more boring work like reducing tail latencies in an aging system, cleaning up broken CI/CD flows, writing monitoring or testing layers for legacy code. So those engineers start optimizing for what gets noticed — not what sustains systems effectively.
This cascades into mimetic drift: As engineers see others rewarded for shallow signaling, they unconsciously adopt the same values. Over time, resume polish becomes more important than production uptime, being able to spell “openshift” becomes more important than “understanding topology implications deeply in n-tier web platforms”, and microservice evangelism becomes more important than “quietly maintained a 10 year old message broker”. The result? Entire engineering cultures drift away from substance prioritization without even realizing it as they learn from each other.
Then, there’s the uncomfortable truth for many technology leaders: Substance is hard to recognize without having it. Engineers without deep experience don’t know how to measure deep experience, so they default to recognizable surface-level traits: Github activity, new framework enthusiasm, and verbal fluency on architectural trends. But someone who’s built real resilience into real systems might speak in cautious, boring, qualified language that is treated as “overly academic” or “overengineered” to what are effectively lay generalists with surface level topic awareness despite having spent years being exposed to that topic. Ironically, the more real experience you have, the less ideal and the more cynical you look. Many very senior technologists are actually conditioned to appear more junior than they are to avoid the problems this creates.
It’s not just the engineering culture, though. There are almost never institutional feedback loops for reality in internal business intelligence at this level. There’s rarely an incentive to audit technical decisions after the fact, or attribute uptime or performance improvements to the right person, or to even reward engineers who prevent problems that never happened. So, the boring smart engineer has an argument to make a change to avoid a problem later for certain scenarios — and all that’s remembered is that there was an argument over “some toomfoolery” (actual quote) instead of that it prevented a serious business impacting problem later. So, engineers trained in enterprise organizations never learn to value substance, and are often punished when they find themselves possessing it.
I have recommendations for engineering leaders on this:
1. Redesign hiring and evaluation criteria.
- De-emphasize buzzword compliance, certifications, and whiteboard challenges.
- Emphasize system debugging stories, legacy system experience, and long-term outcomes like you do in every other field where results matter.
- Use scenario-based interviews: “Describe how you stabilized an aging system under real constraints”.
- Include engineers with substance experience in hiring loops, even if they lack public-facing polish.
2. Reward excellence more than the appearance of excellence.
Formalize recognition for:
- risk prevention over outage repair.
- long term performance improvements over short term bug fixes.
- maintaining complex internal systems others depend on.
Shift the rewards: Track and promote people who reduce incidents, simplify operations (the magic here is that it’s often with complex reasons), and resolve brittle code paths — even when invisible.
3. Balance career progression.
Create parallel career growth paths:
- one for deep domain mastery (e.g. staff+ engineers maintaining critical systems)
- one for signal-heavy impact (e.g. high-visibility delivery or platform modernization)
Avoid penalizing engineers for staying in “boring” but essential areas.
4. Audit outcomes, not appearances.
- encourage retrospectives on successful stability not just incident postmortems.
- attribute value to problems that never happened due to preemptive fixes.
- in architectural review boards, give weight to context-driven pragmatism over trend adherence.
5. Shape culture through examples.
- publicly praise engineers for choosing not to adopt unstable trends when unjustified.
- make room in performance evaluations for engineering judgment, not just tool usage or domain knowledge.
Set the tone: depth is not outdated, it’s core infrastructure.
Let engineers optimize for what sustains the business, not just what makes a better resume. If you do these five things, your business will be more stable, your engineering departments will have better engineers and will follow better advice, and your engineering leadership will be more excellent over time.
This article was cross-posted to linkedin:
https://www.linkedin.com/pulse/engineering-leadership-signals-substance-christopher-m-punches-jicvc