Alternative Advice Forum Flavors

In Chapter 8: An Architecture Advice Forum I only described a vanilla advice forum. But is it an advice forum at its most basic? No, what I described was a standard starting point, but not one which I deploy unthinkingly. I advise you to do the same. In the spirit of experimentation and finding the advice forum which meets your needs, fitting to and nurturing your culture, you should encourage collective experimentation.

The fundamental nature of the advice forum is a regular, face to face (video-conferenceing works for this these days as we’re so used to it) meeting, attended by the advice-seeking and advice-offering collectives; where deciders seek, and advisors offer advice in real time. Beyond/within that, feel free to do whatever you like. There is a lot of space here left for cultural differences to express themselves and for your special collective rituals to form.

It is also a great place to experiment explicitly, while you have everyone’s attention. With the caveat that you stay aligned with the purpose of the gathering, and you make sure that everyone attending cares about what you are adding/removing/changing, what might be some experiments you can think of? In the sections which close out this chapter, I’ll share some of mine. Remember, I’d only try these once your basic forum was up and running. Ideas to remove

It might not seem that there is a lot left to take away from the advice forum as I’ve presented it, but trust me there is. When you do remove parts you even leave that space for self-organization and culture to step in. But, don’t forget the warnings of Jo Freeman’s “Tyranny of Structurelessness”; not all culture is good culture and not all organizational structure is bad. So the question is, how do you know which is which? When do things tip over from functional ad hoc self-organization into the formation of informal cliques and small groups of friends begin controlling information, setting agendas, and wielding power in all sorts of subtle ways? The answer is by experimenting. I’d like to share a quick story to see if I can shoogle your seat a little and in doing so, open you up to the possibility of doing less, not more.

Making space for culture redux

In Chapter 7: Replacing Hierarchy With Decentralized Trust I spent some time looking at the benefits of “doing less” and leaving space for architectural practice in terms of the architecture advice process. The advice forum is a ripe opportunity to look to apply this, explicitly leaving things undone, and seeing what fills the gap. I’ll share some examples from the most extreme form of meeting self-organization as I hope it will give you some ideas.

I’ve been lucky enough to witness and participate in self-organization multiple times in my life, but one which stuck with me most was the Winter Tech Forum open space conference. With open spaces, the idea is that as much of the conference organization as possible is left to attendees. Every year, the host, Bruce Eckell, experiments with the format to see just how little he has to do and how much he can leave up to others. He’s got it working pretty well.

Firstly, what does Bruce do? He books the venue (a church hall in Crested Butte, Colorado) and announces the fact it’s happening. (On his website, the podcast he co-hosts with James Ward, on social media, on an old Google newsgroup and a slack channel) The only other thing he does is to find out if a specific dinner venue is free for the night of the full moon, but more on that later. Everything else self-organizes. The agenda, the sessions, the food, the accommodation, the hackathons, the other entertainment, the gatherings.

All of it.

But how? For talks, attendees suggest topics throughout the conference, putting them into standard time slots which have slowly been settled on over the years. Afternoon sessions self-organize too: Attendees share that they are thinking of doing something, at such and such a venue at such, and such a time and whoever turns up turns up. Food and refreshments also self-organize via a mix of face to face comms and over whatever group chat everyone has agreed to use / experiment with that year. There are two “events” which have emerged as part of the culture of the conference over the years: a progressive dinner and a yurt dinner (that’s accessed by an evening cross-country ski snow-shoe, hence the need to know when the full moon is and so it can be booked in advance.) Finally, evenings are social, and again a tradition has evolved that begins with. groups forming and heading off for food before everyone reconvenes for lightning talks. (You can watch many of them on the Java Posse Roundup Youtube channel.) Typically the type of food is what dictates who goes where with whom. Connections are made and the conversations continue. You get the overall idea. An incredibly rewarding tech conference arises from a group of motivated individuals with the inclination, time, space and trust to make something happen.

This all exemplifies the first key point: while all these things are integral parts of the open space, Bruce, and other “organizers” (there aren’t really any) do nothing to make sure they happen. But they do happen, because the group have done them in the past and want to again, and perhaps there was a thing they wished they’d had last time and so they brought that this year to make things a little easier, but again, no one had had the responsibility to think about these things in advance, they all just emerge.

Now, to the uneducated eye, Bruce can appear as if he’s disengaged; that he doesn’t care. This couldn’t be further from the truth. He cares deeply (and, as we’ll see in the next section, has no qualms about organizing and adding things when they are required) but he also sees that the best things happen when space is made, then yielded to others. This doesn’t happen by accident. The implicit space-sitting is the one to watch out for the most. You must be explicit that others are invited to take control. You need to remind people that they can arrange the morning sessions how they like on the board and that they can do whatever they like in the afternoon sessions. Simply not doing anything is not enough. If you are someone who others will perceive as having the control over a situation, you need to explicitly make it clear that you are not occupying that space and that you invite others to enter it. And you need to do this over and over again. (You can read more about the JPR/Winter Tech Forum on the conference site. There is also a great book on the topic: “Open Space Technology: A User’s Guide” by Harrison Owen.)

With both these things in mind: first that removing pre-planning doesn’t mean something won’t happen, just that it might be happening as a result of the culture as opposed to the structure and rules; and second, you need to actively, explicitly (and most likely repeatedly) step out of the space you want others to potentially fill. Simply shutting up and stopping doing things isn’t enough.

What you might remove from an advice forum

With all this in mind, what might you remove from an advice forum? Hopefully you have a few ideas of your own, but despite the fact the standard agenda is pretty sparse there are things you can play with.

Here are a few ideas to try:

• Stop chasing people up to add their ADRs to the agenda in advance
• Stop adding people’s names to the attendee list
• Leave the AoB section empty.

See what happens. People might develop a ritual of adding their ADRs on a timely basis. The attendee-list may change organically as people figure out who is the best fit (in regards to expertise and time) to serve as delegates. You may find that the AoB section reveals things you didn’t expect.

Ideas to add

When Bruce primed the Winter Tech Forum for self-organization he was a master of not doing things, but that didn’t mean he was afraid to also try adding things, when he (or others) hypothesized they might be needed. The most important element I saw him add was a code of conduct. I’m not suggesting for a second that your advice forum requires such a thing, your workplace has other mechanisms already in place to achieve the same ends, but it illustrates the point, and takes us back to Jo Freeman and the quest for the supporting elements which your culture needs that I talked about at length in Chapter 7: Replacing Hierarchy With Decentralized Trust.

Remember you are adopting the Architecture Advice Process to decentralize the practice of architecture so that it can be performed with trust by the maximum number of people, safely and in a learning environment.

A code of conduct details the rules and boundaries within which individuals are expected to operate at all times. In practice, they play a part in establishing an inclusive culture. In a similar way, you can reinforce the culture of safety and participation within this meeting in particular by paying attention to who talks or doesn’t talk during each advice forum. If it’s the same folks over and over again, it might be time to introduce a new practice. One I’ve used is time limits on advice-offering. It’s not to say that the advice can’t continue in the form of side-conversations or offline ADR comments, but it clears the space for others to contribute. The benefit is that underheard participants don’t need to make this space themselves–it is being made for them. The same ends can also be achieved by asking questions–even if they are as simple as asking for clarification of acronyms–and offering advice which might change everyone’s perspective, or by giving more weight to a contribution which is being overlooked (crediting the person who initially shared it).

Regarding other things you might want to add, heed this warning. The purpose of this meeting is intentionally focused and specific: the seeking and offering of advice with the purpose of making as many quality decisions as quickly as possible. With everyone gathered together, for high-bandwidth, synchronous communications you can achieve a lot very efficiently. Don’t dilute this by adding things which, although the audience all cares about the topic, are off-topic for the forum. Examples of well-meaning, but distracting additions, might be a discussion around what training everyone would like to go on, or meta-discussions around the addition of a new field to the standard ADR template.

Things I have added successfully include:

• Spikes in play - spikes (or “Spike Solutions” as they were originally called in XP, a small piece of work, usually involving code, to explore potential solutions) frequently become ADRs and decisions once completed, and teams can share info on them early. (I spent lots of Chapter 14: The Variability and Interconnectedness of Decisions on Spikes and incorporating them into the advice process)
• Four Key Metrics check - looking at the latest DORA four key metrics can inform a lot of decisions, and spark others. (A detailed account of how to locate, collate, and calculate your four key metrics can be found in my chapter in O’Reilly’s “Software Architecture Metrics”)
• Cloud costs check - this is a great stepping stone to teams owning their own costs
• Coupling checks - architects looking at upcoming stories and features which span teams can help to get ahead of the curve on efforts to decouple
• ADR transit check - how fast are ADRs moving through the system? When do their implementations make it to production?
• Decision failure report - known at Netflix as “Sunshining”, this is a process whereby people talk about a failure openly, encouraging both learning and safety. (I talked in more depth about Sunshining in Chapter 15: The Transition of Power and Accountability.)

It’s important to point out that I spend more time thinking about what to remove, and what to do less of, than I do thinking about things to add. Remember, the ideal is that something happens because of the culture you have given space to emerge. Also remember that every time you want to add or remove something, do it as an experiment, following all the advice I laid out in Chapter 7: Replacing Hierarchy With Decentralized Trust. (There is a case study of one company’s adoption of the Advice Process, ADRs and AAF that I co-wrote with Noush Streets and Kamil Dziublinski. If you have time to read it, it might give you some ideas, especially the “How it Works” section.)

When to experiment?

Before I conclude, it’ll be useful to address explicitly the question of when you should experiment. The short answer is “when you need to”. The needs ought to be self-evident.