Management and trust – So simple, so complex, so important

Testing Trapeze, April 2016

TRUST is a word that often gets used without realizing its importance or weight. It is easy for someone to tell you “of course I trust you” or “I trust in your ability to see this project through”. A person’s ability to talk about trust is not always backed up by an ability to provide the promised trust. Telling someone you trust them to deliver when you give them an easy task which they have delivered on many times previously is pretty easy. History tells us that fulfillment of the delivery is a low risk proposition, but can you repeat that same sentiment when the stakes are high?

I had a number of possible topics for this article, I guess you don’t need to be Sherlock Holmes to figure out what I decided to write about. The reason I settled on this topic is worth relating. I work in a team that has a weekly gathering over coffee. Part work discussion, part social. It is a bonding get together that has been incredibly successful. A recent work meeting that we had all attended came up in discussion. Of all things discussed in the meeting a single comment resonated as “the highlight” and it was discussed with considerable passion and emotion. Why this one specific comment? Because the speaker’s (a manager) opening comment focused on personal consequences of not complying with a new process being rolled out. The comment completely overrode the positivity of the actual roll-out announcement. It communicated a clear lack of trust. Below is a summary of key team discussion conclusions about the lack of a trust culture:

  • It is not just a management issue; this attitude pushes down to others
  • Lack of management trust generates fear of failure
  • Lack of trust erodes a team’s ability to trust each other and work efficiently
  • Lack of trust undermines confidence, generates self-doubt and promotes inefficiency
  • Being assigned a solution rather than a problem removes buy-in and removes feedback opportunities
  • Lack of trust in the form of micromanagement kills innovation and self confidence
  • Lack of trust produces a fear of failure
  • Lack of trust is part of a “carrot and stick” approach with the emphasis clearly on the “stick”
  • Lack of trust creates an implied belief that people will seek to break process or give less than their best
  • Creates a culture of success by finding fault in others work in order to succeed

In an article published in the Huffington Post titled Managing Better: 7 Ways Leaders Say “I Don’t Trust You”, David Peck cites the following issues:

  • Nitpicking: Micro-editing, being hyper-vigilant about the details of their work, too frequent check-ins and telling, rather than asking, “better” ways to do what they are doing.
  • Delegating the “what” and the “how”: Saying, in effect, “This is what I need, and here’s how I need you to do it”, or “You should have done it this way”.
  • Delegating without sufficient context: Making a request or command to do something without explaining why or where it fits in to the bigger picture; “do this”.
  • Delegating responsibility, while actual authority to act resides too high up the chain: Many organizations say they empower their people, yet particularly in difficult times, the reverse is the tidal pull. Pulling too many decisions into committees or up the leadership chain is often the rule. You delegate, but don’t give responsibility for the final decisions related to what you’ve asked them to do.
  • Leading with the mindset that your people are never allowed to fail: However well-intentioned, if people are working at their best, sometimes they will fall down or fail. Intervening, overrehearsing or otherwise being heavy-handedly protective of them.
  • Overriding your people’s input or feedback: Requesting or taking input from your team then (apparently to them) ignoring it without explanation. Asking for feedback, then overriding it.
  • Keeping your people under wraps: Behaviors like bringing your people along with you to an important presentation or moment, and not having them actively participate. Not giving your people opportunities to showcase their work in more important settings.

The sources are separated by significant distance but there are many common themes between Peck’s list and the sentiments expressed in the team meeting. This is clearly not a problem that is limited to a handful of people in a single location. Why, as people, do we hold trust as such an important attribute when it is clear from the above that a real or perceived lack of trust is immensely damaging? I went hunting for a definition or explanation of trust, ending up (somewhat unexpectedly), settling on the following from Wikipedia:

… trust has several connotations. Definitions of trust typically refer to a situation characterized by the following aspects: One party (trustor) is willing to rely on the actions of another party (trustee); the situation is directed to the future. In addition, the trustor (voluntarily or forcedly) abandons control over the actions performed by the trustee. As a consequence, the trustor is uncertain about the outcome of the other’s actions; they can only develop and evaluate expectations. The uncertainty involves the risk of failure or harm to the trustor if the trustee will not behave as desired.

Vladimir Ilych Lenine expresses this idea with the sentence “Trust is good, control is better”. 

I like the above description. It invokes several key themes:

  • Trustor and trustee
  • Willingness
  • Reliance
  • Voluntary or forced
  • Abandoning control
  • Uncertainty
  • Behavior expectations

I also like the final quote (which I will come back to). If you are wondering who Vladimir Ilych Lenine is, you might better know him as Lenin.

From the session responses and the trust rationale described, there is the expectation that trust transfers power and responsibility. It moves it from the trustor to the trustee. Why is this transition such an issue? Surely giving people responsibility and allowing them to create solutions is why we hire people? Part of the answer might be found in Dan Pink’s words. In his book, Drive – The Surprising Truth about What Motivates Us, he raises the idea of three motivational systems, which I’ll paraphrase as:

  • Motivation 1.0: These are your basic instincts. Humans have had these since the dawn of time. This is the drive to survive.
  • Motivation 2.0: The recognition that people respond to reward and punishment (controlled motivation). In the early 1900s Frederick Winslow Taylor was a notable contributor in this area. This approach hinges on rewarding desired behavior and punishing other, unwanted, behavior. This a command and control approach and appears to still be the predominant form of motivation used by managers. Recall that quote from Lenin? Control over trust, that is an example of motivation 2.0 thinking.
  • Motivation 3.0: Tapping into peoples’ intrinsic (autonomous) motivation, the desire to do a great job. Allowing people to utilize their sense of autonomy, allowing them to self-direct. This requires resisting the urge to control people.

Pink elaborates:

“Autonomous motivation involves behaving with a full sense of volition and choice, … whereas controlled motivation involves behaving with the experience of pressure and demand toward specific outcomes that comes from forces perceived to be external to the self.” 

 If you look at the list of observations gathered from teammates about the impacts of a lack of trust you can see they align with a rejection of motivation 2.0 principles and a desire to embrace motivation 3.0. There is a desire to be self-directing, autonomous achievers; engaged and fulfilled by the work.

So how did “we” get to a point where management are directing operations in a way that their people just do not relate and why have we stayed there so long? Tom DeMarco provides an interesting idea in his book, Peopleware: Productive Projects and Teams:

“Consider the preparation we had for the task of management: We were judged to be good management material because we performed well as doers, as technicians and developers. That often involved organizing our resources into modular pieces, such as software routines, circuits, or other units of work … After years of reliance on these modular methods, small wonder that as newly promoted managers, we try to manage our human resources the same way. Unfortunately, it doesn’t work very well.” 

The DeMarco observation highlights two problems;

  • Technical skill gets people to management rather than people skills;
  • Technical competency is built by owning low level detail but this is not ideal when managing people.

This is not an ideal foundation. The following discussion from Joan Lloyd about micro-managers helps to reinforce DeMarco’s views;

“These folks just can’t let go. Typically, they have worked their way up the ladder and they are familiar with the work that needs to get done. They find satisfaction in doing the work, so they like to do it themselves, or tell their employees exactly how to do it. Often, micromanagers are perfectionists, so they breathe down the necks of their employees, checking their work to see if they have completed it exactly like the manager would have done it.

Sometimes micromanagers are created because their boss is pressuring them for fast, specific results. This causes the manager to hover over their employees’ and frequently inquire about the progress of the project. If the manager’s boss is the punitive type, you can bet the manager will be micromanaging his or her employees, so no heads will roll”. 

If managers can’t let go, and that results in a “lack of trust” environment, do we just accept this and move on (“hey that’s the way it’s always been, it’s just the way it works”) or do we seek better and find ways to address the problems? The answer might lay within initiatives that provide managers with leadership skills. Why is this important? While the terms manager and leader are often used interchangeably, they are not the same thing. Consider the following points of distinction from the Harvard Business Review:

Counting value vs Creating value. You’re probably counting value, not adding it, if you’re managing people. Only managers count value; some even reduce value by disabling those who add value. By contrast, leaders focus on creating value, saying: “I’d like you to handle A while I deal with B.” He or she generates value over and above that which the team creates, and is as much a value-creator as his or her followers are. Leading by example and leading by enabling people are the hallmarks of action-based leadership.

Circles of influence vs Circles of power. Just as managers have subordinates and leaders have followers, managers create circles of power while leaders create circles of influence. The quickest way to figure out which of the two you’re doing is to count the number of people outside your reporting hierarchy who come to you for advice. The more that do, the more likely it is that you are perceived to be a leader.

Leading people vs Managing work. Management consists of controlling a group or a set of entities to accomplish a goal. Leadership refers to an individual’s ability to influence, motivate, and enable others to contribute toward organizational success. Influence and inspiration separate leaders from managers, not power and control. 

There is a clear alignment between leadership and motivation 3.0. Is the transformation possible? I can’t see why it isn’t but it will take effort and persistence. This is a cultural transformation. It is the management specific “waterfall to agile” mindset change. Many of these fail because change is hard and old habits die hard but without this change a business risks either failing to reach full potential, or simply failing. Businesses that understand the imperative will surge forward as the trust shown by leaders engage employees and encourages them to do their best in safety.

In closing, from Tom DeMarco again:

“Most managers give themselves excellent grades on knowing when to trust their people and when not to. But in our experience, too many managers err on the side of mistrust. They follow the basic premise that their people may operate completely autonomously, as long as they operate correctly. This amounts to no autonomy at all. The only freedom that has any meaning is the freedom to proceed differently from the way your manager would have proceeded.”

Testers FAQ on certifications

Co writers – Lee Hawkins, Rajesh Mathur

Testing Circus – Volume 7, Edition 1, January 2016

This article (or Testers’ FAQs) is a result of our constant discussions, conversations, debates, teaching, coaching and mentoring over social media and not-social (we are
not saying anti-social) media. Many of these conversations have occurred during our popular TEAM meetups.

We have also been responding to many queries from experienced as well as inexperienced testers lately. Many of these queries are topics such as career advice, growth path, techniques and technology. The most common question concerns testing certifications. The testers out there appear confused about the value of becoming certified. Considering the confusion and common questions, we decided to create this FAQ guide. We have also listed some good references at the end of this article.
Q. In an overcrowded market, there has to be a benchmark which employers can work with. Don’t certificates help employers by becoming that benchmark?
Answer: The central problem is not the missing benchmark. The problem seems to be about assessing job applicants’ CVs before the interview process. One common complaint is that most CVs from testers appear similar, as if a template has been used. This problem is exacerbated by certification, not remedied by it. If every tester is certified by the same body, then this is not a differentiator. Those involved in recruiting testers need to look beyond the cookie-cutter CVs for signs of genuine testing ability and interest, such as community engagement and critical thinking (an example of which would be the realization that certification homogenizes rather than differentiates).

Q. Isn’t it hard to assess a person’s capability until they reach the interview stage? It is an overcrowded market because the employers often get a large number of applications for a single job posting (certified or otherwise).
Answer: A good CV can tell you a lot about a candidate. Focus on understanding the applicant’s past employment history, what they bring at the pure job experience level. Now understand their involvement in learning and contributing. What does the applicant do to extend their testing knowledge? Do they rely on employer provided training or do they have an established self improvement program? Is the applicant involved in the test community? What does this involvement look like? Is this a “9 to 5” tester for whom testing is just a way of making money or someone that wants to grow and add value as a tester? This tells us more about an applicant than holding a generic testing
Employers also have their vested interests in making the hiring process easier for themselves. One approach is to be very clear and specific while drafting the job  description. Most of the testing job descriptions are very vague and poorly drafted and this is why we believe employers receive a large number of applications.
Employers would benefit by spending time understanding the role they really need filled and describing an appropriate job profile. They could also benefit by understanding what certification means to them as an organization, the value it delivers, rather than simply adopting it as a filtering benchmark without understanding the impact of this decision.
Q. Any ideas how the testing industry would set the expectation that certificates are/are not required? There doesn’t appear to be a clear expectation amongst all organizations.
Answer: It would be unrealistic to assume all organizations have the same expectations on this or any other subject. Organizations have different cultures, projects within them also have different ways of  working and their own expectations on the value testing
brings to the project. It is these differences between what constitutes value from testing that is acknowledged by the principles of context-driven testing and these differences are poorly served by a “one size fits all” approach to testing that is almost an inevitable outcome of following certification programs.
Q. For a beginner tester, the certification programs teach techniques that might help in their job. Theory can be a base for practical experience?
Answer: We think that a certification course and a subsequent exam do not teach beginners testing techniques. Most certified testers who we have interacted with confirm that they took the exam only for the purpose of gaining the certificate and not for
learning new techniques. Testing techniques are mostly learned on the job by doing.
Further, when the means to an end is remembering things to regurgitate on an exam then it is not an exercise of practical demonstration but of rote learning. We have worked with numerous testers that have received high certification marks but cannot negotiate their way through real world problems. Certification does not teach thinking skills, it teaches students to follow an established pattern of practice. Students do not leave the courses with any strategies on how to deal with these problems and think through issues. We
advocate getting experienced testers to sit with the new testers. Establish a mentoring program, let real experience guide the development of testers. Let them experience real world problems and develop problem solving skills as they find answers to these problems
while being fully supported. James Bach wrote an excellent post for new testers which we highly recommend (even if you are not new to testing).
Q. For an experienced tester, certification works as a refresher and for up-skilling knowledge. People take certifications to showcase their ability or curiosity to
learn, don’t they?
Answer: We’re all for testers taking responsibility for their own career and a demonstrated history of continuous learning is something you should be looking
for on any tester’s CV. Too often we encounter testers who think taking ISTQB Foundation teaches them all they need to know to be a good tester. In our opinion
this is a blinkered and misguided approach. Testing growth requires a community. The idea that one source of information (certification) makes you complete is a
fallacy. You don’t learn to speak English by reading the dictionary. In a ‘thinking and doing’ profession you don’t up-skill by occasionally getting a certificate. You
improve by immersing yourself in other people’s thinking, be that books, articles or ad-hoc observation (to name a few means) and turning those into experiments. You improve by discussing ideas within your test community, attending meetups, conferences,
workshops. Even coffee chats with other testers who are willing to challenge your ideas, experiment with them, provide feedback on outcomes!
Q. Certification is essential to get into the workforce or be promoted.
Answer: This is why it’s so important for there to be good arguments in place for not having such requirements. With the ubiquity of ISTQB certification, it is not surprising that organizations latch onto it as a prerequisite during hiring and promotion – but that
doesn’t mean it has to be this way. It is up to all good testers to present compelling arguments for alternatives that focus on critical thinking and context.
Q.Most importantly, certifications are for implementing a universal process. Each organization has their own testing strategies, plan and approach. Learning about a
universal process gives the tester confidence to fit into any organization easily.
Answer: Testers serve their stakeholders in a particular context. They cannot work in isolation because there are multiple stakeholders that testers influence and are
influenced by. Since testers serve a specific purpose in a specific context, the universality of language is not required as much as it may be required by a developer. Testers who try to impose their language on their stakeholders do a disservice to our craft. This imposition
serves to create confusion and contributes to poor relationships with stakeholders. Each organization is unique and has its own way of doing things. What one organization may call build verification test, others may call smoke, sanity, shakedown or shakeout test.
Semantics matter and may impact adversely to a context. It is a better approach, in our opinion, to allow project stakeholders to agree a “glossary of terms” for the project so that all stakeholders use common, clear language. The glossary may not survive more than a
project, but, it doesn’t need to. It survives only as long as it is relevant to the project context.

The idea of creating a universal test language is a unicorn. It suggests a level of conformity among the  testing community that, in reality, will never be achieved. Many years ago, being relatively new to testing and having achieved ISTQB foundation, Paul
attempted to formalize the language of eight testers he led. He spent time trying to align terminology to the ISTQB glossary. He eventually dropped the idea as it became clear there was no appetite for the change. He realized not long after that this was a high effort, low
value exercise. We don’t need a common language, we need to discuss and establish context through communication. Michael Bolton’s post on Common Language provides further “food for thought”.
The notion of universality also implies best practices. This is, in itself, an issue as it encourages the idea that I can apply the same approach in any context and it will
be efficient, meaningful, and provide value to the stakeholders. This attitude severely retards meaningful growth in the industry and also damages credibility. Our personal approach, and the one we would recommend, is to consider all possibilities available to
you and use the ones that best fit your needs within the current context. Don’t rest on these decisions though. Contexts change, be alert and ready to assess what those changes mean. Do not blindly follow a pre-determined path.
Q. Understanding the process makes the person a best fit. Certification exams make testers understand the testing process. Hence, certifications are not at all wasteful activity.
Answer: One does not need certification to understand or learn a new process, language or activity. Children learn languages by observation and get fluent by practicing. Similarly, for testers, practice, observation, exploration and learning are more important than
The question whether testing certification is wasteful or not again depends on context. The effort involved in learning the syllabus content to a point where the examination can be passed presents opportunity cost, given that the tester involved could instead be tasked
with learning and exploring the product under test and providing information about it to your stakeholders. Entrenching the so-called standard terminology from the certification may end up being wasteful, as the tester needs to work within the differing project environments in any organization and adopt the de facto terminology in use in each.
Q. We don’t retain knowledge as time passes. So we do need refreshing courses or certifications to get you back into the process.
Answer: Learning can be done in many ways. Certification or paid courses are not the only options for gathering knowledge. Today, there is so much free learning material & support available online that a seeker may not even need an institution.
Q. Certifications or standards were created out of necessity.
Answer: The question is, what necessity or whose necessity? The necessities need to be exposed as these are the assertions that need to be examined for accuracy and relevance. What necessities led to the creation of a very directive method of testing? What other options were discarded and why. If you are going to argue necessity then you need to look at the historical context and examine it.
If certificates were created because of necessity, what was the objective? What benefits were to be accrued through prescribed process in a business of a “million or more” contexts? Is there really “one true process to rule them all”?. Does that original necessity still exist? We have yet to hear a convincing argument that it does. We argue, strongly, that you cannot implement directive approaches to testing without tearing large holes in the credibility of testing as a profession.

Can you hire good testers who do not have a certificate but still have good knowledge of testing? We include Rob Lambert’s post in the references below Rob’s post answers this question in significant detail.
Q. If experience-based testing is what we recommend then what are the entry criteria for freshers? They cannot gain experience without being hired as a tester.
Answer: There are ways by which an entry level tester can gain experience. There are open source projects available online, many websites like CodeAcademy, Khan Academy, Free Code Camp provide learning and experience opportunities. Crowdsourcing sites like
uTest provide opportunities to gain experience and earn as well. Beginners can also join test meetups or engage more anonymously through forums such as LinkedIn.
Beginners can use these to not just learn, but experience and earn too.

1. “Recruiting Software Testers” (Dr. Cem Kaner)
2. “LinkedIn PDCA: Are you ready?” (Rajesh Mathur)
3. “How to Recruit a Tester” (Phil Kirkham)
4. “Certifications are creating lazy hiring managers” (Rob Lambert)
5. “How to Find, Interview and Hire Great Software Testers”
(Simon Knight)
6. “Defending Against Standards and Certification” (Eric Proegler)
7. “Certifications in hiring – Part 1” (Johanna Rothman)

It’s On My List – One Piece of the Quality Jigsaw

Checklists reduce the likelihood of you forgetting to do something important and so increase the chances of delivering quality that will delight your customer. That’s a bold opening statement, it sounds more like a conclusion, but read on, please. This begs the question, if my brief opening summary is reasonably correct, why does there seem to be a general lack of checklist use in software production? When I have raised the idea of checklists with colleagues none profess to using them (or using them in any consistent way for any length of time). I recently spoke about checklists at a test meetup, it was apparent that the audience had spent little, if any time, using checklists as a tool. Why is the use of checklists not a more general practice within software development? When I first tried to introduce them in to a test team some years back I could not get the idea to gain traction. I won’t deny that part of that could have me being a poor salesman rather than the idea being a poor one. Never the less none of the testers seemed to intrinsically see them as useful. Checklists make sense to me. There are very few days where I don’t plan what I need to cover in a day. You might call that a daily plan or a “To-Do” list but it is just as easily viewed as a checklist. Checklists provide a level of comfort that the things I should be doing are getting done. I don’t list everything, just the important things, the things that I do need to complete on the day. When I sit in an aircraft I’m really hoping the Captain and First Officer are calling through those checklists. Wheels down landings at appropriate speed really appeal to me (my full list of requirements in this space extend beyond a single aircraft configuration). It was really my interest in aviation that brought checklists to the front of my thinking

1Pilots have checklists for the following: “before start,” “after start,” “before takeoff,” “cruise,” “pre-descent,” “in-range” (about 10 minutes before landing), “after landing,” “parking” and, if the airplane is finished for the day, a “termination” checklist must be completed. Checklists are fundamental to the aviation industry, the most regulated industry I know, because they virtually eliminate mistakes and oversights. In addition to mechanical checklists mounted in the cockpit, we consult plasticized checklist sheets and electronic ones displayed on airplane computer screens, as well as reference checklists for such procedures as de-icing (courtesy of Air Canada, the bolding is mine).

The use of checklists extend beyond aviation. Medicine, in particular surgery and critical care, has also adopted checklists.

2The concept of using a checklist in surgical and anaesthetic practice was energized by publication of the WHO Surgical Safety Checklist in 2008. It was believed that by routinely checking common safety issues, and by better team communication and dynamics, perioperative morbidity and mortality could be improved. The magnitude of improvement demonstrated by the WHO pilot studies was surprising. These initial results have been confirmed by further detailed work demonstrating that surgical checklists, when properly implemented, can make a substantial difference to patient safety (British Journal of Anaesthesia the bolding is mine).

One of the things I really like about scrum is the Definition of Done (DoD). Why so? Because it is a checklist that the team must make each other accountable for. That checklist represents things that must be done in order to say we have value that can be delivered to our client. It removes the “hey did we complete the code reviews on that release?” scenario as the release flies out the door to client land. It covers off the “did we complete the testing we committed to?” panic question after release to a client (this does assume proper use of the DoD). The DoD is a powerful governance item. The team I work with has it’s own DoD defined in key areas of story card movement and each of those stages has key attributes we believe are vital to ensuring consistent quality. It represents things we shouldn’t even have to think about doing. The “dumb things” that you could never forget to do, but somehow, under pressure, or other distractions, you might. The DoD sits on each team members desk and a big copy of it sits blu-tacked to a window in our area. It’s as visible as we can make it to the team and external stakeholders. So what are the qualities of a good checklist? Or maybe a checklist is a checklist is a checklist? Just make something up and go for it. A checklist isn’t just any list of things, if you want it to be effective: · make sure the people that are going to use the checklist help create the checklist · limit the length of the checklist, four to six items, covering only the critical items · use the checklist as a tool to support, not replace, judgement and creativity You should also give some thought to how you want the checklist to be used. Are you expecting the actions to be acknowledged and physically ticked off? Or are you going to introduce this as a means of prompting thinking and action but not expect execution of the action to be checked? There is no right or wrong. The context in which you are using your checklists will guide how they need to be used. Understanding this is quite important. If you cannot engage people with using checklists, the best checklist in the world will not help you improve. A checklist that sits unused is a waste of effort. Spend time making the checklist as simple and useful as possible. As soon as you get a few checklist “wins”, point them out, discuss them and let the checklist “do its own talking”.

If you are interested in learning more about checklists you might like to grab a copy of The Checklist Manifesto: How to Get Things Right by Dr. Atul Gawande. The good Doctor saw value for checklists in a number of endeavors, including software development. There are a few extracts and overviews of this book on the web if you would a bit more detail before handing over a few dollars to a book retailer. To close I’d like to use the following from an Aviation Week article that quotes Dr. Gawande. 3

“….overcoming historic ignorance is less of a challenge in the field than ineptitude, the “instances the knowledge exists, yet we fail to apply it correctly.” While there is bountiful information available to medical professionals and most study for years to master their skills, the new challenge is to assure they “apply the knowledge . . . consistently and correctly. We have accumulated stupendous know-how. We have put it in the hands of some of the most highly trained, highly skilled and hardworking people in our society . . . . Nonetheless, that know-how is often unmanageable. Avoidable failures are common and persistent.” Disciplined use of checklists “provides protection against such failures.”

While the above specifically references medicine, change the reference to software development and the message still rings true.

Constructing a checklist that is useful takes time and thought. It needs to be open to feedback to get just the right “shape”. It needs to contain the right language (if you have a geographically distributed team the checklist that works well in one location may not be so good in another location). Persist with the effort and you’ll find yourself rewarded with a tool that can help you improve and maintain your quality levels.

1 When do pilots use checklists?

2Surgical safety checklists: do they improve outcomes?

3 Checklists and Callouts: Keep It Simple, Avoid Distraction, Prevent Ineptitude

Stress and work – Strategies that keep you moving forwards

 Women Testers, Edition 6, October 2015

Co-author: Annie Rydholm


What is stress? We often use the term, sometimes as a positive, sometimes as a negative and sometimes as a badge of honour.

1Stress is an everyday fact of life. You can’t avoid it. Stress results from any change you must adapt to, ranging from the negative extreme of actual physical danger to the exhilaration of falling in love or achieving some long-desired success”.

1Not all stress is bad. In fact, stress is not only desirable it is also essential to life”.

“Good stress” is a motivating force. It gets you out of bed in the morning, it makes you relish the challenges in front of you. It makes you sharp and alert, it gets you thinking. Testers work under many pressures, short and tight deadlines, software that is complex and challenging to understand, and sometimes, just plain old “stuff happens”. Sometimes the challenges can seem overwhelming, and your anxiety will start to rise and the “good stress” positives will start to diminish.

When bad stress builds to excessively high levels, it is serious, and medical intervention is required. This article is not about that level of stress. This article is about strategies that will keep you moving forward and help you stay energised.

Stressor 1: Lack of knowledge

Strategy 1: Write down what you do and don’t know

It’s not unusual to find yourself assigned to test a software change where you have little familiarity with the functions you need to focus on. I have over 15 years experience with a particular piece of financial software and I still find myself in situations thinking “how the hell do I test this?”

The reality is you do know something about the software, the functional change and your relationship to it. Give yourself some clear air, that might mean moving to a quiet space for a few minutes, stepping out to a cafe and grabbing a drink. Have a notepad and pen handy and make 2 columns. The first column is “What I know”. In this column you make notes about all the things you know about the project you are going to test. Doesn’t matter how small, write it down. You’ll often be surprised at how much you write in this space. Now add a column called “What I need to know”. In here you can make notes on things that puzzle you, knowledge gaps, just any question that comes to mind. When you are doing this you might find that considering these questions prompts your memory to give up more things you do know. Note these down.

You have now created a means of asserting some control. Talk to people involved in the project to get clarity around the questions you have. I can almost guarantee if you have a question on something, others will have the same question. When this happens you are identifying potentially harmful knowledge gaps and helping to strengthen the product. Feels good right? Not only are you learning you are helping improve quality. While you are having these discussions you can also validate some of the things you do know, this will help increase your comfort level even further.

While writing this article Annie and I spent some time discussing this strategy. Annie, not having used this idea before, tried it out and found that it worked well. Annie noted that just writing things down produced an instant feeling of relief. It took things out of her head and on to paper where she could focus on the ideas and sort the more important from the less important. It helped her make decisions about her next move.

Stressor 2: System complexity

Strategy 2: Create a model you can understand

When you start on a project, the project itself could be reasonably advanced, or, even if you are at project start up, the project does not play to your specific domain strengths. People on the project team are busy, the project is complex, you need to sort out exactly what you are dealing with. Between you and understanding are pages of documentation and very busy project team members. You need to find ways to reduce complexity. It is so much easier to think freely when you can establish the basics in a way you can understand them.

Find the paperwork you need to get a handle on. Most likely this will be a specification document. Read through it once, just try to get a high level overview. Maybe make a small note or two. Once done put it down, take a walk to the kitchen, make a coffee, kick back for a few minutes (and maybe a few extra ones). Now go back to your desk. Open the specification start reading and sketching. Start drawing out all the relationships you get from the document. You are now creating a model. Models are great because 2“Today’s systems are complex with many moving parts (thanks to modern multi-tier and distributed architectures) — models enable us to cope with this complexity by providing a visual abstraction layer that focuses on the higher level concepts in the problem domain and de-couple the “what” from “how”.

In cases where you do not have a written specification, you need to into “ information discovery mode” you need to talk to people who may have the answers (note: having a document does not mean you skip “information discovery mode”). The people could be designers, product owners, developers, any stakeholder relevant to the project. Talk to them and sketch relationship from what you know, then update your model by asking them again.

When you complete this exercise don’t expect it to be perfect, it doesn’t need to be. It needs to be good enough for you to have a visual model of the changes, that you understand, and how they impact the system under test. It needs to be good enough for you to use when talking to busy team members. It should help you understand components of the system under test and to identify areas of focus and conversation. Your models should be subject to continuous improvement.

Often when I do this I find it is the first time the team has sat down with a high level diagram that shows changes and impacts. It can be quite a conversation starter. An example of using this technique, and perhaps one of the first times I used it, I remember finding a bug in the design of a small project. As I mapped out relationships I create a path which showed contradictory actions (the document described a state that could not be allowed). I showed this to the project team who immediately recognised that I had indeed spotted an error. This not only helped the project, the conversation helped validate my understanding of changes and demonstrated that I was serious about helping the project be as good as it could be.

Stressor 3: What do I do next?

Strategy 3: Heuristics

3 “Heuristics do not replace skill. They don’t make skill unnecessary. But they can make skilled people more productive and reliable.”

Heuristics can be a great tool for both experienced and inexperienced testers. Heuristics are not infallible, they do not guarantee you are following the right path. Heuristics however do help you generate ideas about things you might or should test. The heuristic won’t tell you how to go about your testing, how to execute with the right focus. It will open pathways to  information that will assist you to generate thoughts, approaches, create meaningful questions. The heuristic will not do the work for you but it will help you make decisions about what you could do next. The most important thing they will do is get you thinking, and moving. A gentle push to gain some momentum is often enough to start generating that positive thinking energy.

Stressor 4: High work levels/tight deadline

Strategy : Prioritisation, information flows, working slow

Let’s get this straight, right out of the box. This is a problem, but it is not your problem. You don’t own this, but you do need to work with it and keep moving forward. The reasons for work levels getting significantly big against a deadline are many, but, generally, we get in this position because of systemic failure. An aircraft rarely crashes because of a single source of failure. A project is pretty much the same.

Make sure that your stakeholders are well informed about how testing is progressing. Be clear about things that are blocking testing and the impacts of those blockers. However, be realistic, also think about strategies that could help mitigate these issues. It is important to demonstrate that you are not just presenting problems but also helping with potential solutions. It is also important for you, your overall mindset, to think about solutions (positives) and not just problems (negatives).

The deadline remains set in concrete, your report on testing  impediments has been largely disregarded. That sucks but you cannot control others reactions and actions, so focus on things that you can control. Move your focus to agreeing priorities. Of the outstanding testing, what is the most important? Get agreement on scope priority. Work to this and report in terms of the priorities. By going into “priority mode” you immediately reduce the amount of testing you need to focus on and help your state of mind.

So now you want to go fast and really slash through the amount of outstanding testing. “If I go really fast we can still complete all the testing – that’ll impress everyone”. Don’t. The minute you think you need to “go fast” you actually need to “go slow”. Why? Rushed testing, testing to a “tests completed per day” target  is bad, you are focusing on the wrong goals. Rushing increases stress, makes you more likely to skip over things you would have otherwise investigated. It reduces your ability to clearly analyse and think. Give yourself permission to stay focused and calm and look for problems. You will find a sustainable and appropriate speed. At this speed you will do the right thing by you and your clients.

Clearly you cannot avoid stress, in reality you don’t want to. You do however want to maximise “good” stress and reduce any other type. In most cases simply doing something that will keep you moving in the right direction is enough to keep you positive and energised. We hope the strategies outlined in this article help you to maintain forward momentum and a positive focus.


1 McKay, Matthew; Davis, Martha; Eshelman, Elizabeth Robbins; Patrick Fanning (2008-05-03). The Relaxation and Stress Reduction Workbook (New Harbinger Self-Help Workbook) (Kindle Locations 189-191). New Harbinger Publications. Kindle Edition


3 <Source >








We are all thinking testers

When did we start using thinking as an attribute by which testers are, or might be, classified? It’s a question that I’ve pondered a few times. A recent visit to a website that classified group members as “thinking testers” brought this question back into my focus. I’ve heard more than once “everyone here is a thinking tester” or “only a thinking tester would do that” or “I am a thinking tester”. If we believe that “thinking tester” is a valid descriptor then surely the opposite attribute must also be true, a “non thinking tester”.  A computer executing regression tests is a possible example of a non thinking tester (although I prefer the term checking rather than testing in this space and I don’t agree with the idea that a computer can test).  I’ve yet to hear anyone call themselves a thinking tester in comparison to a computer. The assertion has always, to me, seemed to be “at the human level”.

Is it possible for a human tester (tester from here on in means human tester) to not think?  According to Scientific American the answer is No. Humans, from the dawn of time, have been hardwired to think.

“Optimal moment-to-moment readiness requires a brain that is working constantly…….Constant thinking is what propelled us from being a favourite food on the savanna—and a species that nearly went extinct—to becoming the most accomplished life-form on this planet. Even in the modern world, our mind always churns to find hazards and opportunities in the data we derive from our surroundings, somewhat like a search engine server. Our brain goes one step further, however, by also thinking proactively”

So, from a scientific approach, there are no non thinking humans, ergo, no non thinking testers.

Let’s move away from the scientific domain and consider the word itself. The Online Etymology Dictionary provides the following

Old English þencan “imagine, conceive in the mind; consider, meditate, remember; intend, wish, desire” (past tense þohte, past participle geþoht), probably originally “cause to appear to oneself,” from Proto-Germanic *thankjan (source also of Old Frisian thinka, Old Saxon thenkian, Old High German denchen, German denken, Old Norse þekkja, Gothic þagkjan).

Let’s dive into a dictionary and have a look at meaning of this word.From the Oxford Dictionary:

  • the process of considering or reasoning about something
  • a person’s ideas or opinions

and from the Cambridge Dictionary:

  • the activity of using your mind to consider something

There’s a lot of consistency in those sources. So the meaning of thinking can be considered reasonably stable across a long period of time. It’s not a word that has recently attracted new meaning. Whether we think of testing in ISTQB terminology and approach:

Software testing is a process of executing a program or application with the intent of finding the software bugs. It can also be stated as the process of validating and verifying that a software program or application or product: Meets the business and technical requirements that guided it’s design and development.

or we favour the definition from the Rapid Software Testing namespace:

Testing is the process of evaluating a product by learning about it through exploration and experimentation, which includes to some degree: questioning, study, modelling, observation, inference, etc.

I struggle to conceive of a way of doing either that does not involve consideration, reasoning, opinions and ideas. Even deeply detailed, low level, stepped out test cases require thought when they are being executed. In fact those really detailed test cases, if out of date, can require a considerable dose of thinking to get through them. Working out if a variance, an unexpected outcome, is a software issue or user input mistake and what triggered, or may have triggered, the variance takes thinking. Some issues are really elusive, reproducing them requires thinking. Testing, regardless of whether we view it as good testing or bad testing, requires thinking.

When we refer to a “thinking tester” it is far too general to be useful. We are all “thinking testers”. Much in the same way the we are all “breathing humans” (have you ever felt the need to point this out in conversation?). Thinking is useful and it has many dimensions. Perhaps we need to consider various types of thinking. Thinking can be critical, deep, reflective, lateral, quick, slow, analytical, concrete, abstract, divergent, convergent, the list goes on. In understanding types of thinking, how we apply them and how they apply to us we add depth to our toolkit. We start to get a good view of our thinking strengths and weaknesses, we get knowledge on where we could improve. Perhaps we can focus on improving our thinking skills and let others within the community, our peers and those we serve,  recognise our thinking skills through actions rather than words. When the proof is on display it might just be our need to use the label “thinking tester” disappears and we settle for being a Tester.








Community -It’s Our Future

Community: Self-organized network of people with common agenda, cause, or interest, who collaborate by sharing ideas, information, and other resources (

Community, hanging out with a group of people that make hanging out an enjoyable experience, something you want to do. It’s more than that though, look at the definition I’ve chosen, the key attributes, self organising, common agenda or cause or interest, collaboration. It occurs to me as I write this that community is a good description of an agile team (honestly, that is a side thought, not why I started this blog). When I read these attributes it reinforces to me why many people like to be part of a community, to feel a sense of belonging to a group in which they have common goals or interests. Working together to achieve great outcomes is a good feeling. It is a give and take activity and that’s one of the things that, in my opinion, makes community special.

The Test community, in my mind, is a special one. It is full of diverse people, diverse experiences and attitudes and the majority of them are in to sharing and caring. I think most testers see themselves are being on the periphery of software development. Not really understood by many outside their testing peers.I think the Test community is quite special in the way it helps others, it’s not like any other community I have been a part of. You can connect quickly with people in the Test community and they share experiences openly and honestly.

Seek true positive energy, a place where you can help build the community in a caring and authentic way. Spend time finding those testers that will support you, you won’t need to give them anything because their reward is an enormous feeling of satisfaction through helping someone solve a problem or improve the way they do something. Making a connection for no other reason than being a decent, caring human being, for most, is a genuinely satisfying reward.

In closing I want to send a big thank you to those in the test community that have provided me with great support over the journey. Of late there are too many to mention but a few really stand out. Lee Hawkins, a truly great bloke, a great thinker, a brilliant friend and integrity beyond question. Michele Cross who has been a great friend and has listened to a few rants (she does seem to like a rant). Michele is genuinely funny and always at just the right moments. Jyothi Rangaiah, editor of Women Testers who gave me an opportunity to become a reviewer and has provided incredible support, positive feedback and the opportunity to engage with the test community in a very satisfying way.

If you’re reading this, and you’re a tester and you don’t identify with the test community, make a move to join it in some way. Twitter, LinkedIn, test meetups, join AST and involve yourself in their offerings, whatever you might select, just get into the community and talking. You wont regret the investment.



Things we say, things we don’t mean

The Ministry of Testing recently tweeted a list of  words that make testers feel “icky” and those that make testers feel “good”.  I have inserted the list below.




The list is crowd sourced, provided by testers who responded to a request to provide words that they felt belonged in each category. It is undeniably a good thing to reach out to a community and ask for input. In this case words, and I would hazard a guess, words that resonate emotionally with those that provided them. It is hard to think that there is an absence of emotion in the selection of words. The MoT introduction includes the following:

  • we have an image problem
  • it makes them feel……..

I’m unclear how gathering a group of words, especially those that highlight “things that make them feel icky or bad” helps address an image problem. Image problem itself is a likely minefield of emotion and a different problem to things that make you feel good or bad. I’m somewhat surprised to see a list that appears to have a similar volume of “good and bad”. I do wonder if this really reflects the actual responses.

Arguably  we get an interesting snapshot from this exercise, but, at the end of the day, it is almost devoid of meaning. Where is the context? I mean I can look at this list and see a list of words that testers appear to favour and those they don’t, but how does that help me improve things? I genuinely struggle to understand, as an example selection, why

  • Quality Assurance
  • End to End Testing
  • Execution (is this a political corectness statement?)
  • Offshoring

are on the icky list. As a colleague pointed out to me, offshoring on the icky list is just plain offensive to a of part of her team (they are testers in the Philippines, what the hell did they do to be labelled icky?).

Likewise with the words on the “good” list. Why are these words inherently good? They may make a tester feel good but the goodness is in their use in a context where they are useful and the tester knows how to be effective with the choice. Mobbing or BDD might make you feel good but are they good choices in the context of an engagement?  I find it interesting that:

  • fast
  • complexity

find their way on to the good list. When I think of fast I immediately think of testers that feel good if they are just “pumping through the work”. That is an anti-pattern in my mind if you want good outcomes. Same with complexity. Do testers really feel good about complexity? It would make more sense to me if simplicity was on the list. Without context I’m just guessing.

As it stands the list is just words. If we want to make this a platform for change then lets generate understanding of those words. Lets get the community talking about why words are “icky” and why others are good. Words alone do not improve practices. People with a common understanding, working as a group with common cause, improve practices. This might just be an opportunity to open some excellent dialogue that generates further improvement. The challenge is ours and yours.




Time To Say Farewell

Welcome to my blog. This time I’m not writing about testing, management or problems with estimates. This blog is dedicated to something much more real, something much more relevant than our “9 to 5” lives. You see, in the early hours of Monday 29th February, my Father-in-Law, Giuseppe (Joe) Marinelli, passed away. He’d been sick for a long time. Various ailments that, brick by brick, constructed a wall he could no longer grapple his way over. It started with a diagnosis of diabetes. Eventually he lost a leg, amputated at the knee due to gangrene, courtesy of diabetes. You’d think that just might be enough for one lifetime, especially for man that had worked hard and tirelessly for most of his life. Retirement should bring you something better, right? Nature doesn’t play by right and wrong, fair and unfair, it simply rolls on handing out whatever cards are in your deck. Sometimes, if luck is on your side, medical science, natures own change of mind or God (should you choose to believe) gives you the opportunity to hand back a few of the cards and ask for a better hand. Joe didn’t have that luxury, he was out of luck. It’s hard to reconcile in some ways. As a practising Catholic with firm beliefs he should have had a vast cast of Saints and the big Guy himself helping him out. Perhaps it’s easier to reconcile if you hold faith close to your inner most beliefs. While Joe was getting on with walking on a prosthetic limb he was diagnosed with dementia. He fought both dementia and diabetes for while at home with his wife Giuseppina (Josie). Then the going simply got too tough, the cliffs to steep to climb. The last six years of his life being spent in a nursing home where he could receive the dedicated, around the clock care he required.

I could simply farewell Joe at this point but if you’ve read this far he needs to become more than a man racked by relentless diseases. He was a powerful man. To be honest, when I first met him, and for a while afterwards, he could be quite intimidating. Not sure he meant to be, but he was. Like all of us, he was not black and white, but a mixture of infinite shades of grey that blend to produce both lighter and darker elements.  A mix of complexity that makes us distinctly human and means that we are not perfect beings.

When you leave your home town of  Musellaro, Pescara in Italy in 1955, aged 20, bound for a land called Australia you probably learn a bit of resillience. He travelled with a few family members to help set up for family that would follow later. A year later Josie made the same trip, they were married in 1957 and their first daughter born in 1958. For all but the first few moths of his life Joe lived in the same house in Abbotsford. He and Josie raised 4 children in that house, not big by any means, but comfortable, safe and more than being a house, it was a home.

I can’t consider this story complete without mentioning that Joe was (is) a Holden man. We even made sure that his final ride would be in a General Motors Holden vehicle, the big lion sitting proudly at the front. Joe worked at the GMH plant at Fishermans Bend, Port Melbourne for 40 years. Says a lot about his character. There will never be a bigger or better advertisement for a brand than Joe and Holdens. He loved those cars and the people he worked with (and, as far as I can tell, they loved him as much in return).

In a few days we lay Giuseppe to rest. Forever his legacy will live on. Born in Italy, later becoming a naturalised and immensely proud Australian (he loved Slim Dusty and Holdens – do I really need to say more). His stories, his way of talking, his love of food. I’ll always remember how once he wouldn’t eat dessert unless it was fruit. Then it had to be at room temperature because of sensitive teeth. Somewhere along the way, during his illness, that changed to the point he loved dessert and would chomp through frozen cheesecake.  At some point, at the wake, I expect a bunch of Joe’s stories, and stories about Joe, to be told and laughter to follow. These are stories his Grandchildren have heard and ones that his Great Grandchildren will hear.

Joe, you helped produce the young lady that became my wife and my soul mate. We have two kids that you loved unconditionally. You were part of delivering a life I love. Rest in peace, free of pain. You will live on through your family and their memories.


You Can’t Always Get What You Want or Can You?

And no, you can’t always get what you want
No, you can’t always get what you want
Well, no, you can’t always get what you want
But if you try sometimes you just might find
You get what you need, baby
Rolling Stones – You Can’t Always Get What You Want

First blog of the year, inspired by conversations and observations. Three stories I’d like to share.

Mr. Play It Safe was afraid to fly
He packed his suitcase and kissed his kids goodbye
He waited his whole damn life to take that flight
And as the plane crashed down he thought
“Well isn’t this nice…”
And isn’t it ironic… don’t you think

Alanis Morissette – Ironic

Scene 1:

Client Relationship Manager: “The client isn’t happy. They believe the project doesn’t satisfy their acceptance criteria”

Me: “I don’t remember them sharing acceptance criteria”

CRM: “They are drafting them for a meeting tomorrow”

Me: “You get the irony of this conversation, right?”

How on earth do we get to a point where this conversation can happen? Software vendors don’t work in a vacuum. We build software because clients believe the changes will improve their ability to conduct business, improve their profitability. As much as we know our software, and we know our industry, we don’t intimately know everything about the clients business. We call it the “clients business” because it belongs to them. Do they not have a responsibility to have some input? I truly want to help clients by delivering them high quality software, I don’t want to own or run their business.

Lessons: You cannot underestimate the value of bringing the client on the journey.

Create and maintain a partnership mindset.

But I’m just a soul whose intentions are good
Oh Lord, please don’t let me be misunderstood

The Animals – Don’t let me be misunderstood

Scene 2:

The meeting is held, the acceptance criteria delivered. I wasn’t part of the meeting so my involvement was ex posto facto. On reading them I was surprised. The acceptance criteria were in reality a series of very high level, broad statements. We could use these criteria and claim we had met them. Equally we could also mount a case that we had not satisfied them. It was a great reminder that we need to work with our clients, guide them to provide the kind of information we find valuable. There was a surprising delta between what I expected and what I saw. Time wasted by the client. Waste that can be prevented.

Lessons : If you have specific information requirements, be explicit about them. Ensure they are understood.  High quality information from the client allows us to more specifically build them high quality software that provides real value

You cannot underestimate the value of bringing the client on the journey.

Create and maintain a partnership mindset.

Is there anybody out there?
Would you hear me if I screamed or if I cried?
I am looking for an answer

Pink Floyd – Is there any body out there

Scene 3:

“The client is frustrated with the way we are communicating with them”

I’m actually quoting someone but I’m guessing this is not a one time unique utterance. I’ve heard it before, words might differ, the meaning remains the same.

I have a communication structure that I believe works. It’s not unique, I didn’t create it, you’ll nod acknowledgement as you read it. Communicate in the following order:

face to face, phone call, e-mail.

Face to face – body language, eye contact, immediacy, personal warmth and do not understate that many people will recognise that you have made a special effort. How much better is it to run a white board session in an office while working through problems with your client? Sure, you can run a whiteboard session using an on-line app, but chances are you will experience very little of the dynamics and relationship building you experience when compared to face to face outcomes. I’ve dealt with clients that can really rant and rave over the phone line. Face to face it never happened. Proximity and other dynamics remove this and the meetings are far more productive.

I have found a level of resistance to organising face to face meetings. It’s expected of Consultants and Client Relationship Managers. Beyond that clients are often reticent. It drags people away from their “core activities” (business speak for these people are now generating cost rather than revenue). That’s, in my book, a very limited consideration of the game in progress. My experience tells me that phone calls, while generally shorter in duration than a meeting, will be far greater in number and frequency. They will also feature a reduction in absorption of information. Is this a low cost option – not in my opinion. E-mails, forget them, except when there is no other choice, and then, follow up with higher quality communication. I rarely e-mail colleagues these days, I prefer to walk to a desk and interact with a person.

As a business we need to work with our clients and understand how we most efficiently generate value for them. We need to examine old habits, perhaps ones we have trained them to adopt across years of business.

Software vendors often get blamed for failures. Clients under pressure, wanting a solution but not the one they outlined with their requirements. Vendor clients under pressure from third party business because the software solution is to service them. Humans look to deflect criticism and defend their turf by pointing the finger at “next in the line”. My experience is that significant fault lies on both sides. In itself that is immaterial. The real challenge is for vendor and client to build a strong relationship, move beyond blame and focus on quality.

Lessons: What you say and HOW you say it is important. Not all forms of communication are equal.

You cannot underestimate the value of bringing the client on the journey.

Create and maintain a partnership mindset.

That’s it folks. Thanks for stopping by. Hopefully I’ll see you again soon.






The Great Circle

This article was initially going to be something of a rant, it still might go that way. Neil Killick recently tweeted how he loved the honesty of a good rant and there should be more of them (or words to that effect). Inspired I tweeted back that he wouldn’t have to wait long. Sorry Neil, not this time, although the chances now rise of the next blog being rant driven (of course your definition of rant might be fulfilled by this article).

Recently I’ve been musing how things can circle around in unexpected ways. How themes can, and often do circle around until you see that a link has been formed. Multiple pieces of information, each unique in their own way but somehow morphing from linear fact or opinion to smoothly join to another formerly linear slice of wisdom. Eventually they weld to form a nice solid shape that hangs in your consciousness. A shape that increases your knowledge in a useful and meaningful way.

In a previous blog entry I mentioned “Obliquity” by John Kay and it’s main line of thought. I think I might have said that it is a sensational book. If I didn’t then let me say, it is a truly sensational book. If I’ve already said as much, well, it’s worth repeating.  I’m currently reading Dan Pink’s book “Drive: The Surprising Truth About What Motivates Us“. This is also an amazing book. I have to force myself to put it down to do other things (like work).

In recent times I’ve had a series of discussions with people (they are all managers) where we largely discussed approaches to people management and motivation. In summary, just to keep this article brief, command and control is alive and well. Much like ISTQB, command and control seems to have a level of acceptance that it should not have. In actual use they have roughly the same relevance and not nearly enough people questioning why or looking for better approaches. That’s a little depressing. Managers want staff that produce sparkling software that makes clients happy, on tight lead times and they want to control them, within an inch of their lives, to that delivery. They want to control the solution creation rather than trust people to do what they were hired to do. They have a management goal, delivery on time, on budget, all agreed features delivered (to add some perspective here, those features were agreed months in advance). The managers are directly attacking a problem that is complex and has multiple flexing parts. This is simply not optimal. That’s not obliquity in action. Obliquity would require us to tackle smaller problems, experiment, build small blocks, ask questions, be flexible and not assume we can charge directly at the final prize. Is anyone else thinking Agile?

Clearly Dan Pink and “Drive” forms another part of the circle. I don’t want to spoil what is a very good book so I’m not going to dive in too deeply. This book spends some time exploring the impacts of extrinsic motivation (carrot and stick) and intrinsic motivation (the joy of just doing something). The notion of intrinsic motivation is, relatively speaking, new. The book asserts intrinsic motivation is not well understood or incorporated by Management in general. My personal experience leads me to agree strongly. This is overwhelmingly true for most managers I’ve dealt with (note I didn’t say all). One of the really interesting things in Drive is the relationship between extrinsic motivation, intrinsic motivation and knowledge work. I’m going to suggest that software development is very much in the knowledge work domain. Consider the following extracts from Drive (the term “third drive” refers to intrinsic motivation)

“Human beings, Deci said, have an “inherent tendency to seek out novelty and challenges, to extend and exercise their capacities, to explore, and to learn.” But this third drive was more fragile than the other two; it needed the right environment to survive. “One who is interested in developing and enhancing intrinsic motivation in children, employees, students, etc., should not concentrate on external-control systems such as monetary rewards.”


Lakhani and Wolf uncovered a range of motives, but they found “that enjoyment-based intrinsic motivation, namely how creative a person feels when working on the project, is the strongest and most pervasive driver.”


“Careful consideration of reward effects reported in 128 experiments lead to the conclusion that tangible rewards tend to have a substantially negative effect on intrinsic motivation,” they determined. “When institutions— families, schools, businesses, and athletic teams, for example— focus on the short-term and opt for controlling people’s behavior,” they do considerable long-term damage.

Both Dan Pink and John Kay are learned men. Their books are heavily supported by credible research, findings of others that are recognised a leaders in their fields. Why the hell is Management not keeping up with the knowledge that is available, why are they not taking in what science has already established? People are entitled to expect better (do Management not expect their people to “continuously improve”?). Is it that hard to trust someone to do the job they were hired to do? Can teams, team members, not be trusted to follow their  intrinsic motivation (their third drive) and produce innovative approaches, dynamic, joy making solutions for customers. Just perhaps we need new Managers. Ones that will provide the required freedom that intrinsic motivation requires to work at its best. Perhaps we need Managers that would never ask people to “think outside the box” because that means they already acknowledge that their people are already “in the box”. Perhaps we need Managers that do not tell people to “feel empowered” because just by saying that they acknowledge that the standard status is “you’re not empowered”.

The “almost last part of this circle” comes from a book The Critical Thinking Toolkit: Spark Your Team’s Creativity with 35 Problem Solving Activities  by Marlene Caroselli. I plan to run weekly activities with the agile team I belong to. This book has some great activities. A quote that really took my fancy:

Imagination is what takes vision out of its tunnel.

Then I found something that really disturbed me:

“…….a famous longitudinal study of creative potential followed a group of students over a 17-year period. The same test was administered each time to these students. When the students were five years old, 92% of them were found to be “very creative.” By age ten, that figure had dropped to 37%. When the children were fifteen, they were tested again. At this age, the number of children deemed “very creative” had dropped to 12%. Finally, the same students were tested in college. How many were found to be “very creative” at this age? Only 2%!”

We are actively killing creativity at work through bad management and also killing it before our children get out of school. That really is something to think about.

Perhaps it is time we start consistently thinking about “circling” to solutions for complex problems. Give up treating them as 100 meter sprints. In a 100 meter sprint you want to go direct, you want to break the tape first. But that direct approach is fine, this is not a complex problem. Your mission is to run as fast as possible, get there first. However if someone decided to trap that 100 meters with lasers, explosive devices, snipers, and the like, would you still think direct or would you be a little more creative and oblique?

One last thing, a personal experience. Last week I put a critical thinking exercise on the team whiteboard and also a copy in a more central location for others. Within 60 seconds of noting that I’d placed a problem on the board 3 team members went over there and started collaborating on a solution. No prompting, no requirement to do this, no prize on offer, but they did it any way and worked until it was solved. Just chance? I don’t think so. I actually think that it is a very powerful demonstration.

That’s enough from me. Thanks for dropping by. I hope to see you again.




%d bloggers like this: