People Management in Technology: What I Learned Managing Teams from 2013 to 2023
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
| Category | Skill Level | Attitude | Management Approach |
|---|---|---|---|
| Rising Star | Medium | High | Coach and give bigger opportunities |
| Expert Contributor | High | High | Give autonomy and strategic ownership |
| Skilled but Difficult | High | Low | Align behavior quickly before team morale suffers |
| Silent Learner | Low | High | Mentor patiently and build confidence |
| High Risk Team Member | Low | Low | Requires 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
| Category | Action |
|---|---|
| High Impact + High Urgency | Immediate attention from leadership |
| High Impact + Low Urgency | Strategic planning and architecture |
| Low Impact + High Urgency | Delegate carefully |
| Low Impact + Low Urgency | Avoid 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 code, databases, 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! 🥰😍