TL;DR — How I pulled an F up to a B+ in grad school with only a pizza box, a prayer, and an assertion that customers don’t give a crap about ‘how’ apps are delivered.
Let me tell you a story about how I almost failed grad school by failing to communicate how software delivery is a lot like pizza delivery.
Pizza delivery? Yeah, pizza delivery. Y’know, that delicious process where clients give a fig about HOW the pizza is made, just so long as the WHAT feeds their needs.
So indulge me as I tell you a tale of how the conveyance of tomato and cheese coated yeasted flatbread relates the delivery of valuable software and features of value.
It was to be the penultimate semester for my Master of Science in Computer Science, with three night classes on the agenda for the Fall semester. Systems Analysis & Architecture, C Programming, and Managing Technical Teams.
At the time, I was already experienced with programming several real-time applications and hardware integrations in C. At work, was successfully managing a small but talented technical team delivering a very large and complicated enterprise application involving finger prints, hand geometry, smart cards, and door locks at airports.
The driving hypothesis behind taking on such an ambitious class load being: ‘if I could leverage my experience in C and team leadership, I could then focus the majority of my energies on the systems analysis class.’
Was I wrong about that!
In some other post I’ll get into the hilarious details of what happens when someone writing real-time software for which someone pays much money comes up against a department chair with a more … um … let’s just say ‘classical’ approach to C programming.
For today’s tale, we’ll stay focused on how I narrowly escaped failing out of a Master’s program because of a similar situation with an associate professor whose philosophy of team leadership was entirely driven from the perspective of a waterfall practicing certified project management professional.
Making the grade
We basically had 3 elements comprise our final grade for Managing Technical Teams. A mid-term and final exam, coupled with a reply to a Harvard Business School case study. Despite having aced the mid-term, and even though I would go on to ace the final, because my original business case reply received a failing grade — actually a non-grade — I was in jeopardy of failing the class.
I was in a Master’s program that had no tolerance for a failing grade.
Without going into too many specifics, the case study described the woes of a C-level executive who purchased some big iron at a song, then spun up a huge software project to port their current accounting system to run on said mainframe.
Others in my class receiving high marks on their replies had focused their replies solely on managing a work breakdown structure against finite resources.
I just couldn’t bring myself to throwing the team under the bus for working on something the business had no business doing.
Working Software vs. Work Break-down
From where I sat, the entire problem was more top down. The primary cause being a political appointee in charge of a “use it or lose it” budget who purchased on-premise hardware without knowing the needs of the operating system, which in turn was selected without knowing the needs of the programming language, which in turn was selected without knowing the needs of the software application, which was planned fastidiously without the benefit of learning the needs of the client.
In short, the pointy headed boss put the cart before the horse.
Having made the mistake of reading Ed Yourdon’s book ‘Death March’ the previous summer, I voiced an opinion that any issues being suffered by the teams were not an issue of resource allocation, but rather the worker bees being put up against an insane and inflexible schedule to re-invent the wheel … only as a square instead of a circle.
I also expressed my belief that most clients, especially those cited in the case study, would give a little more than a rip about the hot new hardware on which the accounting application was rendered; their expectations and focus being solely set on what they needed to satisfy the requirement of their jobs.
Somehow, this message didn’t resonate with the ‘associate professor, MS, PMP’ grading my paper. A pain point I realized when I received my reply with nothing more than a big red “see me” message scrawled on the cover page.
In the privacy of said professors office I explained my hypothesis, the MS / PMP’s response being a somewhat huffy …
“… well no one else in the Harvard Study has ever come up with this premise.”
Keeping my cool, I simply pointed out the latter portion of my paper identified three real-life, and at the time, recent cases of 3 companies in the D.C. area that had suffered a similar fate after each engaging in a similar purchase-to-failure. I added that my premise was in part based on these instances.
The response was a somewhat incredulous …
“… why didn’t you make your main point more conspicuous in your paper?”
Now even though I actually provided tables of data, references to the government contracts driving the three examples, I realized that at some point early on in my paper the associate professor had simply stopped reading it. So instead I negotiated a re-write, with an agreement I would most certainly make my main point very conspicuous (technically, ‘even more obvious’).
A few days later, said associate professor’s door I graced with a pizza box wearing a borrowed uniform from Domino’s employee pal. Only instead of a sumptuous, sliced Sicilian pie, I had carefully mounted my updated report mounted carefully in a clean/unused box.
The first page offered this VERY, HIGHLY conspicuous premise:
Software delivery is a lot like pizza delivery.
From there, I led my journey into the re-written business case analysis with the premise: When you pick up the phone and order a pepperoni pizza, you expect delivery of exactly that, a pepperoni pizza.
- You don’t really care of the style of management employs stacked ranking or vitality curves.
- You could give a fig if the pizza is baked in a Middleby Marshal versus a Vulcan oven.
- What do you care if the Italian treat transported via Yugo versus a Lexus?
- The gender, race, creed, and color of the driver is immaterial to you.
What does matter? What you do care about is:
- Is it hot?
- Is it on time?
- Is it what I ordered?
- Is it stuck to the top of the box?
- Does it taste like the top of the box?
I then went on to explain: To understand the root cause to XYZ’s failure to deliver an accounting system was less an exercise in team management, and more a problem of product delivery that put the assigned teams in a losing position out-of-the gate.
Fact is, XYZ’s clients — in this case internal stakeholders — could have cared less about how the teams were managed, which programming languages were employed, nor was the raw CPU processing power of the new hardware platform of interest.
What mattered to the client was fulfilling their expectation on delivering an system capable of facilitating generally accepted accounting principles.
Any frustrations with and failures of the teams executing was a direct result of management becoming infatuated with hardware, versus bridging the ‘GAAP’ between existing functionality and minimal expectations of parity. Moreover, with no discovery work, the entire focus was on outputs rather than the desired outcomes.
Sometimes we lose our way. We focus on the technology stack, the hardware, the style of management. We become so enamored with the how that we fail to deliver on the what the customer craves.
A lesson I suspect many of us have learned the hard way.
Oh, and despite the brazen pizza-box delivery, and horrible accounting pun, I graduated with all A’s but for the aforementioned technical teams management class, in which I begrudgingly received a B+ (even though we all know it was an A-grade paper;-).