The Hungry Man Parable
I talk with lots of executives from the go-to-market side of the house who think that building serious software is as easy—and as easy to estimate—as building a fence. Would that it were so.
One destructive side effect of this misunderstanding can be repeatedly changing the No.1 top priority part-way through development, before there’s much to show the world but after spending significant discovery/design/architecture/development time on the previous #1 top priority. As the leadership team gets tired of interim progress reports and longer-than-expected delivery dates, they lose heart and lose trust in the “maker” side of the company. So something new becomes the No.1 top priority. Scattered around the development shop are stacks of partially completed projects not being worked—aging from neglect. And millions of dollars wasted as we repeatedly spend scarce talent getting to half-done.
This is a difficult framing issue, which can reinforce deep-seated beliefs that engineering organizations don’t work hard, are flagrantly inefficient, or need more oversight. (Which usually makes things worse.) It’s a particularly bad strain of Dunning Kruger where engineers think selling is easy, salespeople believe enterprise software is just a “small matter of programming,” and non-tech execs expect that making software is like making sandwiches.
How to communicate this? In the right
Please log in or sign up below to read the rest of the article.