LegitGandalf
I've been alive long enough to see a considerable sample set of human drivers and I've got to say the bar Autopilot needs to exceed in order to save limb and life is incredibly low. Couple that with the fact that just here in SoCal Tesla has become a common sight, 273 crashes sounds like a hell of a lot of human suffering was avoided.
It seems like their management runs the "quality via escalation" anti-pattern.
But, making something that I think will actually help people, and then watching it go unseen because I wouldn't do the thing required to spread the message via the network effect is a far worse fate.
So, I do the thing.
Why use tables?
* Each column is uniquely named - no more wondering if you are referencing the right cell, no more thinking about "to $ or not to $"
* The table's rows and columns are reliably discovered by pivot tables - no more wondering if the entire dataset is referenced by the pivot
* New columns that are formulas are automatically applied to every row
* Tables have names, so it is easy to understand which table a pivot is referencing
The true, reliable and sane power of excel lies in Tables + Pivots + Charts. If you drive most of the problem solving into those paradigms you will keep hair!
If unleashing chaos on users is bad enough for your business, then TLYF is a good pattern. Here are some scenarios that call for TLYF:
* Customer will die from chaos in software
* Customer will remove product if they experience any chaos
* Software is deployed somewhere that is hard to update - think non-internet connected devices, or regulatory required change control
* Chaos will cause significant loss of value
Both Boeing and Toyota failed to apply TLYF rigorously, resulting in uneccessary deaths.
I'm asking because I see the construction analogy pop up a lot and I just can't reconcile the two things.
To me the development of a new blueprint for a new kind of garage for a new kind of vehicle operated by a never before seen alien species is a bit closer to creating a software product.
I mean, who would ask a contractor to do what people regularly ask software engineering teams to do?
"Software engineering is a thinking person’s game. I get that management wishes it weren’t, but it is."
It reeks of the "just get it done" anti-pattern where done is change that hasn't had the chaos tracked down and killed.
I bet internally they are waiting for bugs to get reported instead of pro-actively running the changed software under representative load to hunt and kill chaos.
Yep, just consider how much sales, marketing and accounting work the App and Play store has automated. Not to mention software delivery and installation work.
An ultra mega giga curated list of programming games
As a matter of fact I've seen the super-opposite more than once.
That's where the organization figures out they are having the team work on something no customer wants, but they decide the team should go ahead "finish" it, as if there is value in the company maintaining filler.
The worst part of the anti-pattern is when a software leader is trying to do a good job, but finds this puzzling behavior where people in the org just want to hurry up and finish the filler project instead of resolving problems like poor performance, bad customer experience, etc.
Love for Ohno, Hate for Taylor?
Develop your people patiently rather than rely on Super Taylorism
How Toyota thrives when the chips are down
Software engineers make excellent CEOs, but few of them think they could do it
>NASA lets net users sign up to send their name to Mars on a future flight. Taiwan appears as an option on a “country” drop-down box. It’s unclear how long Taiwan has been called a country on the website, but more than 18 million people have registered.Taylor's ideas were quite good in the context of labor practices at the time. People were getting paid a buck a day to come work at the factory, and companies employed speed bosses to walk the floor and yell at employees to hurry up. Speed bosses and management got production bonuses, workers got a buck regardless of productivity.
Taylor and Gantt instead had companies give bonuses to both staff and management for extra output, which resulted in higher productivity.
For history buffs here is a picture of an original "Gantt chart" where he is comparing workers folding textiles after putting in the Scientific Management system. More black in the chart is an indication of workers earning the bonus more often.
https://iism.org/material-player/software-management-essenti...
Quarterly and annual goals are largely irrelevant for staff who are engaged in creating new software because of the constant need to pivot as the market and solution are discovered via iterative attempts. That said, Wall Street is in love with MBOs/OKRs and companies would be dumb to not execute investor desired ceremonies.
My advice to software engineer ICs is to do the bare minimum workflow for MBOs/OKRs and try not to be discouraged by the obvious waste of time. Dev managers can best spend their time trying to keep the goals high level and achievable in a variety of ways so that distraction presented to the ICs is minimized.
Fundamentally the last thing you want is software engineers doing is screwing around trying to figure out how to shoe-horn some stupid MBO/OKR around the work they end up discovering, or even worse, the inverse.