Making software is not about code

People outside the industry still believe this idea that software people just type on a keyboard all day and many devs do want that but are then hit with the reality that you need to talk to others in the company. Turns out that the so-called ‘soft skills’ are actually an essential part of the whole process. The way in which information flows from one human to another inside a company is crucial to what the final output will be. I want to look at that idea on two different levels

Organisation

There’s an information flow in every company. Business analysts and product managers gather information about what customers need and then translate that into a set of requirements. This goes to devs and designers who build the product. Software testers then take both of these pieces (requirements and working software) to verify it's correctness. Ultimately, the product is then shipped to customers who through their use (or abandoning) of the service give information about the value the company offers. This is our information loop.

It’s an oversimplification of course as there could be more sources of information about how and what to build - compliance teams may have input on constraints and marketing teams may have input on what tone of voice to use. Worth mentioning here is Conway’s law which states that how people on a team communicate is reflected in how well the system is designed and operates.

At each of these points of contact between people with different skillsets, there could be loss or misinterpretation of information which is where communication is crucial. The only way to deal with the loss inside the information loop is to learn more and uncover missing pieces through experimentation. How fast this happens is largely determined by the processes and workflows inside a company which is where agile comes in (see What most companies get wrong about Agile?).

On one end of the spectrum we have complete silos of information, business analysts and product managers compile lists/documents/tickets with requirements, pass that on to designers who come up with some visuals and then that’s handed to developers. It’s a very linear and step-by-step type of progression. A designer could come up with the most epic looking web page with the shiniest graphics and animations that could rival Pixar… but if a developer needs to move mountains of code, is this really a feasible and elegant design? Notice how in my poor diagram below the communication/information lines flow only in one direction.

What’s on the other end of this spectrum then? Having people with different skillsets talk to each other at every step of the process. Ideally every day with as little barrier as possible. Poor diagram number 2 shows a different way of communicating.

It’s not a new idea to have cross-functional teams but it seems to me that many companies claim to be so very agile and still form knowledge silos in their workflow. Developers do their coding, designers make mockups in Figma and product people write Jiras. They only pass the ball to each other instead of sitting together during their respective build phases.

Reducing barriers for communication can be boiled down to both process and company culture. By company culture I mean people actively trying to share information and communicate. Unfortunately, sometimes this is affected by interpersonal relationships in the workplace but more on that in a bit.

Essentially, It’s about people in different domains having touch points and appreciating the constraints and challenges others face. Developers thinking like product managers, designers thinking like developers and so on. It’s a mindset shift where people can get involved, question requirements and share ideas regardless of their title. From the point of view of a developer myself, what I've observed is that developers who are able to do that and deeply understand how the business works and what customers need are much more valued in a company. It's a powerful combination.

Human to human interactions

One level down from the team are individual human interactions. Something that’s often overlooked is the impact of complex social dynamics at play in any organisation. Just because we’re adults making software doesn’t mean we’ve evolved better social skills than when we were in kindergarten and school… Personality differences are inevitable, people will become angry, upset and so on. It’s very easy for things to spiral out and hurl names and labels at each other. Maybe not to their face but certainly with your buddies at work. How we work through those differences is what’s important.

Let’s say you and I are developers on the same team and we need to figure out a solution for a new feature. Both of us will have a different mental model of what is actually needed and why. Each of us has worked on different products in the past so we both have opinions on coding practices, libraries, system design. A heated debate and clash can easily occur where both of us end up angry at the other person for not seeing ‘the right solution’.

A dose of humility goes a long way in bridging the gaps in our mental models. I think that’s one of the most reliable ways for resolving clashes like that. You likely don’t know everything about the problem and its constraints and neither does the other person so asking questions is one of the best ways to reconcile differences.

What goal does each of us have and is it shared? Maybe you aim for a more configurable design and I aim for a less complex one.

Do the proposed solutions serve the goal? Sure, you suggested a cool new piece of tech but does it help us reach the goal?

Is the goal even worth it for the code base and the product as a whole?! Maybe we have a way of knowing we’ll gain a million customers in the next few months but we could be just doing premature optimisation.

Every software implementation will have trade-offs so it’s good to establish what the goal is as that will help resolve conflicts of that nature. Approaching differences with curiosity is crucial in those moments so that you can find the parts you're seeing about.

Another point to make is that people sometimes speak different languages. And I don’t mean in the sense of English vs German or Java Vs Python. Something more subtle is that we put different meaning into the same words. Developers talk about services or messages and think they understand each other. These are some of the most overloaded words in the industry. It may sound very minor and irrelevant but you’d be surprised how often this can lead to misunderstanding and wasted work. Therefore, it’s best if we can agree on the meaning of these concepts to remove all ambiguity. It’s even worse when technical and non-technical people need to talk and don't share an understanding of language and concepts. Speaking a shared language is valuable and often overlooked.

Alright, that’s it for today. Do you agree with the importance of communication? Let me know what you think!