1.2 - The people variable: Root of all system problems

When I first started out, I had a very simple belief: if you are good at technology, you can build great software and successful products. I even thought that if my technical skills were sharp enough, I could easily build a software product on my own and sell it to make money.

This mindset is exactly like thinking that just because you know how to cook, you can successfully open and run a restaurant.

For many years - as a developer and then moving into leadership positions - this belief gave me false confidence. I genuinely believed that every single problem in software development could be solved with technology. I even thought that if a team member refused to cooperate or fell behind, a great developer could simply step in and do their entire job for them.

I thought code could fix everything. I was wrong.

---

The corporate reality check

My perspective began to shatter when I started working in large corporations and banking environments. For the first time, I faced massive, interconnected problems that I could not solve alone, no matter how hard I coded or how clever my architecture was.

I began to realize that the real bottlenecks had very little to do with technology. Instead, the actual challenges were rooted in:

• Communication Gaps: Misalignments between what was requested and what was built.
• Influence and Persuasion: The difficult art of convincing stakeholders or pushing someone to align with a specific technical direction.
• Human Cooperation: Realizing that a single "superstar" developer cannot replace a dysfunctional or disconnected team.

flowchart LR
    subgraph The Illusion
        direction LR
        A1[Problem] --> B1[Better Code] --> C1[Solved]
    end
    subgraph The Reality
        direction LR
        A2[Problem] --> B2[Human Alignment\n+ Process Improvement] --> C2[Solved]
    end

Shifting from tech to business logic and process

The biggest turning point was realizing that many complex technical issues were not technical issues at all - they were business logic and workflow problems.

I noticed that instead of spending weeks writing complicated code to work around a problem, we could solve it instantly by simply changing our perspective, improving the daily workflow, or altering the business process.

I learned that:

1. Code is the last resort: Writing code should be the final step to automate a solution, not the first tool used to fix an organizational mess.

2. The "People" variable dictates success: A perfect system architecture will fail if the people running it do not communicate, while a messy system can survive and thrive if the team is highly aligned and collaborative.

This realization changed my career path. I stopped looking at engineering problems through the lens of a compiler and started looking at them through the lens of human behavior. This is exactly why I stepped away from the pure technical track to become an Engineering Manager: to fix the root of all system problems—the people variable.

🎯 Self-Reflection for You

Think about the biggest blocker your current project faces right now:

1. Is it truly a limitation of your programming language, framework, or cloud infrastructure?

2. Or is it actually caused by a lack of alignment, poor communication between product and engineering, or a broken internal process?

If you are tired of trying to solve human conflicts with code patches and want to learn how to build high-aligning engineering teams, let's look at your team dynamics together in a virtual coffee chat.