[PLUG] Ghosted? (posted payscale)

[Keith Lofstrom]

On Mon, Jul 28, 2025 at 07:53:35AM -0700, Ted Mittelstaedt wrote:
> But today, there's a whole list of states that require disclosed pay scales by law.  And trust me, ANY employer in any of those states who lists a job and does NOT do that - they WILL get reported - by hundreds of job seekers.  And the state employment divisions just LOVE fining employers for this kind of stuff.

90% good idea, 10% bad idea.  Agreed, most jobs are "cogs in
the machine".   Such jobs are quantifiable, and their worth 
and costs to employer and employee can calculated. 

Better jobs are defined collaboratively between "boss" and
"underling", and evolve into teamwork and fluidly delegated
responsibilities in both directions.  It took half my life
to figure this out.

Decades ago at Tektronix, my Motorola-trained manager was
preparing his annual budget for his manager.  One of the
tasks on his list for the team was to prepare a test
program and a probe card and a mask pattern for the new
"depletion gate NMOS process".  The task he delegated to
me was to figure out how many weeks and tens of thousands
of dollars that design time and purchases this would take.  

I came back the next day with "done" and "zero dollars".
Not the answer he (or his bosses) were expecting.

Looking at the problem, I quickly realized that the probe
card for the existing CMOS process was perfectly usable for
a new NMOS proces.  Juggling the process layers for the
CMOS test pattern yielded a usable NMOS pattern (adding a
few details for the production workers to tell them apart). 

Changing a few lines of code in the CMOS test program
created a new program that could test both NMOS and CMOS
circuits, and route results to the appropriate production
database. 

Indeed, the production workers wouldn't need to tell the
test station software which process it was measuring and
which database to add it to;  the workers would follow the
very same steps for either process, and the program would
tell them "CMOS or NMOS" and route the data to the correct
database.  An opportunity to dispel confusion rather than
create it.

However ... my manager (and his manager) was not expecting
a rapid "zero cost" solution to the problem.  As a newbie
engineer, I did not anticipate how much trouble this would
cause as it rippled through the rigid management structure.

A mal-adaptive structure that was brilliantly fluid when
Jack Murdock and Howard Vollum created and grew Tektronix,
but suffered from rigor mortis after both Jack and Howard
died.

I observe similar rigor mortis in 2025 Intel, now that
Gordon Moore and Robert Noyce and Andy Grove are all dead. 
Still many excellent minds working there, but not allowed
to tinker with a formerly-winning formula.  Constrained by
HR and federal employment regulations to select new hires
and replacement management using standard measures of
worth (mediocrity), rather than unhinged mavericks who
will shatter and rebuild a past-focused company. 

Hell, some of those deviants might cause lawsuits,
while they create vast new opportunity for employees,
stockholders, customers, and the entire world.

Meanwhile, I read about crazy new products that just might
blow mosfets and von Neumann architectures out of the water:

https://spectrum.ieee.org/negative-capacitance-schottky-limit
https://spectrum.ieee.org/efficient-computer-dataflow-architecture

90% chance these two examples will fail, as most new ideas do.

https://en.wikipedia.org/wiki/Sturgeon%27s_law
-
Luckily, we have more thousands of new ideas in 2025 than
any past year.  Companies and nations willing to take the
risks to ride these waves may wipe out - or they might
be the next Intel.  Or even the "next" United States,
where OUR wretched huddled masses, yearning to breath
free, will escape TO, FROM our teeming shores.

"Whenever I run into a problem I can't solve, I always make
it bigger" - attributed to Dwight Eisenhower. 

H.R. and "safe hiring" is not the best way, but is better
than the blind bigotry that plagues many companies.  How
do we enable "best", without enabling occasional "worst?"

Keith L.

-- 
Keith Lofstrom          keithl at keithl.com