IT Organisation 2025

Thomas Heinevetter: How do you envision the future collaboration between IT and business? To give you some initial orientation for your answer, you can choose from four scenarios: 1. Business and IT merge completely. They work together in mixed end-to-end product teams. Infrastructure services come either from an external partner or from the cloud. 2. Here, IT is divided into two parts; the business-oriented area merges with the business as in scenario 1, while the infrastructure area is organized as platform or foundational IT. The 3rd scenario runs under the keyword Product-IT and is similar to the second. However, they are not dedicated teams, but virtual teams consisting of both business and IT, working together end-to-end. The 4th scenario is close to the current structure. On one side, there are mixed virtual teams, but on the other side, there are also traditional plan-build-run teams in IT. So, which scenario do you find most appealing?

Björn Dröschel: At our company, I see more of a mix of scenarios 1 to 3. For example, I believe that the infrastructure teams will be integrated into the product teams. They will continue to perform their infrastructure tasks but may also contribute to the product to some extent. This is how we are currently operating. I don’t think it’s a given that business and product will completely merge. A business executive handles many other tasks alongside product development, where they work independently of product development. It wouldn’t make sense to merge these two roles into one fixed team. However, I am sure that we need to promote and intensify cross-functionality. Of course, this depends on the orientation of each company. The more technical it is, the closer business and product should collaborate. After all, the business sells technical products and wants to incorporate customer feedback, especially in the development phase. That’s why agility is so important here. There’s no longer this linear development process where requirements gathering comes at the beginning and the product at the end. It’s about interconnected work with numerous and as early as possible feedback loops between producer and customer.

Heinevetter: So, would you also endorse virtual teams?

Dröschel: Yes. I mean, adaptability is one of the most important requirements today. And with virtual teams, whose setup I can fundamentally change if necessary, I can respond to change most quickly. That’s the flexibility I need today. An example from our sales: Salespeople naturally form their own sales teams, but practically every salesperson also works in one or more product development teams because they want to feed customer feedback back into the development process as early as possible.

Heinevetter: Do Citizen Developers and Low-Code platforms play a role in your organizational considerations? Does Low Code make the business more independent?

Dröschel: Towards the customer, this is a very important topic for us. Normally, a software provider wants to keep its customers as dependent on them as possible. The customer should direct requirements to the provider, who then develops and is paid by the customer for additional functionality. But that’s not how it works today. At least, we want to make our customers more autonomous, so that they can respond to their customers’ requirements to some extent independently. And Low Code helps us with that already. For example, in the area of configurability. Here, we enable our customers to adapt certain logistics processes themselves. As I said, adaptability is the biggest requirement. In the traditional model, change costs the software provider time and effort, and since our IT is always operating at the limit anyway, it’s smarter to involve the customer directly, show them simpler ways of change, and thus relieve both sides.

Heinevetter: Isn’t that overwhelming for the customer?

Dröschel: IT affinity has developed positively in recent years. Many more people now have some knowledge of IT than three years ago. And the organizational issues we’re talking about here are also affecting other companies.

Heinevetter: In our discussions with IT executives, the topic of Low-Code is associated with shadow IT and is therefore sometimes seen as a risk for IT. In your opinion, does Low-Code hinder or promote, as it also strengthens IT competence in the business departments?

Dröschel: I lack a bit of imagination to perceive that as a risk. Everything is becoming digital, and there will always be enough tasks for IT where they can support the business department. If the business department can empower itself and solve things on its own, that, to me, leads to an acceleration of development for the whole company. That’s something everyone should wish for because then a company can produce more sellable value. I don’t see IT becoming useless at some point; instead, it will take on other tasks that the business department cannot handle.

Heinevetter: We briefly talked about product teams. I’d like to delve deeper into that. What success factors do you see for setting up product teams in terms of competency, skills, roles, size? But also in terms of the question of internal or external, and whether they should be held stable or whether their composition should be flexible?

Dröschel: In my experience, you should build core product teams within the company and only occasionally expand them with external forces. After all, we’re talking about things the company wants to sell, about the company’s core business. Other processes outside the core business can also be staffed with external forces.

Heinevetter: Do you work with Scrum teams?

Dröschel: That’s where we come from, but we adapt the Scrum principle to our needs. At the moment, we’re working according to the domain principle and dividing ourselves into thematically oriented teams, which can also include up to 20 people. Depending on the requirement, these teams can further divide into smaller teams, for example, for sprints. Each team has at least two product owners and is reinforced by additional expertise: UX/UI designers, frontend experts, mobile developers, backend specialists, and so on. Depending on customer requirements and priorities, these teams split up for two to four weeks and work on the desired products.

Heinevetter: Is there also an overarching team formation across the two major teams?

Dröschel: We have divided the two teams thematically into domains to create focus. Of course, there are intersections between the major teams. At Spotify, they’re called guilds, and we call them expert teams. People with similar skills – for example, frontend developers – meet weekly and coordinate. They try to create a common basis. The same goes for product owners, architects, and so on. Additionally, we believe it’s very important for the various skill groups to be able to exchange ideas across domains – so cloud engineers with backend developers or architects and product owners, and similar.

Heinevetter: Does the way leadership is conducted change as well?

Dröschel: Yes, for example, we are considering People Coaches who would focus more on people’s development. The mindset of the individuals is crucial. These coaches need to be highly empathetic, able to put themselves in others’ shoes, to understand what is needed. These leaders don’t necessarily have to be the better experts in their field, but they need to set the framework for people, especially in IT, to develop further. Many no longer aspire to titles but seek the opportunity to shape, take responsibility, and develop. Something fundamental has changed in this regard. It used to be that if I’m good at my job, deliver excellent performance, I’ll soon become the boss myself. There wasn’t another way to advance one’s career. Today, we must create opportunities for technical careers; otherwise, we risk turning good technical experts into poor leaders.

Heinevetter: You’re a very young company. Therefore, you can more easily explore new paths. But what advice do you have for traditional IT organizations facing this challenge? They can’t just wait until established managers retire, managers who strongly define themselves through hierarchies and how many people they lead.

Dröschel: Traditional companies also need to adapt. They need to demand self-reflection from their managers first. What type of leaders are they? Are they strongly technically oriented, do they have a product vision, or are they more management-oriented? Can they handle people well, organize effectively, do they have mastery over their leadership toolkit? Based on their strengths and weaknesses, they need to seek support, whether technical or disciplinary. If they can’t do it themselves, the company takes over. They become more embedded in a leadership team, no longer solitary figures. I think this also makes the led feel more comfortable. They no longer deal with a boss who has weaknesses in one area and strengths in another; instead, they are led by a team that covers all aspects.

Heinevetter: Let’s move away from people and onto the topic of data. What impacts does the data-driven approach have on companies? Will there perhaps even be a separate organization for data, similar to what we’ve seen with IT? Will there be a Chief Data Officer, meaning data will be centrally managed, or will it be processed decentrally and be part of each individual organizational unit?

Dröschel: I think both will be the case. On the one hand, when it comes to collecting, processing, and basic analysis, companies will likely take a more centralized approach because it’s more effective. On the other hand, for deeper analysis, I can imagine that it will be both decentralized within teams and centralized. But there will be a central body in the company driving the overall data agenda. It will incorporate the teams’ requirements regarding data collection and analysis that cannot be met within the teams. However, the overarching question is what the company wants to do with the data. Organizational questions and which roles are needed where depend on this, of course.

Heinevetter: How have you implemented this?

Dröschel: We’ve created a cross-team Analytics area: Data engineers and data scientists handle data collection and analysis. At the same time, it’s also possible for these roles to work within the teams for a certain period to optimize specific functions from their perspective. With this dual approach, we hope to further embed the data topic within our company and prepare ourselves for AI and machine learning.

Heinevetter: I’d like to address one more significant issue: Transformation. As a young company, you must consider what your next evolutionary stage looks like and how you’ll get there. What are the success factors for such a transformation?

Dröschel: I believe there isn’t one transformation after which a company returns to a stable phase. I believe that transformation is, at least for a certain period, a permanent process in which collaboration, transparency, and communication are essential. This also involves trying out many things and continuing to develop or discard them with intensive feedback loops from the workforce. Not everyone needs to decide everything, but everyone must have the opportunity to provide feedback on all developments.

Heinevetter: Have you had any experience with this?

Dröschel: We’re currently trying this with a task force. We’ve identified the roles that should be involved in the discussion about the company’s further development, then sought volunteers within these roles who want to participate. In this task force, we also seek external advice. We discuss various scenarios and develop common models. We then present these to colleagues in the teams and gather their feedback, which we also consider. We hope to involve everyone who wants to be involved in this way, without creating a basis for democracy. But this way, everyone is engaged. Whether it will work, I don’t know because we’ve just started with it.

Heinevetter: One last question. What are the three most significant challenges you have to address in the short and medium term?

Dröschel: The first is the shortage of skilled workers – especially in IT. The second major challenge is to stay up to date with technology evaluation. Which new technologies are important and which are good for my company? The third major challenge is the pace of development. How can I ensure that I can respond to new customer needs as quickly as possible?