Working on a system & Working in a system ...

[A fundamental principle of Trusted Shops' software engineering organization]

This article is about one fundamental principle of how software engineering is set up at Trusted Shops.

Latest update: 2024/02/06

As context always matters, let’s start with it:

• There are roughly 130 people across all functions working on the products and services of Trusted Shops.
• Trusted Shops is not a startup anymore. But we are still in an evolving game, which requires us to adapt to learnings, market changes, etc.
• The organizational setup is guided by two pillars of the Tech Strategy: Autonomy on organizational level & Empowerment and ownership on team level

System-thinking and beyond

Now that the context is clear(er), let’s look at the fundamental principle:

1. We understand our software engineering organization - actually product engineering organization - as a system. It’s composed of smaller interrelated subsystems (domains and teams) who work on different products to achieve an overall goal. (If you want to learn more about organization as system, this is a good source.)
2. We separate between "Working on a system" and "Working in a system". This separation is important because both aspects have different goals and require different needs to achieve them.

Many companies use their disciplinary structure to handle operational work. To illustrate this, one example are Team Leads or Head of Engineers who take technical decisions for their teams. Operational work dominated by the disciplinary structure works fine for repetitive work. But it hardly works for knowledge work. Knowledge work is about solving complex problem(s) which requires expertise, critical thinking and interpersonal skills.

Working IN a system

To address this demand we highlight the operational structure. It’s described as “Working in a system”. “Working in a system”, there are no disciplinary hierarchies. There are only individual contributors with different roles and technical responsibilities. The decisive factors are skills and experience. Cross-boundary collaboration (e.g. to manage dependencies) is handled via network approach. This means, there are direct connections between teams where needed and when needed.

Working ON the system

Working on the system is represented by the hierarchical structure. In our case these are Engineering Managers, Director Software Engineering and CTO. The goal is to provide an effective environment on all levels. This starts with the organizational setup and the hiring and the development of talents. But it’s not “people business” exclusively. It’s also about the involvement in one-way-door decisions, defining standards, applying best practice and solving systemic issues - to name a few -, always based on the mindset to measure and improve the environment. This work happens more on a tactic and strategic level. It still requires a technical background even though it contributes only indirectly to the overall success.

At the end the disciplinary structure is serving the operational structure. But this doesn’t mean it’s less important. The system can only unveil its potential if both complement each other.