Background
I’d like to share a story about failures I experienced as a software architect which taught me the lesson "architecture is about people, not technology."
I was working as the software architect for a company in the healthcare space. This company provided online services about physicians and medical facilities in order to help the general public make informed choices about their healthcare decisions. The organization employed approximately 20 application developers and testers and a little more than that as data and ETL developers. My primary responsibility was to help the developers in creating and adopting good architectural designs and practices.
Outcomes
Despite my best efforts and some initial successes, I later considered myself a horrible failure in this role. My interactions with the teams were sporadic, and when they happened, they were strained. Adoption of my ideas by the team members was limited, at best. Furthermore, a rift between the teams and management (including myself) formed and increased over time which caused mistrust on both sides.
Mistakes
At the time, I suffered from a couple of syndromes. The first was SPITR, or Smartest Person In The Room. This is the mistaken belief that I know more or better than others around me. Even though I was not the smartest person in the room, I sure thought I was! After all, I was the expert; that’s why I had the fancy title! I had been doing development for far longer than anyone else in the organization, and I knew the technologies we were using much more deeply than anyone else. SPITR syndrome is deadly for relationship building, and it caused me to view the team members as inferior, spiteful, and unappreciative of my knowledge (oh, how arrogant I was)!
The second syndrome was ODOR, or One Definition Of Right. To this point in my career, I had a core belief that if someone could give me enough information, I would uncover the single right way to implement something. I thought of my job much like a sculptor who chips away at the superfluous and unimportant chaff until what remains is the one thing that must be the "right" way to do something. This attitude made me rule out great ideas from others very quickly, causing me to be dismissive of others and their opinions. In my mind, I had considered their perspective and had already reasoned why those options were invalid, but that’s not how I came across. I was perceived as judgmental, arrogant, and dismissive. And, as the saying goes, perception is reality.
Lessons Learned
It took a bit of time, but I finally learned what I did wrong. First, I needed to counter my SPITR syndrome. That happened when I realized that I have only a single perspective, and my particular perspective was much less valid than the perspectives of those doing the work on a day-to-day basis. This was hard for my ego to accept. As smart as I thought I was, I wasn’t smart enough to recognize the daily and hourly impact of my architectural decisions. Said another way, the consequences of my choices were born by the team members rather than by myself. I finally recognized this fact, and now I seek to make sure that the people impacted by decisions are the ones making those decisions.
Second, I needed to counter my ODOR syndrome. This one took a bit longer for me. Ultimately, I had to realize a couple of truths. First, there is no single “right” in this world, not with technology, and certainly not with people. Second, what is right pales in comparison to what is good. Good beats right every moment of every day of every year of existence. I lost sight of what was good for people in the search for the right technology and the right design decisions.
The ultimate lesson can be summed up in this principle: architecture is about people, not about technology. I’ve seen incredibly simple and elegant architectures fail because the people maintaining the architectures were not bought in, and I’ve seen the ugliest and most over-complicated architectures succeed because the people maintaining them owned the ideas. We can talk all day long about architectural trade-offs and non-functional requirements, but none of these matter if we lose sight of why we do things: people.
Agile Reinforcement
We can tie these lessons to a couple of principles from the Manifesto for Agile Software Development. The first is "Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done." Trust is of paramount importance to getting to good solutions. If we don’t trust the people doing the work, the problem is not with the people, the problem is with us.
The second principle is "The best architectures, requirements, and designs emerge from self-organizing teams." This is a hard one for many architects to swallow, especially when we are not embedded in the teams. It’s easy to fall into the SPITR or ODOR syndromes. However, dictating architectures and designs is not emergent. Trusting teams and allowing design and architecture to emerge is crucial for success.
SAFe Reinforcement
From a Scaled Agile Framework perspective, there are a couple of additional principles that apply to this lesson, as well. First, is "unlock the intrinsic motivation of knowledge workers." This very much parallels the first Agile Manifesto principle I mentioned previously. However, this principle additionally reminds us that people are already intrinsically motivated. This further reinforces the ideas that we need to trust our people and get out of their way!
The second Scaled Agile Framework principle is "decentralize decision-making." As an architect, I thought my job was to make decisions. Silly, right? I know that now. My job was to be an expert resource for the teams so they could make good decisions. They are the ones that live with the daily consequences of those decisions, so the decision are theirs to own. My job was to serve the teams and team members, not the other way around.
I hope my struggles and failures can help teach you this important lesson: Architecture is about People, not Technology.