What becoming vegan taught me about software testing

While I’ve been in the software testing industry for twenty years, I’ve only been vegan for a few years. Veganism is a movement around minimizing harm to our fellow human and non-human animals with compassion at its core, and I think of it as being built on three main pillars, viz. ethics, the environment, and health.

I will discuss how being vegan has strong parallels with being a software tester in terms of the three pillars of veganism, the similar challenges involved in changing the mindsets of others – and also the need to frequently justify one’s own beliefs!

Be prepared to learn something about veganism and maybe having some long-held assumptions challenged, but also expect to take away some ideas for changing hearts and minds in your life as a tester.

Ethics

At its heart, veganism is an ethical principle designed to reduce – to the greatest extent possible – the suffering we cause to other human and non-human animals. It is unfortunate that the movement is seen as “radical” or “militant” when it essentially asks nothing more of us than to not cause unnecessary suffering. It feels to me like the animal rights movement is on the rise, just as the human rights movement was through the 1800s and 1900s.

With ethics being at the core of veganism, they also need to be at the core of software testing. Doing the right thing is the right thing to do and our job as testers often involves the relay of bad or unpopular information. As algorithms take over so many decision-making processes in the modern world, our dependency on the developers writing these algorithms to do the right thing only increases. The Volkswagen “dieselgate”[1] scandal is an example of where many people involved with the development of the “defeat devices” (possibly including both software developers and testers) didn’t speak up enough to stop these devices going into the public domain and potentially causing harm to so many people.

Since we have now acknowledged as a society that humans have the right to live a life free from unnecessary suffering and so on, organizations employing testers have an obligation to engage them in intellectually challenging work fit for humans to invest their valuable lives in. Putting intelligent humans into roles where they are expected to mimic the actions of machines (e.g. executing step-by-step detailed test cases) is, to me at least, unethical.

Environment

According to a recent study by the University of Oxford[2], the leading cause of greenhouse gas emissions is the animal agriculture industry, with the bulk of these emissions emanating from factory farms. This significant contribution to one of our planet’s most pressing problems is rarely acknowledged or publicly discussed, especially by governments. Our disregard for the environment is bad for the animals and bad for humans. It’s not too much of a stretch to view factory farming and so-called “factory testing” in similar lights. The mechanistic dogma of factory testing is bad for our business, yet remains for many organizations their default position and unquestioned “best practice” approach to software testing, despite the evidence of its inefficiencies.

The animal agriculture business is also the largest contributor to deforestation, either to create pasture for grazing or to grow soy beans or grain to feed to animals. Animals are very inefficient in their conversion of food and water into the products eaten by humans (in terms of calories and protein[3]), so we could easily enormously reduce the amount of deforestation while at the same time providing more food for humans to eat directly. The dominant ideology around consuming animal products again makes this a conversation rarely heard. We could similarly cut out the inefficiencies in a large proportion of the world’s software testing industry by removing the “middle man” of excessive documentation. I hoped that the rise in popularity of more agile approaches to software development would spell the end of heavyweight “testing processes” in which we spend more time writing about the testing we might do and less time actually interacting with the software to see what it does do and assessing whether that’s what we wanted. The dominant ideology around software testing – very successfully promoted by organizations like the ISTQB – still manages to push challenges to these approaches to the fringes, however, and talks of detractors as radical or even unprofessional.

Health

Credible studies[4] point to the fact that reducing animal products in the human diet (or, better, eliminating them altogether) leads to improved long-term health outcomes. A wholefood plant-based diet appears to be optimal for human health, both in terms of physical and mental wellbeing.

It’s good to see some important aspects of self-care entering the conversation in the IT community, such as practicing mindfulness and getting adequate sleep. The mythology around “all nighters” and hero efforts popularized in the IT community thankfully seems to be unravelling as we realize the importance of physical and mental wellbeing when it comes to our ability to perform well in our work settings. Testers have often borne the brunt of last-minute hero efforts to get releases out and I’m encouraged by the changes I see in our industry to a mindset of the whole development team being responsible for the quality of deliverables, a positive outcome from the move to more agile approaches perhaps.

The same old questions, time and time again

One of the challenges of being vegan is the fact that everyone suddenly becomes an expert on nutrition to explain why it is unhealthy to not consume animal products. The questions are surprisingly similar from many different people and can be seen in the many online materials from vegan bloggers and influencers. The most common question is probably “where do you get your protein?”, reflecting both a modern obsession over protein intake (it’s almost impossible to be protein deficient when consuming an average amount of calories) and also poor nutritional advice from doctors, government bodies, and mainstream media. It’s worth remembering that your typical GP receives only a few hours of nutritional training during their time at medical school, while government policy is heavily influenced by lobbying from big agriculture and mainstream media relies heavily on advertising revenues from the animal agriculture industry. The animals consumed by humans as meat get their protein from eating plants, just like humans can.

Another common question is “What about vitamin B12?” and, yes, most vegans will supplement with (vegan-sourced) B12. What most people don’t realize is that factory farmed animals are supplemented with B12 so vegans are simply cutting out the middle man (or, rather, middle animal). Animals are not some magic B12 producing machine, B12 comes naturally from bacteria in soil and hence the need for supplementation in animals now raised in such unnatural conditions.

The animal agriculture industry relies on this marketing and mythology, as well as the general lack of questioning about what is seen as the norm in consuming animal products. The same applies to the software testing industry where big players and repeated mythology have created such a dominant world view of testing that it goes unquestioned by so many. If you go against the grain in this industry (say, aligning yourself with the context-driven testing “school”, as I have chosen to do), you can expect some of these common questions:

  • How do you measure coverage?
  • How can you test without test cases?
  • What percentage of your testing is automated?
  • Why do you focus so much on semantics (like “testing” and “checking”)?

Software testing is also one of the few specialties I’ve seen in the IT industry in which people outside of the specialty believe and openly express that they know how to do it well, despite having little or no experience of actually performing good testing. The ongoing misapprehension that testing is somehow “easy” or lesser than other software development specialties is something we should all counter whenever we have the opportunity – software testing is a professional, cognitive activity that requires skills including – but not limited to – critical thinking, analysis, attention to detail, and the ability to both focus and defocus. Let’s not devalue ourselves as good testers by not speaking up for our craft! Knowing how to respond well to the common questions is a good place to start.

Hello old friend, confirmation bias!

When it comes to cognitive biases, one of the most common I’ve witnessed is “confirmation bias”, especially when talking about food. Confirmation bias is the tendency to search for, interpret, favour and recall information in a way that confirms your pre-existing beliefs or hypotheses. Talking specifically in the context of the food we eat, everyone is looking for good news about their bad habits so any “research” that suggests eating meat, eggs, dairy products, chocolate, etc. is actually good for you gets big press and plenty of clicks. (One trick is to “follow the money” when it comes to research articles like this, as funding from big agriculture invariably can be found somewhere behind them, in my experience.) It should come as no surprise that the overwhelming scientific evidence to the contrary doesn’t warrant the same attention!

I see the same confirmation bias being displayed by many in the testing community, with big differences of opinion between the so-called “schools of testing”[5] and a lack of willingness to even consider the ideas from one school within the others. Even when credible experience reports[6] have been published around the poor efficacy of a test case-based approach to testing, for example, there is no significant shift away from what I’d call “traditional” approaches to testing in many large organizations and testing outsourcing service providers.

To counter confirmation bias when trying to change the mindset of testers, it’s worth looking at the very different approaches taken by different activists in the vegan movement. I was first introduced to the Socratic Method when I took Michael Bolton’s Rapid Software Testing course back in 2007 and it’s been a powerful tool for fostering critical thinking in my work since then. Many vegan activists also use the Socratic Method to help non-vegans explore their logical inconsistencies, but their approach to using it varies widely. A well-known Australian activist, Joey Carbstrong[7], pulls no punches with his somewhat “in your face” in style, whereas the high-profile UK activist Earthling Ed[8] uses a gentler approach to achieve similar results. These stylistic differences remind me of those I’ve personally experienced by attending Rapid Software Testing delivered by Michael Bolton and, later, with James Bach. I strongly believe in the power of the Socratic Method in terms of fostering critical thinking skills and it’s a powerful approach to use when confronted by those who doubt or disregard your preferred approach to testing based on little but their own confirmation bias.

Time for dessert!

Any belief or action that doesn’t conform to the mainstream narrative or paradigm causes people to become defensive. Just as humans consuming animal products is seen as natural, normal and necessary[9] (when it is demonstrably none of those), a departure from the norms of the well-peddled testing methodologies is likely to result in you being questioned, criticized and feeling the need to justify your own beliefs. I would encourage you to navigate your own path, be well informed and find approaches and techniques that work well in your context, then advocate for your good ideas via respectful dialogue and use of the Socratic Method.

And, yes, even vegans get to eat yummy desserts! I hope you’ve learned a little more about veganism and maybe I’ve helped to dispel a few myths around it – maybe try that vegan option the next time you go out for a meal or check out one of the many vegan activists[7,8,10,11s] spreading the word about veganism.

References

[1] Volkswagen “dieselgate”: https://www.sbs.com.au/news/what-is-the-volkswagen-dieselgate-emissions-scandal

[2] “Reducing food’s environmental impacts through producers and consumers”, Science Volume 360, Issue 6392, 1st June 2018: https://science.sciencemag.org/content/360/6392/987

[3] “Energy and protein feed-to-food conversion efficiencies in the US and potential food security gains from dietary changes” (A Shepon, G Eshel, E Noor and R Milo), Environmental Research Letters Volume 11, Number 10, 4th October 2016: https://iopscience.iop.org/article/10.1088/1748-9326/11/10/105002

[4] Examples from the Physicians Committee for Responsible Medicine (US): https://www.pcrm.org/clinical-research

[5] “Four Schools of Testing” (Bret Pettichord), Workshop on Teaching Software Testing, Florida Tech, February 2003: http://www.testingeducation.org/conference/wtst_pettichord_FSofST2.pdf

[6] “Test Cases Are Not Testing” (James Bach & Aaron Hodder), Testing Trapeze magazine, February 2015: https://www.satisfice.com/download/test-cases-are-not-testing

[7] Joey Carbstrong https://www.youtube.com/channel/UCG6usHVNuRbexyisxE27nDw

[8] Earthling Ed https://www.youtube.com/channel/UCVRrGAcUc7cblUzOhI1KfFg/videos

[9] “Why We Love Dogs, Eat Pigs, and Wear Cows: An Introduction to Carnism” (Melanie Joy): https://www.carnism.org/

[10] That Vegan Couple https://www.youtube.com/channel/UCV8d4At_1yUUgpsnqyDchrw

[11] Mic The Vegan https://www.youtube.com/channel/UCGJq0eQZoFSwgcqgxIE9MHw/videos

Advertisements

Two decades at Quest Software

Today (2nd August 2019) marks twenty years since I first sat down at a desk at Quest Software in Melbourne as a “Senior Tester”.

I’d migrated from the UK just a few weeks earlier and arrived in Australia in the middle of the late 90s tech boom. The local broadsheet newspaper, The Age, had a separate section once a week which was a hefty tome and packed full of IT jobs. I sent my CV to many different recruitment companies advertising in the newspaper and started to get some interest. My scatter gun approach was a response to the lack of opportunities for LISP developers (my previous skill from three years as a developer back in the UK, working on expert systems for IBM) but I did focus a little on openings for technical writers, believing I could string words together pretty well and had a decent grasp of technology.

One of the first interviews I secured for such a technical writing position was for a company I’d never heard of, Quest Software out in the Eastern suburbs of Melbourne (Ashburton, at that time). After some hasty company research, I remember catching a train there and following the recruiter’s directions to “take the staircase next to the bottle shop” to locate the Quest office (actually, one of two offices in the same street due to recent expansion). My interview would be with the head of the technical writing team and we started off with a chat over coffee in the kitchen. I didn’t even realize this was the interview, it was so relaxed and welcoming! At the end of the coffee/interview, he asked whether I’d also like to chat with the head of the testing team as she was looking for people too, so of course I took the opportunity to do so. This was again a very informal chat and I left the office with a technical writing task to complete. After completing the task, I was soon contacted to return to the Quest office to further my application for a software testing position, but not the technical writing one. A test case writing task formed part of this next slightly more formal interview, my first attempt at writing such a document! It was very shortly afterwards that the recruiter let me know I had an offer of a role as a “Senior Tester” and I couldn’t return the required paperwork fast enough – I’d found my first job in Australia!

I considered myself very fortunate to have secured a position so quickly after arriving into Australia. I was certainly lucky to find a great recruiter, Keith Phillips from Natural Solutions, and I recall visiting him in person for the first time after the deal was done with Quest, down at his office in South Melbourne. It turned out we had a common connection to the University of Wales in Aberystwyth, where I studied for both my undergraduate and doctoral degrees. We also studied in the same department (Mathematics) and, although Keith’s studies were some years before mine, many of the same department staff were still around during my time there as well. I believe Keith is still in the recruitment industry and I have fond memories of his kind, professional and unhurried approach to his work, something not common during my experiences with recruiters back then.

Back to 2nd August, 1999, then and my first day at the Quest office in Ashburton. Amidst the dotcom madness, Quest were growing rapidly and I was just one of many new starters coming through the door every week. We were sitting two to a desk for a while until we moved to bigger new digs in Camberwell, about three months after I joined. We grew rapidly and I enjoyed my time as a tester, slotting in well to a couple of different development teams and learning the ropes from other testers in the office. Being new to the testing game, I didn’t realize that we had a very “traditional” approach to testing in Quest at that time – I was part of an independent testing team under a Test Manager and spent a lot of my time writing and executing test cases, and producing lots of documentation (thanks, Rational Unified Process).

I was also learning the ropes of living in a new country and I’m indebted to my colleagues at the time for their patience and help in many aspects of me settling into a Melbourne life!

I worked across a few teams in my role as a “Senior Tester” from 1999 until 2004 when I was promoted to a “Test Team Lead” and given people management responsibility for the first time, leading a small group of testers as well as retaining hands-on testing commitments. I realize now that I was a classic “process cop” and quality gate fanatic, persisting with the very traditional ideas around testing and test management. This was an interesting and challenging time for me and, while I enjoyed some aspects of managing people, it was also not the most enjoyable aspect of my job.

It was during my time as test lead that Quest ran the Rapid Software Testing course in-house with Michael Bolton, in our Ottawa office in 2007. It was a very long way to travel to attend this course, but it was truly career-changing for me and opened my eyes to a new world of what testing was for and how it could be done differently. I returned to work in Melbourne inspired to change the way we thought about testing at Quest and took every chance I could to spread the word about the great new ideas I’d been exposed to. Looking back on it now, I banged this drum pretty hard and was probably quite annoying – but challenging the status quo seemed like the right thing to do.

During a shift to adopting Scrum within some of the Melbourne teams and a move away from the independent test team, I really saw an opportunity to bring in new testing ideas from Rapid Software Testing and so, in 2008, a new position was created to enable me to focus on doing so, viz. “Test Architect”. Evangelizing the new ideas and approaches across the Melbourne teams was the main job here and the removal of people management responsibility gave me a welcome chance to focus on effecting change in our testing approach. I enjoyed this new role very much over the next five years, during which time we moved to Southbank and Quest Software was acquired by Dell to form part of their new Software business.

My role expanded in 2013 to provide test architectural guidance across all of the worldwide Information Management group as “Principal Test Architect”. One of the great benefits of this promotion was the chance to work closely with colleagues in other parts of the world and I became a very regular visitor to our office in China, helping the talented and enthusiastic young testers there. I also started my conference presentation journey in 2014, a massive step outside my comfort zone! While attending a testing peer conference in Sydney in 2013, I was fortunate to meet Rob Sabourin (who was acting as content owner for the event) and he encouraged me to share my story (of implementing session-based exploratory testing with the teams in China) to a much wider audience, leading to my first conference talk at Let’s Test in Sweden the following year. This started a journey of giving conference talks all over the world, another great set of experiences and I appreciate the support I’ve had from Quest along the way in expanding the reach of my messages.

Dell sold off its software business in late 2016 and so I was again working for Quest but this time under its new owners, Francisco Partners.

My last promotion came in 2018, becoming “Director of Software Craft” to work across all of the Information Management business in helping to improve the way we develop, build and test our software. This continues to be both a challenging and rewarding role, in which I’m fortunate to work alongside supportive peers at the Director level as we strive for continuous improvement, not just in the way we test but the way we do software development.

My thanks go to the many great colleagues I’ve shared this journey with, some have gone onto other things, but a surprising number are still here with 20+ years of service. The chance to work with many of my colleagues on the ground across the world has been – and continues to be – a highlight of my job.

I’ve been fortunate to enjoy the support and encouragement of some excellent managers too, allowing me the freedom to grow, contribute to the testing community outside of Quest, and ultimately expand my purview across all of the Information Management business unit in my capacity as Director of Software Craft.

Little did I think on 2nd August 1999 that my first job in Australia would be the only one I’d know some twenty years later, but I consider myself very lucky to have found Quest and I’ve enjoyed learning & growing both personally & professionally alongside the company. My thanks to everyone along the way who’s made this two decade-long journey so memorable!

On AI

I’ve read a number of books on similar topics this year around artificial intelligence, machine learning, algorithms, etc. Coming to this topic with little in the way of prior knowledge, I feel like I’ve learned a great deal.

Our increasing reliance on decisions made my machines instead of humans is having significant – and sometimes truly frightening – consequences. Despite the supposed objectivity of algorithmic decision making, there is plenty of evidence of human biases encoded into these algorithms and the proprietary nature of some of these systems means that many are left powerless in their search for explanations about the decisions made by these algorithms.

Each of these books tackles the subject from a different perspective and I recommend them all:

It feels like “AI in testing” is becoming a thing, with my feeds populated with articles, blog posts and ads about the increasingly large role AI is playing or will play in software testing. It strikes me that we would be wise to learn from the mistakes discussed in these books in terms of trying to fully replace human decision making in testing with those made by machines. The biases encoded into these algorithms should also be acknowledged – it seems likely that confirmatory biases will be present in terms of testing and we neglect the power of human ingenuity and exploration at our peril when it comes to delivering software that both solves problems for and makes sense to (dare I say “delights”) our customers.

“Range: Why Generalists Triumph in a Specialized World” (David Epstein)

I’m a sucker for the airport bookshop and I’ve blogged before on books acquired from these venerable establishments. On a recent trip to the US, a book stood out to me as I browsed, because of its subtitle: “Why generalists triumph in a specialized world”. It immediately triggered memory of the “generalizing specialists” idea that seemed so popular in the agile community maybe ten years ago (but hasn’t been so hot recently, at least not in what I’ve been reading around agile). And so it was that Range: Why Generalists Triumph in a Specialized World by David Epstein accompanied me on my travels, giving me a fascinating read along the way.

David’s opening gambit is a comparison of the journeys of two well-known sportsmen, viz. Roger Federer and Tiger Woods. While Woods was singularly focused on becoming excellent at golf from a very young age, Federer tried many different sports before eventually becoming the best male tennis player the world has ever seen. While Woods went for early specialization, Federer opted for breadth and a range of sports before realizing where he truly wanted to specialize and excel. David notes:

The challenge we all face is how to maintain the benefits of breadth, diverse experience, interdisciplinary thinking, and delayed concentration in a world that increasingly incentivizes, even demands, hyperspecialization. While it is undoubtedly true that there are areas that require individuals with Tiger’s precocity and clarity of purpose, as complexity increases – and technology spins the world into vaster webs of interconnected systems in which each individual sees only a small part – we also need more Rogers: people who start broad and embrace diverse experiences and perspectives while they progress. People with range.

Chapter 1 – “The Cult of the Head Start” – uses the example of chess grand masters, similarly to golf, where early specialization works well. David makes an interesting observation here around AI, a topic which seems to be finding its way into more and more conversations in software testing, and the last line of this quote from this chapter applies well to the very real challenges involved in thinking about AI as a replacement for human testers in my opinion:

The progress of AI in the closed and orderly world of chess, with instant feedback and bottomless data, has been exponential. In the rule-bound but messier world of driving, AI has made tremendous progress, but challenges remain. In a truly open-world problem devoid of rigid rules and reams of perfect historical data, AI has been disastrous. IBM’s Watson destroyed at Jeopardy! and was subsequently pitched as a revolution in cancer care, where it flopped so spectacularly that several AI experts told me they worried its reputation would taint AI research in health-related fields. As one oncologist put it, “The difference between winning at Jeopardy! and curing all cancer is that we know the answer to Jeopardy! questions.” With cancer, we’re still working on posing the right questions in the first place.

In Chapter 2 – “How the Wicked World Was Made” – David shares some interesting stories around IQ testing and notes that:

…society, and particularly higher education, has responded to the broadening of the mind by pushing specialization, rather than focusing early training on conceptual, transferable knowledge.

I see the same pattern in software testing, with people choosing to specialize in one particular automation tool over learning more broadly about good testing, risk analysis, critical thinking and so on, skills that could be applied more generally (and are also less prone to redundancy as technology changes). In closing out the chapter, David makes the following observation which again rings very true in testing:

The more constrained and repetitive a challenge, the more likely it will be automated, while great rewards will accrue to those who can take conceptual knowledge from one problem or domain and apply it in an entirely new one.

A fascinating – and new to me – story about early Venetian music opens Chapter 3 – “When Less of the Same Is More”. In discussing how musicians learn and apply across genres, his conclusion again makes for poignant reading for testers especially those with a desire to become excellent exploratory testers:

[This] is in line with a classic research finding that is not specific to music: breadth of training predicts breadth of transfer. That is, the more contexts in which something is learned, the more the learner creates abstract models, and the less they rely on any particular example. Learners become better at applying their knowledge to a situation they’ve never seen before, which is the essence of creativity.

Chapter 4’s title is a nod to Daniel Kahneman, “Learning, Fast and Slow”, and looks at the difficulty of teaching and training to make it more broadly applicable than the case directly under instruction, using examples from maths students and naval officers:

Knowledge with enduring utility must be very flexible, composed of mental schemes that can be matched to new problems. The virtual naval officers in the air defense simulation and the math students who engaged in interleaved practice were learning to recognize deep structural similarities in types of problems. They could not rely on the same type of problem repeating, so they had to identify underlying conceptual connections in simulated battle threats, or math problems, that had never actually been seen before. They then matched a strategy to each new problem. When a knowledge structure is so flexible that it can be applied effectively even in new domains or extremely novel situations, it is called “far transfer.”

I think we face similar challenges in software testing. We’re usually testing something different from what we’ve tested before, we’re generally not testing the same thing over and over again (hopefully). Thinking about how we’ve faced similar testing challenges in the past and applying appropriate learnings from those to new testing situations is a key skill and helps us to develop our toolbox of ideas, strategies and other tools from which to draw when faced with a new situation. This “range” and ability to make conceptual connections is also very important in performing good risk analysis, another key testing skill.

In Chapter 5 – “Thinking Outside Experience” – David tells the story of Kepler and how he drew new information about astronomy by using analogies from very disparate areas, leading to his invention of astrophysics. He was a fastidious note taker too, just like a good tester:

Before he began his tortuous march of analogies toward reimagining the universe, Kepler had to get very confused on his homework. Unlike Galileo and Isaac Newton, he documented his confusion. “What matters to me,” Kepler wrote, “is not merely to impart to the reader what I have to say, but above all to convey to him the reasons, subterfuges, and lucky hazards which led to my discoveries.”

Chapter 6 – “The Trouble with Too Much Grit” – starts by telling the story of Van Gogh, noting:

It would be easy enough to cherry-pick stories of exceptional late developers overcoming the odds. But they aren’t exceptions by virtue of their late starts, and those late starts did not stack the odds against them. Their late starts were integral to their eventual success.

David also shares a story about a major retention issue experienced by a select part of the US Army, concluding:

In the industrial era, or the “company man era”…”firms were highly specialized,” with employees generally tackling the same suite of challenges repeatedly. Both the culture of the time – pensions were pervasive and job switching might be viewed as disloyal – and specialization were barriers to worker mobility outside of the company. Plus, there was little incentive for companies to recruit from outside when employees regularly faced kind learning environments, the type where repetitive experience alone leads to improvement. By the 1980s, corporate culture was changing. The knowledge economy created “overwhelming demand for…employees with talents for conceptualization and knowledge creation.” Broad conceptual skills now helped in an array of jobs, and suddenly control over career trajectory shifted from the employer, who looked inward at a ladder of opportunity, to the employee, who peered out at a vast web of possibility. In the private sector, an efficient talent market rapidly emerged as workers shuffled around in pursuit of match quality. [the degree of fit between the work someone does and who they are – their abilities and proclivities] While the world changed, the Army stuck with the industrial-era ladder.

In Chapter 7 – “Flirting with Your Possible Selves” – David shares the amazing career story of Frances Hesselbein as an example of changing tack many times rather than choosing an early specialization and sticking with it, and the many successes it can yield along the journey. He cites:

[computational neuroscientist Ogo Ogas] uses the shorthand “standardization covenant” for the cultural notion that it is rational to trade a winding path of self-exploration for a rigid goal with a head start because it ensures stability. “The people we study who are fulfilled do pursue a long-term goal, but they only formulate it after a period of discovery,” he told me. “Obviously, there’s nothing wrong with getting a law or medical degree or PhD. But it’s actually riskier to make that commitment before you know how it fits you. And don’t consider the path fixed. People realize things about themselves halfway through medical school.” Charles Darwin for example.

Chapter 8 – “The Outsider Advantage” – talks about the benefits of bringing diverse skills and experiences to bear in problem solving:

[Alph] Bingham had noticed that established companies tended to approach problems with so-called local search, that is, using specialists from a single domain, and trying solutions that worked before. Meanwhile, his invitation to outsiders worked so well that it was spun off as an entirely different company. Named InnoCentive, it facilitates entities in any field acting as “seekers” paying to post “challenges” and rewards for outside “solvers.” A little more than one-third of challenges were completely solved, a remarkable portion given that InnoCentive selected for problems that had stumped the specialists who posted them. Along the way, InnoCentive realized it could help seekers tailor their posts to make a solution more likely. The trick: to frame the challenge so that it attracted a diverse array of solvers. The more likely a challenge was to appeal not just to scientists but also to attorneys and dentists and mechanics, the more likely it was to be solved.

Bingham calls it “outside-in” thinking: finding solutions in experiences far outside of focused training for the problem itself. History is littered with world-changing examples.

This sounds like the overused “think outside the box” concept, but there’s a lot of validity here, the fact is that InnoCentive works:

…as specialists become more narrowly focused, “the box” is more like Russian nesting dolls. Specialists divide into subspecialties, which soon divide into sub-subspecialties. Even if they get outside the small doll, they may get stuck inside the next, slightly larger one. 

In Chapter 9 – “Lateral Thinking with Withered Technology” – David tells the fascinating story of Nintendo and how the Game Boy was such a huge success although built using older (“withered”) technology. Out of this story, he mentions the idea of “frogs” and “birds” from physicist and mathematician, Freeman Dyson:

…Dyson styled it this way: we need both focused frogs and visionary birds. “Birds fly high in the air and survey broad vistas of mathematics out to the far horizon,” Dyson wrote in 2009. “They delight in concepts that unify our thinking and bring together diverse problems from different parts of the landscape. Frogs live in the mud below and only see the flowers that grow nearby. They delight in the details of particular objects, and they solve problems one at a time.” As a mathematician, Dyson labeled himself a frog but contended, “It is stupid to claim that birds are better than frogs because they see farther, or that frogs are better than birds because they see deeper.” The world, he wrote, is both broad and deep. “We need birds and frogs working together to explore it.” Dyson’s concern was that science is increasingly overflowing with frogs, trained only in a narrow specialty and unable to change as science itself does. “This is a hazardous situation,” he warned, “for the young people and also for the future of science.”

I like this frog and bird analogy and can picture examples from working with teams where excellent testing arose from a combination of frogs and birds working together to produce the kind of product information neither would have provided alone.

David makes the observation that communication technology and our increasingly easy access to vast amounts of information is also playing a part in reducing our need for specialists:

…narrowly focused specialists in technical fields…are still absolutely critical, it’s just that their work is widely accessible, so fewer suffice

An interesting study on patents further reinforces the benefits of “range”:

In low-uncertainty domains, teams of specialists were more likely to author useful patents. In high-uncertainty domains – where the fruitful questions themselves were less obvious – teams that included individuals who had worked on a wide variety of technologies were more likely to make a splash. The higher the domain uncertainty, the more important it was to have a high-breadth team member… When the going got uncertain, breadth made the difference.

In Chapter 10 – “Fooled by Expertise” – David looks at how poorly “experts” are able to predict the future and talks about work from psychologist and political scientist, Philip Tetlock:

Tetlock conferred nicknames …that became famous throughout the psychology and intelligence-gathering communities: the narrow view hedgehogs, who “know one big thing” and the integrator foxes, who “know many little things.”

Hedgehog experts were deep but narrow. Some had spent their careers studying a single problem. Like [Paul[ Ehrlich and [Julian] Simon, they fashioned tidy theories of how the world works through the single lens of their specialty, and then bent every event to fit them. The hedgehogs, according to Tetlock, “toil devotedly” within one tradition of their specialty, “and reach for formulaic solutions to ill-defined problems.” Outcomes did not matter; they were proven right by both successes and failures, and burrowed further into their ideas. It made them outstanding at predicting the past, but dart-throwing chimps at predicting the future. The foxes, meanwhile, “draw from an eclectic array of traditions, and accept ambiguity and contradiction,” Tetlock wrote. Where hedgehogs represented narrowness, foxes ranged outside a single discipline or theory and embodied breadth.

David’s observations on this later in the chapter reminded me of some testers I’ve worked with over the years who are unwilling to see beyond the binary “pass” or “fail” outcome of a test:

Beneath complexity, hedgehogs tend to see simple, deterministic rules of cause and effect framed by their area of expertise, like repeating patterns on a chessboard. Foxes see complexity in what others mistake for simple cause and effect. They understand that most cause and effect relationships are probabilistic, not deterministic. There are unknowns, and luck, and even when history apparently repeats, it does not do so precisely. They recognize that they are operating in the very definition of a wicked learning environment, where it can be very hard to learn, from either wins or losses.

Chapter 11 – “Learning to Drop Your Familiar Tools” – starts off by telling the story of the Challenger space shuttle disaster and how, even though some people knew about the potential for the problem that caused the disaster, existing practices and culture within NASA got in the way of that knowledge being heard. The “Carter Racing” Harvard Business School case study mimics the Challenger disaster but the participants have to make a race/no race decision on whether to run a racing car with some known potential problems. Part of this story reminded very much of the infamous Dice Game so favoured by the context-driven testing community:

“Okay…here comes a quantitative question,” the professor says. “How many times did I say yesterday if you want additional information let me know?” Muffled gasps spread across the room. “Four times,” the professor answers himself. “Four times I said if you want additional information let me know.” Not one student asked for the missing data [they needed to make a good decision].

A fascinating story about the behaviour of firefighters in bushfire situations was very revealing, with many of those who perish being found weighed down with heavy equipment when they could have ditched their tools and probably run to safety:

Rather than adapting to unfamiliar situations, whether airline accidents or fire tragedies, [pyschologist and organizational behaviour expert Karl] Weick saw that experienced groups became rigid under pressure and “regress to what they know best.” They behaved like a collective hedgehog, bending an unfamiliar situation to a familiar comfort zone, as if trying to will it to become something they had actually experienced before. For wildland firefighters, their tools are what they know best. “Firefighting tools define the firefighter’s group membership, they are the firefighter’s reason for being deployed in the first place,” Weick wrote. “Given the central role of tools in defining the essence of a firefighter, it’s not surprising that dropping one’s tools creates an existential crisis.” As Maclean succinctly put it, “When a firefighter is told to drop his firefighting tools, he is told to forget he is a firefighter.”

This reminded me of some testers who hang on to test management tools or a particular automation tool as though it defines them and their work. We should be thinking more broadly and using tools to aid us, not define us:

There are fundamentals – scales and chords – that every member must overlearn, but those are just tools for sensemaking in a dynamic environment. There are no tools that cannot be dropped, reimagined, or repurposed in order to navigate an unfamiliar challenge. Even the most sacred tools. Even the tools so taken for granted they become invisible.

Chapter 12 – “Deliberate Amateurs” – wraps up the main content of the book. I love this idea:

They [amateurs] embrace what Max Delbruck, a Nobel laureate who studied the intersection of physics and biology, called “the principle of limited sloppiness.” Be careful not to be too careful, Delbruck warned, or you will unconsciously limit your exploration.

This note on the global financial crisis rings true in testing also, all too often we see testing compartmentalized and systemic issues go undetected:

While I was researching this book, an official with the US Securities and Exchange Commission learned I was writing about specialization and contacted me to make sure I knew that specialization had played a critical role in the 2008 global financial crisis. “Insurance regulators regulated insurance, bank regulators regulated banks, securities regulators regulated securities, and consumer regulators regulated consumers,” the official told me. “But the provision of credit goes across all those markets. So we specialized products, we specialized regulation, and the question is, ‘Who looks across those markets?’ The specialized approach to regulation missed systemic issues.”

We can also learn something from this observation about team structures, especially in the world of microservices and so on:

In professional networks that acted as fertile soil for successful groups, individuals moved easily between teams, crossing organizational and disciplinary boundaries and finding new collaborators. Networks that spawned unsuccessful teams, conversely, were broken into small, isolated clusters in which the same people collaborated over and over. Efficient and comfortable, perhaps, but apparently not a creative engine.

In his Conclusion, David offers some good advice:

Approach your personal voyage and projects like Michelangelo approached a block of marble, willing to learn and adjust as you go, and even to abandon a previous goal and change directions entirely should the need arise. Research on creators in domains from technological innovation to comic books shows that that a diverse group of specialists cannot fully replace the contributions of broad individuals. Even when you move on from an area of work or an entire domain, that experience is not wasted.

Finally, remember that there is nothing inherently wrong with specialization. We all specialize to one degree or another, at some point or other.

I thoroughly enjoyed reading “Range”. David’s easy writing style illustrated his points with good stories and examples, making this a very accessible and comprehensible book. There were many connections to what we see in the world of software testing, hopefully I’ve managed to illuminate some of these in this post.

This is recommended reading for anyone involved in technology and testers in particular I think will gain a lot of insights from reading this book. And, remember, “Be careful not to be too careful”!

“Essentialism: The Disciplined Pursuit of Less” (Greg McKeown)

After seeing several recommendations for the book Essentialism: The Disciplined Pursuit of Less, I borrowed a copy from the Melbourne Library Service recently – and then read the book from cover-to-cover over only a couple of sittings. This is a sign of how much I enjoyed reading it and the messages in the book resonated strongly with me, on both a personal and professional level. The parallels between what Greg McKeown writes about here and the Agile movement in software development are also (perhaps surprisingly) strong and this helped make the book even more contextually significant for me.

The fundamental idea here is “Less but better.”

The way of the Essentialist is the relentless pursuit of less but better… Essentialism is not about how to get more things done; it’s about how to get the right things done. It doesn’t mean just doing less for the sake of less either. It is about making the wisest possible investment of your time and energy in order to operate at your highest point of contribution by doing only what is essential.

Greg argues that we have forgotten our ability to choose and feel compelled to “do it all” and say yes to everything:

The ability to choose cannot be taken away or even given away – it can only be forgotten… When we forget our ability to choose, we learn to be helpless. Drip by drip we allow our power to be taken away until we end up becoming a function of other people’s choices – or even a function of our own past choices.

It’s all too easy in our busy, hyper-connected lives to think almost everything is essential and that the opportunities that come our way are almost equal. But the Essentialist thinks almost everything is non-essential and “distinguishes the vital few from the trivial many.”

Greg makes an important point about trade-offs, something again that it’s all too easy to forget and instead over-commit and try to do everything asked of us or take on all the opportunities coming our way:

Essentialists see trade-offs as an inherent part of life, not as an inherently negative part of life. Instead of asking “What do I have to give up?”, they ask “What do I want to go big on?” The cumulative impact of this small change in thinking can be profound.

The trap of “busyness” leads us to not spend the time we should reflecting on what’s really important.

Essentialists spend as much time as possible exploring, listening, debating, questioning, and thinking. But their exploration is not an end in itself. The purpose of their exploration is to discern the vital few from the trivial many.

The topic of sleep comes next and this seems to be a hot topic right now. A non-Essentialist thinks “One hour less of sleep equals one more hour of productivity” while the Essentialist thinks “One more hour of sleep equals several more hours of  much higher productivity.” This protection of the asset that is sleep is increasingly being demonstrated as important, not only for productivity but also for mental health.

Our highest priority is to protect our ability to prioritize.

Prioritizing which opportunities to take on is a challenge for many of us, I’ve certainly taken on too much at times. Greg’s advice when selecting opportunities is simple:

If it isn’t a clear yes, then it’s a clear no

Of course, actually saying “no” can be difficult and a non-Essentialist will avoid doing so  to avoid feeling social awkwardness and pressure, instead saying “yes” to everything. An Essentialist, meanwhile, “dares to say no firmly, resolutely and gracefully and says “yes” only to things that really matter.” This feels like great advice and thankfully Greg offers a few tips for how to say “no” gracefully:

  • Separate the decision from the relationship
  • Saying “no” gracefully doesn’t have to mean using the word no
  • Focus on the trade-off
  • Remind yourself that everyone is selling something
  • Make your peace with the fact that saying “no” often requires trading popularity for respect
  • Remember that a clear “no” can be more graceful than a vague  or non-committal “yes”

The section on subtracting (removing obstacles to bring forth more) resonated strongly with my experiences in software development:

Essentialists don’t default to Band-Aid solutions. Instead of looking for the most obvious or immediate obstacles, they look for the ones slowing down progress. They ask “What is getting in the way of achieving what is essential?” While the non-Essentialist is busy applying more and more pressure and piling on more and more solutions, the Essentialist simply makes a one-time investment in removing obstacles. This approach goes beyond just solving problems, it’s a method of reducing your efforts to maximize your results.

Similarly when looking at progress, there are obvious similarities with the way agile teams think and work:

A non-Essentialist starts with a big goal and gets small results and they go for the flashiest wins. An Essentialist starts small and gets big results and they celebrate small acts of progress.

The benefits of routine are also highlighted, for “without routine, the pull of non-essential distractions will overpower us” and I see the value in the routines of Scrum, for example, as a way of keeping distractions at bay and helping team execution appear more effortless.

This relatively short book is packed with great stories and useful takeaways. As we all lead more connected and busy lives where the division between work and not-work has become so blurred for so many of us, the ideas in this book are practical ways to help focus on what really matters. I’m certainly motivated to now focus more on a smaller number of projects especially outside of work, a decision I’d already taken before reading this book but reading it also validated that decision as well as providing me with good ways of dealing with whatever opportunities may arise and truly prioritizing the ones that matter.

Kevlin Henney at the “Software Art Thou?” meetup (Melbourne, 7th March 2019)

The latest in Zendesk’s excellent “Software Art Thou?” meetup series saw the UK’s Kevlin Henney addressing a packed house (of over 100) in Melbourne on the evening of 7th March.

Kevlin is an independent consultant, speaker, writer and trainer. His development interests are in patterns, programming, practice and process. He is co-author of A Pattern Language for Distributed Computing and On Patterns and Pattern Languages, two volumes in the Pattern-Oriented Software Architecture series. He is also editor of 97 Things Every Programmer Should Know and 97 Things Every Java Programmer Should Know.

The talk was advertised as follows:

“It’s just semantics.” How many conversations about philosophy, politics and programming are derailed by this thought-stopping comment?

Semantics is all about meaning. If there is one thing we struggle with and need to get better at, it is the search for and clarification of meaning. The world in which a software system lives is filled with meaning. The structure, concepts and names that inform the code, its changes and the mental models held by developers and others business roles are expressions of meaning. The very act of development is an exercise in meaning — its discovery, its formulation, its communication. Paradigms, processes and practices are anchored in different ways of thinking about and arriving at meaning.

But just because we are immersed in concepts of meaning from an early age, and just because the daily work of software development is about wrangling meaning, and just because it’s just semantics, that doesn’t mean we’re necessarily good at it. It takes effort and insight. Let’s talk about what we mean.

Kevlin’s talk was titled “What do you mean?” which he quickly modified to “WTF do you mean?”. He kicked off by talking about abstraction and this quote from Dijkstra:

The purpose of abstraction is not to be vague but to create a new semantic level in which one can be absolutely precise

He pointed out that when we’re criticized for trying to be precise with language with statements such as “It’s just semantics”, we need to remember that this literally means”It’s just meaning” so why wouldn’t we seek that?!

Turning specifically to software development, Kevlin argued that code, tests, scripts, etc. are all “code”, literally the codification of knowledge. Software development, to him, is a process of knowledge acquisition through learning, communication and social negotiation. Software architecture is a model of participation with design comprising synthesis and analysis (which are opposites of each other).

An Ernest Hemingway quote came next:

The only kind of writing is rewriting

Kevlin argued that software development is the production of variation, it’s not manufacturing – kudos to him for this messaging, it’s still all too common to see this ill-placed manufacturing/factory model placed on software development and it leads to nonsense like “Quality Assurance” when we really should be talking about testing. He also made the good point that what we do is straddling natural and programming languages.

Kevlin said that the domain (whatever it is) always looks very different from the inside and that:

Your customer doesn’t mean what they say

They use their terms and context, they leave out significant details (what they don’t say), they make assumptions, and actually don’t know what they want in the first place (it’s just a property of humans)!

As an argument for iterative development and the idea of slowing down to become faster, he quoted Neil Gaiman:

You learn from finishing things

There is a big difference between speed and velocity, with the latter being overloaded by the agile community. He claimed speed often leads to us “building the wrong thing brilliantly” rather than going slower in the right direction.

He made another excellent point as he was close to finishing up around our modern fascination with “prioritizing by business value”, with the suggestion we say “estimated business value” as this judgement of value is itself prone to error.

This was a very professionally-delivered talk, serious in nature but delivered with anecdotes and some dry British humour along the way, supported by a very nice slide deck.

Zendesk always put on a great meetup and this was no exception. Their space is large and airy with excellent audio visual facilities plus they lay on a lot of finger food and a well-stocked (and varied) bar service. The quality of their presenters is also always top notch and, although I wasn’t familiar with Kevlin and his work, this was a really engaging (even after talking non-stop for seventy minutes!) and interesting talk on a topic that gets scant treatment in the software development industry – and also in testing, specifically. Many of us in the context-driven testing community are often accused of playing semantic games but, as Kevlin ably demonstrated, conveying meaning is critically important and genuinely difficult to do well.

“Turn the Ship Around!” (L. David Marquet)

After seeing a number of positive reviews and recommendations for this book, I asked the Melbourne Library Service to procure a copy – they agreed and I’ve recently enjoyed reading the fruits of their investment.

Marquet is a former nuclear submarine commander and the book details his moves to change the leadership on a poorly-performing submarine from leader-follower to what he calls “leader-leader”.

He starts out by describing what leadership meant in the (US) Navy, quoting from the “Naval Academy leadership book”:

Leadership is the art, science, or gift by which a person is enabled or privileged to direct the thoughts, plans, and actions of others in such a manner as to obtain and command their obedience, their confidence, their respect, and their loyal co-operation

As he points out “leadership in the Navy, and in most organizations, is about controlling people. It divides the world into two groups of people: leaders and followers.” His solution to the leader-follower pattern is the leader-leader model:

The leader-leader structure is fundamentally different from the leader-follower structure. At its core is the belief that we can all be leaders and, in fact, it’s best when we are all leaders. Leadership is not some mystical quality that some possess and others do not. As humans, we all have what it takes, and we all need to use our leadership abilities in every aspect of our work life.

The leader-leader model not only achieves great improvements in effectiveness and morale, but also makes the organization stronger. Most critically, these improvements are enduring, decoupled from the leader’s personality and presence. Leader-leader structures are significantly more resilient, and they do not rely on the designated leader always being right. Further, leader-leader structures spawn additional leaders throughout the organization naturally. It can’t be stopped.

Marquet details his journey of building the leader-leader model during his time turning around the flagging fortunes of the Sante Fe submarine. His passion, guts and honesty in making the changes he did shine through the narrative and results in a really simple but powerful model for changing the way we view leadership in organizations.

He argues that “the core of the leader-leader model is giving employees control over what they work on and how they work. It means letting them make meaningful decisions. The two enabling pillars are competency and clarity.”

One of the first things Marquet noticed on joining the Santa Fe was their focus on avoiding mistakes:

What happened with Santa Fe…was that the crew was becoming gun-shy about making mistakes. The best way not to make a mistake is not to do anything or make any decisions. It dawned on me the day I assumed command that focusing on avoiding errors is helpful for understanding the mechanics of procedures and detecting impending major problems before they occur, but it is a debilitating approach when adopted as the objective of an organization.

This observation led to his first mechanism for clarity: achieve excellence, don’t just avoid errors.

His discovery of the processes around signing off sailor’s leave led to his first mechanism for control: find the genetic code for control and rewrite it:

The first step in changing the genetic code of any organization or system is delegating control, or decision-making authority, as much as is comfortable, and then adding a pinch more. This isn’t an empowerment “program”. It’s changing the way the organization controls decisions in an enduring, personal way.

I like this idea of “Don’t move information to authority, move authority to information” in this area too.

The next control mechanism Marquet came up with was: act your way to new thinking:

When you’re trying to change employees’ behaviours, you have basically two approaches to choose from: change your own thinking and hope this leads to new behaviour, or change your behaviour and hope this leads to new thinking. On board Sante Fe, the officers and I did the latter, acting our way to new thinking.

The next control mechanism rings very true in software development, especially when adopting agile practices: have short early conversations to get efficient work:

Supervisors needed to recognize that the demand for perfect products the first time they see them results in significant waste and frustration throughout the entire organization. Even a thirty-second check early on could save your people numerous hours of work… a well-meaning yet erroneous translation of intent [could result] in a significant waste of resources.

In his mission to turn passive followers into active leaders, a “minor trick of language” turned into an effective means of control: use “I intend to…” Marquet would “avoid giving orders. Officers would state their intentions with “I intend to…” and I would say “Very well”. Then each man would execute his plan.” It turned out that this simple change “profoundly shifted ownership of the plan to the officers.”

Another control mechanism follows: resist the urge to provide solutions. This is a really hard habit to break and I’ve been working on this personally during my coaching and mentoring activities. I can see how it breaks down the leader-follower mentality, but it takes a deliberate effort to stop yourself from stepping in and solutionifying!

Marquet’s next control mechanism is: eliminating top-down monitoring systems:

Supervisors frequently bemoan the “lack of ownership” in their employees. When I observe what they do and what practices they have in their organization, I can see how they defeat any attempt to build ownership.

Worse, if they’ve voiced their frustrations out loud, their employees perceive them as hypocritical and they lose credibility. Don’t preach and hope for ownership; implement mechanisms that actually give ownership… Eliminating top-down monitoring systems will do it for you. I’m not talking about eliminating data collection and measuring processes that simply report conditions without judgement. Those are important as they “make the invisible visible”. What you want to avoid are the systems whereby senior personnel are determining what junior personnel should be doing.

More control follows in the shape of: think out loud:

When I heard what my watch officers were thinking, it made it much easier for me to keep my mouth shut and let them execute their plans. It was generally when they were quiet and I didn’t know what they would do next that I was tempted to step in. Thinking out loud is essential for making the leap from leader-follower to leader-leader.

Regular inspections were part of Navy life and Marquet and his crew decided to “be open and invite outside criticism”, in a control mechanism he calls: embrace the inspectors.

Embrace the inspectors can be viewed as a mechanism to enhance competence, but I think it fits even better in the discussion of control because it allowed us not only to be better submariners but also to maintain control of our destiny.

[It] also turned out to be an incredibly powerful vehicle for learning. Whenever an inspection team was on board, I would hear crew members saying things like, “I’ve been having a problem with this. What have you seen other ships do to solve it?” Most inspection teams found this attitude remarkable.

While Marquet started off by pushing decision making and control to lower and lower levels in the organization, he found that control by itself was not enough and he also needed to bolster the technical competence of his crew if this approach was to be successful.

The first mechanism for competence he outlines is: take deliberate action. Following an incident where a circuit-breaker was mistakenly closed on the submarine, the idea of taking deliberate action arose following a postmortem:

“Well, he was just in auto. He didn’t engage his brain before he did what he did: he was just executing a procedure.”

I thought that was perspective. We discussed a mechanism for engaging your brain before acting. We decided that when operating a nuclear-powered submarine we wanted people to act deliberately, and we decided on “take deliberate action” as our mechanism. This meant prior to any action, the operator paused and vocalized and gestured toward what he was about to do, and only after taking a deliberate pause would he execute the action. Our intent was to eliminate those “automatic” mistakes. Since the goal of “take deliberate action” was to introduce deliberateness in the mind of the operator, it didn’t matter whether anyone was around or not. Deliberate actions were not performed for the benefit of an observer or an inspector. They weren’t for show.

This particular mechanism reminded me of the ideas in Daniel Kahneman’s “Thinking, Fast and Slow” book.

The next competence mechanism is easy to relate to: we learn (everywhere, all the time). Embedding the idea that everyone in an organization needs to be constantly learning is a very good thing, be it in a military setting like Marquet’s or a software engineering setting. I actually think folks in IT are generally on board with this idea due to the high rate of change in technology, programming languages, etc. and the popularity of IT-related meetup groups, for example, are an indicator of a willingness to continue learning outside of the scope of the day-to-day in the office.

His next mechanism for competence is: don’t brief, certify.

A briefing is a passive activity for everyone except the briefer. Everyone else “is briefed”. There is no responsibility for preparation or study. It’s easy to just nod and say “ready” without full intellectual engagement. Furthermore, the sole responsibility in participating in a brief is to show up. Finally, a brief, as such, is not a decision point. The operation is going to happen and we are simply talking about it first.

We decided to do away with briefs. From that point on we would do certifications.

A certification is different from a brief in that during a certification, the person in charge of his team asks them questions. At the end of the certification, a decision is made whether or not the team is ready to perform the upcoming operation. If the team has not demonstrated the necessary knowledge during the certification, the operation should be postponed.

Another competence mechanism is presented next: continually and consistently repeat the same message:

Repeat the same message, day after day, meeting after meeting, event after event. Sounds redundant, repetitive, and boring. But what’s the alternative? Changing the message? That results in confusion and a lack of direction. I didn’t realize the degree to which old habits die hard, even when people are emotionally on board with the change.

This mechanism is one I’ve employed frequently in coaching testers around the world and it’s surprisingly effective (I say “surprising” since it surprised me that it is both necessary and valuable to do it).

Marquet’s last competence mechanism is: specifying goals, not methods. This arose from a fire drill in which the team members followed a prescribed response but failed to extinguish the fire within the safe time limit:

…[now] the crew was motivated to devise the best approach to putting out the fire. Once they were freed from following a prescribed way of doing things, they came up with many ingenious ways to shave seconds off our response time [to fires].

The problem with specifying the method along with the goal is one of diminished control. Provide your people with the objective and let them figure out the method.

Lovers of “best practices” please take note!

The third and final set of mechanisms Marquet introduces are around clarity:

As more decision-making authority is pushed down the chain of command, it becomes increasingly important that everyone throughout the organization understands what the organization is about. This is called clarity.

Clarity means people at all levels of an organization clearly and completely understand what the organization is about. This is needed because people in the organization make decisions against a set of criteria that includes what the organization is trying to accomplish. If clarity of purpose is misunderstood, then the criteria by which a decision is made will be skewed, and suboptimal decisions will be made.

His first mechanism for clarity is: building trust and taking care of your people:

It’s hard to find a leadership book that doesn’t encourage us to “take care of our people”. What I learned is this: Taking care of your people does not mean protecting them from the consequences of their own behaviour. That’s the path to irresponsibility. What it does mean is giving them every available tool and advantage to achieve their aims in life, beyond the specifics of the job. In some cases that meant further education; in other cases crewmen’s goals were incompatible with Navy life and they separated on good terms.

The next mechanism for clarity is: use your legacy for inspiration. This one helped to provide organizational clarity, explaining the “why” for the crewmen’s service:

Many organizations have inspiring early starts and somehow “lose their way” at some later point. I urge you to tap into the sense of purpose and urgency that developed during those early days or during some crisis. The trick is to find real ways to keep those alive as the organization grows. One of the easiest ways is simply to talk about them. Embed them into your guiding principles and use those words in efficiency reports and personnel awards.

Another mechanism for clarity comes next: use guiding principles for decision criteria.

Leaders like to hang a list of guiding principles on office walls for display, but often those principles don’t become part of the fabric of the organization. Not on Santa Fe. We did several things to reinforce these principles and make them real to the crew. For example, when we wrote awards or evaluations, we tried to couch behaviours in the language of these principles. “Petty Office M exhibited Courage and Openness when reporting…

Most of you have organizational principles. Go out and ask the first three people you see what they are. I was at one organization that proudly displayed its motto in Latin. I asked everyone I saw what it meant. The only one who knew was the CEO. That’s not good.

I’ve personally seen these working well within Quest – we have a set of Core Values and we refer to them regularly at all levels of the organization.

Another mechanism for clarity is: use immediate recognition to reinforce desired behaviours. I really like this one, it’s simple but easy to forget to do:

When I say immediate recognition, I mean immediate. Not thirty days. Not thirty minutes. Immediate.

Look at your structures for awards. Are they limited? Do they pit some of your employees against others? That structure will result in competition at the lowest level. If what you want is collaboration, then you are destroying it.

A mechanism for organizational clarity comes next: begin with the end in mind.

As you work with individuals in your organization to develop their vision for the future, it is crucial that you establish specific, measurable goals. These goals will help the individuals realize their ambitions. In addition, you as a mentor have to establish that you are sincerely interested in the problems of the person you are mentoring. By taking action to support the individual, you will prove that you are indeed working in their best interest and always keeping the end in mind.

His final mechanism for clarity is: encourage a questioning attitude over blind obedience. He asks “Will your people follow an order that isn’t correct? Do you want obedience or effectiveness? Have you built a culture that embraces a questioning attitude?” Reinforcing that asking questions is a good idea is so important in what we do as software testers (I recently heard Nick Pass define “QA” as “Question Asker” during his talk at the TiCCA19 conference) and there are sometimes personality and cultural barriers to overcome in encouraging people to question (the latter I have much experience of while working with our teams in China).

In summary, Marquet’s set of mechanisms for Control, Competence and Clarity are as follows.

Control

  • Find the genetic code for control and rewrite it
  • Act your way to new thinking
  • Short, early conversations make efficient work
  • Use “I intend to…” to turn passive followers into active leaders
  • Resist the urge to provide solutions
  • Eliminate top-down monitoring systems
  • Think out loud (both superiors and sub-ordinates)
  • Embrace the inspectors

Competence

  • Take deliberate action
  • We learn (everywhere, all the time)
  • Don’t brief, certify
  • Continually and consistently repeat the message
  • Specify goals, not methods

Clarity

  • Achieve excellence, don’t just avoid errors
  • Build trust and take care of your people
  • Use your legacy for inspiration
  • Use guiding principles for decision criteria
  • Use immediate recognition to reinforce desired behaviours
  • Begin with the end in mind
  • Encourage a questioning attitude over blind obedience

There are so many useful takeaways in this book; it’s a short but engaging read and the direct applicability to the way we manage the people in software development projects is very clear – especially if you’re aiming for truly self-organizing agile teams!

I highly recommend reading Turn the Ship Around to anyone interested in genuinely empowering people in their teams.