Ever look around a large company and wonder, why do people think so small? Can’t they see the BS all around them? How do they even live like this?
I have. But now I kind of get it.
Consider that this quiet of mind may be by design. It may be functional stupidity.
Alvesson and Spicer describe the concept in a 2012 paper called “A stupidity-based theory of organizations.” (pdf) They push back against the idea that organizations try to maximize information flow and computation. After all, too much thinking about everything can tie us in knots. We need to buckle down and get work done, not spend all our time trying to reach consensus.
Functional stupidity means not self-reflecting, not demanding reasons, and thinking critically only within safe boundaries.
Think about how you can do the work, not about whether you should.
This is not dysfunction. It is functional: it gives people a positive outlook. A feeling of certainty (people love that, tragically IMO). Friction is reduced when people don’t all question everything.
Workers get a sense of who they are, what they want, and how to get there. A career path is laid out for them, describing how to move up the escalator, managed by their people leader.
Meanwhile, leaders get followers. Don’t bring your unrelated thoughts to work. Be “professional.”
I can see why this is useful in many organizations. But it will never produce good software.
Developing software, I make decisions every day. I decide what the computer should do in every situation, I decide how to instruct it to do that, I decide how to fit that together with all the other parts. Then I type that in, try it, decide whether it worked.
To make good decisions, I gotta know why I’m a doing a thing. I need to think hard about what I’m doing. When it gets hard: is this the best thing to do right now? And I need think critically about the wider system, more than just my piece.
Example: “Display the number of orders received today.” OK, why? If it’s for a dashboard, for executives to feel like they have the pulse of the business, then it can be optimistic and include orders that aren’t finalized. If it’s for accounting, then maybe not. If it’s for operations to notice high or low volume, then maybe a graph will be better. For operations, latency needs to be low so I’ll go to extra effort to get the data there fast. For accounting, accuracy is important but there’s not such a rush. I also need to know how all the order data sources work, what their data means, and what its latency is.
If I don’t know why I’m displaying that number, then what can I do but aim for perfection? Work way too hard to get the number perfect and up-to-the-minute. It won’t be, that’s physically impossible. But I’ll say that it is, because that is what’s asked of me. I’ll avoid thinking too hard about it. And I’ll query the heck out of downstream systems without asking whether that load is a problem, or whether they could give me a push notification instead to smooth the whole flow.
Functional stupidity is a disaster for software development.
That’s because software development is more like C-suite executive strategy than office work.
Yeah, we sit in front of a computer and type. But when we do that, we’re telling people computers what to do.
Both executives and developers build and operate sociotechnical systems. Their system is more heavily social and ours is more heavily technical. Theirs is bigger, OK, sure, sometimes.
Consider that every decision a developer makes is executed gazillions of times by who-knows-how-many computers. These decisions matter! They need to be made with perspective!
So bring your whole self to work. Be “unprofessional.”
Demand reasons! Managers: convince me, don’t tell me, to do a thing, because then I know why. (I’m easy to convince.)
Consider the wider picture, as much as you have room for. Design subsystems, not systems. Develop social connections to match the software dependencies, and talk together to smooth the whole.
Eschew functional stupidity — and pay for it. This means accepting uncertainty, finding your own identity, managing your own career. It means balancing all those “but what about”s with trust in the rest of the team, trust that they are competent and also care.
The opposite of functional stupidity is “thoughtfulness, critical reasoning, and dialogue.” We need these to build good software.