People business

The opening chapter of Peopleware has a gem that greatly influenced me back in the day: “..we are mostly in the human communication business. Our successes stem from good interactions by all participants, and our failures stem from poor human interactions.”

Though it has taken me years to completely let that sink in, every single success, victory - as well as failure - can be traced back to the quality of human interactions in that context. Realizing that we are in the people business, however, is necessary but not sufficient idea to keep you on a solid path.

Through my journey, I have picked up some thoughts and ideas that have helped me and could be of use also to others.

As a problem solver in technical domains, I’m rarely in situations where we are solving just a technical problem in a void. What we solve with a technical artifact is someone’s interpretation of the situation and what could be an improvement to that situation. Taking everything granted can be effective and productive in short term, but longer those wrong assumptions live - more expensive correcting them will be.

It is 2018 and this should not be a controversial idea, and as a thought, it is not - but in practice it is. We still make unvalidated assumptions and treat them as facts, set the direction and run full steam ahead.

In some settings, it can work, and in states of confusion it can be a strategy to combat indecisiveness - but without checks and balances, it can be an expensive gamble. Successful gamble will be celebrated and intuition that was correct kept in high value, while failed gambles are forgotten and not spoken about.

Think what business you are in and how value is understood

This could sound trivial and elementary thought, but more often than not differences in understanding the nature of the business and the reason for existence for the organization and its services cause conflict between people.

While implementing technical solutions we admire and value technical excellence and abhor - rightly so - quick fixes and hacks. We know hacks to bite ourselves later on if we need to maintain that hackety hack solution any longer, and do not get the possibility to fix the technical debt that causes problems. But if we waste money to wrong parts early on, we might never live long enough to see the problems in those hacks. The struggle is real.

If we only had a common view on what the business is and how value is created in different parts of the organization - and in processes - it could help us to have better conversations about where to invest efforts and why. But in many cases we do not know or see how the organization really works unless we spend time and effort really studying first hand what happens.

In those situations I try to capture some kind of systemic view of the business - and use some go to-tools from my tool chest to turn data into insights. I can try to identify failure demand, recognize constraints in value flow and start to manage flow. Theoretical underpinnings / influences being John Seddon’s Vanguard method, Theory of constraints, lean and Kanban.

Talking about failure demand is one way to improve the common understanding on what is value demand and what work is just a reflection or ripple effect of something that was not done properly earlier. It can also help to surface assumptions and decisions made in the organization to accept inefficiencies or failures in certain parts.

Identifying constraints or bottlenecks in processes can help to understand how value flows and where could easy improvements be made to improve the whole throughput of the system. Discussion about potential constraints can help in covering more understanding about the value and how people work.

And finally to manage flow and to make changes to the system installing a Kanban-like process can help people to collaborate. Goal being working together on understanding, visualizing and optimizing value flow - instead of working in own individual silos and trying to optimize their own local work.

The caveat here again is that this is a long-term process requiring discipline, not something you can do just once in a fire and forget way.

Heart of agile: Collaborate, Deliver, Reflect and Improve

Alistair Cockburn’s Heart of agile captures nicely the essence of our work in software development.

We collaborate. Transfering ideas from one head to another.

We use our skills to deliver learnings and working software to meet needs.

Reflection allows us to learn and be introspective. Are we making an impact and are we doing right things.

And constant improvement allows us to change what is not working, and experiment with things that could work better in the future.

Those four words are sufficient, simple, and still support the complexities of modern Agile development

Architecture and Conway’s law

Though Conway’s law was introduced in 1967 we still fail to fully appreciate its’ observation. If the organizational structure affects our system designs we can also evolve the organizational structure with architectural designs towards better fit with the business goals.

When we talk about digitalization and transformation of businesses, this is more important than ever. Goal should not be just to apply new technology with old structures, but to evolve both.

Similarly when talking about software architecture and changes into the architecture of existing systems, it is vital to think and talk how it affects the work and communication of people who will work on it or with it.

Constraints as well as possibilities given by different styles of architectures and technologies are not relevant topics only from technical perspective, but sometimes more important from team or organisational perspective. Drive towards microservices and API economy are important signals of that - as well as the whole devops-movement.

Patterns for thinking and doing, tools and languages matter

Techology choices affect our thinking and vocabulary - and ability to express ideas. Full stop.

Or if you rather listen to Heidegger: “Man acts as though he were the shaper and master of language, while in fact language remains the master of man. "

Though there are way more perspectives to take into account when choosing technology or technologies, it is important to realize that languages and models you choose affects the rest of your journey. There is the old Paul Graham’s article that echoes the same sentiment in a different way.

I am not postulating that you should aim to select the most powerful language and tools available, but rather be aware of the implications that technology choices have to teams. This is not much different from the question of architectural styles, but a continuation of that theme.

Depending on architectural styles you choose, you can try to run software components in multiple different languages in your system – and leverage the best sides of those tools in depending on contexts, instead of just choosing one language, framework, and style of thinking.

There is nothing wrong in using familiar and very popular safe tools when solving problems, as long as we do not fall into myopia that every single problem looks the same and should be solved in the same way. Case in point: there are other ways to store data than in a normalized relational database and good reasons to use them.

Complex adaptive systems perspective to change

I think it was Joseph Pelrine, a friend of mine, who quipped something along the lines that when you add people into any situation things become complex. He was also the person who introduced me to complexity thinking applied to software development and software development teams - and was the first person I know who brought Dave Snowden’s Cynefin framework for decision making into the agile world.

Joseph taught and has spoken years about social complexity and social aspects of software development, bringing insights both from theory and praxis into the agile community. For me, the implications have been huge in how I think approaching decision making and making changes to people systems where I work. Every change I propose or think is an intervention into a living system and can have unintended consequences for which I should be prepared in terms of how to amplify positive and how to dampen negative effects.

Having the complex adaptive systems mindset and vocabulary has helped me tremendously to make sense of the world and try to act accordingly in different contexts. And it has made to be aware of the fact that when we talk about people and people interacting with each other, I am highly unqualified and uneducated to make any better guesses than any other self educated layman.

And that is a good thing.

Responsibility, empathy and non violent communication

Last but not least a big influence in my thinking and being has been Avery’s responsibility process and trying to look how people behave through the lenses of empathy.

For my own behavior, I can take responsibility for my own actions, inactions, words, and thoughts. It is my failure in leadership if I am not able to create an environment and vision to help people take actions towards the right direction. Instead of blaming the situation or others, the final responsibility is with me.

Working in different environments and people systems has taught to me that in our work there rarely are people who want to be or do bad things. But in some cases the system and processes in which we work causes or influences people to behave in ways that can make them look that way.

Having empathy towards people helps us all to understand how can we help each other and work together to create something better. It is also a necessary precondition to being able to start any kind of facilitation or design of any kind of intervention to the situation.

As a communicator I try to utilize non-violent communication and behave as a compassionate human being. There are still situations and moments, when emotions overwhelm me and the jackal speaks - but at least I am becoming more aware of myself and can work on from those situations, instead of being just a victim to those conflicts.

And the journey continues

I assume that in a few years or decades when looking back this moment and this text - I will see some naivete in my thought and writing. That is to also just to say that my journey and apprentice to becoming a better human being and better professional still continues.

And that there is hope - even for engineers like me.