As software engineers, we've all been left staring at an egregious problem while a manager prevents us from doing anything about it. "That's not a priority right now," she might tell us. "Run these SQL queries because the senior leadership team needs some numbers."
Nothing is worse for the morale of a company that depends on software engineering than moving engineers onto non-engineering tasks while big problems are floating around waiting to be solved.
In the 1981 classic by Archibald Putt, Putt's Law and the Successful Technocrat, Putt's Law was unleashed on the world:
Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand.
The truth of Putt's law must have felt like a smack across the face with a cold, fresh mackerel. It tells us what we've always known: that the priorities of managers are determined in a vacuum of knowledge, while those with eyes on the ground are prevented from doing anything with the information they've gained.
It's easy to react like Edward Yourdon, who said:
If you think your management doesn't know what it's doing or
that your organisation turns out low-quality software crap that
embarrasses you, then leave.
But this would be missing a major opportunity.
Sharing knowledge up
To work against and offset Putt's Law requires a coordinated grassroots effort at the ground floor. It requires the engineers to put their feet down and do something about the blindness coming from the top. It's not only a huge opportunity, but also a vital imperative. Without your efforts, your job will devolve into Office Space and Dilbert.
How can you prevent that?
Tell your manager what you know. Then back it up with data. Then tell them again.
It's that simple. Share what you know! If you see something, say something. Gain the support of evidence and the wider team.
Then sit back and have some patience.
Why the ground floor is so important: a lesson from history
In my experience, the ground floor is as important as the top floor, but usually no one is saying anything to the top floor. I don't know how many informal gripe sessions I've been an incidental party to over a couple beers--gripe sessions that hold valuable information that managers should know.
What were the engineers at IBM thinking in 1943 when Thomas Watson, the current chairman, said this:
I think there is a world market for maybe five computers.
The IBM personal computer wasn't introduced until almost 40 years later, on August 12, 1981. By that time, dozens of manufacturers were already on the market with their own personal computers. Most of these "manufacturers" were hobbyists working out of their garage, like famed Apple co-founders Steve Jobs and Steve Wozniak.
A former IBM programmer of the time, Rich Seidner, told PBS in 1996 that IBM leadership was so blindly proud of their quality control process that they ignored evidence that showed it "would take at least nine months to ship an empty box" under their system.
Thankfully, the public jumped all over the IBM PC when it did come out and the rest is history, but the point still stands. They were way behind the curve, so much so that the Wikipedia entry for the IBM PC has its own section about how they were too late.
If only the programmers, like Rich Seidner, were louder and more persistent with their managers.
At any rate, IBM at least moved toward the opportunity. In the midst of the personal computer revolution, Ken Olson, the chairman of DEC, was still actively an ostrich in the sand:
There is no reason why anyone would want a computer in the home.
Ken Olson, Present, Chairman and founder of Digital Equipment
Corporation, 1977
So stand up and talk
Knowing this, I've come to believe that engineers should talk to managers, and managers to engineers, far more than they do. Any successful software organization needs constant cross-pollination between these two camps. Since the managers aren't doing it, it falls to us!
Software engineers of the world, here's to setting our hands to the task. We don't have much time. Our organizations are already about to miss the train. Someone needs to fire up the megaphone. The bad decisions we see are only because they don't know what we know. Let's get talking!
Top comments (4)
Great post, Scott. I think it works both ways. Management doesn't know what we know and we don't know what management knows.
How many software engineers actually know enough about their company, customers, marketing strategy, operations, opportunities, threats, strengths, and weaknesses to make intelligent suggestions?
I only have anecdotal experience to go on, rather than hard data, but, personally, I think near 100% of software engineers know enough about their company and customers to make intelligent suggestions.
I have spent years in casual conversation with Seattle techies working at Boeing, Microsoft, Amazon, Google, Expedia, Tableau, and others, because I work in tech in Seattle, attended the Seattle University Master of Software Engineering program the past four years, go to meetups, and otherwise randomly meet people at parties and neighborhood gatherings. Almost every person I have talked to eventually mentions that they carry around a laundry list of really obvious changes that could be made in their products to serve their customers better. Most of the time, software engineers are the customers of their own products.
Usually these obvious changes are boneheaded usabilty gaffes that arise from the integration of two or more systems underlying a single user flow. It might take users three pages to login to a system for instance. For one Microsoft example, go try to log in to outlook.com email. Once you land on Outlook.com, you click "Sign in." On the next page, you are only allowed to enter your email address. On the next page after that, you can enter your password. When you hit the fourth page, you are finally looking at your email. You had to load four whole web pages before you get somewhere.
I agree it goes both ways but in many companies, it is viewed as politically dangerous for software engineers to talk up the chain and there are systematic mechanisms in place that only allow directives to flow down a one-way street to the engineers without any possibility of feedback or even knowing where a decision came from. This is a sure way to insure failure, or at least to limit success.
Hey Scott, Thanks for the reply. I agree with your points, even if my experience differs from yours. You run in pretty high-end circles in Seattle compared to me in Edmonton so that could cause our differing perspectives.
I love your writing. Keep it up.
Fantastic read!