Make software architecture accessible to everyone by introducing a shared vocabulary – an interview with Mindler’s Björn Helgeson

The CTO vs Status Quo series studies how CTOs challenge the current state of affairs at their company to push it toward a new height … or to save it from doom.

“I’m a big fan of domain-driven design and having a shared vocabulary with the rest of the organization”

At many organizations, the conversation about software architecture is often dominated by engineers. Does it have to be this way? Sure, this is a technical subject, but it extends to all aspects of the business.

Mindler’s VP of Engineering, Björn Helgeson, offers a different perspective on software architecture. He sees it as an area where everyone in the organization contributes and learns.

Is it really possible? And how can an organization benefit from it?

Read on and find out:

• why you shouldn’t optimize for a future that hasn’t arrived yet
• how to improve the engagement of all employees by answering the question “Why?”
• how to talk about architecture in a way that meets the needs of every person and department in the organization
• why the one-size-fits-all approach to documentation doesn’t work most of the time
• how can cross-functional collaboration be improved with the use of simple drawing tools

But first, meet Björn!

About Björn 

Mindler’s vision

Hello Björn. You joined the Mindler team as VP of Engineering in March this year. Congrats on that. How is it going so far? Tell me more about your work at Mindler.

Hello. Mindler is a digital therapy provider with an international presence. We’re active in 5 different markets.

What intrigued me about Mindler is that it’s not just a video consultation provider. We actually have a digital product that enhances a patient’s therapy outcomes. It’s a really exciting project.

In these eight months, Mindler has been a really amazing workplace, a fantastic group of people, and offers great company culture, too.

I also really love the problem domain. I studied psychology when I was younger. I find it fascinating. There are talented psychologists in a lot of different positions at the company – in senior management, product, or working as country managers. Psychology as a domain of knowledge is really infused into the organization. As a result, there are so many nuggets of knowledge and wisdom to absorb from different parts of the organization 

Until recently, you were the CTO and co-founder of EsterCare, a startup on a mission to make specialized health care more accessible to women. Did this fact also have something to do with your interest in Mindler?

I actually met Mindler’s previous CTO while working at EsterCare. We started exchanging insights on how we built our companies.

These two organizations are definitely similar in many ways. Both are active in the Swedish healthcare market. Even their tech stacks are quite similar – both on AWS, using a TypeScript stack and opted for similar architectural choices and integrations. There are also many general similarities in digital healthcare, such as the popularity of the video meeting feature.

What’s really great about working in healthcare is the feeling of purpose. After I left EsterCare, I wanted to continue working in the industry, getting testimonials from patients directly and hearing them talk about how our services helped them make their lives better.

The conversation about software architecture

Speaking of missions, I wanted to talk about educating and advocating for software architecture in an organization. That, too, could become a mission in and of itself, one that doesn’t only concern the CTO or VP of engineering.

I recently spoke to a CTO about architecture. We talked at length about how the tech’s desire for the scalability of software architecture clashes with the need for business flexibility. It seems that the conversation about architecture often comes down to this binary choice. What do you think about it?

Business flexibility is often a mix of architecture and business scalability.

I used to work a lot with different startups and greenfield projects. Often, a product or R&D department would come with weirdly specific requirements, like their service has to be able to read 20,000 invoices per second, even though they didn’t have any clients yet. They didn’t do the market validation, and they didn’t know anything about the customer or end user behavior yet.

People often mistake scalability for building at scale. When they talk about scale, they mean load or performance requirements. They think that whatever they build now it needs to be able to handle gigantic traffic from day 1. These kinds of specifications are very easy to write down and verify if you reached them or not. What’s more useful and harder to achieve is to think about scalability as the ability to change – and support the business needs.

First, you should build rapid delivery and flexibility. Then, with the right focus on code quality and separation of concerns, you can easily adapt your architecture for new pivots or other new requirements that emerge from new business needs. Scalability in my world is a lot about changeability, about how easy it is to modify what you’ve done so far.

It seems you might have found an interesting angle for the software architecture conversation that doesn’t lead to conflicts but perhaps can unify the organization around it.

I’m a big fan of transparency from a strategic perspective. We’re going in this direction at Mindler, and everyone is in on it — that’s one of the most important parts. 

Everyone should be able to get familiar with the steps they want to take to achieve a given architectural objective, not just the objective itself. Then, if something happens and you need to change course, everyone will understand why there’s a change.

Another interesting angle is that you invest in the architecture to be able to do rapid prototyping of proof of concepts. When you do an MVP, there should be a common understanding that it’s not the final product. Everyone should know that you trust them with all the necessary work when you make another pivot, give up on something, or try something new again.

So, informing everyone about the middle steps that lead to an objective?

Exactly. A previous employer of mine was a digital agency focused on prototyping and MVPs, and going from idea to production software in a rapid and effective fashion.

There’s a lot that large companies have to learn about the process of prototyping, such as being able to run a hackathon or an exploration project, and having development be more technology-led.

When the Product department defines the scope and requirements for everything, it tends to be very user-centric and business-like, which is exactly what we want. That’s one way of going forward. But there is another way: technology-led development, where you let technology guide what and how you build something. In software development there are many occasions where the devil is in the details. We easily get overwhelmed by details and forget the purpose and the “why” of what we’re doing. Technology-driven product development means getting technical input early, and going more “with the flow” of what is easy to do.

Software architecture at different stages

Let’s talk about software architecture at different stages of an organization’s growth. You were a founder of a small startup. In an ideal scenario, how would you go about ensuring that everyone, not just engineers, is aligned about software architecture? Is there even a need for it this early in a company’s life?

Definitely, but startups do have some distinct characteristics. They tend to focus on doing something fast, while more mature organizations want to do the right thing and do the thing right, so both the scope and quality matter.

In a startup, you know so little about what it means to do the right thing. You need to try new things and pivot to find your business model, so it’s more important to do things fast and gather information.

I’m a big fan of domain-driven design and having a shared vocabulary with the rest of the organization. You can sit down with the domain experts and listen to them describe their problems and reality. You can model software architecture after that. I found that this sort of shared vocabulary is particularly important for a startup. In a larger organization, there’s more room for different vocabularies and views on the same thing. It may even be necessary for different departments.

However, in a startup with a team of 10-15, it works differently. Someone would ask me a simple question such as: “How many bookings did we have last month?” It feels like there should be a single, straightforward answer to this. But in reality, there are many different complications – patients book appointments and then cancel or never show up. Sometimes the clinician doesn’t show up, or uses the booking slots in their calendar as blockers for something else. At other times, the patient needs to be referred to someone else during the meeting.

I realized that different people asked me the same question but had different things in mind. For example, when the marketing team asks about the booking situation, it’s in order to optimize the conversion funnel, they care less if a patient afterwards cancels a reservation. They just wanted to know if they went through the funnel correctly. When the CFO asks, she wants to know how many bookings we were paid for in the last month. When the Operation Manager asks, we need to separate available slots and booked meetings, for enabling the work of matching supply and demand.

We ended up creating a shared vocabulary that includes multiple precise terms with a clear meaning for everyone.

What about a scale-up? At that stage of maturity, technical debt starts to show up, and the engineering department often tries to negotiate more time and resources for architecture optimization in vain. Can something be done to prevent this?

It helps a lot to visualize. At Mindler, we’re searching for a common tongue and tangible effects – how much this particular technical debt costs us, slows us down, and so on. I think that we’re pretty good at it, but there are some things that are harder to measure the effects of, like joining two separate global environments to cut time spent on debugging or monitoring.

What has helped me a lot when discussing optimization is giving rough estimates, apologizing for them being rough, and being honest about the fact that you can’t measure it exactly. But it requires that you have trust already.

Another solution is cross-department cooperation, which involves establishing a trusted relationship with other stakeholders, especially with the management team.

You also mentioned a mature organization. What would characterize a mature organization in terms of software architecture awareness? Can you describe an ideal situation?

Like I mentioned, I would require this shared vocabulary. It must be something that any layman could use to talk about a given subject. Having that written down in a manifesto or an onboarding manual is very helpful.

In addition to this, I think that there’s some space for having different mental models of how things work in different departments.

Big companies often try to create one single architectural chart to rule them all. They want to draw out their architecture. It’s typically a huge document with hundreds of nodes, trying to explain how one user base of a particular service interacts with something else and so on. That’s really useful for no one because it’s just too much information.

Instead, create a mental model specifically for the person who wants to understand something. I’m a big fan of illustrations and architectural diagrams. I encourage all of our developers to draw or sketch something on a whiteboard to share our models of how things work.

If a psychologist wants to understand why they can’t use the same password for the UK and Swedish versions of the Mindler platform, you can create a model with diagrams and visualization to explain that. You don’t show them anything else that is not relevant for their issue.

When we architects describe what we build, we tend to be biased. We really want to show off the complexity of what we’ve built. We are proud to be able to handle all of these advanced solutions, after all it’s our job. And when we spend 60% of the development time on a rare and particularly difficult corner case, we will really want to talk about it. In most cases however, this is not a good approach.

Instead, you want to make things easier and sometimes even lie about something being simpler than it really is. If someone is curious and wants to understand more about how something works, then you can give the more advanced explanation.

Education and advocacy

Let’s now try to figure out how to get as close as possible to this ideal of software architecture awareness. We’re going to create a little roadmap for tech leaders interested in truly owning the software architecture conversation in their company.

For starters, how can one speak about software architecture in simple terms about what it is, why it is important, and what impact it has on the business and product?

Like I said, put your pride aside and focus on the target audience. It’s simply not possible to make a single architectural presentation that will suit everyone.

Perhaps one problem description should be provided for the management team that wonders how we store data for risk awareness. Then, another model might be used to describe to our customer support staff how all the systems they interact with work, leaving everything else out. Create those context-specific presentations and illustrations.

You can also use that technique in writing. For example, we use Notion a lot for note-taking for certain projects and initiatives. It is a good tool for highlighting specific information about architecture that is relevant for non-tech people.

But don’t overdo it. The problem today is not that there is not enough documentation – at least, it wasn’t the case in the last couple of companies that I’ve worked with – but that the documentation is quickly degrading. It gets old quickly, and the more documentation you create, the more you have to maintain. It’s worse to have outdated documentation and a lot of it than a little but well-maintained documentation.

Remember also to start with the “Why” question. Most people in your business aren’t simply interested in hearing about architecture for architecture’s sake. They want to know how it relates to their work.

As engineers, we’re often simply interested in how something works, and the why is a bonus. But that’s not the case for everyone. Most people want to know why they should care about it.

Before teaching leaders to start educating, perhaps it would be wise for them to find allies within or outside their department. There may be some new stakeholders for whom architecture is also dear across the organization. You may even appoint dedicated software architecture advocates in different departments.

What do you think about it?

I’m not sure if you should have a single dedicated person for software architecture knowledge. You can have a facilitator overseeing the general shape and format. But apart from that, I think that in order to give good explanations, you need specific domain knowledge.

For example, your head of analytics or data could be the one to model and explain data storage. And your AWS or DevOps guy should be the one that draws the architectural AWS diagrams. Your lead or frontend developer should be the one who explains how state handling in the React Native application works.

Of course, as they do it, they should use the shared vocabulary that everyone understands. They should use their expert knowledge and best judgment to find a way to simplify an issue in a written form or in a verbal discussion. That’s hard.

Preparing some documents or organizing an event may turn out to be the easy part. The harder part could be to make this effort ongoing and ensure that everyone in the company shares a common understanding and core knowledge of software architecture.

Yes. There are standards for illustrations and architectural diagrams. At Mindler, we tried using different formats. The problem with those has been that they have a learning curve. You often need to learn a certain syntax or rules to be able to create something. Not even every developer wants to use it as a result.

I’ve had more success with simple drawing software like Excalidraw or Whimsical. It’s quick to learn, and although it looks crude on purpose, it’s easy to use it to create something decent-looking quickly.

And what would be the best time to pass all that knowledge by means of visualization or in any other form?  How do you like the idea of a cross-department workshop about software architecture?

The easiest time to improve things is when you’re changing. Think about that in terms of the regular software development cycle. For example, you’re documenting a new integration that you’re building – that may be the right moment to add sign documentation and illustrations or something else for educational purposes.

As for workshops specifically, first, when you do them internally in the tech department, make sure to engage developers or tech leaders who are actively involved in the upcoming change. We have them partake in an explanatory workshop. Then, they participate in other recurring meetings, such as a developer forum that we have once every second week or a tech lead forum.

As for extending that into the rest of the organization, we’re doing it mostly in connection to another change that is relevant for whoever is the listener.

For example, when we onboard a new company client at Mindler, we package relevant information into a workshop to explain how the app will work, how the user will log into the app, what the data storage looks like, when the data will be updated, and so on.

What about self-learning? Once inspired, folks could probably keep on learning by themselves as long as they have access to knowledge that isn’t overly technical. How would you go about creating such content?

When I managed developers directly, my general advice was almost always for people to draw whatever they were thinking. When you draw the solution, you have something tangible that you can show someone else so you can think about it together.

Drawing is an especially helpful tool for junior developers who want to communicate their problems. It also makes it easier for senior developers to understand the issue. They don’t need to waste time asking many basic questions. 

So, draw things and build your own mental models around problems, then compare them with others. You can then ask questions such as: “Do you also think like this about how our session handling using web tokens works in our application?”. That way, you’ll have a fruitful conversation that builds up shared knowledge.

Let’s return for a bit to the idea of making a case for a software architecture initiative, like a need for some optimization or re-architecting. How much education could make it easier to get support for such an initiative?

It could make a difference if you gradually create a culture that appreciates initiatives backed by strong data or other valuable arguments. Let’s consider an example.

Suppose we have 350-400 psychologists. They need to log in to each of the two systems they use separately, and we want to enable a single sign-on for them. We need to show other stakeholders how much time it costs the psychologist to log in using the current setup and how much we could improve it. There are 400 power users who use it multiple times a day. If you multiply the numbers, it may turn out that this redundancy costs real money. That way, you can translate architectural tasks into real business benefits.

But there are also some things that you can’t really measure that may still be highly important. To advocate for them, you may use testimonials. Gather feedback from users and demonstrate how annoying a given feature is to them. Present this feedback as a voice of the customer calling for a change.

Ultimately, both solutions boil down to showing how architecture problems may have real-world consequences.

But some architectural issues might, in fact, hurt your engineers the most. Developers are very expensive. They are always happy to see improvements in productivity that allow them to spend less time on monitoring or bug hunting.

The topic of how architectural or development metrics translate to business value is very interesting. There are many approaches. For example, I really like the DORA metrics.

Can you elaborate on that?

DORA was a research team that was acquired by Google a bunch of years ago.

They gather data from thousands of different companies and try to see what metrics in their IT or DevOps departments best correlate with their business success.

Eventually, they came up with four independent metrics. The idea is that when you’re doing well in the areas they relate to, your organization is healthy. They are Deployment Frequency, Lead Time for Changes, Change Failure Rate, and Time to Restore Service.

Of course, you shouldn’t consider it as gospel. It’s a bit dangerous to reduce the complexity of the organization and the world to just a few metrics. I’ve had clients who wanted to measure productivity based on the number of lines of code or commits. You need to be more flexible than that. However, metrics are valuable as a guiding force.

Resources

Let’s close with some additional learning resources that could help tech leaders prepare for education and advocacy in the area of software architecture. Do you have something on your mind?

I can definitely recommend a lot of interesting tools. As far as software architecture is concerned, I’d recommend Domain-Driven Design by Eric Evans, Measure What Matters by John Doerr, and No Rules Rules by Reed Hastings and Erin Meyer. All of them relate to the issues I mentioned today.

On a more general note, I always recommend Drive: The Surprising Truth About What Motivates Us, Turn the Ship Around!, and, of course, The Lean Startup – these three are great reads for any tech leader!

I also follow a lot of podcasts, I enjoy Pivot and Freakonomics for example. However, I’ve always had a hard time listening to coding or tech podcasts specifically. They’re probably not the right format for me.

What’s next? Three actions for CTOs to take

So what do you think? Are you ready to reshape the software architecture conversation in your company and create a shared understanding of it so that everyone is on the same page when it comes to the relationship between technology and business?

By giving people consistent language and precise key terms to use, you can improve the efficiency of all your individual employees and departments, giving them the knowledge they need when they need it. But first:

• Develop a common vocabulary for your organization so that everyone can talk precisely about the important issues that concern everyone, improving problem solving.
• Pass architectural knowledge in context by including practical information about how any new change impacts different departments when the changes happen, using the shared vocabulary you developed.
• Further the knowledge by visualizing a problem, which is an excellent way to explain it to someone who has a different perspective on it.

Each conversation only works when you can empathize with the other party. The one about software architecture is no different!