Breaking Iron Triangle Thinking: A New Approach to Agile vs. Continuous Testing



When I used to work as a project management consultant, I would hear brilliant leaders around me say: “Speed, quality, cost. Pick two.” In other words: if you want a higher quality product, you have to sacrifice speed, cost, or both. And everyone would nod along: this was true, and it was obvious. In this frustratingly pervasive “iron triangle” decision-making philosophy, true improvement is not possible—only trade-offs are possible. We are doomed to do only as well as we are doing now; our only options are to choose which priorities will be sacrificed to others. 

Because the leaders I met believed this model, they missed opportunities to actually improve their project—for example, to find cost improvements without negatively impacting quality or timeline. They never put in the effort to find these opportunities because they implicitly believed these opportunities didn’t exist. I have learned over my career that our implicit, unchallenged beliefs about the world have a powerful impact on the choices we make, for good or ill. 





In software development, people may not talk about the project management triangle, but this same trade-off-only mindset—an implicit belief in this Iron Triangle—still exists. Iron Triangle thinking means that engineers often feel stuck between prioritizing quality of code, speed (time to market), and cost. Of course we will always have choices that we can make between speed, quality, and cost. But the fallacy of Iron Triangle thinking is believing that the parameters of these choices are fixed. When we believe that improving speed means necessarily sacrificing quality, cost, or both, we limit our potential for innovation. 

The pervasiveness of Iron Triangle thinking means that many engineering leaders see only a hard trade-off between the cost and speed benefits of continuous development, and the quality benefits of deploying slower and testing more. They believe these competing demands are irreconcilable. As a result, many development teams who want to improve cost and speed are hesitant to make the move toward continuous development because they’re afraid of impacting code quality. They feel forced to choose between developing in two-week sprints—with a massive test suite that is expensive and slow, but assures quality at the end of the sprint—and moving to a Continuous Integration/Continuous Delivery (CI/CD) mode that is faster and cheaper, but sacrifices quality with less testing. 



In traditional end-to-end (E2E) testing processes, there is no pressure not to add tests because you want a minimal chance that any bugs will make it to production. Typically, in the sprint-based (“agile”) development approach, quality is optimized at the price of cost and speed.

Most leaders are accustomed to running E2E testing at the end of a sprint, so the test suite can run as long as it needs to. Once E2E test suites grow to a certain size, you have to run them less frequently, as they can take several hours and simply can’t be run every time developers check in code. This means that there’s a feedback lag: developers discover bugs in their code days or weeks after they’re written. At that point, it’s impossible to pinpoint which deployment even caused the bug, so you can’t toss the buggy code back to the developer who wrote it. Often, leaders assign these bugs to more junior developers who are forced to mine the code to understand the intent of the original developer. In all, these bugs require a bunch of time and resources to fix.



In a CI/CD environment, a team supports continuous development with continuous testing: every deployment is tested individually before it is staged or shipped to production. With fewer tests, the test suite runs in a matter of minutes, feedback lag is minimal, and buggy code returns directly to the engineer who wrote it. With this approach, developers are more fresh on what they just wrote so that when bugs do get caught, they’re able to pinpoint exactly where the problem is and resolve it in minutes, rather than hours or days. Developers kick out code and move on, producing more code in the same amount of time. Thus, with the continuous approach, the KPIs that the engineering leader maximize are developer velocity (faster deployments) and cost (fewer tests to maintain). 

The drawback to having fewer tests, of course, is that you’re ensuring less quality before your code goes out the door. Fewer tests simply means fewer opportunities to catch bugs before they hit production. A purely continuous testing suite sacrifices quality in favor of speed. 



As engineering leaders, as long as we continue to subscribe to Iron Triangle thinking, we will never be provoked to ask ourselves if we can actually improve a process without making a trade-off. When we break Iron Triangle thinking, we can find a third way: an option that is not some form of compromise between competing priorities. We can find paths that give us the best of everything. In software development, choosing a third way means believing that it is simply not the case that every improvement in either speed, cost, or quality must necessarily come at the expense of the other two. Breaking Iron Triangle thinking requires that we do the harder thing and choose a smarter, more strategic approach to deployment design. 

One such way to break the Iron Triangle is to simply choose the best parts of testing from both agile development and continuous deployment. What gets us both the speed of the continuous environment and the quality of the agile environment? One possible design change to your deployment structure is to implement continuous testing early in your SDLC with the quality benefits of the end-of-sprint testing that occurs in agile development practice. 

In this structure, you preserve the benefits of continuous development: your developers can still contribute small chunks of code and run tests continuously for rapid feedback. In addition, you can run a larger test suite in a staging environment against a number of builds to catch bugs that the continuous test suite missed. This approach means many of your bugs—and if your continuous test suite is well-targeted, your priority 1 bugs—are caught sooner and fixed faster. Anything missed here is caught by the larger test suite later. This way, your developers get the speed advantage of continuously developing and testing, and your application gets the quality benefit of running a larger test suite—all without costs beyond maintaining the larger suite that would’ve been written for an agile team anyway. 



How do we manage both agile and continuous test suites? At ProdPerfect, our team uses data to maintain a continuous test suite focused on our customers’ most commonly-used features, while they manage their own larger test suite. Whatever your prioritization mechanism is, you can start the process by building your total regression test suite and tagging your top priority tests. Then, you can configure your CI to continuously run only the tests that are tagged as priority, and run the whole kit daily (or at whatever frequency works for you) on your staging environment. Compared to the “agile” testing approach we explored, this new approach to deployment design improves speed and cost with no negative impact on quality. Compared to pure continuous testing, this approach improves quality with zero to minimal impact on speed and a positive impact on cost (you’re catching more bugs before production). Instead of choosing one approach and sacrificing the other, you are implementing both intelligently and improving multiple parts of your project triangle without negatively impacting the others. You’ve broken the Iron Triangle and get the best of all worlds.

As engineering leaders and teams, you can break the Iron Triangle of project management by structuring your improvement cycle not around trade-offs, but on continuous improvement. A great engineering leader will use the momentum and mindset shift gained from their first Triangle-breaking win to push their team to challenge the assumptions that have held them back from improving all parts of their engineering practice. 

Beyond Whack-A-Mole: Shifting From a Reactive to Proactive E2E Testing Strategy

Of all of the classic arcade games, Whack-A-Mole just might be the most frustrating. You can’t win the game of Whack-A-Mole. Every time you think you’ve hit the mole, the little scoundrel always finds a way to pop up again somewhere else, and you’re always one step behind. 

In the world of end-to-end (E2E) testing, we can get stuck playing Whack-A-Mole when we reactively write tests to bugs that pop up in production in order to prevent them from appearing again. I like to call this practice Whack-A-Mole testing because it’s a common approach, yet can easily become an endless cycle in which testers are always one step behind. As leaders in our organizations, we must instead figure out how to be one step ahead, committing to developing more courageous, forward-thinking E2E testing strategies.


Quality Assurance (QA) teams live in an unenviable world: their work is largely unnoticed until something goes wrong. They’re then faced with explaining their decision not to test something, especially if the results cost the organization money. We’ve heard so many times, “Why didn’t this get tested?” Whatever the reason for the revenue-impacting bug, if QA “fails” to assure quality, they can be chastised by other leaders in the company. QA leaders and engineers are thus under immense pressure to prevent mistakes and ensure the same bugs don’t pop up in production more than once.

Prior to co-founding ProdPerfect, I used to do some consulting work with factories. Operations such as oil refineries are able to clearly track metrics related directly to revenue and cost, and can thus fairly easily make decisions related to return on investment (ROI). In a refinery, you can easily measure how many barrels of oil were produced each day, and thus prioritize what investments to make to increase this daily number. Many factories lose sight of the ROI on their actions and become reactive to the most recent problem that occurred in the plant. But when they do make the commitment to prioritize their work on high-ROI improvements, it’s fairly easy to measure the results. 

When you measure performance of software QA within an organization, you can’t measure six man-hours of code in barrels. Test code isn’t uniformly valuable, and each update doesn’t have an equal impact (good or bad) on the business. Because of this variance, it can be hard to resolve multiple competing priorities: How do we deliver value and quality without sacrificing speed? The lack of clarity in measuring speed, value, and quality prevents engineers from having clear ROI agreement and unified productivity KPIs.

Despite the challenging and often organizationally unclear work of measuring performance in engineering, the pressure to perform still exists for engineers. And since QA teams often feel the brunt of this pressure, QA leaders are often forced into operating from a reactive stance in their E2E testing strategy. In other words, due to a lack of clear prioritization metrics, many teams resort to playing Whack-A-Mole with their testing to appease the organization at large. Sticking to high-ROI initiatives in testing is difficult, but just as important as in a refinery.


To challenge this practice, we as leaders first need to ask ourselves: Does a bug slipping through in one part of an application increase the likelihood that it’s going to happen again in the same place more than anywhere else? I like to think of the comparable, yet common fallacy in gambling: If you pull the slot machine six times and didn’t get jackpot, does this mean the next time you pull it, there’s a higher likelihood of hitting jackpot? Though our guts may tell us otherwise, the answer to both questions is ultimately no.

The fallacy of Whack-A-Mole testing is assuming that if we create another test where we previously saw a bug, then we’re more secure than if we wrote that test elsewhere. It’s simply not the case that because a bug happened in a certain area, then it follows that there’s an increased likelihood that the bug will happen in that area again. Whack-A-Mole testing is NOT a proactive testing strategy: a Whack-A-Mole test doesn’t add a test to the area of the application with the greatest need for tests. Instead, it is a passive strategy: we’re testing an area as a reaction to seeing a bug there. The fact that a bug came up last week shouldn’t change our organizational focus on writing tests for high-priority areas: areas that are more likely to produce bugs, that are important for customer use, or that directly impact revenue.


Whack-A-Mole testing hurts engineering organizations for several reasons:

  1. It distracts us from writing well-prioritized tests. Before any bug shows up in production, a QA team has developed a strategy for what to test, based on a certain mechanism of prioritization. When we write Whack-A-Mole tests, we’re pivoting our test-writing resources away from whatever prioritization mechanism we otherwise had and towards the Whack-A-Mole test. As a result, we delay writing future high-priority tests.
  2. It adds maintenance burden to your team. Whack-A-Mole testing decreases your team’s capacity to write future high-priority tests. Every time you write an E2E test, you’re committing to maintain that test. This creates a fixed, unavoidable ongoing level of work that decreases your capacity to write more tests with the same number of engineers. Most teams I’ve seen attempt to make up for this by simply hiring more.  
  3. It slows down developer productivity and velocity. In a continuous delivery process, each new E2E test adds to the test suite run-time, which lengthens your regression cycle. If your test suite takes half an hour to run and you’re running with each commit, this means either that 1) your developers aren’t producing anything during that time or 2) your developers are checking in code less often because they don’t want to wait for the tests to run (or both). In both cases, you lose developer productivity and provide less-frequent quality feedback for each build, meaning each incremental Whack-a-Mole test costs developer velocity. 
  4. It bloats your test suite and increases instability. At some point, your test suite will have grown large enough that there’s a high probability that it will fail on a given run due to instability. Once instability reaches a certain critical mass, the test suite fails so frequently that developers stop paying attention. When that happens, it starts providing negative value: adding deployment runtime without contributing to quality. 


How do we reverse the damage of Whack-A-Mole testing? First, our organizations need to re-examine our testing choices through a blank-slate exercise. We must ask ourselves: If we were to build this strategy from the ground up once again, what would be our testing priorities? What would we test to balance test coverage with speed, maintenance burden, and stability? Once we’ve defined what’s ideal for us to test, we need to then overlay that outlook on what’s currently being tested as is. And here’s the hard part: we need to have the courage to shut down tests that don’t align with this strategy. And we need to move on.

One helpful aid in this process is to evaluate tests that have been in the suite for 6 months or longer and review: Have they caught any bugs in the last 6 months? If they haven’t, your team should strongly consider retiring them, as they’re likely not worth prioritizing. Unless you’re committed to testing every possible permutation of behavior, it’s essential to re-prioritize. What we learn by doing this exercise is that most Whack-A-Mole tests never actually catch a bug. Whack-A-Mole tests may give us short-term comfort in the face of organizational political pressure. But when we let the data speak instead of human impulse, we see that the vast majority of the time, writing Whack-A-Mole tests provides little to no real business value. It’s when we stare this harsh reality in the face that we find the courage that we need to reprioritize our test suites, drastically reducing the number of unnecessary tests.

Ultimately, developing a new testing strategy from the ground-up that highlights your most important priorities will free up your developers and QA resources to properly cover what’s truly important to your business. The benefit is three-fold: 1) better quality, 2) better speed and cost, and 3) higher trust from your developers in the test suite.


Many QA teams resort to Whack-A-Mole testing because they’re under pressure to respond to quality problems in prod.  A better QA practice is only possible when all leaders across our organizations share and fulfill the commitment to stick to the team’s QA strategy, rather than muck with it every time something seems to go wrong.

First, it’s crucial for engineering and product leaders to recognize alongside QA leaders that Whack-A-Mole testing does not necessarily improve quality assurance. We must understand that a bug appearing in a certain place shouldn’t necessarily change priorities for what to test moving forward. Our leaders must keep their commitment to a well-defined trade-off mechanism between speed, productivity, and QA. Each organization’s trade-off will be different and change over time, but it needs to be sacred at any given time. When we see a bug in our code, we need to commit to asking: “Do we need to rethink our strategy, or possibly rethink our trade-off point? Are we prioritizing the right way? Are we making the right commitment to what an acceptable level of testing looks like? How might our testing approach be unduly burdening our team?” This discipline helps us resist the knee-jerk reaction to build a new Whack-a-Mole test.

At ProdPerfect, our commitment to each other is that we will not be reactive in determining QA priorities. We invite you to join us in this commitment: We will not act upon knee-jerk reactions to immediately build tests for every bug. Rather, we will learn from bugs. We will evaluate them over a period of time by overseeing where bugs are slipping out and what damage they’re producing. Then, we’ll make data-driven decisions to inform our testing strategy. We’ll collectively own the consequences and costs of making changes to our testing strategy. But we will not knee-jerk respond by playing Whack-A-Mole with our testing approach.

Making this commitment requires organizational discipline and courageous leadership from all. All our leaders must agree to see quality assurance as a partnership in which organizations need to effectively balance their testing priorities and determine the best level of coverage for the business. Each of us has something to benefit in making such a commitment, and I invite you to share in this commitment with me. Instead of burdening our processes and teams with reactive Whack-A-Mole testing, let’s care for them well by thinking proactively and letting data alone drive our testing strategy.

Power and Liberation in Humility

Humility is the absence of ego.

Humility is not modesty. It is not an act, it is not an etiquette by which you under-sell yourself in order to secretly impress others with how “humble” you are. Attempting to show others how modest you are is an act of your ego, and it is not humility. I have never been modest, and I do not plan to become modest. I seek instead to become free of ego. I have in the past been tortured and consumed by ego; I have hurt others and failed them by believing and acting upon the stories my ego tells. I have had painful failures that were just jarring enough to force me to consider whether I needed my ego to succeed, or whether it was actually holding me back. In my current business, I attempt to role model humility—an absence of ego—sometimes failing and sometimes succeeding. 

What is Ego?

What, then, is ego? Ego is simply the part of you that believes a falsehood that you will find fulfillment in getting what your mind thinks it wants. Your mind thinks it wants power, recognition, money, pleasure. The ego shares pictures of you and a curated life on social media, thinking that evoking envy or awe in others will make you happy. It seeks a job title and social status, thinking that by having others think you are better than they are, you will be happy. It seeks to impose your beliefs on others, thinking that by showing others that you are right and they are wrong, you will be better than them, and you will be happy. It seeks to put down or seek revenge on others that slight you, thinking that if you diminish them, you will be happy (and it lies to you, telling you this is “justice”). It seeks titles and honors bestowed upon it by others, because if you have those titles, others will think you are better than they are, and being better than others will make you happy. It seeks to have what others cannot afford, because if you can have something that others cannot, you will be better than them and therefore be happy. It seeks to insist that others put your name—a fleeting pair words—onto what you do so that you can feel important, thinking that feeling important will make you happy.

However, rich people do not tend to be happier than middle-class people. Powerful people are not more comfortable and fulfilled than individual contributors in society, and they have insecurities about all of the other people they worry are more powerful than they are. Famous people are unusually likely to get divorced, require drug rehabilitation, and commit suicide. Those considered beautiful are more likely to have body issues, even as others celebrate their beauty. Why are all these seeming contradictions observably true? It is because getting what you think you want does not make you happy. Getting what you think you want can give you temporary pleasure, but that pleasure will fade. Let us differentiate what we think we want from what we need. Maslow’s hierarchy of needs sums it well: we need food and shelter, safety, human connection and love (which do not come through impressing others), self-esteem (which also does not come through impressing others), and finally self-actualization (which does not come from believing we are better than others). The ego does not pursue needs, it pursues what it thinks it wants. 

The ego, therefore, is somewhere between slightly and destructively insane. It compels us to seek out things that do not make us or others happier. It is an addictive entity that seeks continual highs in drugs of thought (“I am better than others”) or drugs of pleasure that all fade, returning us to a base state of happiness or lack thereof, seeking more of the drug over and over until we die, or until we stop letting ourselves believe that what the ego thinks it wants will make us happy. If you have your core needs met but still have problems with anger, low self-esteem, anxiety, frustration, excessive pride, drama, conflict, or other avoidable psychological pains, the ego is the cause. You will be free of these when you set it aside.

To set ego aside, you must first admit that you have a problem and wish to be free of it. The problem is not you, it is not your fault—such judging of yourself is an act of the ego—but it is your responsibility to commit to changing. 

What Occurs As Ego is Set Aside?

Humility is the absence of ego. Imagine being free of the seeming-need to impress others, or to be recognized, or to be envied, or to tell yourself that you are better than others. Imagine being free of constant craving or feeling that you need some new toy, piece of clothing, exotic vacation, status symbol, or sexual partner. What could you do if you could feel satisfied with who you are and what you have, as long as what you have meets your real needs? Imagine how powerful you could be if you let go of even a little bit of this cycle of addiction to psychological and experiential self-inflation. Imagine the focus, passion, and quality you could devote to a purpose greater than what your ego thinks it wants. 

It is through humility that you finally become free to meet your ultimate need: self-actualization. Through humility, you can ask, with a clear mind, “what does the world require of me?” And quietly let the world and your heart provide you an answer that is not clouded by what your mind thinks it wants. If you start a business, it will not be in order to see yourself as someone’s boss, see yourself as a successful person, buy a boat, or be pictured in the media so everyone can know how “great” you are: you will start a business to go build something that the world and your heart are telling you the world needs. If you join politics, you will not join it to have power over others, to be lauded as a hero, to be added to the annals of history, or to spread your ideology: you will join politics to help your city or nation or world become a place where more people are free and enabled to meet their own needs. If you enter a romantic relationship, it will not be to use another person to make you feel better about yourself or to give you pleasure: you will enter a romantic relationship to give both you and that person human connection, love, and attention that does not keep score or seek any payment in return. 

Humility at Work

Imagine if you go into work every day with a humble heart. Instead of obsessing over, “is someone else taking too much vacation and not pulling their weight?” or asking, “how can I extract the most economic return from this organization through the least amount of effort?” or saying, “if people don’t listen to my ideas or do what I tell them, they are bad and must be put in line,” you will instead go to work every day asking, “how can I use this opportunity at work today to use my unique gifts and talents to make the organization and the industry and the world better, and to help and inspire others to move closer to self-actualization with me?” When there are setbacks, you will not rage, or seek blame, or fall into despair because the setback diminishes the fragile ego: you will ask, “what is the action this situation requires of me now?” In moments of triumph, you will recognize your contribution to the success, and you excitedly celebrate the contributions of others as well: their success does not diminish yours, because your ego is not convincing you to play a game of “who is best?” You recognize that their success is your success and the world’s success, and that by succeeding together you have done more than you could do apart. 

And if you find that you are in an organization that discourages or blocks you from using your gifts to improve it and the world, then you will not complain. You will not say, “it’s not fair!” You will ask, “what does the world need of me at this moment?” And you will either attempt to make the best of the situation that you can, change the organization from within, or move to one that will help and enhance your mission.

Humility is also the greatest catalyst to learning, something critical for every successful career or business. When our ego is involved, feedback (regardless of its form) feels threatening. We dread feedback because it is a reminder that we are not omnipotent and omniscient. It reminds us that we have limitations, that we can’t do everything on our own, and that we need one another to truly succeed.  Avoiding feedback means that, we resist the opportunity to learn and grow. When we discount feedback, we justify and rationalize our previous actions, presume that the person giving us feedback must be wrong, and choose instead to reject a learning opportunity. But if we lay our egos aside, we are able to recognize that feedback does not threaten us as individuals, but only helps us to grow and enhance our gifts and strengths. If we practice humility, we will be eager to receive feedback, eager to find opportunities to improve, and eager to seek out the people and information that can teach us most. Imagine what power you will have when you have taken away one of the greatest barriers to learning.

Those who have cultivated some humility are less attached to ideas or beliefs. They recognize that they have in the past changed their minds in light of new information, and that far from being a bad thing, it is a wonderful thing: they have not gotten their ego tied up in “being right.” They know that, having changed their minds before, they might change their minds again. This allows them to be more curious and recognize that what they think is true may not be reality. This makes them more able to objectively process new information and incorporate it.

A humble person can learn even from those who give feedback in an unpleasant or harsh way (such as, “you are an idiot”); you will ask, “what was the thing I did that contributed to them reacting in this way?” We do not need to accept fault, feel shame, or internalize negative labels others may impose: these are all games of the ego. In practicing humility, we are free to simply consider the facts, observe and understand what has happened, and archive this datapoint for future interactions.

Humility is the absence of ego, and humility is the path to being liberated from the never-ending cycle of drama and addiction to recognition, “being right,” pleasure, status symbols, and the like. Imagine being free of the terrible burden of constantly chasing after an ever-changing “bar” or goal after which you give yourself permission to have happiness and self-love and peace. Imagine being free of constantly trying to prove to others that you are good enough or better than, in order to feed your ego’s need for external validation. Imagine the liberation that comes when you realize and accept that after all of the accolades, the credit, the standing ovations, the money, the arguments you “won,” the fancy clothes and cars, the news articles, the romantic partners, and the social media likes, you are no happier than you were before. That nothing about you has actually changed. When you realize and accept that none of it really helps you, you stop believing your addictive ego when it tells you that you need it all so badly, just one more time, and then you will finally be okay. You realize that you’re okay now. That you’re not intrinsically more or less worthy or worthwhile than anyone else, and nothing you or anyone can do or say to change that. In that realization, you let go of all of these false promises, and you let go of your ego just a bit more.

Humility is the path by which you may seek self-actualization, as by putting aside the obsession with all of the petty things you think you want, you are left with only one question at every moment and forever: “what does this situation and the world require of me right now?” Or, stated differently, “what can I do at this moment to share my greatest gifts with the world?”

Humility is the path to unlocking our greatest power: through humility, we stop worrying about who is best at what, and we can objectively consider our strengths and gifts, as well as others’, in service to the greater need we have chosen together to fulfill. In this way, we can align our strengths and others’ to whatever the moment does require of us. We quit the games of “who gets credit,” and spend less time wondering how big our bank accounts will become, or when we’ll be featured on Forbes, or whether we’ll be envied or awed or remembered for what we do, and much more time and energy thinking of the impact of our actions on our own needs, the needs of others, and the needs of the moment, the person, the business, the industry, the world. 

And indeed, are not the people living in such a way happier than those that are chasing scraps of pleasure and ego satisfaction?

How Can I Cultivate Humility?

Any leader seeking the power of humility in their organization must absolutely cultivate humility in themselves first: it will never take root if we leaders do not first learn to model it. If this is not yet a regular practice, it will initially feel painful. In order to find the power and liberation that comes from humility, we must commit to feeling the pain that comes from seeing how our egos have hurt ourselves and others in the past. We will need to confront and question how we have used our time and energy previously and recognize that much of it was not truly in pursuit of what we or the world actually need. We may need to seek feedback about our mindset and behavior from others around us, and that feedback will likely feel threatening to the ego. We will need to accept that feedback—though not necessarily always correct, is usually valid and helpful. We will need to, repeatedly, feel the defensiveness and resistance of our egos well up in us, and the carving of new patterns will cause psychological pain. 

I cannot pretend to have a clear answer for any individual person about how to cultivate humility, and I will not pretend that I am fully free of my own ego, but I can share a bit of my story. I believe that very public failure and the pain of my reaction to it, as well as very direct feedback from some wise mentors, were catalysts for investing the time and energy to begin learning about ego and humility. This might be called “The Way of the Cross,” and I certainly hope others can take alternative paths to making the choice to understand ego and humility. 

When I had made that choice, my understanding of both ego and humility came from a whole lot of reading. Not everyone has time for a lot of reading. I rely on audiobooks when doing laundry, cooking, driving, taking a train, and the like. If the reading resonates with you, then you will over time begin to seek out experiences and people that help you to recognize your ego and, action by action, moment by moment, recognize when it is creeping up. 

You can begin to ask yourself questions. When you want to get in an argument, you can ask, “how does this really help me?” When you crave recognition or credit, or a status symbol, or a public display of showing you are better than others, you can ask again, “how does this really help me?” Your ego will try very hard to give you an answer. If you are on the fence when that answer comes, ask again: “but why do I need that?” And if the craving is from the ego, it will run out of answers. You will find, in that moment, you don’t need to act out its addictive compulsions. Every time you see the ego for what it is, and choose not to be part of its games you have struck an incredible victory. You have become a bit more humble, more free, more powerful.

Reading That Has Influenced My Exploration of Ego and Humility, For Those Curious

In no particular order, I fear. These are a motley crew of books and different ones will speak to different people differently. I suggest beginning with the book that speaks to you most when you read the blurb. 

  • Carol Dweck, Mindset
  • Kaley Klemp, Diana Chapman, Jim Detmer, The 15 Commitments of Conscious Leadership
  • The Dalai Lama and Paul Ekman, Emotional Awareness
  • Eckhart Tolle, The Power of Now and A New Earth
  • Seneca, Letters
  • Marcus Aurelius, Meditations
  • Viktor Frankl, Man’s Search for Meaning
  • Martin Seligman, Flourish
  • Michel Eyquem de Montaigne, Essays
  • Aldous Huxley, Island
  • Brene Brown, Braving the Wilderness
  • Sinclair Lewis, Babbit
  • W. Somerset Maugham, The Razor’s Edge
  • The teachings of Jesus of Nazareth in the New Testament (whether or not you are religiously inclined)

Values Spotlight: A Labor of Enthusiasm

“When you arise in the morning, think of what a privilege it is to be alive, to think, to enjoy, to love …” — Marcus Aurelius

“Every morning when I wake up, I experience an exquisite joy —the joy of being Salvador Dalí— and I ask myself in rapture: What wonderful things is this Salvador Dalí going to accomplish today?” — Salvador Dalí

I want to paint my best understanding of enthusiasm by example.

Imagine breaking rocks all day and then throwing them in a hole. This would be a drudging task, because it is not interesting, and it serves no purpose. Imagine instead breaking rocks to something beautiful or useful: a sculpture, a deep well, a home, a place of worship. It is mentally stimulating, it is rewarding, it is engaging, and it delights both because others enjoy it and because it is utilitarian or beautiful for its own sake. When you are done, you can look upon your work with great satisfaction: your work was interesting and engaging, and it served a purpose. Both tasks may use the same hammer and chisel, and both may leave you sweaty and covered in dust. One is done begrudgingly and the other can be done with enthusiasm. The difference is not the form of the labor, but the engagement of the mind and the heart.

When you are breaking rocks, time moves slowly. You are counting the minutes until it is over. When you are sculpting, you forget the world. You forget to eat. You look up to find that the sun is rising, you’ve worked through the night, and your heart breaks because you must move on and do something else. 

Enthusiasm happens at a very precise point in space and time: here and now. When you are doing work for its sake, when you are interested in the work and challenged by it, your mind focuses on where you are, what you are doing. Your purpose is to correctly land each strike of the chisel. When it is done, the next strike is your next purpose. Something beautiful awaits, but you do not pursue it with grim determination or anxiety. You enjoy the work. And from doing this work enthusiastically, you imbue the work and the result with a greater quality than if you did it begrudgingly. 

The greatest misperception, stated explicitly or believed implicity, about work which I have heard is that to bring quality into your work requires you to give up something to your task or to the organization. People believe it costs you something to do quality work that it does not cost you to do mediocre work. But the wonderful secret is that the opposite of this is true: when you find enthusiasm in your work, you produce greater quality in whatever time you put into the task, and also extract greater joy and satisfaction. There is no trade-off involved in doing your work with enthusiasm. Indeed, the privilege of having that enthusiasm is part of what can make life wonderful. 

Finding Enthusiasm Within

Many people believe that they are either lucky enough to have a job which gives them enthusiasm, or they aren’t. They believe that whether they are enthusiastic or miserable at work is outside of their control, and so often they feel resentment, and they come to work begrudgingly in order to pay rent. But as our rock-breaking example illustrates, enthusiasm comes from the mind. Specifically, it comes from being able to tie the work you do to something meaningful: that is, if you know why what you do matters, you are much more able to be enthusiastic and enjoy your work. And you do not need to be a doctor or CEO to make your work meaningful. 

I used to work in milk bottling factories. They were loud and a bit smelly, and almost always were pretty far out in the middle of nowhere. As you might imagine, many of the people who worked in these facilities had worked there for a very long time. What they did was very repetitive: every day, they needed to fill hundreds of thousands of bottles of milk by operating and maintaining filling machines, casers, stackers, palletizers, forklifts, trucks. I had imagined that they were very unlucky to be working there, and that I was very lucky to instead be a consultant jetting about to help them. 

On one project, I met the operator of the bottle-making machine, called a blow-molder. He had been the senior blow-molder operator for 18 years. This guy was a wizard with a machine that was otherwise very finicky and difficult: typically, any time precision heat is involved in a process, you need skill to make it work. But the blow-molder mostly tended to itself, taking in plastic and cranking out bottles. To me, it looked boring. But we were working together because the plant wanted to reduce some of the downtime on the line, and I had gotten to know him over a few weeks.

One day I saw him standing at the blow-molder, arms crossed, smiling. He had just brought it back online after some of the bottles had come out malformed. I said to him: “You look like you’re looking at a painting you just made.”

He put his arms down and looked me in the eye. I could tell his own eyes were getting a bit moist as he told me this story: “Ten years ago, when I was in the grocery store with my wife and my granddaughter, my wife pointed at all the milk on the shelves. And she said to our granddaughter: ‘Honey, did you know your grandpa makes all of this milk that thousands of people drink every day?’ And I’ll never forget the amazement in my granddaughter’s eyes when she said: ‘Wow! That’s amazing!’ And hugged me. And ever since then, I’ve been very proud of what I do.”

I know for a fact that he is happier at work than many people making ten times as much, with much easier and more conventionally “successful” careers. He goes to work every day with enthusiasm for bringing milk to the kitchens of Indiana. 

In these same travels I also got to know some of the people who performed housekeeping at the hotels I would stay at. She was always so chipper and we would chat briefly when we would see each other. She had a similar story: whenever she cleaned a bathroom or made a bed, she knew that every day, dozens of people like me would drag themselves into the hotel after a long flight and a long day at work, exhausted. It was in her hotel rooms that they could let their shoulders relax, and they could leave the day behind them, comfortable and without worry in a soft bed and a warm shower. She knew she was bringing comfort and joy to weary travelers, and that she got a lot more exercise than most desk-jockeys. She loved her job. 

For my part, I loved working in milk plants, too, even though the hours and the travel were pretty exhausting. I was keeping factories afloat, I was fixing problems that got in peoples’ way. I found enthusiasm in being a teenage line cook because I was learning a lifelong skill to make delicious food. I found enthusiasm as a landscaper because I could listen to audiobooks all day and get exercise. When I worked in customer service, I found enthusiasm in brightening people’s days: and I was subsequently far better at accomplishing just that brightening than colleagues who focused on feeling put-upon by customers who complained at them. 

In this way, enthusiasm becomes a self-fulfilling prophecy. When you can articulate why what you are doing is meaningful–for you, for others, for the world–the increased quality you bring to the work improves the result, and yields the meaning you have tied to the work.

So when you show up to work, there’s no reason to not show up. If you’re going to be there, it costs you nothing additional to really be there, and you get so much more out of it.

Enthusiastically Learning and Growing

Enthusiasm, in combination with humility (which we discuss elsewhere), is a key to unlocking learning and growth. Let us consider again a few of the examples above. If you are a line cook, cooking with enthusiasm will provoke you to ask questions of more senior cooks about how to perfect a sandwich. If you are operating a blow-molder, enthusiasm will make you curious about how you can better understand the machine’s current state, and better control it. In an office (as in school), enthusiasm leads to curiosity and hunger to know more about what you are doing. Your mind will be more active and engaged, and you will be more open to seeing lessons that you would otherwise miss if you were shuffling your way through the day. If you work out enthusiastically, that last five minutes of trying to beat your personal record is exciting rather than miserable and tedious, so you will run all the harder with a smile on your face.

The logic of this is straightforward: enthusiasm comes when you see meaning in what you do. If you care about that meaning, whether it is a personal accomplishment, the realization of some external good, or the acquisition of a skill for later use, your mental engagement and thus rate of learning will be much higher. 

Enthusiasm’s Price

At ProdPerfect, enthusiasm is one of our core values, so we ask everyone to find it in themselves and bring it forth into their work and their teams. This request can feel at times a bit trite: who would not want to be enthusiastic about their work? 

While I believe the choice to be enthusiastic is a clear one, it does not mean that enthusiasm does not require giving up something. To be enthusiastic, one needs to give up emotional distance. There are people who are quite happy who see work as a means to an end: their enthusiasm is poured primarily into their families, volunteer work, and/or hobbies. These people have some emotional distance at work: because they are less attached to the meaning which we discussed above, they can more easily muster equanimity when things are not going well. 

If one is very enthusiastic about the outcome of one’s work, it can be devastating when one encounters a major setback. If you are enthusiastically training for a marathon and then shatter your foot, or if you enthusiastically build a tech company and then see a multibillion-dollar juggernaut release a new product line that matches your own, it can feel like your world is falling apart. Imagine the feeling of the sculptor who tips over a statue just a few buffs away from being completed. 

Even in less dramatic circumstances, is it hard to be enthusiastic without becoming attached to the subject of your enthusiasm, and thus to be emotionally ruffled when your work is not going well. Buddhist monks train for years to strike just this balance: if you are familiar with some monks’ intricate sand art, you see this in action. They spend days carefully creating something beautiful–practicing enthusiasm–and then upon completion immediately shake the table of sand, returning the art to the state of chaos from which it came–practicing acceptance and equanimity. For us laypeople, simultaneous enthusiasm and equanimity is difficult to reach. 

We each of us have only so much energy. While enthusiasm in work does not require extra time, and it likely gives us more total mental and emotional energy than we would have if we were simply dragging ourselves through the day, it also costs energy, and some days can cost quite a bit. 

Preventing QA Burnout Means Choosing the Right Values

“Transparency, Humility, Enthusiasm, Impact-Orientation, and Ownership. These are very admirable values, but they seem much more about how to live than how to run an organization. And they seem to have very little to do with your product. Why did you pick them?”

An investor recently asked me this question.

At ProdPerfect, we’ve chosen these company values because they fight burnout within our organization, within the QA teams we serve, and in the world around us.

Our Company Mission: Fighting Burnout

We designed our company values explicitly around our core mission of fighting burnout. We want to fight burnout for both our customers and our own team. When organizations neglect these values, eventual burnout becomes inevitable:

  • Without organizational transparency, teams lack understanding of the facts and reasoning behind big decisions, and may not fully trust leadership, creating an atmosphere that breeds anxiety and resentment, contributing to employee burnout.
  • Without humility, employees are likely to spend emotional energy bickering, fighting, and playing politics, leading also to burnout.
  • Without enthusiasm, work becomes a grind or drudgery, and employees spend time at work preferring to be elsewhere, contributing to burnout.
  • Without connecting the impact of their work to the mission of the organization or the welfare of others, individuals default to believing that their role does not have intrinsic value, contributing to burnout.
  • Without clear ownership of KPIs or problems, people easily become confused, problems persist, and frustration arises. When employees don’t feel that their area of ownership is respected, they feel helpless, and they may develop resentment. Each of these experiences contribute to burnout.

We continually strive internally to fight burnout by individually cultivating, and collectively teaching, reinforcing, and celebrating transparency, humility, enthusiasm, impact-orientation, and ownership. Holding to these values makes for a much more delightful, fulfilling, and productive workplace.

But, beyond our internal organization, how does ProdPerfect’s QA automation service fight burnout? How does it help other businesses adopt and reap the benefits of our values?

ProdPerfect QA Automation as Organizational Transformer

When ambitious, forward-thinking organizations partner with us, they are able to break through barriers to excellence that are a direct result of the core dysfunctions of legacy software quality assurance. ProdPerfect helps our clients reach further towards each of these values, decreasing burnout common to the conventional state of a software organization.

Transparency: In conventional QA testing, there is little clarity to the software organization as to which tests have been developed or why. Teams of similar sizes can have a few dozen end-to-end tests or thousands of them. What ultimately drives this? It’s unclear. This creates frustration for the developers whose code is being tested, and a lack of alignment between developers and QA engineers. Cross-silo fighting often results.

With ProdPerfect, data exclusively drives what the machine identifies as important to test. It’s clear that each test case reflects a pattern that users perform frequently, and teams can see exactly how frequently users interact with patterns that do and don’t have test cases in the ProdPerfect suite. Testing decisions become extremely transparent and there is less room for argument.

Humility: In conventional testing, intuition drives the decisions around what to test. The industry has for decades asked QA automation engineers to get in a room with some excel sheets and come up with what’s important to test. Sometimes the product team helps, sometimes developers help, and sometimes product analytics helps. But ultimately these decisions are made by people’s intuitions and they become attached to them. When bugs are missed, egos come out to play. “Why wasn’t this covered?” is the conversation every QA lead dreads, but must frequently face. When this question is asked, people get defensive, justifying their decisions. By its design, this system fails the people involved.

Because ProdPerfect’s test suite is objectively built off of data, there are no egos involved. The tests exist because users told us that these workflows are important to them. If a bug is caught, great. If a bug makes it into production, we can know that the facts told us it wasn’t worth the maintenance resources or test runtime (see: testing pyramid) to build a test for it. No room for ego.

Enthusiasm: Who loves maintaining end-to-end test suites? Who loves chasing down and diagnosing a flaky or unstable test? That’s right, nobody. ProdPerfect means machines take that burden away from humans, and so they can move on to work that deserves more enthusiastic attention.

Impact: Because of the intuitive nature of conventional test case development, it’s impossible to know if the test you’re writing has a large impact, a small impact, or zero impact. You might be writing tests that cover a pattern of behavior that nobody will ever use on your application, and you know that.

ProdPerfect’s data focus means every test is impactful. No longer are engineers spending time writing tests that have little or no value to the software organization. That waste has been removed.

Ownership: Who owns quality? Is it QA, or developers? Is it both? How often do these two departments fight back and forth over who is responsible for which area of quality, and how often do they fight over who has the power to make decisions about quality? When a bug is found in an end-of-sprint regression cycle, who is responsible for hunting it and fixing it? In many organizations, the relationship between software developers and QA engineers is quite toxic, and it’s because their ownership seems to overlap, with neither being clear what they have full ownership of and control over.

With ProdPerfect deployed, we can get part of the way towards clarifying that question. Developers should own their own unit and integration tests over the parts of the application they write. ProdPerfect will own testing the application as a whole: with each build, developers will get objective feedback about whether they broke the application. If they did, they own fixing their code, and have the power, tools, and context to do so. QA can continue supporting in many other realms: from other forms of testing to serving as analysts and advisers to developers to help them write quality code from square one.

Ultimately, software development and QA testers or engineers are set up for a frustrating relationship in the old model. Most experienced engineering leaders reading this will recognize elements of the above from their past, and most are likely familiar with toxic or dysfunctional developer/QA relations. By breaking that wheel of ineffective, unclear, intuition-based testing and mutual antipathy between these two groups, we enable a transformation towards a much healthier, more productive, and less burnt-out organization.

We exist as an organization because we wanted to bring something into the world that would help us and others further what we find most important. With our team, our investors, and our partners, we will strive to help all of us to avoid burnout, and thereby to thrive.