The Agile Mindset - Beginner's Mind, Fundamental Attribution Error
The wisdom of the ages informs us, "You can't judge a book by it's cover." Except we judge books by their cover all the time.
(This article is part of an on-going series dedicated to developing Agile mastery. Each post offers value to students on this journey, however, there is an advantage to those who start at the beginning.)
"From Rusticus . . . I learned to read carefully and not be satisfied with a rough understanding of the whole, and not to agree too quickly with those who have a lot to say about something." - Marcus Aurelius, Meditations, 1.7.3
When I'm working with a new company or forming a new team or working to restore an existing team, I sometimes lead with a particular story as part of my introduction. It's a story of success. But more importantly, it's a story of one of my biggest professional failures.
The story begins with a small software company working in the healthcare space. They knew they had a problem but couldn't get a handle on the issues. Everything they tried seemed to make the situation worse. Three million dollars worth of client contracts were on the line and current customers were unhappy. Very unhappy. The development of highly requested features deemed critical to the company's viability were months behind scheduled. Even worse, the current platform was unstable and customers were growing increasingly skeptical of the underlying security of their data. This is a bad thing with any product. Doubly so for software products that deal with personal health information.
Through a lucky mention of my name in a casual conversation between the company president and a mutual colleague, the company reached out to me to see if I could help. After an initial conversation, the situation had all the earmarks of too much of the wrong kind of management. I didn't want to fix their situation, but I agreed to evaluate the teams, software code, and supporting systems. I would deliver my assessment and several suggested courses of action.
As I got to know the software development team it became clear the issues were not of their making. The company president had no experience in leading a software company and had made the mistake of hiring a friend to fill the marketing VP spot and place him in charge of software development. This is very much like putting the fox in charge of the hen house. The development team was pulled in multiple directions and priorities changed from one day to the next. There was no clear plan for the product and work was driven almost exclusively by the loudest customer.
An extremely negative report from an independent security analysis of the company's computer infrastructure combined with my analysis of the software and development practices was enough for me to recommend a couple of clear courses of action. The company president liked what he read and began to work very hard to recruit me for the task of implementing the changes I proposed. Normally, saying "no" is easy, but I had formed a bond with the software development team over the course of several weeks. This group seemed to me to be a solid tribe with considerable development talent but were caught in an unpleasant management environment and hobbled by the lack of a strong technical lead.
My analysis of the situation had revealed that, among many other problems, the senior software developer, Dan, was a significant problem. Dan had built the flagship application from scratch some 8 years prior, but he had grown complacent, his code was horrible, and he wasn't liked by the rest of the development team. Yet because the company president lacked a basic understanding of how computers worked, he had put all his trust in Dan. Eventually, I agreed to help with implementing my recommendations. But I had two conditions: 1) The marketing VP has zero jurisdiction over the development team and 1) Dan was released from the company by the marketing VP before I took over as IT Director.
After a few days, the company president agreed to my conditions and I signed on for a 12 month contract. I was asked to be present at Dan's termination in case the marketing VP needed me to chime in with any computer-speak to explain the situation. It wasn't until later I learned the marketing VP and the HR VP - both of whom one would think new Dan better than I - were afraid he would respond emotionally, perhaps even violently. So I and a security officer were there to help dissuade any such response just by our presence. Fortunately there was no need. Quite the opposite. When Dan got the news, his face took on an expression of relief. It was as if a great burden had been lifted. As if something he had expected for a long time finally came to pass and it was no longer a burden to him. I've been face-to-face with angry men, desperate men. Dan had none of that look about him.
Jumping ahead 12 months, I can say the implementation of Agile practices was a resounding success. The legacy software was so poorly written and maintained that it was the first and so far only time I've recommended a complete rewrite a company's flagship application. The software development team rose to the challenge and exceeded my expectations as their productivity and morale flourished under a new management structure and direction. The second security audit ten months after I started work found less than ten minor issues that were resolved within a few days. Customers were happy and we were finding it easier to sign contracts.
Yea! I was the hero!
No. Not really. Of course, I gave high praise to the team at every opportunity. They deserved it and it was their work that made me look good. I led, they delivered. But there was a dark side to this story. Something that has dogged me for many years since I closed out this gig and moved on. I had missed something very important.
When a software developer who works with sensitive information is let go under adverse conditions it's a common practice to have them escorted out of the building by security immediately after informing them. They aren't permitted to access any company assets on their way out the door. So it was left to me to clear out Dan's office and box up his belongings. Since we were a company that dealt with personal health information, I couldn't just box up his belongings and hand them over to him. I had to go through everything he had in his office to be sure nothing related to company business was leaving the building.
The first thing I noticed as I began this task was how much food Dan had stashed away. Not just the usual munchies, but also food items that one might take on an extended camping trip. There was toothpaste, a tooth brush, and an electric razor. All the signs that he was living in his office, at least part time.
Next were the file cabinets. Here's where the picture became clear. Dan had been working with a divorce attorney for a couple of years. It wasn't an amicable separation. Out of necessity, I had become privy to information I really didn't want to know. Worse, I should have known at the time he was struggling with something outside of work. All the signs were there. He looked to be in poor health and sleep deprived. His apathy at work certainly was cause for concern. More than anything, though, it was this new information matched with my memory of Dan on the day he was terminated that had a profound impact on how I manage and work with teams to this day.
This is a somewhat lengthy preamble to get to the subject of the article's lesson: A particularly insidious cognitive bias known as the fundamental attribution error.
The Fundamental Attribution Error refers to a logical fallacy: our belief that the way people behave in one area carries consistently over to the way they behave in other situations. We tend to assume that the way people behave is the result of their innate characteristics and overrate the influence of their personality. We underrate the influence of circumstances and how they can impact people’s behavior.
To be blunt about it, I had judged the Book of Dan by reading it's cover.1 So, future master agilist, the message is clear: Don't do that.
Easier said than done, especially when strong emotions are involved. In Dan's situation, since it was a small company, emotions were high for everyone in the company. With this much visibility, keeping your feet emotionally grounded can be a challenge. There can be a lot of energy and spin happening in the moment, so the best way to counteract the effects of the fundamental attribution error is to prepare. Your task this week is to complete the following.
Recall an incident for which you had strong feelings related to the outcome but you learned after the fact there was considerably more to the story. We've all had these experiences. With pen and paper, write out the story and pay special attention to the things you believed before the outcome and the things you learned after the outcome that counteracted your earlier understanding. What could you have seen (or more accurately, actually did see) that were clues to a much different story of events? Now go further and recall a second and a third example.
With one of your recalled incidents, imaging the same people displaying the same behaviors in a completely different context. Rather than the office, what if the incident took place at an amusement park or a graveyard or the middle of the woods? What behaviors seem out of place? What behaviors still make sense in the new context?
Pick one person and write out a story of their day leading up to the incident. Work to imagine things they might have experienced which could account for how they were behaving.
Now for the hard part, in light of the work you've done above, write out the specific judgments you made that resulted in the initial conclusions you had about the incident. What was your rationale behind each of these judgments?
If you have any questions, need anything clarified, or have something else on your mind, please use the comments section or email me directly.
Photo by Mediamodifier on Unsplash
While I went on to great success in the company - the team and I won the company's highest award for achievement - that success rings hollow with memories of Dan. How could I have missed those signs? What could I have done to help Dan regain a footing and become a productive software developer again? "What's done is done," I told myself. But I also told myself, "Never again." Through no design of his own, Dan showed me the weakest part of my management capabilities. This experience was the beginning of a very long and continuous journey toward understanding people and developing a genuinely curiosity about what motivates and excites them. I heard a few years later that Dan had landed on his feet. And for my own self, I went on to greater successes that were built on empathy and curiosity more than simple technical prowess.