This is a good article, written in 2000. I think it was my introduction to the term "cargo cult" way back when.
> We call the imposter organizations sweatshops because they emphasize working hard rather than working smart
I wrote on a whiteboard at an office, early in my career, "Company motto: Work harder, not smarter" out of frustration following a meeting with a manager where that phrase was nearly stated verbatim. I had thrown in a ton of OT getting things working (I was young), including a nearly 36-hour run (7am Monday to 6pm Tuesday, with a few hours off for lunches, dinner on Monday, and a trip home to shower and change Tuesday morning). The OT was worth it, I fixed the thing that was blocking us and I set it up so that we wouldn't have that issue in the future. I identified various areas where procedural improvements would reduce our error rate in cases where we had repeatedly run into the same issue (or similar issues with a common root cause), and it was discarded by this manager with something like the above motto and "We don't do that here". This meant that I was going to get lots more OT (yay money!) but I just wanted to sleep at night again.
I still do this after 15 years! Commitment means creative autonomy though. If valid solutions get tossed out by impostors then it becomes impossible to sustain. Or when authoritarians and people low on agreeableness traits start trying to make everyone predict all implementation details up front under the guise of process improvement (it allows unexperienced managers to pretend they understand details).
There is a minimum level of mutual co-operation and diplomacy required to nurture commitment and ownership, and alas it seems so uncommon as soon as a team goes over 5 people IME, unless the business is REALLY careful about hiring for openness and agreeableness.
I left my last job for many reasons, but fiefdoms were one of the big ones. I had a manager, when I brought up increasing automation in testing, say: But then what would the testers do?
My answer was: Automate more tests and test more systems, no one is being let go but now we can do more across the team and organization.
The threat of losing personnel though, to a reorg as the needed numbers changed, was enough to stop managers from doing things that would improve their product and the quality of life of their teams. It was pathetic.
Yeah I've never seen an increase in automated testing have the effect of laying off testers. Usually it results in testers moving up the food chain a bit: they get involved with the automation, help with things like CI integration, and find more time to devote to test strategies, documentation, etc.
That was one of my points as well. Our testers weren’t technicians flipping switches. They were engineers and computer scientists who designed test cases, maintained them, ran them, and analyzed the results. I wanted to free them from running the test cases (which could take weeks when the full suite was executed) so they could do more of the rest.
I'm not sure. I think most people know to at least pay lip service to "collaboration", even if they're awful at it. The best bet would be directed questions about how they have achieved collaboration in the past and how they might try to improve collaboration as a manager in your office. But you're pushing into mind reading territory, you'll need to be able to observe where they came from and what was actually done there. If it's an internal hire/promotion this is feasible, but it's not possible, in general, if you're hiring from outside your company.
Thanks! So, seems to me you're saying it's more important to look at what they actually did in the past (if there're any ways to find out), rather than listening to what they say.
Makes sense, humans are so good at quickly learning what sounds good and others want to hear, are they not
Many engineers/Creative professionals chafe at being told how to work, so they will resoundingly push back on any procedural change. Usually you'll find that as an individual contributor you have wide latitude to develop in any manner you see fit as long as you earn the trust of your manager and can satisfy his leadership's tracking requirements.
On paper I often work in a scrum team, in practice I subdivide my own work along arbitrary story guidelines to make sure that at the end of the spring I have the requisite number of points + 20% on average. If someone else needs to pick up some work, I'll slice off a whole workstream for them - and then we'll subdivide the workstream to have the requisite number of points + 20% for them as well. I've worked in agile shops for 8 years at this point, and this approach has yielded the best results for both myself and the company - but "not using scrum/agile" is a great way to be viewed as rocking the boat in an unhelpful manner.
Process improvements are typically valued at zero unless and until a director (or above) is annoyed by the issue addressed or, worse, their bonus may be impacted.
Process improvements are perfect CYA. You hand it in in writing, get a written turndown because too expensive/annoying/whatever. When shit hits the fan, you are covered. I like process improvement.
Other than that, I only saw one improvement realized. It was one a colleage turned in, got rejected. Then turned in again almost verbatim by a manager 2 layers up, who got it accepted and got the bonus for it...
Or they get read by the consultants who then take credit for the suggestion and get paid. Granted, the consultants are also a blame sink if the suggestion doesn't work, or ruffles feathers.
> We call the imposter organizations sweatshops because they emphasize working hard rather than working smart
I wrote on a whiteboard at an office, early in my career, "Company motto: Work harder, not smarter" out of frustration following a meeting with a manager where that phrase was nearly stated verbatim. I had thrown in a ton of OT getting things working (I was young), including a nearly 36-hour run (7am Monday to 6pm Tuesday, with a few hours off for lunches, dinner on Monday, and a trip home to shower and change Tuesday morning). The OT was worth it, I fixed the thing that was blocking us and I set it up so that we wouldn't have that issue in the future. I identified various areas where procedural improvements would reduce our error rate in cases where we had repeatedly run into the same issue (or similar issues with a common root cause), and it was discarded by this manager with something like the above motto and "We don't do that here". This meant that I was going to get lots more OT (yay money!) but I just wanted to sleep at night again.