People Management in Technology: What I Learned Managing Teams from 2013 to 2023

Reading Time: 5 minutes

Most people think people management is about:

  • assigning tasks
  • monitoring performance
  • conducting meetings
  • reviewing KPIs

But after spending more than 10 years managing teams in technology, I realized something:

Managing people is actually about managing energy, trust, pressure, communication, and expectations.

I started my career as a technical person.

Back in the early days around 2005, I was heavily focused on programming, troubleshooting, and infrastructure.

I worked as:

  • Technical Support
  • PHP Developer
  • Java Enterprise Developer
  • C Developer for EDC/POS terminal systems
  • System Architect

At that time, success felt simple.

If the system worked, then everything was good.

But around 2013, my role started changing.

I began leading teams.

And honestly, that transition was much harder than learning programming languages.

From 2013 until around 2023, I experienced multiple leadership situations across:

  • enterprise software development
  • payment systems
  • infrastructure projects (PCIDSS)
  • product development
  • operational support teams
  • business development

And one thing became very clear:

Technology problems are often people problems wearing technical clothes.

The Hardest Part Was Not Technical

When engineers become managers, many assume the hardest challenge is:

  • architecture
  • scalability
  • performance optimization
  • deployment complexity
  • infrastructure

But surprisingly, the hardest problems are usually human-related.

Examples:

  • senior engineers fighting each other
  • unclear ownership
  • burnout
  • communication gaps
  • hidden frustrations
  • team silos
  • ego conflicts
  • fear of making mistakes

I learned that managing humans requires a completely different skillset compared to coding.

Code is logical.

Humans are not always logical.

My Early Leadership Mistake

One of my biggest mistakes early in management:

I thought strong teams were built from the smartest engineers.

So naturally, I focused heavily on:

  • technical capability
  • speed
  • problem solving
  • delivery performance

But over time, I discovered something unexpected.

Some highly skilled engineers actually reduced overall team performance.

Why?

Because technical skill alone is not enough.

I saw situations where talented engineers:

  • created fear inside teams
  • rejected collaboration
  • avoided documentation
  • hoarded knowledge
  • refused feedback
  • overcomplicated systems

Meanwhile, some average developers became incredibly valuable because they:

  • communicated clearly
  • helped others
  • documented things properly
  • stayed calm during incidents
  • were reliable under pressure

That completely changed my perspective about leadership.

Real Leadership Happens During Production Problems

Working in payment systems taught me a lot about leadership.

Especially during outages.

In payment environments:

  • downtime affects transactions
  • merchants become angry
  • customers panic
  • management escalates immediately
  • pressure becomes extremely high

And usually, incidents happen during:

  • weekends
  • midnight deployments
  • public holidays
  • peak transaction periods

Classic production reality.

I still remember moments where:

  • application teams blamed infrastructure
  • infrastructure blamed networks
  • networks blamed firewalls
  • vendors blamed integrations
  • everybody became defensive

And this is where leadership becomes important.

Because panic spreads very fast.

One thing I learned:

During incidents, the emotional stability of the leader affects the entire team.

If leaders panic:

  • teams stop thinking clearly
  • communication collapses
  • mistakes increase

Sometimes the most important leadership skill is simply creating calmness.

Not technical brilliance.

The Bus Factor Problem

One dangerous pattern I repeatedly saw from 2013 to 2023:

The “hero engineer.”

Almost every company has one.

The person who:

  • knows everything
  • fixes everything
  • has all passwords
  • handles all deployments
  • becomes the dependency center

Management often loves this at first.

But actually, this creates huge operational risk.

Because eventually:

  • the engineer burns out
  • resigns
  • becomes overloaded
  • blocks scalability

I learned that healthy teams distribute knowledge.

That is why I always value:

  • documentation
  • mentoring
  • cross-training
  • knowledge sharing
  • operational procedures

A strong organization should survive even if one key person is unavailable.

Junior Engineers Need Psychological Safety

One thing I always tried to improve inside teams:

Making junior engineers comfortable asking questions.

Because many production problems happen not from incompetence, but from fear.

Junior engineers are often afraid to:

  • ask questions
  • admit confusion
  • report mistakes
  • challenge assumptions

Especially in highly technical environments.

This creates silent teams.

And silent teams are dangerous.

Because hidden confusion eventually becomes operational failure.

Over the years, I realized:

Teams learn faster when people feel safe enough to speak honestly.

That does not mean removing accountability.

It means creating an environment where learning is possible.

Micromanagement Slowly Destroys Teams

This is another lesson I learned over time.

Micromanagement creates weak organizations.

I have seen managers constantly:

  • checking every detail
  • monitoring every minute
  • controlling every implementation
  • interrupting engineers continuously

At first, it may look productive.

But eventually:

  • engineers stop taking initiative
  • ownership disappears
  • creativity dies
  • dependency increases

Good engineers want ownership.

They want room to think.

So instead of controlling everything, I learned to focus on:

  • defining clear objectives
  • setting operational boundaries
  • giving technical direction
  • removing blockers

Then allowing the team to execute.

Trust creates stronger engineers.

A Simple People Management Matrix I Often Use

Over the years, I started mentally categorizing team members using a simple matrix.

Not for labeling people negatively.

But to understand how to manage and support them properly.

Skill vs Attitude Matrix

CategorySkill LevelAttitudeManagement Approach
Rising StarMediumHighCoach and give bigger opportunities
Expert ContributorHighHighGive autonomy and strategic ownership
Skilled but DifficultHighLowAlign behavior quickly before team morale suffers
Silent LearnerLowHighMentor patiently and build confidence
High Risk Team MemberLowLowRequires close evaluation and clear expectations

This matrix helped me realize something important:

Attitude problems usually damage teams faster than skill problems.

Skills can improve.

But toxic behavior spreads quickly.

Another Important Matrix: Urgency vs Impact

During management roles, I also often categorized work using a simple operational matrix.

Urgency vs Impact Matrix

CategoryAction
High Impact + High UrgencyImmediate attention from leadership
High Impact + Low UrgencyStrategic planning and architecture
Low Impact + High UrgencyDelegate carefully
Low Impact + Low UrgencyAvoid wasting excessive energy

This helped reduce chaos.

Because one common management problem is:

Everything feels urgent.

But not everything is important.

Communication Is a Technical Skill

One underrated truth in engineering:

Communication failures create technical failures.

I have seen expensive delays happen because:

  • requirements were unclear
  • assumptions differed between teams
  • nobody documented decisions
  • business expectations changed silently

Especially in enterprise environments involving:

  • banks
  • ministries
  • vendors
  • switching companies
  • large customers

Clear communication becomes critical.

And strong engineers eventually need communication skills too.

Not only coding ability.

Managing Senior Engineers Is Different

Senior engineers usually dislike:

  • unnecessary meetings
  • vague direction
  • excessive reporting
  • micromanagement

What they usually want is:

  • context
  • business clarity
  • technical trust
  • meaningful challenges
  • ownership

I learned that strong senior engineers perform best when leaders:

  • align objectives clearly
  • remove organizational blockers
  • trust their expertise

Not when controlling every implementation detail.

Leadership and Emotional Control

One underrated leadership skill is emotional control.

Especially under pressure.

As managers, people observe us more than we realize.

If leaders become:

  • reactive
  • emotional
  • unstable
  • defensive

Teams absorb that energy immediately.

But calm leadership creates stability.

This became one of my biggest lessons from managing teams between 2013 and 2023.

Sometimes leadership is less about giving orders.

And more about protecting team focus during difficult situations.

What I Believe Today About People Management

After years of leadership experience, I no longer believe the best teams are built purely from technical brilliance.

I believe strong teams are built from:

  • trust
  • accountability
  • communication
  • ownership
  • consistency
  • learning culture
  • operational discipline
  • psychological safety

Technology changes extremely fast.

Programming languages evolve.
Infrastructure evolves.
Architectures evolve.

But managing humans remains one of the hardest skills in technology.

And honestly, it is still a continuous learning process for me too.

Final Thoughts

If there is one thing I learned after managing teams for roughly a decade, it is this:

Leadership is not about controlling people.

It is about helping people perform at their best together.

Good leaders do not create fear.

They create:

  • clarity
  • stability
  • trust
  • accountability
  • direction

Because at the end of the day, technology is still built by humans.

And strong systems are usually built by strong teams.


If you’d like to explore more of my notes, feel free to check out my other sections on codedatabases, and even management – all still connected to the broader world of technology.

That’s all for now, folks! Keep learning, keep building, and most importantly enjoy the journey! 🥰😍

← I Didn’t Panic When Stock Market Dropped

Leave a Reply

Your email address will not be published. Required fields are marked *