I once asked my therapist (yes, I had one of those; more people should.) what personality traits I should watch for to signal personality disorder. He said, "
lack of self awareness and the inability to change". In other words, everyone is at a different stage of emotional growth, but those two things signal that a person can become healthier, even if they are not currently. For example, narcissism is essentially some part of the psyche getting stuck in early childhood developmental stages, often because of trauma between the ages of two and four.
But, this isn't a post about personality disorders; it is about organizations and why they fail. Organizations, like any complex organism, have a personality. Oftentimes this follows the personality of someone in leadership or a combination of people. They can be overly cautious or reactive or arrogant or a hundred other things.
This tends to manifest as patterns that repeat themselves within the
organization - think fractals. If the org (the organization, the
organism) lacks the self-awareness to spot those fractals, they will
continue indefinitely, for better or worse. Let's take a look at the
way some of these things manifest.
Reactivity
If an organization is reactive, this often manifests in frequent changes in direction. There will always be some market trend, competitor action, or customer request that seems all important in the moment, and the reactive company will drop everything to address it. The signs are easy to spot:
- A trail of unfinished projects
- Teams regularly missing deadlines because they are busy putting out fires or estimating potential projects.
- Rapidly accumulating technical debt, because there is never time to go back & fix it.
The problem is that these companies end up spinning their wheels. So much time is spent context-switching that more valuable long-term work never gets done.
There is a saying, attributed to a variety of people, which I repeat often to my teams: "Slow is smooth, smooth is fast". Frenetic action rarely saves time. In my experience, as pressure mounts, so does the tendency to become reactive. I picture an army bracing for battle as the enemy charges. The commander screams, "Hold the line!" because being reactive in that situation means the line breaks.
Like any personality attribute, reactivity exists because it is advantageous in some situations. For example, in an early startup, the ability to pivot quickly can mean the difference between the company surviving or failing. But, at a certain scale, it becomes a weakness. At scale, customers expect a certain level of polish to features, a certain level of reliability, a certain level of performance. Those things rarely come from quick & dirty solutions.
I would be remiss if I didn't mention something: reactive companies can be exciting - in the same way that adrenaline sports are exciting. They are exciting because there is a chance that things could go very badly. Those quick & dirty solutions breed a firefighting culture - exciting, and it will kill your company.
Resistance to Change
Perhaps the polar opposite is resistance to change.
Andrew Harmel-Law had the keen insight that code often follows the personality of the person who wrote it. I have seen this firsthand in an organization that had a personality resistant to change. Dependencies in the code staying just ahead of end-of-life, and upgrading them often became an existential problem.
A common characteristic of these companies is that products, code, & services stagnate and become so expensive to maintain that they are often completely replaced rather than being reworked. The catch is that, unless the company's personality has changed, the replacement will be just as rigid and will, in turn, be replaced after a few years.
These companies often exist in non-glamorous industries with low profit margins because they wouldn't survive anywhere else.
So, What is to be Done?
How do we build companies that can adapt in a healthy way?
First, I think we prioritize hiring people with the attributes mentioned at the outset: self-awareness & the ability to change. These people will be adept at spotting patterns within the org and advocating for change when needed.
Second, we balance weaknesses through collaboration. Smart organizations build diverse teams. One person's weakness will be another's strength. For example, people resistant to change like consistency. That is a strength in some situations. That personality type might enjoy maintenance work in on a stable product in which they can finely hone their skills to that environment. Another personality type might enjoy the novelty of a new & evolving project.
This brings me to a common anti-pattern. I often see companies break up high performing teams. The thought is that they will spread the members of that team elsewhere to raise the performance of their new teams. This isn't always misguided, but it ignores the group dynamic. A high performing team owes as much to the relationships between the team members and their ability to collaborate as it does to the abilities of each individual.
Third, perhaps we apply software development processes to people process:
A/B Testing
Did you know that the Amazon/Instagram/Gmail you see may be different than many other people? I don't mean just the content, but the structure of the page, the colors, etc. These companies are constantly trying different things with test groups and tracking the results on product usage.
Yet I rarely see this in org structures. Most orgs have a consistent structure from top-to-bottom, with minor differences where some managers tweak things. What could we learn if we tried different structures & compared the results?
Observability
In a hosted software system, we typically use observability tools. That is, we have real-time indicators of system performance. How long is customer wait time? How full is our database? Have any errors occurred?
What indicators could we track for people systems? Most "metrics" focus on outcomes, e.g. X revenue in Y timeframe. I propose tracking process metrics:
- What percentage of POCs resulted in the project being pursued?
- Similarly: What percentage of projects estimated were pursued?
- What is the average lifespan of a product or feature?
- How often can new features be released?
- What percentage of releases require human intervention?
- How happy are members of the org? (Happy people work harder.)
- Do people like their colleagues?
We could make quite a long list, but the point is that we often don't monitor our people process like we do our product performance. When we do, it is often at the individual level and using some silly metric like lines of code written or hours per day the mouse is wiggled, because we don't actually know what to measure.
Meta Analysis
This isn't from software development, but from scientific research. In the world of peer-reviewed research, there are meta analyses - that is, a study summarizing the findings of many other studies on a given topic. In an organization, the "study" might be project retrospectives. How many companies do you know that do a meta-analysis of their retros? Let's be honest; most companies don't do enough retros to even consider it.
Retrospective meetings are an oft-recommended practice. However, in my experience, most companies conduct them
only sporadically, after major failures, and often the findings are not
turned into organizational change.
The lesson? Do retros. Every time. Then analyze them as a whole, and build a mechanism to ensure change results.
Conclusion
All organizations have weaknesses. Those with the ability to spot & correct them will thrive; those that do not can only hope to get lucky.
Comments
Post a Comment