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, I set out on an ambitious workload of three-night classes for the Fall semester. Systems Analysis & Architecture, C Programming, and Managing Technical Teams.
The 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.’
After all, at the time, I was already experienced with programming several real-time applications and hardware integrations mostly in C. I was also currently moving up the career ladder, successfully managing a small but talented technical team delivering a very large and complicated enterprise application involving fingerprints, hand geometry, smart cards, and door locks at airports. This after leading a few other teams successfully in smaller projects.
Was I wrong about that!
In some future post I’ll get into the hilarious details of what happens when someone writing real-time software in C for a living comes up against a department chair with a more … um … let’s just say ‘classical’ approach to C programming.
However, 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 — similarly lacking in real-world experience —teaching a philosophic brand of team leadership entirely driven from the perspective of waterfall practicing certified project management professionals.
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 mini computers geared for telecommunications at a song, then spun up a huge software project to port their current financial accounting system to run on said mainframe.
This all occurring in the dark ages before SaaS, PaaS, and programming language & data interoperability.
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 professor’s office I explained my hypothesis, the MS / PMP’s response being 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 somewhat incredulous …
“… why didn’t you make your main point more conspicuous in your paper?”
Now even though I actually provided tables of data, links to the related government contracts, and news articles regarding these three real-world examples 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 about 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 are 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 of 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 of delivering a 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;-) … all while successfully delivering value to customers in real life.