o

olivierg

Writing about organizations architecture & considerations in a VUCA (BANI) world. #100Days

Social Distancing Or Physical Distancing?

The more people are isolated from one another, the weaker they are, as social interactions are one among the universal human needs. The less they can find their needs fulfilled by their social network, the easier they can be controlled by external forces.

The so-called tragedy of the commons happens when actors are acting based on self-interest AND not coordinating with one another when they realize that the common resource risks depleting.

The tragedy is not that the resource is getting depleted, it is that economists believe and want others to believe that it is the natural conclusion. Only in a simple model of reality does this become the case.

Is it possible, then, that the term “social distancing” stemmed from the same (lack of) perspective? That it came from a paradigm where people are agents that will only stop getting infected if they cut off human connections? A simple model of reality that ignore the difference between physical distance and social distance, or, rather, that chooses the one that will also make people easier to control?

By asking people to reduce social connections, bureaucrats in charge of policies reinforced the belief that people should not talk to each other and coordinate with one another? Was this a Freudian slip?

Note: the World Health Organization favours the term over “social distancing”)

Recipes or no recipes?

Nicklas Luhmann was a social scientist and prolific writer. He published over 60 books, with some of them revolutionizing his field. A few people have studied his technique of taking notes and associating them, which seemed to explain how he could come with novel ideas and write them down so fast. I can’t recommend enough the book “How to Take Smart Notes” by Sönke Ahrens (2017). The book describes principles and generic steps to take notes for successful writing.

What is interesting, though, are the some of the negative reactions to the book by Ahrens. They can be phrased as “the work system is not prescriptive enough” or “the work system would not… well… work for me”. But they reflect the lack of desire or ability to even try the new work system.

There are a number of assumptions in any described work system. You have to understand its goals, have the same ones, be at a point where the system resonates with the way you’re already working, so you see how to modify your existing system (everyone uses systems even if they don’t realize it- the most basic rely on habits and intuition), adopt it with some success, use it for long enough to perceive benefits. The biggest obstacle resides in the tools you use or can use. They are highly contextual.

Successfully changing your work system requires Aha moments where you try something different, and you feel it works better, and becomes a new habit.

All this requires that you have an idea of how you currently work, and think of it as a work system. Or, you can simply adopt the new one, but it requires a leap of faith- and if you are opinionated, you will just write down a negative review of the book on Goodreads!

The issue, when considering the new work system, then, is to be able to see it like a new recipe in an existing realm of recipes you have at your disposal. Today, I use this method to cook my rice. Tomorrow, I will try this other method.

When you have no idea how you cook rice today, though, the new work system will just not make any sense. It will feel “too abstract“ or “too different”.

Ahrens’s promise to “boost writing [for] Students, Academics and Nonfiction Book Writers” is very ambitious. If you are a student, you know by comparing how you work with how other students you know work, how incredibly diverse and different your work systems all are.

For people who have not thought hard about how they work today, expecting to adopt a new work system like a new recipe, is like trying to read a partition for a musical instrument you do not know how to play.

Recipes are for people who know how to cook.

Should you have Testers?

I once worked for a company that had no testers. Software developers but no testers. Zero.
I was really surprised.
Even more surprising was the absence of testing or staging environments!

How was the quality?

It was actually not bad at all. It was even better than in other organizations that had almost as many testers as there were developers.

How could this be?

It turned out that there was a culture of testing. Developers knew that nobody was coming after them to check their code, the production environment, or customer satisfaction. They had to do it all by themselves.

What did the developers do when they found a bug in production? They relied a lot on logging, some automated tests, automated monitoring, small and frequent releases, and fixing-forward: fixing the issue instead of rolling back.

It was incredibly fast and efficient.
Testing is a mindset first, it’s an attitude. A focus on quality. Anyone can adopt this mindset.
Also, if a developer is humble enough to ask for a code review, they can ask a peer to test their code.

I’m not saying this is what I recommend. There have been costly mishaps.
But think about how better your product development team would be if developers had a culture of testing.

How would you develop this culture where you are?

Should you have Projects?

Some claim you should manage products, not projects. Projects are a huge drain on resources, requiring to stop what people are doing, gather a diverse project team and that will focus only on the project until… the project is completed.
What would be recommended instead, is have fixed teams to whom you give portions of the project work, and manage dependencies between teams if several teams are required. The stable element being the product, and the systems that constitute it, you should rely on product experts to understand what is to change, implement the changes, deploy, run and operate. Organizations typically underestimate the lifecycle of their products, and projects discourage long term investments in the delivery (development, testing and operations) pipeline.

Focus on the product and invest in its evolutivity, they say, and you will find that the resulting shift will make your changes much smoother, allowing you to bring changes faster and of higher quality, will less regressions.

Well. They are far from being wrong. I actually learnt to become of huge advocate myself, of merging development and maintenance in teams. You build it? You run it also, then.

But not all changes are equal. Some projects touch upon several systems and products. Some remove parts, or add new ones. Which teams should take the work, then? Also, how do you maintain consistency across different teams? How do you communicate and preserve the design decisions, the philosophy? How do you create a sense of togetherness that is required for mutual help towards the delivery of the expected outcomes of the project?

I have felt this in rare Program Increment (PI) Planning events, when several teams were presented a challenge and abandoned the silos of their respective teams, to embrace re-teaming, more suited to tackling the new work streams.
But projects do not always nicely fit an existing (slow) pace or defined set of existing teams.

I can’t think of any reason to abandon projects altogether. I think they also bring an opportunity to create a renewed feeling of mission. I have fond memories of some (very) big room kick off meetings, where the energy created was palpable, that contributed a lot to the sustained levels of communication across a large number of people.

But projects need to be kept as short as possible, and eventually succeed- or fail- but end clearly.

Yes and. Yes to products. And yes to projects.

Should you have Project Managers?

Should you have project managers?

How do you assign responsibilities inside a group or organization?

Let's say you have a team and several tasks or projects. They are complex and involve the same people. These people have to collaborate. There will be opportunities when task A competes with task B.
Is this good or bad?

Well, it depends on whether the bigger picture is lost or not. Can we focus on task A and put task B on hold? Probably. How do we when task B becomes so late that it affects the larger team's success, reputation, or health?

We can't tell at the level of the tasks. We need to watch the highest level.

You can have people accountable for parts of the work IF and only IF you also have mechanisms in place to watch for the well-being of the team at all times.

This is what I call energizing Resilience.
You can have people responsible for separate tasks and projects, but you should always have someone (and that someone getting help from everyone else) watching for the well-being of the team and everything associated with its resilience.

You can have project managers IF you have people managers, and the latter have more power than the former.
IF you want resilience, that is.