Let’s make one thing perfectly clear right off the bat. Engineering is not an assembly line.
Life would be much simpler and cleaner if we could just start with a pile of widgets that needed to be engineered, quickly and methodically remove and engineer each one, and smoothly transfer it to the neat and tidy “engineered” stack. If one engineer could engineer 5 widgets per hour and we had 8 work hours per day, that would be forty widgets per engineer-day of output. A team of ten engineers could therefore engineer four hundred widgets per day, or two thousand widgets in a week. Project scheduling would be a dream. If we were a thousand widgets behind schedule, we’d know exactly how many hours of engineering overtime we’d need to ask for to get back on track.
Some managers may actually think that’s how engineering works.
But engineering is messy. Engineering goes in fits and starts. Engineering is about wasting hundreds of hours at the office, and then doing a year’s worth of invention in the shower on a single Saturday morning. Engineering is a random, soulful, creative labor of genius – a gruelingly frustrating and rewarding endeavor that punctuates long periods of abject hopelessness with blinding flashes of absolute brilliance. If nothing else, engineering is unpredictable.
Nonetheless, the world desperately wants to schedule engineering. They want to categorize and modularize engineers, define interface protocols, and hot-swap engineering talent like Lego blocks. They want to turn requirements into specifications, specifications into schedules, and schedules into reliable launches of products whose actual workings have not yet been invented. Not satisfied with an engineering discipline that is capable of unbelievable acts of veritable magic, the world wants magic that can be scheduled, budgeted, predicted, controlled, and directed at whatever problem feeds their fancy.
The world wants engineering on an assembly line.
So, when the world wants something engineered, they gather a bunch of engineers, put them in a hamster wheel, set the spin counter to zero, and dump in a bunch of feed. “Is it engineered yet? No? Should we dump in more feed, or administer electric shocks?” If one engineer falls off the wheel, they grab the first handy one and throw it on instead. “Now is it engineered?”
Engineers tend toward personalities that belie the true nature of engineering. Often, engineers are methodical, orderly, disciplined individuals whose demeanors would seem to be the polar opposite of the nature of the engineering task itself. Most likely, this is an internal attempt to make order out of chaos, to tame the wild and frantic nature of the unsolved and unknown. This personality trait is not a reflection of the task. It is a dike straining against the tempest.
I’ve worked in engineering environments where the strategy was to empower the individual. Where every engineer had a walled office with a closable door. I’ve worked in places where the entire engineering team was thrown into a giant open sandbox, hoping that some magic concoction would emerge from the combination of arbitrary ingredients. I’ve worked where punctual starts at 8AM were mandatory (with a much more flexible “5PM, but preferably much later” departure time). I’ve worked where time and attendance were not tracked at all – assuming that the demands of the project would motivate engineers to put in far more than the required minimum hours.
The quest to engineer engineering itself has explored an enormous gamut of solutions. Carrots and sticks for motivation, open and closed office plans, rigid and flexible dress codes, waterfall and agile development models, open and closed-loop scheduling – the list goes on and on. And, today, the quest for the on-time delivery of thoroughly tested, well-designed deliverables is as elusive as ever. Sure, there is a component of engineering that is task-oriented, and those tasks can be predicted, scheduled, and tracked. But the true soul of engineering, the thing that makes the magic, the element that causes new technologies to emerge from seeming nothingness, the spark that breathes life into the otherwise inanimate framework of schematics, lines of code, components, and datasheets – is invention. And, invention cannot be scheduled, controlled, or predicted.
The spark of invention is what differentiates engineers. It is what makes (as a friend who runs a consulting business puts it) an “excellent” engineer 45 times as valuable as a “good” engineer. It is what pushes a new product over the line from “me too” to “revolutionary.” And, while we cannot quantify the exact circumstances of invention, we do know that it correlates well with passion. Find an engineer who is passionate about a problem and you’re likely standing near a place where invention is likely to occur.
The modern corporate engineering team is awash in non-engineering activities. By the time we are done with the weekly stand-ups, the status reports, the tracking documents, the team building, the project reviews, the company-standard tools and processes and procedures, invention is crammed into a vanishingly small space with little room to breathe. Perhaps that is why the majority of invention occurs in small startups and winds its way into the corporate domain only after a grueling series of proof points and acquisitions.
Perhaps the very idea of the corporate environment is anathema to engineering. Maybe the creative spark of invention is too attenuated in the soul-sucking structure of the modern massively collaborative for-profit enterprise. It is possible that the passion and unity of vision required for truly brilliant innovation can flourish only in the wild, and attempts to breed strong specimens in captivity are doomed to failure.
Of course, corporations do somehow manage to innovate. There seem to be examples of well planned, precisely executed product development where the desired effect rolled off the assembly line on schedule, one gleaming perfectly engineered widget at a time. Undoubtedly the engineers on those teams arrived at the office precisely at 8:59AM, Starbucks lattes in hand, and began their day’s work with a review of the project status. Probably they pulled out of the parking lot at 6:37, having put in a full day plus an “exceeds expectations” half-hour of overtime including an extra seven minutes for the monthly team lunch out, and stopped by the golf course for a modest 9 holes while avoiding the rush hour for their evening commutes.
I suspect, though, that putting the magnifying glass to those projects, scanning a little bit below the surface, we’d see evidence of a different reality – traces of the gory, fussy, frustrating, unpredictable mess that is our profession – traces of the starts, stops, and do-overs that characterize every real-world project worth doing – sparks of brilliance emerging from shower heads at 6AM – between the shampoo and the cream rinse…
3 thoughts on “Hamster Wheel”
You capture the essence of engineering so well!
Thank you so much for the article!