Bob Marshall “didn’t sign up for all this people shit“. Neither did I. But like Bob — and Tom and Stuart and Ruth and Chris and Dave and so many others before me — I’ve come to realise that talking about the architecture of software-intensive systems might be distracting me from the core of the problem of building and running effective systems (although they haven’t phrased it in exactly these terms). Focusing on people and their needs might be a more effective approach. This is tough, at least for me, and I can fail at this in the most spectacular ways.
If a classification seems necessary, thinking of the architecture of people-intensive systems might be more useful to me than thinking of the architecture of software-intensive systems.
I’ve been struggling with the architecture of people-intensive systems more concretely:
Fred Wilson‘s video of the week was “Simon Singh on Confirmation Bias“. I learnt about cognitive biases in formal education, read and heard about them on different occasions, and certainly experienced my share of them the hard way. I even knew about the specific example used by Simon Singh.
Despite all of this I was completely floored by the powerful experience delivered in this video…enough to make a hard man humble…
But what are practical implications of this? Say, for the next time we analyse anomalies in an information system? Or about the production problem we analysed last Friday, and the consequences we drew from that analysis?
Better stay away from that tool shed…
…but we do need to know the way home. All by ourselves.
Jeff Gothelf and Josh Seiden said it well in Lean UX:
Over the long haul, collaboration yields better results than hero-based design… Teams rarely learn or get better from working with heroes.
The same is true for any other discipline the hero might practice. And there isn’t really much to add to this.
Except, perhaps, for a little more context:
The most effective way I’ve found to rally a team around a design direction is through collaboration. Over the long haul, collaboration yields better results than hero-based design (the practices of calling in a designer or design team to drop in, come up with something beautiful, and take off to rescue the next project). Teams rarely learn or get better from working with heroes. Instead, designing together increases the design IQ of the entire team.
Just one more thing: Read Lean UX. Much of its content is applicable way beyond UX.
I’m still uncomfortable with job titles such as architect used in software-related contexts. Nonetheless, it is difficult to ignore the fact that this title is used and adopted with apparently increasing enthusiasm.
So what do I think an architect does? Or, perhaps better, how do I think someone having the architect job title could provide value to the people she works with?
Against this mental model of architecture, Bob Marshall’s antimatter principle led me to this:
An architect attends to the architecture.
A little longer:
A system’s architect attends to folks’ needs by fostering the shared understanding of this system’s purpose, context, function, form, structure and characteristics.
How do you do that? Well, it depends…mostly on folks’ needs.
For those who’d rather be something than do something: An architect is an attendant to the architecture.
I like this definition of attendant: “a person employed to provide a service to the public in a particular place”. And I like to understand to attend as to look after (source).
2013-11-30: Added form, made function singular.
2013-11-08: Added characteristics to definition.
So if we want people to own the work that needs to be done, we need to explain context and purpose (again and again), and then get the hell out of the way.
At least that’s what I’ve seen working before. And I’ve seen it play out again today — and I loved every minute of it.
“I don’t know what you think about this point, but I think <lots of opinion here>…” to me isn’t an effective way to request contribution from others. To me, it can be considered a violent act, especially if others are one’s subordinates.
“What do you think about this point?” at least opens up space for a contribution.
“Would you be willing to share your views on this point?” might be even more effective.
Four and a half years later, I’m a little surprised I reacted so strongly to this. Looking back, I can only assume that this situation involved significant asymmetry of power and that I perceived it the way I described it. This seems to re-inforce the point I was trying to make.
…and usually doesn’t lead to the best decisions the team could make. Enabling others to make good decisions instead (and accepting others’ help in making good decisions oneself) is likely to scale better and to lead to better decisions.
If this works on a nuclear submarine, chances are it works pretty much everywhere else.
I saw the leader-follower mindset in action again. It wasn’t pretty. I intend to do better.