.jpg)
Does this sound familiar: a vague feature gets conceived by “the business,” budgeted behind closed doors, and then handed off to a team in “IT” with fixed requirements and timelines to deliver? You’re expected to deliver it flawlessly, but kept at arm’s length from the problem you’re solving. It’s an assembly-line mentality: rigid, linear, prescriptive. But software engineering isn’t an assembly line, and engineers aren’t interchangeable parts. They’re creative collaborators who could drive real innovation given the chance. The model is broken and there’s a better way, rooted in how assembly lines are made. Let’s rethink outdated assumptions we’ve inherited and move toward a better way.
I continue to find a familiar pattern, whether I was a full-time employee, a contractor, or a consultant – the mentality across so many organizations is the same. When approaching software development, our mental models mimic an assembly line: “draft, plan, deliver, repeat.” However, the assembly line is misapplied to software development because we’ve lost sight of what an assembly line is the result of and what it does. Let’s deconstruct this.
Coding is the creation of a virtual assembly line
I was raised by my grandfather who was a lineman for a major US automaker. Every year, manufacturing plants shut down for about a week to do line maintenance, machine updates, and sometimes refactoring of lines to start making the new year models. These annual shutdowns are the culmination of months of discovery, prototyping, experimentation, and planning to validate assumptions, test hypotheses, and scale production in factories. Teams outside the factory worked to determine changes to implement in factory logistics necessary to solve new problems for drivers, car safety, and innovate into the future. They were determining the methods to deliver end products – the vehicles and the experience of driving – reliably and repeatedly. They created blueprints, documentation, and requirements for updating the assembly lines as a result of these discovery phases.
The problem is that our collective psyche in software has misapplied where this work happens in software development. How many of our software engineers on teams feel like they are merely machines on an assembly line churning out code? This is wrong, and we must course correct this model fast.
Engineers aren’t the machines on an assembly line, but rather, they are the ones building the assembly line. If assembly lines are the automation built by factory planners to deliver vehicle experiences on repeat, then our engineers are the ones writing code to deliver software experience on repeat. That code is the assembly line equivalent, not the engineers. It’s the code that delivers an experience on repeat, but it’s only through trial and error, prototyping and experimentation, discovery and innovation that we can make this work to solve real problems. We cannot achieve this in our current model. Our current model stifles the innovation and creativity of engineers when we don’t allow them to co-discover the problems worth solving for our users, customers, and businesses. This mindset robs our organizations of the potential that our talented engineers can provide. They are the technical experts and understand what’s feasible to solve problems for our customers that drive value back into the business.
Embrace the inherent flexibility software provides to experiment rapidly
Software offers a lot more flexibility than physical hardware. Once I place a machine on an assembly line, there’s a LOT of work to change that. Software, while posing its own challenges, is much more malleable to rapid change and redeployment. On day one, unlike an assembly line, we don’t need all the details to be set in stone; we can gradually solve the problems in piecemeal fashion. Our product teams can co-discover along the way as they build, experiment, succeed or fail, and understand what code needs to be written to solve problems in a way that delights users and customers and delivers value back to the business. Rather than providing prescriptive solutions, leaders should bring engineering teams into discovery to co-create what the future will look like, and let them help drive the plan and budget.
As a product manager, I’ve seen preplanning, SAFe, and a demand for absolute certainty crush innovation and demoralize great engineering talent. The root cause is this misapplied model and a demand for certainty. It doesn’t have to be this way. If you’re a leader who is expected to have certainty, take a step back and acknowledge how many projects go off the rails and are late, over budget, and have ballooned scopes. We’ve never had certainty, but we can commit to strategies that divest from certainty.
Our strategies should focus on understanding problems as we build, learn, and reduce assumptions we make. Engineers can be trusted to help discover the right problem to solve, and allow them the freedom to explore solutions. They have the technical expertise to know what’s possible and where innovation could occur. As a leader, you can shift your mindset away from optimizing for predictability to fostering resiliency and a focus on impact; from maximizing arbitrary productivity to focusing on results that improve business metrics and drive long-term success.
A new path forward can reshape how we build the future
The world is unpredictable. The illusion of control should have been shattered when COVID-19 changed our entire world. “Given our stormy present, the dogmas of our quiet past are inadequate,” as Abraham Lincoln said in 1862. “Our occasion is piled high with difficulty, and we must rise with the occasion. As our case is new, so must we think anew, and act anew.”
As our world changes, so should our approaches. We shifted our mindsets drastically to deal with a sudden shutdown the pandemic brought, and so we should continue to evolve our mindsets. The most valuable lesson the pandemic taught is how our collective ingenuity can be manifested quickly to adapt to new environments. We have the potential to change and pivot our behaviors quickly, and our businesses and our teams need to shift their mindsets now more than ever.
The rigidity of the assembly-line model in its current application prevents our teams from dreaming bigger and better. Software is a fertile ground for creativity and imagination, and our engineers are visionaries whose potential is untapped when given the freedom to co-explore problems and iterate on solutions. Rather than treating them as interchangeable parts, treat them as partners. They are best equipped to uncover and deliver technical feats when unfettered by prescriptive processes. Foster their ingenuity; don’t limit it. The future will be shaped by those who empower their teams to constantly research, experiment, and co-create. The opportunity lies with our talented people only when we have the courage to reimagine how we work.
We see this conclusion from thought leaders like Margaret Heffernan, Marty Cagan, and Melissa Perri. The time for change is ripe, and those who don’t embrace resiliency and plan for inevitable uncertainties will continue to lose to those who do. Our mindsets must move away from the misapplied models of the industrial age and move toward a new age that prioritizes discovery-led development. Nothing is more imperative.
The solutions we build when we’re all involved in discovery aren’t just better for the sustainable long-term bottom lines of our companies, but they provide better solutions for consumers, users, and often result in better benefits for the whole of society.
Join the conversation in our N.E.A.T. forum.
