A good friend and mentor of mine said, “We should eat the bread that we make.” He is James Wardlaw, now of Summit Engineering Solutions, LLC and he reminded me of this piece of wisdom in a recent conversation.
It means that we should be forced to live with the consequences of our own work. We should be forced to deal with and correct our own mistakes. We should be forced to manage our own designs after they are released. We should be forced to live with the fallout of our decisions.
When we do, we are naturally more concerned with the quality of our work, the integrity of our choices, and the long-term sustainability of our plans and designs. Holding everyone accountable for his or her own work is absolutely the best way to drive a culture of quality performance because doing it becomes a natural concern. We all know it.
Unfortunately, most organizations aren’t designed to do so. Let’s use the product development genre to explain.
Many organizations that conduct product development or related forms of engineering design and development organize at least two different groups of engineers. One group engineers the solutions and manifests them to design release and product launch. This group is usually called Design Engineering or Design Development.
The other group conducts post-launch engineering, including cost reduction changes, custom design changes, minor changes to accommodate material or supply changes, and, sometimes, new features. Some names for the second group are Maintenance Engineering, Sustaining Engineering, Production Engineering, or Product Support Engineering.
A few organizations further segregate engineers into additional functions such as Quality Engineering, Reliability Engineering, and Supply Chain Engineering. There are intelligent reasons to do so.
One of the biggest challenges to an organization that does its own product development and production is tearing resources away from the chore of maintaining existing products to invest in developing new ones. While engineers are generally eager to design something new rather than write change orders for something old, there is the one-more-thing syndrome that tends keep those engineers distracted with production obligations.
So, to battle that, we create two distinct groups. One that reports to the business development or growth agenda, and one that reports to the production and productivity agenda.
Similar logic applies to the other engineering roles. Specialists that travel to suppliers to discuss outsourced designs and processes and negotiate contracts report to the supply chain function. Similarly, it makes sense to have engineers reporting to the quality function checking the integrity of other engineers’ designs because they are not beholden to the same time and cost agendas.
Specialized skills like reliability analysis and engineering, or dynamic modeling and stress analysis, or regulatory compliance are easier to manage as a shared resource pool.
From a resource management perspective, it makes perfect sense to organize multiple groups for various roles that are devoted to specific business agendas. Unfortunately, it creates a difficult accountability challenge. It also makes it difficult to standardize engineering practices.
It’s simply too easy, as a design engineer, to prioritize schedules, performance targets, and design costs over long-term manufacturability, supplier selection, or productivity values because of to whom the engineers report and what those business leaders are pushing. It’s too easy, almost necessary, to finish the design and let the next team worry about optimizing the design for productivity.
It becomes unavoidable when the design team has little or no knowledge or experience with the manufacturing and assembly methods for their designs. A limited perspective of the entire business engineering process, from idea creation and selection to retirement from production means that an engineer cannot possibly make an informed decision about something that affects processes outside of that perspective.
Thus, while we like to blame engineers for making unfortunate design decisions, we haven’t always enabled them to make more informed ones.
Also, the fact that these various engineering groups report to different business functions and leadership teams means that they inevitably develop varying practices and engineering methods. Likewise, the communication breaks down and an engineer might never learn that his or her decision caused a problem.
These are the challenges that James and I and the rest of our team struggled to overcome while we all worked together. It was an enormous effort to try and standardize methods and drive accountability among several different engineering teams in multiple locations.
The hardest part was getting the various leaderships to endorse the common practice. It appeared to some as a compromise rather than an optimized methodology and they were concerned it would hamper their teams’ abilities to satisfy specific agendas.
In the end, organizational changes pulled James and I away from that mission before total integration and standardization was achieved. I don’t know if it ever was.
My wife also laments a change in practice and behavior where she works. She is a principle or chief engineer, but she started out in a product support role.
When she signed on, it was the practice of the company to start all new engineers in the product support role to learn the various products, the manufacturing and assembly challenges, the total business perspective, and to deal directly with customers complaining about product performance or requesting custom changes.
The company years ago stopped insisting on beginning engineers in product support roles before graduating to design roles. The design engineers without the product support experience sometimes create problems because of a lack of perspective over the entire business-engineering process.
Even with those few engineers that grew up the old way mentoring new recruits, the understanding and an appreciation for the long-term impact of design choices doesn’t get transferred. There is no teacher like experience.
If we put it all together, as usual, the solutions to the challenge are simple, but not easy. We often organize our businesses around the management of resources instead of leadership, communication, and accountability. Accountability, however, is undoubtedly the best tool for ensuring a culture that does things right the first time.
To achieve the quality-focused cultural behaviors we desire we can take on the herculean effort to drive a standardized methodology across multiple groups with multiple leaders and agendas. The success of that approach is limited and rare in my experience because leaders frequently change, and the process takes a step backward with each turnover.
The practice of beginning one’s career at the downstream end of a total-business process and graduating to upstream roles with time an experience is good, but it too has limits to it’s success potential. Even engineers are known to turn over and change with greater frequency than our graduation plans can tolerate.
The most effective way to establish accountability is to, as my friend James says, eat the bread we make. We must live with our decisions and designs. One only needs to make one poor design decision and be forced to address the consequences thereafter to become very conscientious about future decisions.
Unfortunately, demanding that personnel maintain their processes, product designs, or supply and sales relationships long-term also has challenges and drawbacks. It can be difficult to assign or enable a team member to a new project when he or she is overwhelmed with nursing and maintaining old ones.
In the end, we must make a decision. What are we most willing to put up with? Are we willing to taste the sour discomfort of passing problems from one group to another to deal with, or do we prefer to grind the meal of difficult resource management challenges in order to maximize accountability?
Whatever we decide, we should undoubtedly make our best effort to let each person taste the outcome of his or her work. To that end, what does your work taste like?
Stay wise, friends.
If you like what you just read, find more of Alan’s thoughts at www.bizwizwithin.com