"The higher you go in an organization, the more your suggestions become interpreted as orders." - Marshall Goldsmith
An Architect garners a high level of authority by being an expert. People will follow their lead. But what if the Architect is wrong? They will follow right off a cliff.
In the book "Turn the Ship Around", David Marquet tells his story as Captain of the US submarine the Sante Fe. On January 21, 1999, Marquet gave an order that could not be carried out, but the crew tried anyway. When he asked why, they responded "Because you told me to". After this incident, Marquet vowed to never give another order. Instead he replaced it with intent. Instead of asking for permission, his crew would tell him what they intend to do. Marquet took his first steps to get his crew to start thinking like the Captain.
How do we get people to think like the Architect? Use the principles of Intent-Based Leadership to decouple the success of your project from the personality of the architect. By creating clarity around architectural goals and by engaging people in problem solving rather than defining rules and standards we can divest control and create an organization of leaders.
I’m going to tell you a story.
I was scheduled to go in to get allergy testing. For those that have had it, it is a pretty routine operation. It is painless and goes by quite quickly.
It just happens that morning I had gone in to donate blood. (Gesture to the area in the elbow where they put the needle in) Another routine procedure, and one would think has nothing to do with allergy testing.
Back to the allergy testing I’m talking to the doctor
I like to be really sure about medical stuff, so just for safety I made sure the doctor knew that I had just donated blood. I didn’t think it would affect the allergy tests, but you never know.
He doctor of course let me know that the two things have nothing to do with each other and it would be fine. (better safe that sorry though!)
The procedure itself goes fairly quickly.
The nurse puts a grid of allergens on your arm and proceeds to prick them into your skin one at a time.
Here is where I should confess… I’m really not great with needles.
They have this unfortunate side effect of causing me to lose conciousness.
I thought I would be fine though. These were very small pricks and they didn’t hurt it all so I assumed I would be fine.
However, the accumulation of this sensation seemed to be building up and I started to feel a bit funny. The nurse was just finishing up and I told her that I was feeling like I might faint.
She laid me down immediately and called the doctor in.
The doctor wants to make sure I’m OK and proceeds to take my heart rate and blood pressure. In order to do this, she presses her stethosocope right into my elbow.
At this point two things are racing through my head.
The first one: OUCH
The second: Isn’t she worried this is going to rupture my puncture mark? She knows I just had blood taken?
At this point two things are racing through my head.
The first one: OUCH
The second: Isn’t she worried this is going to rupture my puncture mark? She knows I just had blood taken?
It’s ok, she probably has a really good reason for this.
After all, she is a doctor.
After all, she is a doctor.
Anecdote: First feature we worked on. PSS Model. Usually 1 person. Leap of faith and got a whole team to work on the same feature.
New project:
Anecdote: “Transaction manager”
Anecdote: Repository replicated many times over
Anecdote: Repository replicated many times over
Design Skills, Knowledge of DDD, Enterprise architectuer patterns,
Organizational Clarity -> Conceptual integrity on architecture approach, understanding of client’s needs, assumptions of current approach. The context. The WHY
Anecdote: Team was trying to decide between two different API designs for our domain layer. I could see that one of the designs would be problematic if we ever had to make changes, because there was some sequence coupling. Each caller would be required to call a set of methods in a specific order or else a part of the underlying system wouldn’t behave properly.
Option 1: “This design is better, because bl……”
Option 2: “If we changed the underlying mechanism, which design would require the fewest changes?”
The question communicated to them that I wanted them to be considering maintainbility, but it also engaged their thinking. The question itself communicated a value, but without handing them an answer.
Anecdote: Team was trying to decide between two different API designs for our domain layer. I could see that one of the designs would be problematic if we ever had to make changes, because there was some sequence coupling. Each caller would be required to call a set of methods in a specific order or else a part of the underlying system wouldn’t behave properly.
Option 1: “This design is better, because bl……”
Option 2: “If we changed the underlying mechanism, which design would require the fewest changes?”
The question communicated to them that I wanted them to be considering maintainbility, but it also engaged their thinking. The question itself communicated a value, but without handing them an answer.
Anecdote: Production aggregation -> I just want to hand them the solution! I already have it!
Pull you out of the argument mode. Physically separate from the design options.
Pull you out of the argument mode. Physically separate from the design options.