I’ve made a few observations after spending a year in consulting, where I worked in the intersection of technology (AI) and traditional management consulting. Startups are and were my thing before and after this sejour, but this was my time when I observed large companies (10k+ employees) from the inside. Overall, I was surprised at the level of bloat, slowness, politics and lack of will to change and make progress. I think some people will be able to relate, while others may be in teams that are cohesive and agile (in the actual meaning of the word agile, not “certified” agile).

Apart from observations, I also include some thoughts on what people on the inside can do to fix issues that I saw, mainly around leadership. Most of these thoughts also extend generally to organizations, big and small.

Before I go into the observations, I should say that I’m in no way an expert in leading or managing organizations. I’m 25 and I’ve never had a formal leadership role. Take everything with a grain of salt. But I hope my point of view, someone who works in startups and generally had not seen big companies from the inside, can be somewhat interesting.

What kills progress?

Slow progress can be fixed, if you know what’s wrong. I observed four areas that I think contributed most to the bloat and slowness I saw:

Indecisiveness from leaders
Unnecessary and lengthy processes
Non-technical staff in charge of technical staff
No urge to progress

I’ll go through them one by one.

Indecisiveness

Leaders in companies have a mandate (and a salary) to lead and make decisions on imperfect information. I saw too many examples of “hands-off” leadership, where bosses deferred decisions to their subordinates. What ensued was endless discussions and no decisions. I attended meetings with 6 managers that all had different viewpoints, managed by the same person, and you needed them to agree on a topic. Every meeting ended with “let’s develop some more material and schedule a follow-up meeting”. You need the leader to step in, listen to the different viewpoints, and make a top-down decision. Otherwise, nothing will be built.

Why does this indecisiveness happen though? What I observed was a sentiment that the upside from making a big bet was limited, while the downside can be significant. If you make a bet or decision that goes wrong, your position is at risk. This is especially true in organizations with heavy politics, as people around you may be looking for good reasons to get rid of you.

On the other hand, not producing anything, or deferring your responsibility, will keep you with your position and salary. It was especially sad to see that not producing anything was acceptable – it was the prevailing idea in some organizations that no progress is fine, they just had to muddle through and not mess anything up.

Unnecessary and lengthy processes

If you wanted to deploy an application you developed at a company I visited, good luck. The paperwork burden to get approval was massive – and even if you happened to be really fast at filling out the required documents, the approval times reached months as the teams reviewing were of course swamped with work (because they had designed an extremely inefficient process, but they had not realized yet that they put themselves in that place, and also had no incentives to make it faster).

This inhibited progress to an extent that I think is difficult for them to understand. Every application, big and small, internal and external, had to pass the same process. Do you think any developer would take the time to start some side project that could fix a pain point no quarterly planning would have caught? No! Grassroot developer initiatives were impossible as you needed to dedicate significant time to deploy. Only large scale projects were possible, but even then, most projects ended up in the proof of concept stage due to the efforts needed to productionize them.

The abovementioned may sound like an extreme example, but I saw unneccessary processes in many corners of companies. On a micro level, they kill the ambition and entrepreneurial spirit of employees. On a macro level, they cause inefficiencies for the company, with unclear gain. Many tout reduced risk as the benefit, but I am not sure about that. Long documents and approval processes do not equal reduced risk, but well-designed, often automated, guardrails do (that are as smooth as possible for the value creating employees). There doesn’t have to be a tradeoff between low risk and high progress.

I started to wonder then how all the processes came to be. Something must have gone awfully wrong some time, which warranted the introduction of these processes and approvals? The answer I heard was that no one knew. Maybe in some cases some crisis triggered better risk processes, but a majority I think are conceived like this:

A new technology is brought in (e.g. a SaaS solution), and someone decides that you need some form of approval to use it, which is usually fair in large organizations
They then draw up a few steps you need to go through and create short document templates to fill in. At this point the process scope is likely still fair.
As the technology grows in popularity, these processes are assigned to distinct teams (or, new teams created to handle these processes specifically), as the original team does not have enough capacity to handle all requests
The teams then of course want to fill up all their available time. They thus spend it on “refining” the process. For no reason other than them wanting to signal that they do work, the process is updated and extended. Think an intranet post that proudly declares: “We are excited to announce the updated approval process X, version 2024.2!”, where the version numbers are linearly correlated to the effort required to complete the process.
The “refinement” continues indefinitely. Moreover, processes are never removed, and are applied broader and broader, “just to be sure”. E.g., a process that had the intention to check the accessibility of external-facing websites are now applied internally as well, because the “external” got lost somewhere along the way.

All of this requires a top-level manager to tear down and question why processes are there to begin with. Speak with the people in the lowest level of the organization – do they have processes that hinder them in delivering valuable work? And, encourage employees to contact an executive if an unnecessary process is found, so it can be removed.

Non-technical staff

Leaders of technical teams were not technical where I was. At worst, the ratio of technical to non-technical was 2:2. That was one project leader and one agile coach for two developers. I felt like I was in some kind of farce, which got funnier when they declared that a product owner was missing from the team. It was obviously not a pure technology company, but, what company isn’t at this point.

What are consequences of this? I think two major ones: poor decision making and reduced employee productivity. Decision making is rather obvious: to quote a tech leader, would you want a cavalry general that can’t ride a horse? A person leading in tech must know tech, even if they are just leading a handful of programmers. I saw poor technical leadership in every level of the organization: at the highest level, poor (and often extremely slow) choice of technology to be used company-wide was a major one, slowing down all tech people below them as a consequence as the tooling they had access to was not up to the task.

Reduced employee productivity comes as a consequence of non-technical leaders pulling people into meetings. Technical people feel useful when they are actually useful, e.g. producing things like code. Non-technical people on the other hand feel useful when they talk to people, i.e. are in meetings. Keeping your calendar full becomes synonymous with being productive, and as the meetings are often about topics regarding the entire team, non-technical leaders pull in their technical team instead of just debriefing them afterwards.

As a developer, being brought into meetings of course reduces valuable coding time. Let’s make a quick estimate: assume someone is working ~7 hours per day, a standard work day for most Nordic employees. Imagine you have ~30 minutes check-in/check-outs, and two meetings of one hour each – that’s 4 hours remaining then. Let’s also add 1 hour of context switching time, and you have 3 hours left per day. You will never get anything done. Or, to get something done, you have to increase your headcount which leads to bloated and slow teams.

So, as a company leader, bring in technical people to manage your teams. And as a team lead, do not bring in team members into meetings unless they are critical. In fact, even asking a developer whether they want to join may be bad, because most people say yes since they don’t want to feel out of the loop. Protect the precious time where things are built. A sense of accomplishment is fleeing, a built thing lasts.

Some may argue though that modern leaders can be non-technical, but defer technical choices to their technical team members. I’d refer to the Indecisiveness section for a rebuttal.

No urge to progress

The urge to progress through implementation is the most essential ingredient of all. Urgency, trial and error, and implementation are key to achieving anything. Every week matters, and when your company loses urgency, the people innovating will be seen as the outliers, instead of the people relaxing their way through work.

I saw millions of dollars being spent on initiatives across companies that just outlined the possible paths forward, adding dubious value. Playbooks, strategy documents, case studies – they are all just hypothetical work based on assumptions. Just build, observe the outcome, and iterate. Leaders can have disproportionate impact here by instilling a culture of innovation and urge to progress. Make it clear that every week counts. Although, I must say I had my worst days when a new week passed (they go by so quickly sometimes) and I didn’t progress the way I planned. But those weeks remind me that on Monday again, everything is possible.

Very practically, encourage your team to write down their achievements during the week, and what their goals are for the next week. But be relaxed about them, and encourage honesty. They need to hear this from top management for them not to exaggerate or overpromise. I have been there.

Conclusion: How can you fix progress?

Progress in any company is possible. Leaders have the mandate to create it. I’ve touched on some ideas for how leaders can create progress above, but the main messages I want to send with this essay are the following:

Take fast decisions. Just do it, rather than discussing topics at length. But, be ready to change your mind if the data tells you to. Be opinionated. Your literal job is make important decisions based on incomplete information, that’s why you are paid more than the people below you.
Bypass the hierarchy and get rid of it eventually. Speak 1:1 with people at the lowest levels – understand what their issues are and how you can fix them.
Build small, technical-led teams.

There are of course things you can to as a non-leader as well:

Push back on ALL meetings
Block significant time for development
Write down goals for the week and execute on them