What's Maslow's Hammer got to do with the Community of Practice for Architecture

The “Law of the instrument” or “Maslow’s Hammer” is a cognitive bias that involves an over-reliance on a familiar tool. You heard already that when you have a hammer, everything looks like a nail.

This bias is very active in software delivery – we get ahold of one technology stack and one architecture, and continue replicating such systems irrelevant to the business case we’re solving. The first step in breaking this habit is understanding that not all business cases are the same. And we want business cases to be different since that is where innovation lies. Once we start looking for peculiarities of business cases, we will see them all over the place. And we can start discussing the most appropriate technology stack and architecture for each of those business cases. Such discussions are always easier and more productive in a team since we can take into account different perspectives and experiences.

One way to start team discussions about product architecture is by forming a Community of Practice for Architecture. At CROZ, we call this community the Technical Council.

As a professional services company, we work with many clients in different industries on different projects which increases the variety of products that we work on. That makes it even more important not to treat them all equally. Considering the business and technical diversity we face on our projects, our Technical Council consists of equally diverse roles: Architects, Developers, Team Leaders, Data Scientists, and Operations. Sounds like a lot of people, but actually it isn’t. There are 14 members of our Technical Council and they get together every other week for a 90-minute session to discuss topics from the backlog.

Anybody in the company can ask for help from the Technical Council, particularly in the following situations:

• “I’m starting a new project, I have a general idea of how to go about it, but I’d like to discuss it with somebody and get a second opinion”
• “my team is continually experiencing the same problem, I’d like to talk to somebody about their experience in solving it”
• “the client is asking me about some super-cool new technology or methodology, but I’m not completely sure what is our company position on this”
• “I see friction and suboptimal performance in our collaboration with the client and I’d like to recommend improvements but I’m not sure where to focus our efforts. I’d like to share my observations with somebody who could use their experience to give me advice that I could share with the client”

Anybody in the organization can raise a topic and that person navigates the conversation to get the answers they need. Once a quarter, members of the Technical Council sum up everything that was said during that quarter and present that to the whole organization. That way everybody benefits from their insights.

Although it is a great concept, it doesn’t come without challenges in real life. Here are the Top 3 pitfalls and gotchas that we discovered along the way:

#1 Sessions ending without a real closure

Situation: we have a good discussion but we don’t finish everything in time. Some things are left to be finished after the session, documentation included. But that never happens.

Solution: This is a common follow-up problem and we solved it by forcing individual ownership on particular tasks.

#2 Sessions turning into philosophical discussions

Situation: we have a good discussion but we end up down different rabbit holes. We cover things “a mile wide, an inch deep” and we end up with a superficial conclusion.

Solution: Stronger facilitation with continuous refocus on the goal of the session. It helps to write down the goal in the beginning and to point a finger at it whenever we feel we’re straying off.

#3 Not all people are equally engaged

Situation: During the session, some people are talking all the time while others don’t say a word.

Solution: Before the session, talk to reserved people and encourage them to share their opinions. They are members of the Council for a reason and we need their input. During the session, explicitly ask for their opinion.

Header photo by Jean van der Meulen