Bridging the Value Gap
Introduction
Hello, my name is Volodymyr Hirnyj and I started Q Harmonics as a medium through which I may direct my creative desires in technology. My mother would tell you that I have been fascinated with how things work ever since I was a baby – I had a steam train toy and she is always delighted to tell people how much I loved taking it apart and putting it back together. Eventually this interest in how things work transformed into a desire to make them work, which is how I ended up with two degrees in electrical engineering, an old motorcycle that I restored, and a workbench that I hope will one day earn me some kind of cool mad scientist nickname.
Over time I noticed the engineers and creators I most respected and admired had something in common: a consuming desire to create with the highest degree of quality. The influence quality had over me continued to get stronger over time as I rode the waves of support engineering. In a customer-facing manufacturing environment I was tasked with fighting fires that sometimes were the result of low quality work. Being witness to the customer’s reaction to these problems as well as the downstream business failures were poignant experiences and tremendously affected my philosophy of work. The concept of quality has embedded itself in the way that I operate and I become completely gripped by ensuring that the thing I am working is the best it can possibly be.
What is Quality Actually?
As much as I would love to digress into a philosophical discussion about Zen and the Art of Motorcycle Maintenance to answer this question, a pragmatic approach is bound to be more useful. Ultimately, quality is that which contributes to delighting the customer. This could mean B2B, internal customers, and end users – anyone that is on the receiving end of the labor. So this obsession over quality really comes from the desire to delight anyone on the receiving end of the work, and this could be as simple as not receiving a single complaint. We certainly never want to be on the receiving end of bad quality, so why shouldn’t we do our best to minimize those experiences at our own hands?
The case for perfectionism presents a set of challenging problems in the world of specialized labor, particularly for consultants and contractors. Some initial reactions include, “Well yeah, you should always be doing the best possible job!” or, “Who would want to pay extra for the finishing touches on something that already works?” or, “There’s never time for perfection, ship it now!” And they’re all correct – balance between these extremes is the ultimate goal. So we live in a world of values that are constantly at odds with one another due to budgets, schedules, and quality of the final product. If everyone has their way, the job gets done in a minute, for free, and is perfect.
The Real World
This Venn diagram maps the value conflicts – being a perfectionist I desire to spend all my time in the “good” zone. If I were to impose this zone as a limitation then I would effectively cut off entire market segments which don’t have either large budgets or relaxed schedules (such as early-stage start-ups). But if I were to compromise on the value of quality, then I could find myself in a situation where I am required to solve problems without any budget for tools or parts, stress is prevalent due to schedule woes, and (worst of all) the integrity of my work is compromised and could result in disaster. Even if a team of people share a common vision to bring something into the world that can revolutionize an industry, these conflicting values, unless managed properly, can prove fatal to the whole effort.
Before discussing some practical strategies of how these values might be reconciled, let’s define the requisite axioms. First, the responsibility of bridging this gap lies both with the business leaders, from PM to CEO, and the engineers (I use the word engineer but this applies to any specialized labor, consultants and employees alike). Second, these strategies are meant to pull us towards the “center” without ever leaving the “good” zone, implying minimum standard of quality. Without these axioms, the conversation is not possible.
The conversation is also not possible if engineers and managers aren’t speaking the same language. A common source of friction is managers and engineers talking past one another because one doesn’t understand the technical implications of their business decisions, while the other doesn’t understand the business implications of their technical decisions. This subject is a deep one on its own but a single point can be addressed without diving too deep. If an engineer needs to make a case for quality, they can much more effectively make this case if they can translate it to dollars, or some other form of data such as sales, warranty claims, bug reports, one-star reviews, failure rates, returns, etc. This is the type of language business leaders use to make decisions – we can more effectively bridge the value gap by also bridging the communication gap.
A note of warning before we proceed into strategies: If your default modus operandi is speed and cost with a loose quality standard, you might be in the low quality zone without realizing it. Honestly evaluate your business and check your confirmation bias. While there’s nothing inherently wrong with being in this zone, moving up in quality can help reduce the risk of certain disaster. Consider some case studies such as this one or this one or this one – while these results were catastrophic, most sacrifices of quality end in less severe cases of failed businesses, product flops, dissolved partnerships, and broken promises to customers. Also, no claim is made that quality can guarantee a successful business or product, but lack of it can certainly break it. So let’s examine some strategies that help us get closer to the impossible zone.
Concept Convergence
The strategy of concept convergence is useful for situations where an idea exists without any specific engineering inputs. This typically occurs when non-technical clients are looking for technical labor. They have an idea for a product or business but don’t know how it can be made, or if it can be made at all. The purpose of the concept convergence exercise is to generate practical engineering design inputs. Concept convergence would answer the questions of: How does it work? What does it do? How big is it? What’s it made of? And so on, until a clear and specific set of requirements is generated.
The result of this exercise should be enough information to get an engineering team started. A modern device could require mechanical, software, electrical hardware, and of course product level requirements. Operating without these requirements is guaranteed to generate chaos. Building without any specific declaration of scope of work is sure to generate waste in terms of time and money. So while this activity does require some initial up-front investment, it will absolutely pay dividends over the life of the project by defining the objects of focus for the various teams involved.
Minimum Viable Product
Concept convergence builds a vision of what your product can be and how it can take shape in the world. However, in most cases it’s not practical to start with the best version. You almost certainly won’t get it right on the first attempt anyway. That’s why designs constantly need to be iterated upon. Aside from the technical risks, there also exist financial limits and a focus on getting the product on the market as quickly as possible. So the next most useful exercise is to define the minimum viable product or MVP. This means identifying the core problem solved by the product or its basic purpose and setting that as your target for the first iteration, thus narrowing down the focus of technical efforts further still.
Trap warning – this is a stage where quality can suffer because certain ways of doing things can be considered by some to be above what constitutes “minimum”. It is absolutely critical that the idea of what is minimum applies to the product requirements only, and not how they are executed. These scope limitations serve the purpose of reducing cost and development time by more narrowly focusing efforts on only what matters most, NOT by reducing the quality of those efforts. Remember that we’re still in the “good” zone moving in. So once all these requirements are set in place, the team’s goal should be to build the highest quality version of what constitutes their MVP based on the established design requirements.
Scope Control
From the previous strategies you may have already gathered that there is a meta-strategy of how one might reduce cost and schedule without compromising quality. This meta-strategy is to narrow the scope of work and laser-focus on only the tasks required. Perfectionists can fall victim to being pulled in different directions so it’s important for us to stay in the critical domain of execution. It also seems that leaders are very tempted to ask more of their engineers than what was initially agreed upon. “Just program it” is a very common version of that. So it’s equally as important for both sides to stay within the scope.
Things will always happen along the way: deals fall through, new technology is discovered, and feasibility investigations turn up disappointing results. Ensuring an open channel of communication is critical to dealing with disturbances in the plan. If decisions need to be changed, change them slowly to protect yourself against rampant indecisiveness – a common area of waste is clients changing their mind about what they want and frequently interrupting the focus on executing, or simply re-hashing already made decisions only to reach the same conclusions as before. So what is a practical method of keeping the scope under control and managing everyone’s expectations?
Status Reports
Ah yes, the tedious extra work that we all dread. However, we can apply the Pareto principle to this in order to maximize the effects and minimize the agony. Granted, the format of these open dialogues will vary from place to place. I personally prefer a single page report, but they could be emails or even meetings. What is important is that progress is documented along the way. Generally speaking, they need to summarize a few critical components of the state of the project on a regular basis:
- What has been completed
- What are the next tasks
- What are the current impediments and risks
- What is the current state of the budget
- What is the current state of expected deadlines
- A brief commentary on any attention items
This exercise benefits both engineers and leaders. To leaders it communicates very clearly exactly what is being worked on, thus giving an opportunity to ask questions about scope. It warns of upcoming obstacles to minimize impacts to schedule. And it also helps non-technical people get some visibility on progress that doesn’t have any tangible results – a common issue in the coding world. To engineers (and this surprised me) it helps maintain focus. If you were required to summarize your work, you are put in a position to justify how what you’re doing is valuable. It also forces you to consider the future which opens the door to planning next tasks, thus reducing idle time or even preventing unnecessary work before it happens.
Time Estimates
Another dreadful task. If you estimate too low, you set unreachable expectations. If you estimate too high, you won’t win the work in the first place. Unfortunately for everyone involved, we do have to take our best guess at how long things take to accomplish. Constantly revising and updating schedules is critical to an ongoing management of expectations. We do tend to get better at this over time, but are there any effective techniques that can be used to improve our accuracy before we have decades of experience doing only a few things?
First, break the task down into the smallest manageable pieces and then estimate those pieces individually. You might surprise yourself at how quickly those add up. A common error is to estimate the whole effort at once without looking into the individual slices. Large scale estimates tend to be very optimistic, so it pays to spend some time planning to a certain level of detail. Second, don’t forget to consider all the possible challenges along the way. We tend to estimate how long things take if conditions were absolutely perfect and that’s simply never the case. Our work and attention don’t exist in a vacuum. It’s therefore useful to add a small fudge factor to account for unexpected interruptions, perhaps 20%. If that seems like a lot, consider that it’s only 12 minutes of every hour.
Summary
The strategies here aren’t exhaustive, and entire chapters can be written to further refine only the ones listed here. The purpose of this summary was to present some useful concepts that have helped me bridge the gap as well as retroactively analyze outcomes that could have been improved. While living in the high quality zone is where I operate best, my overall value proposition can be improved by recognizing the real-world limitations.
- Concept Convergence – produce engineering inputs to define scope
- Minimum Viable Product – distill scope to the basic problem or purpose
- Scope Control – maintain an ongoing dialogue of the vision and goals
- Status Reports – communicate the details of what is being worked on
- Time Estimates – be realistic and manage expectations on both sides
