Behavioral Domains

Just as leadership has three common domains, the same goes for how people within an organization tend to think and behave. These are the Behavioral Domains and are commonly described as: Operations, Engineering and Architecture. What varies is how each of these are defined within an organization. What is one group's engineering is another's architecture.

I suspect everybody has seen these described in a variety of ways, and there may not be a single best way to structure the separation of duties. The factors involved include how large your organization is and the focus of work effort. Larger organizations may have enough capacity to separate out operations and engineering duties, while smaller organizations may have to ask individuals to perform both domains.

With the improvement on operations technologies and the advancement of “Devops” concepts, the lines between teams is becoming more muddied, yet these domains are still relevant even within the a single team.

Coming to a consensus through definition of what these domains entail for you and your organization is valuable in reducing fears. I have found it useful to consider the aspect of time and how things are designed and implemented over time, when wrestling with this challenge (see The Problem: Time).

We have different people who have their own comfortable window of time, or basically have fixed upon a specific time frame of thought that works for them. Some of us will think on a scale of 1-3 months. These are the ER doctors who keep us alive on a daily basis. They provide life support when it is needed and are vital to our organization. But challenges lasting more than a couple of months do not concern these people because their job is not long-term care, and they are just as apt to use duct tape and bailing wire to fix a problem as the proper surgical tools. It is immediate “get it done now” sort of thinking. These are the Operations people, often called fire fighters.

Others will think on a scale of three months to half a year or so. These are the Engineers who could build a house in a week, if given the time to plan it out and the right amount of support. They figure out the tough details of making specific things work in the wild. They provide the glue and the bolts to make the fabric of our infrastructure hum. But when faced with a challenge to build an infrastructure of interconnected skyscrapers, they might simply say the job is too complex and urge focusing on something they can get done in six months or less (the second story bathroom).

Architects bring in the long-game strategy. They think across all time ranges, from the next few months to several years. Sometimes called time travellers because they can think and often talk in all three time frames, the challenge of an Architect is to recognize the timeframe of their audience and focus the conversation to it. Instead of coming to the engineers and administrators with a multi-year conundrum of building an entire subdivision and talking about how to make it all work, the Architect should come to them with a one-month challenge, such as building the plumbing in a single house, and ask them to help make it happen.

“How to make it work?” you might ask. The idea seems so simple: just focus on the Behavioral Domain and put a label on it. The challenge is people do not like to be pigeon-holed in such a simple manner. Everybody wants to do the design work for what they care about, yet keep focused on just their silo of effort for operations. Telling somebody that they cannot do design or architecture because they are now operations may very well be a recipe for disaster.

Design is an element that is most beneficial when it exists at all levels. If everybody should participate in the design process, then the leadership domain of Design is different from the general need for design across all behavioral domains—it becomes that of a facilitator to help others through the process of Design Thinking.