In 1933 the Navy rejected Draper Kauffman due to his poor eyesight. Ten years later he trained the special units which would later become the SEALs. The training includes a grueling first week to filter out. "Hell Week separated the men from the boys", Kauffman said. "The men had sense enough to quit—leaving us with the boys!”
In his program, everyone did the training, no matter their rank. This, of course, included Kauffman. The enlisted men of the first class took one look at their ungainly, nearsighted commander and reached the same conclusion; There was no way this guy would make it. But as the trainees watched, he proved them wrong.
"We were testing Kauffman all along," wrote Dan Dillon, a member of the first demolition class, "but my respect for him deepened because a lot of the officers will tell you what to do, but they won't do it themselves. This man asks for suggestions. If they're good, he uses them. And he participates in everything. The dirtiest, rottenest jobs that we tackle, he is in there doing as well as the rest of us. How could you not respect him?" –The Culture Code
Kauffman is one of those leaders who jump into the dirty trenches together with his team. In his case literally during the second world war at the invasion of Japan. Leaders who make their hands dirty gain "ethos", as Aristotle called it, and so people care about their suggestions.
Architects Must Code
Software architects are technical leaders but they have no budget and no command. So an architect must work through persuasion and influence. However, do not pursue raw authority because when a group makes decisions, they better discuss it as equals. You want all information and experience on the table but authority can silence valuable opinions.
Many developers tell me that architects must code like they do otherwise they will not be aligned well. Nobody likes architecture astronauts. The software architect should be a peer among developers to be trusted and the most simple way is to do the same work like Kauffman. Write code, review pull requests, and debug issues. When developers see that architects share their values like clean code, it builds trust.
However, architects only have little time for coding. At least, I work on a manager schedule more than half the time. So I avoid anything time critical and invest extra effort that others can maintain my code as well.
Speak Business with Managers
Software developers are not the only ones an architect will have to persuade. There are all kinds of managers (at least in embedded automotive projects): Project managers, line managers, safety managers, security managers, requirements managers, and so on. These people talk a different language and the role for the software architect is to act as a translator here.
To a developer, you can say "the code is a mess because everything is coupled together." To a manager you rather need words like "we should invest more in refactoring to reduce volatility in the marginal cost of features." Instead of "devs are fed up with this mess and leave" say "we can reduce our turnover by investing 10% of our time in our code quality." Nicolas Carlo wrote more about that. Maybe the examples are too extreme for your organisation as tech companies should have managers who are more technical.
What happens if the gap between management and engineers widens is well told in this story about Boeing. The turning point of May 2001 looks like this for Boeing's stock price:
An example how different the views of management and developers can be is documented in a case study about the development of a medical instrument. The project had a total cost overrun of 419% of the approved budget. It took nearly twice as long as the approved plan. Management considered the project a failure. However, the developers considered it a success:
In response to the question, what was the most successful project that you have worked on, and why, the researcher was surprised to find that over 50% (5/8) of the interviewed software developers identified Project A1! The other three interviewed software developers identified Project A1 as second best. The common theme on all the responses included (a) the project was a technical challenge, (b) the product worked the way it was intended to work, and (c) the team was small and high performing.
Martin Fowler calls it the Elephant in the Architecture. Software architects are in between this tension and the job is to find the proper tradeoff.
Tell Stories
Recently, I blogged a story at work. It covered the last three years of my project and the big lessons about big automotive projects I learned there. The feedback was surprising. Managers multiple levels above contacted me. People who were starting other projects asked me for details. My company documents lessons learned in every project as part of the usual process. However, my story had wider influence. Storytelling as a tool is underrated and so I'm trying to learn it.
The meaning for "story" here is wide. In a professional setting, you will not spend an hour narrating gripping fiction. This is about short stories like the three paragraphs at the beginning. Some people might only call it "example".
I would not call this storytelling. I would simply call it giving a relevant example. –Lucy Kellaway
However, there are no people who call themselves "example-givers" but there are people who call themselves "story-tellers" and their know-how is useful.
The most obvious difference is that stories are concrete unlike abstract architectural diagrams and that helps for communication. However, stories also work in more subtle ways. Neuroscience shows that stories trigger mental simulations that even affect the body.
We can't imagine events or sequences without evoking the same modules of the brain that are evoked in real physical activity. Brain scans show that when people imagine a flashing light, they activate the visual area of the brain; when they imagine someone tapping on their skin, they activate tactile areas of the brain. The activity of mental simulation is not limited to the insides of our heads. People who imagine words that start with a 'b' or 'p' can't resist subtle lip movements, and people who imagine looking at the Eiffel Tower can't resist moving their eyes upward. Mental simulation can even alter visceral physical responses: When people drink water but imagine that it's lemon juice, they salivate more. Even more surprisingly, when people drink lemon juise but imagine it's water, they salivate less. –Made to Stick
There are different kinds of stories depending on what you want people to care about. Maybe you want to share some knowledge? Maybe you want to inspire collaboration? Maybe you want to introduce a new technology? Maybe you want to emphasize cultural values? Different use cases require different stories. Sometimes the story must be true and sometimes it doesn't matter. Sometimes plenty of details are helpful and sometimes not. Fortunately, you don't have to be a great at telling stories. Even a story which is not entertaining, dramatic, or funny will do its work.
As a first step, my suggestion here is that you start collecting stories (I have a note-taking system for that) and tell them. If the outcome surprises you then tell me that story.
Summary
If you communicate your architecture well but they ignore you anyways, this article had three suggestions to increase your influence:
- Get your hands dirty in code to gain the trust of developers.
- Learn the right language with managers.
- Collect and tell more stories.
More generically, the first two points can be merged with Covey's 5th habit: Seek first to understand, then to be understood.
Dirty hands photo by Alex Jones on Unsplash.