Digital Sovereignty as Self-Understanding

Dieser Artikel ist auch auf Deutsch verfügbar

This article is part of a series

• Part 1: From Data Graveyards to Knowledge Landscapes
• Part 2: Digital Sovereignty as Self-Understanding (this article)

This article applies the concept of “digital sovereignty” to implementation teams as networks of people with their own individual skills, desires, needs, and visions. Starting from the premise that the foundation for technical and organizational sovereignty of complex systems lies in the capabilities of the people who build these systems, the article analyzes the characteristics of effective implementation teams and key levers that organizations can use to become more sovereign at the operational level. How do we, as individuals and teams in the European digital industry, overcome the feeling that we’re always just chasing Google, Meta, and others, and how do we empower ourselves to find our own solutions to our own problems in line with European values?

We Are Not Google?

We are not Google. This phrase is ubiquitous in IT. When discussing digital sovereignty, it should give us pause, because it can express a self-understanding that has nothing to do with sovereignty. Let’s be clear: it’s right to realistically assess a software’s user base and importance. Internal construction software for a mid-sized German company has different scalability and throughput requirements than Google – granted. But there’s often something else lurking beneath the surface. We are not Google. Self-doubt. Envy. The Americans are light-years ahead in software technology; we’ll never catch up. Silicon Valley has more resources, technical talent, and power concentrated there than we in old-fashioned Europe could ever assemble. This feeling that we’re playing in the minor leagues while others build the “real” software (and make fortunes doing it) that we use daily and, frankly, couldn’t live without: Windows/macOS/iOS, Microsoft 365, Google Workspace, AWS, ChatGPT/Claude… what’s next? The eager anticipation when Apple’s CEO takes the stage before the world press in California… almost like Christmas! But why not in Berlin? In Paris? London? Why is it always “the Americans” driving innovation forward?

There’s Plenty to Do

Don’t misunderstand: this isn’t a plea to “build the next Facebook” in Europe. Our framework conditions are different. Sovereignty relates to responsibility for us, in the quite traditional sense; and perhaps digital capitalism isn’t really our thing anyway. But that doesn’t mean there’s nothing to do here. Could GenAI, for example, make the thoroughly European maze of regulations and laws navigable for ordinary mortals? Everyone’s frantically searching for use cases for this technology right now. Here’s one – mind you, for the coming European AI, which will have exactly the same massive energy appetite as its American and Chinese counterparts. How to satisfy and ideally contain that appetite, preferably without building a nuclear plant next to every data center… unresolved. And then (forgive me) the uncomfortable truth: somewhere in the world, human-caused climate change was voted out of office last November. But temperatures are still rising, and solutions – including digital ones – are needed. Green IT, anyone?

The list goes on – the point is: if we extract digital sovereignty from the context of a threatening geopolitical “turning point” from which its necessity is usually derived in German discourse, we can understand it more positively, more constructively. Then the alarm bells in our heads don’t constantly distract us, and we don’t act reactively but, precisely, sovereignly. Understood this way, digital sovereignty is the intellectual and organizational capacity to digitally solve complex problems ourselves.

Yes, this includes the ability to develop European alternatives to Google, AWS, and Microsoft 365. But above all, it’s the ability to tackle challenges of any kind – the ones mentioned above are just examples. Having the courage to do this is a strategic decision, but that alone doesn’t change the world. The best idea is worthless if it’s not implemented at the right time with appropriate resources. One thing is certain: for this to succeed, the we-are-not-Google mindset must disappear – at all levels, but especially among implementation teams. Let’s examine what characterizes sovereign development teams and what levers we can use to promote sovereignty at the operational level.[1]

The Sovereign Team

We’ll approach this from the outside: a team of computer scientists and domain experts develops software for an organization that wants to be digitally sovereign. Our team wants to support this goal. How can we assess whether they’re succeeding?

The Goal-Oriented Perspective

Since we initially assume we don’t know the team’s internal processes, we can only examine the results. Reflexively, we turn to the standard metrics of effectiveness and efficiency: a team that delivers exactly what’s needed is effective. If it doesn’t consume more resources than necessary, it’s efficient. These are qualities we’d colloquially describe as expressions of sovereignty. They’re qualities that help the organization achieve its goals and assess the feasibility and resource requirements of future objectives. This organization will miscalculate less often than others. Its software quality will provide competitive advantage. Its teams can find adequate solutions to problems and implement them – without external support, or with external support to an appropriate degree. All of this contributes to people in the organization experiencing themselves as sovereign and qualifies the organization as digitally sovereign in the constructive sense proposed above.

Effectiveness and efficiency appeal to managers because they’re measurable (efficiency) and decidable (effectiveness) – but only in hindsight. Starting from the result, I can judge whether the path was good. I can examine metrics and say “yes, we’ll do it that way again” or “no, that didn’t work.” I can start measuring along the way, bring in benchmarks, and try steering and course-correcting. But the uncomfortable truth is: metrics will do little to accelerate my team. Nobody likes being measured, judged, and pushed in a direction. Besides, numbers and charts have limited impact on intrinsic motivation – if any at all.

Effectiveness

Let’s assume our team actually acts sovereignly. We look at the result and find it was both effective and efficient. What characteristics does the team probably have? We’re looking for qualities more elusive than what metrics can capture. Freely associated and unordered: energy – learning ability and resilience – commitment – expertise – technical competence – discipline – good team dynamics – decisiveness and decision-making ability – product identification – patience… The set isn’t sharply bounded or complete: many hard-to-measure qualities that we’ll summarize with the energetic word effectiveness. Effective people and teams will very likely prove sovereign. An effective team can deliver – quickly and precisely, and not just once. An effective team wants to deliver. And it probably does so more convincingly each time.

The problem is that I can’t organize effectiveness into existence. There simply aren’t three golden rules of team building that will transform my developers into a dream team overnight. Effectiveness eludes precise definition, and thus any repeatable strategy for creating it – and that’s a good thing. These are people developing our software: complex, complicated beings with individual strengths, weaknesses, desires, and visions. Not to mention the team itself, this fragile social system about which no one can predict with certainty what dynamics will develop.

Team effectiveness presupposes individual effectiveness. Individual effectiveness presupposes task-specific expertise – and individual maturity: I must have learned to direct and deploy my energy in measured doses. I must have experienced how empowering it is to take responsibility, and how satisfying to contribute to something greater. I’ve probably understood that neither free snacks nor in-house baristas are sufficient criteria for a good work environment. Maybe at the end of the day, it’s even more important to me to roll up my sleeves and create something than to feel comfortable… Clearly, we can’t just manufacture such people. We also can’t list all this under job requirements: “You’re passionate about XY” just feels cringeworthy; and if we start demanding proof of life experience or therapy hours, first HR will object, then the data protection officer.

In summary: we want effective teams because they’re probably effective and efficient – i.e., sovereign. Effectiveness emerges and operates at a level that eludes external assessment and managerial manipulation. But we’re not powerless: effectiveness is an expression of the unhindered interplay of various healthy, fundamentally human qualities. Being effective simply feels good, and given inspiration and opportunity, I’ll probably develop into a more effective person over time. What conditions are favorable for this? How can we give our developers and teams the opportunity to become more sovereign from within?

Levers and Pitfalls

Let me randomly select observations from our daily project work that fit this context. They can sharpen awareness of conditions that make development teams more effective in the medium term—or not. Many are things “everyone knows”—but that too often fall by the wayside because they’re considered soft and difficult to influence.

Keep It Simple, Stupid

Every developer who’s had to read through a large, unknown codebase will confirm: KISS is fundamentally sound. At the organizational level, the concept is applied less frequently. Yet the advantages are obvious: the simpler organizational structures and processes are, the less indirection and friction loss occurs. The less time teams spend understanding unnecessarily complicated structures or building them themselves, the more time remains for actual work. Note: this isn’t a call for anarchy. Division of labor must be organized – but every team is different, and the basic assumption should be that a group of adults with a clear goal can organize itself ad hoc based on a few established principles. If I show this trust to a team, it will develop awareness of autonomy and decision-making power over its own processes – a basic prerequisite for energetic action and decisiveness.

No Fear of Hierarchies

This also isn’t a plea to abolish hierarchies. Flat hierarchies are probably good because they’re more efficient than long chains of command. No hierarchies – that ends in chaos. Where things must function despite adverse circumstances and limited resources, there are hierarchies.[2] The difficulties with hierarchies don’t lie in decisions being made elsewhere. Problems arise when: (a) decisions take too long traveling up and down the chain of command, (b) teams don’t understand or can’t identify with goals postulated two or three levels up, and (c) the aftertaste of subordination and power imbalance is too strong, eroding any feeling of personal sovereignty. But if we understand hierarchies horizontally rather than vertically (“those up there”), then it’s not about pecking orders but clear task allocation: This decision is made by X because they’re well-suited due to expertise and have time to keep the organizational context in view. If the decision affects units outside the immediate environment, I bring in Y, who sees things from greater distance with a wider field of view. Long story short: hierarchies have a worse reputation than they deserve, as long as they’re not burdened by extraneous, unhealthy dynamics.

Meaningful Goals with Identification Potential

The wisdom isn’t new: to get many intelligent people running in the same direction, you must give them a reason. You must formulate clear goals, and these goals must awaken intrinsic motivation. Many smart people have tackled this alignment challenge within large organizations – precisely because it often remains difficult. Anyone who’s worked extensively with software engineers (or other complex engineering roles) knows these people often have deep substantive interest in their work, and that the tasks themselves often matter more than financial success. If building high-quality, sustainable software that does meaningful things for people has value in an organization, that organization will find it relatively easy to get teams to identify with their tasks and products. Conversely, a corporate culture where revenue is paramount, and where corresponding metrics and charts are the central steering mechanism, tends to foster inner distance from one’s own actions among the creative and conceptual workers at the implementation level.

Demanding Performance When It Makes Sense

The beautiful thing is: when teams identify with their goals, performance can indeed be demanded, even beyond usual measures. Most software developers have experienced the all-nighter when a feature simply must ship, or when an unforeseen problem delays production release. With genuine identification with one’s work, such things are absolutely possible. The point is: it feels good – given sufficient recovery phases – to push beyond your limits to achieve something you previously thought impossible. The more comprehensively I can pour creative energy into the task, the better, even if inertia and complacency tell me beforehand: don’t strain yourself. Effectiveness also means desire to create. It goes without saying that no one should be tempted to burn out a team. Regular overload phases are destructive and indicate deficits in planning or process that must be addressed.

Scarcity as Incentive

The abundance of financial resources in IT remains enormous compared to many other industries. Our profession can therefore be very comfortable. Do our high salaries make us more productive? There’s a great quote from Leonard Bernstein: “To achieve something great, you need two things: a good idea, and not enough time.” Resources are always limited –but provided what I want to do is really “great” (or in our context: meaningful and worth striving for), awareness that “it’s getting tight” can produce tremendous energy. So when time is pressing, it’s important to carry this awareness down to the teams – but please with justification! “We’re really stressed because X has to answer to Y at the steering committee at quarter’s end” – well, let’s hope the team members like X…

Decisiveness

Software development is a sequence of technical and professional decisions, interspersed with phases where decisions are implemented, tested, adjusted, or discarded. If decisions take too long or are regularly delegated upward, something’s wrong. Two possible causes are: (a) vertically understood hierarchies (i.e., power imbalances) combined with distrust that management won’t support decisions, and (b) lack of trust among team members, leading to too many people wanting involvement in decision-making. The former, if chronic, probably can’t be solved without external support. For the latter, it helps to create awareness that dividing responsibility areas (not just tasks) makes a team more efficient long-term and isn’t a sign of distrust in individual abilities. The core idea of “we do this together” isn’t “we occupy ten brains with problems that two would handle,” but “we coordinate ten brains so their solutions to seven different problems mesh well together.”

Investing in Minds

Finally, an appeal close to our hearts at INNOQ, which serves as the quintessence of these considerations: a digitally sovereign company’s greatest asset is its employees. Investing in their intelligence, professional and technical competence, problem-solving abilities and willingness to learn, familiarity with modern tools, but also their personal growth, enthusiasm, and resilience pays off long-term. Teams that learn together and get the means to actually grow from current challenges will handle upcoming challenges better, and subsequent ones even better, and so on. I want to know that the company to which I dedicate a large part of my lifetime doesn’t just rent my labor but enters into a long-term partnership with me. I want this company to have an interest in me strengthening my abilities and gaining new ones – to our mutual benefit! Then “I work for you and you pay me” becomes real give and take, and I gradually make the company’s goals my own. If a digital organization succeeds in developing such dynamics with as many people as possible, then the increasingly effective interaction of individuals contributes significantly to the organization’s constructively understood digital sovereignty.

1. The following observations apply to any creative and conceptually working teams. We limit ourselves here to the software development domain due to our own familiarity and in the interest of concreteness.  ↩

2. In the military context, no one would think of assigning decisions that must be made within minutes, perhaps seconds, to a committee. And the Berlin Philharmonic, a team of world–class highly specialized craftsmen, don‘t decide democratically how to play Brahms’s Fourth. Why? Because they know they would burn infinite time in discussions for a mediocre result: time that doesn‘t exist in the culture industry, quite simply because there’s no money.  ↩