Performance Comes From Boundaries
... at the right places
Two different companies. Both international, very successful, very large, very well known. In both, it’s a career advantage just to have worked there.
The people there are qualified, they’re cool, they’re nice, they have track records to show for it.
In both companies, large important initiatives are underway, involving data and more (this was before AI).
The leaders in both companies are genuinely nice people. They’ve all been through many leadership training. You get along well with them. Both companies also have excellent processes, everything is perfectly organized when it comes to on-boarding and things like that. Both companies have outstanding HR departments.
One company blew several million euros on a data platform project. The other company successfully ran a program consisting of 10 teams, and afterward an entire ecosystem of data, software, and hardware was up and running. I unfortunately can’t go into too much detail, otherwise you’d be able to guess which companies I’m talking about.
I worked in both as a freelancer. I’ve thought a lot about WHAT the actual difference is, when so much is really similar and especially the people in both companies were genuinely great. So it was definitely not about the individuals. I got along with everyone. But I also couldn’t prevent the waste of money in one of the companies. Why not?
Oh, and both were agile, so that wasn’t it either.
So what are the differences, you ask?
I have to emphasize it once more. It’s not the people. It’s not their qualifications. It’s also not the company in general, both companies are profitable.
It’s something that’s often overlooked. Something you don’t even think about. Something that’s not on your radar. There’s also no direct literature about it, only indirectly and on adjacent topics. I assume that the people who typically write about these kinds of topics professionally don’t have the opportunity to get these direct insights.
Both initiatives required multiple teams. We’re also not talking about scaled agile frameworks, because it wasn’t just software being delivered, but also infrastructure, platform, and hardware and more.
The difference between the two initiatives was the combination of goals, boundaries, recognition, performance, and career paths.
In the company that threw a lot of money out the window, goals were vague, boundaries were arbitrary, recognition was based on personal likability, performance was irrelevant, and the career path was hierarchical.
In the very successful company, goals were razor-sharp and crystal clear, boundaries were extremely tight, recognition came exclusively for performance from the very top directly to the team member, performance was a criterion that decided whether you were in or out, and the career path ran along the value chain.
In the company that spent millions on nothing, there were hundreds of PowerPoint slides about the goals and dozens more Miro boards. It all sounded great, but you couldn’t sum it up in one sentence. The goals were the product of many external vendors and consultants. You’ve all seen this before. The anti-pattern: If you had woken someone up in the middle of the night and asked what the goal of the initiative was, everyone would have stammered something different. It was diffuse.
In the other company, it was exactly one sentence, and everyone knew it, understood it, and can still recite it years later.
In the company that spent millions on nothing, there were no boundaries. The scope was constantly expanded on a massive scale. Everything was coupled together. Then this was added, then that. Oh, and let’s also redo this while we’re at it. Financially, there were no limits at the beginning either. Wish for whatever you want.
In the other company, there were many strict constraints. Both at the strategic level and at the program level. There was clarity at every level. Tight financial constraints. Clear expectations for what’s required of everyone. Clear directives on how to work. The scope was easy to understand (and yet hard to execute – it was an entirely new field, something nobody had done before, absolute uncharted territory, not some run-of-the-mill topic, you had to talk to experts worldwide, but the WHAT was crystal clear). There were very strict rules about what had to be working at the end of the sprint (the results were integrated across all teams, and the outcome was tested in a running machine at the end of each sprint).
All features and bugs from every team were measured at the end of the sprint – specifically the ones reported by the end user of the machine, and when a user reported an error, the team had to take care of whatever was raised first. There was a very clear stance from leadership. Where the problem surfaces is where it gets fixed, and nobody wants to hear that the root cause lies with another team. There were rules for how retro results had to be made transparent, and there were rules for how learning happened across the entire program.
Vendors were kept on a tight leash, there was no stepping out of line, and the daily rates were extremely low. And yet it was a fierce competition to get in as a vendor, because everyone knew you’d learn an incredible amount there and it was worth it. It would go beyond the scope of this article to list every detail, and I also don’t want to give the company away, but there was a strict regiment – you have to understand that.
In the company that spent millions on nothing, there was no clear definition of what team performance was expected. They more or less expected tickets to be completed and the plan to be followed – a plan that kept changing. Recognition was given for being nice and likable. People who got along well with all stakeholders received recognition. But there was no systematic approach. It was more of a random occurrence.
In the other company, there were clear expectations: Teams must deliver working features every sprint. Performance was defined as: Solve problems together (there were many technical challenges). All teams work with each other. If one team builds central components for the other teams and it becomes a bottleneck, the other teams must contribute to building the central components. Features must increase every sprint. Bugs must be fixed.
Features must be demonstrated in a running machine during the review. Recognition comes from the board for teams and team members. For performance and results. Nothing else. The board regularly reviewed the results. You can surely imagine how uplifting that was for the engineers. They came from all over the world, were young, and they were happy and proud after a successful review.
It’s an incredible feeling when you’ve achieved something and the board sees it and acknowledges it. You are seen! And you’ve accomplished something big! It's like in sports – the joy of winning only exists because the rules are strict and everyone knows exactly what winning looks like!
This is perhaps the most important point. Career – how does it work? Does it go from team member to team lead? And then hierarchically upward from there? Maybe also at the project level – do you become a project manager, program manager, etc.?
Is the career path a different path from the value chain?
How many departments and teams in your org chart do you need for a data and AI initiative?
How is value created? Through the combination of business unit, data team, AI team, and maybe infrastructure/platform?
Okay, and how do you build a career with that combination?
The successful company has a different org chart than the hierarchical one we all know. There are very few levels of hierarchy, for one. On top of that, hierarchy was completely stripped of its significance. There are only people managers, each responsible for around 100 people. It’s purely about admin tasks. There are no more role titles either – they were abolished.
The entire hierarchy runs along the value chain. You advance through more recognition, more responsibility, more money, more visibility. No titles, no roles, no little fiefdoms – instead, a radical rethinking.
And we’re talking about something that happened over 10 years ago at this company. It’s not even new.
My firm conviction is: if you want to improve your business with data and AI at scale, you cannot get around learning these basics and aligning the entire organization to that goal.
The hierarchical org chart was not a mistake. It fit the world at the time. You had separate departments. If they worked well, the business ran well. So career advancement went hierarchically upward. That worked because it matched the reality of that era.
But if I now want to deploy AI at scale then I need at least one, if not all business units, all data teams, all AI teams, all infrastructure teams. That’s something that simply didn’t exist before. There was nothing like it.
That means: the org chart with its departments no longer fits what the future looks like. And the career logic embedded in it doesn’t either.
Career must orient itself around how value is created. And value is no longer created within a single department. It’s created in the combination – business, data, AI, infrastructure, together, toward one goal. So career logic must follow that same path.
If good performance is rewarded by making someone the lead of a small team of only engineers, that only increases the complexity of the initiative – you’re just adding more overhead, another person who wants to coordinate. If someone is rewarded for performance by being more visible, receiving more recognition, and above all being given a larger, cross-departmental scope of responsibility, then that supports exactly the kind of collaboration that creates value. Hierarchy then only serves to handle the old logic of contracts and vacation approvals.
My conviction is: Many organizations need to fundamentally reinvent how they’re set up, or they’ll be left behind. The complexity of what’s ahead demands radical simplicity in the organization and very tight boundaries in execution. Both must be in harmony with each other. Those still busy doing things the old way will be outpaced by those who operate with simplicity and discipline.
