A trust-based approach to software development

In a team like SitaWare Aspire, you can really make your mark on the final product. Trust and feedback go hand in hand, as everybody on the team pitches in to create our solutions.

In the Aspire team, all ideas are appreciated and evaluated, and then turned into actions when they are mature enough. This allows everyone on the team to make their mark on the product – and to Architect Asger Hammarberg Andresen, this way of working ensures value and satisfaction for both customers and team members.

“We don’t really care much for hierarchies. Instead, we want the best idea to win – no matter who has pitched it. Everybody chips in with ideas and suggestions. Nothing gets dismissed at first glance,” Asger says.

Sometimes, it can be an idea for functionality that is relatively easy to develop. Other times, a developers’ input can lead to improvements on a strategic level – and have great impact over time.

In these cases, Asger always prioritize sparring with team members, if needed, before the idea is put forward to Product Management.

No micro-management – only teamwork

Sharing ownership is a fundamental part of Asger’s work life. In his experience, the better team members take ownership and responsibility, the better solution is delivered in the products. With that perspective continuous sparring and feedback is crucial.

“No one is capable of knowing everything about everything, so we need each other’s views and expertise. It improves our teamwork, makes us work more efficiently,” he explains.

While receiving and providing feedback is a central part of his work, Asger has no need for being involved in everything the developers do. In fact, much of the feedback is aimed at letting developers run with the ball themselves.

“Trust is an essential part of Systematic’s DNA and something we really practice in the team. My ambition is to always show trust and let my teammates solve their own tasks, even though it can be tempting to get involved. That is very important to me.”

A smaller team with big impact

As SitaWare Aspire addresses a variety of customer challenges, Asger always tells the developers: “You are solving a problem, not coding a feature”. To do so, they need to understand the problem they are solving.

“We use outcome as a measurement of providing successful solutions and have the domain and technical experience to deliver the right solutions. This means e.g., that users of SitaWare Aspire will not get the solution they ask for but a solution that solves the underlying problem. Obviously, this is a delicate balance but when it makes sense, we challenge our customers to ensure the best possible solution,” Asger explains.

“As an Architect, I am very aware that we should not fall in love with a technically nice feature, but rather keep our eyes on how to best solve present and future challenges for our users. SitaWare Aspire will have a direct impact on soldiers’ work and potentially their safety. That is what makes it all worthwhile for me, and it sparks my motivation every time I get to see how much the soldiers appreciate our work.”