In recent days, I’ve been reminded of some core company values, once fresh and different, later taken for granted. It was good to be reminded of them.
I was on a call the other day when a member of the client’s team said, “we don’t prioritize because something is easy, we prioritize something because it is hard.” They went on to acknowledge that some of my colleagues had counseled them to do this some months before I started working with them. I was overjoyed to hear the client say this.
When I first joined ThoughtWorks in 2005, one of our core messages was to solve an “outer quadrant” problem first - something in the problem space that is difficult and complex. Something small and discreet of course, as opposed to trying to boil the ocean, but very much in the category of “hard” than “easy”. This was contradictory to the prevailing wisdom at the time (that persists to this day), which was to lead with quick wins, pilots or proofs of concept.
By and large, none of these latter approaches address the core of the problem that needs to be solved. “Quick wins” attack the margins. They might very well be useful, but quick wins are just as likely to contribute to systemic complexity by layering on new points of integration, adding logic and system redundancies, and creating confusion over veracity of data or transaction success. I once came into contact with a company whose primary engagement pattern was to create duplicative data warehouses by copying data from existing data sources and writing reports off it. They’d done this 6 or 7 times at one company alone. It isn’t difficult to imagine the “single source of truth” problem that arose from timing discrepancies and reliability problems among all of those data warehouses. All those quick wins did was make them more sclerotic.
Pilots and proofs of concept tend to be evaluated in environments heavily favored to the success of the pilot, not in environments representative of the actual problem space that needs to be solved. The result of quick wins and pilots and proofs of concept is a false positive with regard to the affordability and even solve-ability of a particular problem space. You might feel good for having done something, but the something doesn’t make material progress toward addressing the underlying problem.
It seems to me that the “quick win” and “pilot” philosophy became increasingly prominent in American business in the 1980s. In the 1970s, American corporations had earned a reputation for poor quality. They also had become gripped by analysis paralysis fueled by, among other things, a fear of making a mistake. Management consultants like Tom Peters struck a nerve on this conflation of “poor quality” and “doing nothing about it”. In the book “In Search of Excellence” published in 1982, Peters and Robert Waterman listed what they called the “8 characteristics of excellent companies”. Top of the list was “a bias for action:” “a preference for doing something - anything - rather than sending a question through cycles and cycles of analyses and committee reports.” Peters, Waterman and others advocated “a bias for action” to cut the Gordian knot of inaction.
At the same time, Japanese management techniques were in the ascendency. Japan’s economy was booming, in no small part because products made in Japan had earned a reputation for both quality and affordability. American managers wanted to know what their Japanese counterparts did differently. Among the things that came to the surface in what made Japanese management different was to solve small problems and learn before solving a big problem. Whereas an American company would attempt to solve Big Problems with Big Solutions, the Japanese management philosophy attacked Big Problems by solving Small Problems with Small Solutions. In the American company, more often than not the Big Solution yielded a Big Mistake: massive cost overruns, excessive time delays, and all-too-frequently outright failure. In the Japanese company, The Big Problem was resolved over time as a sum of the evolution of Small Solutions.
Iterative solution development resonated with the “bias for action” theme because it provided a means of overcoming the collective learned helplessness among employees of American companies. A systemic problem in an American corporation was larger than any one person or small group of people (or their budgets) within an enterprise could solve, but small problems could be solved through simple, affordable solutions. The emerging personal computer technology of the time enabled this tremendously. The result was a brief management revolution of the 1980s, where pent up frustration among employees of being trapped in oppressive systems that yielded poor quality met up with the evangelical management themes of excellence that stressed “action” and “devolved decision making”, which in turn were operationalized by the liberating personal technologies of the day.
The themes of a “bias for action” and “iterative solutions” and many other things stressed by Peters and others under the aegis of “excellence” live on in many forms today, not least of which are Lean and Agile software development as well as product management practices. All well and good, but somewhere along the way the messages get corrupted. All too often, a “bias for action” prioritizes “quick wins” which are interpreted as “go after the low-hanging fruit” and is applied as “do the easy stuff first.” The easy stuff is almost always at the margins and not the core, and are not representative of the need. Similarly, even the most well-intentioned proof-of-concept misses the mark if it intentionally excludes the challenges central to the problem space.
To hear somebody say “we’re prioritizing the hard stuff first” is rewarding indeed. It’s an indicator that they’re serious about solving the problem at hand.
When I joined ThoughtWorks, one of the things that many of the experienced software developers stressed was mentorship. They would seek out less experienced colleagues who were difficult to staff on a client project and mentor them in everything ranging from technical skills, to the value system for how we worked, to ways in which they could be effective consultants.
Mentoring can be a slow process, the results difficult to measure, it doesn’t scale, and it doesn’t garner a whole lot of attention. Mentoring is not something that comes naturally to a lot of people, and by and large there are more people interested in doing things that are noisy and that scale - go on sales calls, speak at conferences - than in doing the humdrum work of mentoring a person.
Mentoring does more than just help people acquire skills and consulting acumen. It gives new people first hand experience in practicing the values that a company of people holds. This builds muscle memories that become their default way of working. That, in turn, builds the culture of a company, better than any email or podcast or missive ever can.
We had virtual leaving drinks for a long-time colleague particularly adept at doing this kind of mentoring, as he is joining another firm. I will miss him.
