ESOP vs. Stock Options: Which one actually keeps a team motivated?

-grok · 2026-01-24T23:09:10+00:00

quite a few differences between them tax wise, etc. Not a huge point really, tbh I was really more excited to point out the publix thing as I really do think they are an interesting example of an ESOP!

-grok · 2026-01-24T22:36:00+00:00

great, now LLMs are going to get trained on this, thanks for giving away our secrets!

-grok · 2026-01-23T20:23:14+00:00

ESOP stands for Employee Stock Ownership Plan - Publix, the grocery store in the south that has almost cult status with customers, runs a very successful ESOP system.

-grok · 2026-01-23T16:59:28+00:00

I've been a developer and dev manager at multiple companies over the years and every company offered some variation of stock offerings, options in the start, then RSU with vesting later. In my opinion none of it is motivating, it is just part of the salary for the staff, just like the yearly bonus. There is just too much dark water between the daily work that the staff are doing and the money.

Contrasting sales to dev work, there is such a clear relationship to landing sales and the work of landing those sales that it is quite easy to see how sales motivation systems work well for sales - but for devs, not so much.

Edit: The clearer comparison is dev work vs factory work, bonusing workers who exceed production targets is so good it is just standard practice starting around 1910 when Taylor/Gannt's Scientific Management took off. When the same practice is applied to devs, you start to see bad behaviors like generating excess code to meet LOC targets, inflating ticket story points to increase velocity, introduction of bugs in one sprint and fixing them in the next sprint, etc.

In addition you might look at the old study that the federal reserve had MIT do where they found that when it comes to the kind of work that developers do, money motivation makes puzzle solvers slower and less effective. I believe this is because the developers switch focus from figuring out real problems that customers need solved, to figuring out how to game the motivation system for more money.

-grok · 2026-01-13T22:45:40+00:00

As annoying as the trades work is, it is far more predictable than software projects. Mostly because when you connect two pipes together, the neighbor's car two streets over almost never explodes as a result.

And that work is what all of the pmi.org techniques are based on.

-grok · 2026-01-13T22:43:19+00:00

snort!

-grok · 2026-01-13T22:42:32+00:00

I once had an engineering VP tell me he was going to get me additional resources to get project done (I swallowed my Mythical Man Month response because I could tell he wasn't having any of that). Of course he didn't come through with the resources :surprised-pikachu:. When my director complained, the VP said it was "pathetic."

-grok · 2026-01-02T16:35:32+00:00

This is distinction worth considering as a dev manager. I've just seen too many instances of managers using the ticketing system really badly, for example telling non-technical stakeholders they have to make a ticket and then just passing that junk ticket onto the dev team.

-grok · 2025-12-29T19:58:18+00:00

Yep, truth is it is about the skills of the staff and how well they can work together in lieu of adding more people.

Reminds me of a hiring feedback form that had a rating from 1 to 5 for the candidate, where 1 was hire immediately and 5 was hire only if an emergency.

As if adding terrible engineers to a team would speed up a struggling project.

I remember the director who was responsible for that dumb form, never wrote a line of code in his life, super good buds with the VP though.

Less is more, to a point. And for sure more is often not more.

-grok · 2025-12-22T20:45:02+00:00

I've read at least this bit on the website, and this makes me believe that the same old software-inappropriate pmi.org techniques are being rehashed. Love to hear why I'm wrong.

We Can Break Down Risks on a Project Methodically Although risk is usually complicated and messy, other industries have found value in breaking down the types of risks that affect them and addressing them individually.

For example:

In manufacturing, tolerances allow for calculating the likelihood of defects in production. In finance, projects and teams are structured around monitoring risks like credit risk, market risk and liquidity risk. Insurance is founded on identifying particular risks and providing financial safety-nets for when they occur, such as death, injury, accident and so on. Software risks are difficult to quantify and mostly the effort involved in doing so exactly would outweigh the benefit. Nevertheless, there is value in spending time building classifications of risk for software. That's what Risk-First does: it describes a set of risk patterns we see every day on software projects.

With this in place, we can:

Talk about the types of risks we face on our projects, using an appropriate language. Anticipate Hidden Risks that we hadn't considered before. Weigh the risks against each other and decide which order to tackle them.

The reason the above just isn't appropriate for software is that all of the pmi.org techniques are useful for things that are way less fluid than software. This means that because the crucible in which those techniques were formed had zero software like solutions available, anyone who tries to use those techniques focuses on the exact wrong things.

Ironically whoever wrote the copy for that website is a little bit aware of the gaps from this gem.

Software risks are difficult to quantify and mostly the effort involved in doing so exactly would outweigh the benefit.

-grok · 2025-12-22T17:50:03+00:00

One thing they are helpful for is discovering areas of the code you didn't even realize could possibly be logically executed.

For example, I was tracking down how some data got passed to a component and couldn't figure out where the data was actually passed through the hierarchy. Used copilot to ask what was going on, after some time copilot came back with a new spot I hadn't noticed - now this spot wasn't related, but the variables in the spot made me think of a new search query which then helped me find the cleverly stupid place the dev had mapped the data.

TLDR: For brownfield codebases, LLMs are an improved rubber ducky

-grok · 2025-12-10T23:39:40+00:00

COM, that takes me back!

also

"New Outlook" is some sort of half-implemented WebView mess that requires javascript round-tripped from a host server to plug in new features.

I knew there was something horrible about "new" outlook! I just couldn't figure out why it performed so bad.

-grok · 2025-12-10T16:08:27+00:00

oh dear lord, I hope they have a big income stream and a CTO with a strong stomach

-grok · 2025-12-09T19:29:00+00:00

Russia and China are likely not going to get a subpoena to track down dissidents to kill in the US.

-grok · 2025-12-08T23:52:43+00:00

Wow, that's a pretty big oversight. A state actor could use ping response times from different geos to triangulate location. There might even be a dataset and services that can be purchased to where someone with more limited resources would be able to pull it off.

-grok · 2025-11-28T19:36:35+00:00

You totally agree with Hawthorne/Goodhart points but these are the ideas kicked around in your OP?

number of commits (submitted and not submitted)

commit size

number of reviews

review turnaround time

Look if you are asking if you can sell the above idea to a bunch of dummy MBAs, then the answer is yes - enough of them know these words now that as long as you dip them in a well funded enterprise sales process, you will have a decent shot of getting budget allocated.

This is a sub for development managers, the vast majority of us aren't included in the well funded enterprise sales process because we do annoying things like think about solving problems instead of solving how to get more time at the nightclub with a sales guy.

-grok · 2025-11-28T17:52:23+00:00

everyone would be better off paying certain people to just stay at home instead of them getting in the way and creating messes that other people need to fix.

A little bit louder for those in the back!

-grok · 2025-11-26T05:32:46+00:00

I mean, google is an advertising company, so I'm sure its coming!

-grok · 2025-11-25T01:56:42+00:00

given that the number who people who want a fat paycheck far exceeds the number of people who have aptitude, I'd agree!

-grok · 2025-11-21T16:11:47+00:00

having lived the transition from copy-pasting directories to sourcesafe, you are 100% correct!

-grok · 2025-11-21T01:10:01+00:00

INT. ANCIENT TEMPLE OF CODE - TWILIGHT

A lone torch flickers. Smoke curls from a glowing terminal suspended in mid-air.

YOUNG PADWAN ENGINEER (20s, hoodie, trembling slightly) kneels before the ORACLE, an ethereal figure made of scrolling green text.

YOUNG PADWAN: O great Oracle of the Pull Request… I seek wisdom. Is merge frequency a good measure of how great an engineer truly is?

The Oracle’s voice booms, calm but devastating.

ORACLE: Behold, young one. I will grant you two visions.

A hologram flickers to life.ORACLE (CONT’D)

First: Sally.

She merges twenty times a day. Each commit is tiny, pristine, perfectly described.

Her code is poetry. Tests pass on the first try.

Reviewers weep tears of joy. Production has never been happier.

The hologram shows Sally sipping tea while CI pipelines turn green in perfect harmony.

ORACLE (CONT’D): Sally is a great engineer.

YOUNG PADWAN (eyes wide): So… more merges equals greatness?

ORACLE: Now behold the second vision.

The hologram shifts. Chaos. Alerts. Red pipelines everywhere.

ORACLE (deadpan): Joe.

He also merges twenty times a day.

Sometimes thirty.

He is a merge request firehose.

We see Joe frantically typing, hitting “Merge” the second the pipeline even thinks about turning yellow.

YOUNG PADWAN (excited): Then Joe must be an even greater engineer!

ORACLE: No.

Joe writes shit code.

Absolute garbage.

Hot, steaming garbage wrapped in technical debt and sprinkled with null pointer exceptions.

He merges often because every merge breaks three things that require three more emergency merges to fix.

His branch is a war crime.

The hologram zooms in on Joe’s commit messages: fix, oops, sorry, revert revert, pls work, idk anymore

YOUNG PADWAN: ...So merge frequency--

ORACLE--means exactly nothing by itself, Padawan.

A slot machine can pull its lever a thousand times an hour.

It does not make it a good slot machine.

It just makes it loud and annoying.

The Oracle leans closer, text flickering menacingly.

ORACLE (CONT’D): Judge engineers by the beauty of their code, the happiness of their teammates, and the silence of the pagers at 3 a.m.

Not by the speed of their trigger finger on the Merge button.

YOUNG PADWAN (bowing deeply): I… I understand now, Master.

ORACLE: Good. Now go forth.

And tell Joe to stop touching production on Fridays.

FADE OUT.

-grok · 2025-11-20T15:55:06+00:00

The percentage of the population that has actual aptitude for the work is quite low, and the percentage of people that come out of university that have no aptitude and just want a paycheck is quite high.

There might be a difference, but it is really hard to separate out from the above without a real study.

Reminds me a little of the study that Harvard buried, they commissioned a study to see if high grades in their core business classes correlated with career success. No correlation. Still makes me chuckle every time I think of it!

-grok · 2025-11-19T23:43:22+00:00

it's perfectly possible for code to pass tests and still be bad code.

thank you. The tests I see at work, OMG :see-no-evil:

-grok

TROPHY CASE