The importance of including a social perspective in technology

Prior to starting my new job as a Tech Lead at Worth, I had a couple of weeks of free time. During that time, it was a perfect moment to reflect on a couple of things. One of these things being the various projects that I have worked on. While reflecting on these projects, I became curious about what I liked about the ones that were a success, and what I disliked about the ones that turned out to be a failure.

Of course, there’s often not a single reason why a project is either a success or a failure. However, after reading Nick Tune’s introduction to Sociotechnical Architecture Patterns, where he describes various organisational designs, I found some answers. After reflecting, I recognized from my own experiences that taking the social aspects into account made the chances of success much higher.

It strengthened my belief that a software developer, architect, or designer, should not simply live in their own bubble. We need to be truly emerged in the problem domain and the organisation that provides the solution. It is important that we have a strong relationship with the organisation and the problem domain. In such a relationship we will be able to deliver a solution that solves the problem with less political wranglings.

Since the article from Nick Tune, I have been reading a lot of articles and watched a bunch of videos. Over time, I’ve learned that there are many perspectives that we can apply at our field of software engineering. Besides sociotechnical organisation design, I also came across many other kinds of behavioral science research. For example, ‘Thinking Fast and Slow’ by Daniel Kahneman, in which he explains the two systems in our brain that are fighting over who’s in charge which makes us prone to errors and false decisions.

The importance of organisation design

A lackadaisical design choice in either the system of work or the system of software can introduce severe bottlenecks that cause weeks of lost effort and exasperating political wrangling. – Nick Tune

Previously, I worked at a well-known Dutch e-commerce company. When I started working there, a couple of teams were responsible for a shared set of systems and functionalities. While growing, we learned that releasing new functionalities became harder and harder. For instance, it required more and more coordination between the different teams. As a consequence, it slowed down delivery and innovation, and it had a negative impact on the quality of the delivery and its functionality.

By rethinking and redesigning the organisation of the company, we were able to speed up the delivery and success of the teams. In this case, we chose a business-capability heuristic. We looked at the main customer journey and sliced it in pieces. In the case of an e-commerce company, that meant there was an area responsible for product navigation, ordering of a product, the shipment of the order and many others. As a result, these areas became responsible end-to-end. In addition, this responsibility also affected the daily operations and other non-technical concerns.

It’s all about communication

As a result, the delivery of new functionalities increased in terms of velocity and quality. We were able to learn quicker from what we created and iterate based on what we had learned. Conversations between the business and the development teams became better as they better understood the problem. The effect was larger than just the software systems delivered. It tremendously improved operational processes and the communication between the various parts of the customer journey.

As Conway’s law already tells us, we design systems that copy the communication within the organisation. Therefore, it makes sense to put effort in describing the organisation design prior to looking into the software architecture. To me it shows that any tech strategy is based upon the business vision, product strategy and the organisation design. Only when we have these things clear and defined, we can create a solid Tech Strategy. At Worth, we can support in discovering and creating these – to me – prerequisites of a Tech Strategy.

Reducing dependencies
One of the main objectives with organisation design is reducing dependencies. Albeit dependencies for the team, or with regards to the work they have to do. Empirical research as described in Accelerate shows us the prequisites of high performant teams. As the researchers find in their report:

“If we achieve a loosely-coupled, well-encapsulated architecture with an organizational structure to match we can achieve better delivery performance… and substantially grow the size of the engineering organization and increase productivity linearly” – Nicole Forsgren & Jez Humble

Personally, I have experienced delivering with higher velocity and quality. In these projects, we were able to manage and control our own infrastructure environments. We were in charge of our own build and release pipelines. On the other hand, I have also seen the political mess when an organisation doesn’t make conscious decisions. For example on the topology of DevOps it chooses to adopt and implement. To me, it is a decision that needs to be made with consideration. It requires conscious thinking, deliberate choices and support throughout the organisation.

Having a shared sense of reality

Reducing dependencies helps to ensure that the whole team is on the same page. Less communication with others makes it easier to share a sense of reality. Evelyn van Kelle describes this in her in-depth talk about ‘Essential Social Heuristics’. In this heuristic, she describes the importance of a T-shaped team where technology and domain experts blend together. This collective makes it easier to define the problem. Using that information to come up with a solution and refrain from falling back on biases like the Availability Heuristic.

Strategies and heuristics as provided by ‘Domain-Driven Design’ help to reduce dependencies with regards to the problem space. The approach centers the problem. It enables the team(s) that work with the problem to understand and model the problem. It counters simply creating a solution that tries to solve barely known problems. But this deserves an article on its own.

Sustainable digitalisation

At the start of Evelyn van Kelle’s talk, she raises a valid concern. “How sustainable are our current efforts to digitalise our information society?”. I agree with her that we can do a better job. That taking into account social aspects in our daily work can help to deliver solutions in a more sustainable way.

This is originally posted on the blog of Worth Systems.