(Wersja PL poniżej EN)

Let’s face it — getting promoted is exciting. Whether you’re a software engineer stepping into your first leadership role or a manager eyeing that elusive director title, the road to advancement in ICT is paved with opportunity… and landmines.

So how do you get ready for the next level without burning out or losing your grip on what made you successful in the first place? How do you grow into new expectations, build real leadership presence, and actually help your teams — all without becoming that manager?

Let’s walk through three common transitions in the ICT world, the challenges that come with them, and how to navigate each using one of my favorite leadership books of all time — Patrick Lencioni’s “The Five Dysfunctions of a Team.”

I’ve used this book for years to shape organizational design, culture, and leadership habits. It’s not just theory — it’s a practical lens through which you can understand your place in the hierarchy, and more importantly, your responsibilities to the team you belong to, not just the one you lead.

The First Promotion: From Developer to Team Leader

The moment you move from contributing code to leading the people who do, your world changes — fast.

Suddenly, you’re no longer judged solely on how elegant your solutions are or how fast you close tickets. Now, it’s about how your team performs — together.

What Changes:

• Your primary team changes. You’re no longer just part of the delivery team — you now belong to the team of team leaders.

• Your new peers aren’t engineers. They’re fellow leads who also struggle with timelines, performance, and keeping morale high.

• You’re now accountable upwards — your manager expects you to lead your team, not just echo their voices.

Common Pitfalls:

• Not letting go of the keyboard. It’s hard to stop coding and start coaching. But if you don’t create space for your team to shine, they’ll never grow — and you’ll burn out.

• Trying to be everyone’s buddy. You might still feel emotionally tied to the dev team. That’s natural. But if you fail to reset the relationship, especially in terms of accountability, you’ll confuse everyone.

The Second Jump: From Team Leader to Manager

This leap is more subtle — and more dangerous. The expectations shift again. You’re no longer managing tasks — now you manage people who manage tasks. Strategy, planning, hiring, performance management… they’re all on you.

What Changes:

• Your new team is not your former engineers — it’s now the team of leaders you support.

• You become part of the management team — the group that shapes departmental priorities, not just team execution.

• You must start looking outside your scope — thinking cross-functionally.

Challenges You’ll Face:

• Struggling to zoom out. You’ve got to stop solving only the problems of “your” area and start thinking about how everything connects.

• Hanging onto operational detail. If you’re still micromanaging JIRA boards, you’re not leading — you’re stuck.

• Avoiding tough conversations. At this level, you don’t just need feedback loops — you need to build a culture of candor. Trust and conflict (healthy conflict!) become non-negotiable.

The Final Stretch (or So You Think): From Line Manager to Senior Leader / Director / CTO

This is where the stakes get real. You’re now expected to think like an owner. Not just optimize your org — you must protect and grow the company’s value.

What Changes:

• Your primary team is now the executive or leadership team. The team you manage is secondary — and this is a mental shift many never make.

• Your decisions ripple far beyond your own department. Misaligned priorities can cause friction company-wide.

• The focus shifts from execution to enablement, direction, and long-term impact.

Mental Traps:

• Sticking to tribal thinking. If you’re still fighting only for your team’s resources or arguing just from your vertical’s POV, you’re not operating as a leader of the company.

• Expecting others to spell out your responsibilities. At this level, initiative defines your value.

The Two Teams: Belonging vs. Leading

Here’s a principle I return to again and again — and it’s a game-changer:

You belong to one team. You lead another.

If you’re a developer, you belong to the delivery team. If you’re a team lead, you belong to the team of leads. If you’re a manager, you belong to the management team — not just the crew you oversee. This is your first team.

Your second team is the one you lead — your direct reports. But your loyalty, alignment, and responsibility first and foremost lie with your first team.

Why? Because that’s where real trust, shared accountability, and decision-making happens. That’s where strategy is formed and culture is shaped.

Lencioni’s framework explains this brilliantly. If the leadership team (your first team) lacks trust, fears conflict, avoids commitment, ducks accountability, or is unclear on results — the dysfunctions will cascade down the org like a virus.

Why Promotions Break People

Let’s name the real pain of getting promoted:

• You lose your old tribe.

• You don’t instantly get a new one.

• Your to-do list changes, but your mindset takes time to catch up.

A few examples from my experience — and ones I’ve seen in others:

• Failing to mentally leave the old role. Still behaving like a developer when you’re a lead? Like a lead when you’re a manager? That creates confusion.

• Focusing too narrowly. You’re still championing just your team, unaware of the bigger strategic picture. But leadership means seeing across — not just down.

• Over-delegating or under-delegating. You either fear letting go or you dump too much without support.

The key is resetting expectations — both yours and others’. Understand what level of autonomy is now expected. And own it.

A Lesson From General Klisz

I once had a conversation with General Klisz from the Polish army. I asked him whether feedback and initiative exist in the military. Can soldiers come to him directly with problems?

His answer was sharp and unforgettable:

“Of course they can. But if someone comes to me about worn-out boots — something they could’ve solved five ranks lower — they’ll get sent packing.”

It’s a reminder that the higher we go, the more we must self-filter. We have to think like our boss, and our boss’s boss. Anticipate what matters at that level. Don’t show up with noise — show up with value.

Final Thought: Don’t Let Them Down

Promotions aren’t just rewards. They’re transfers of trust.

Someone saw your potential. They believed you were ready. They gave you the privilege of relieving them of work they used to carry.

So don’t disappoint them.

Don’t make your CEO babysit a CTO who keeps putting out fires. Don’t make your CTO handhold leaders who can’t set boundaries or motivate people.

Lead up. Think up. Earn the trust again — every day.

Recommended Read:

The Five Dysfunctions of a Team by Patrick Lencioni — one of my foundational books for understanding how real teams work (and fail). Required reading if you’re building anything beyond just a team of doers.

---

Jak przygotować się do awansu (i nie zwariować)

Awans to ekscytująca sprawa. Niezależnie od tego, czy jesteś programistą, który właśnie wchodzi w pierwszą rolę liderską, czy menadżerem, który celuje w stanowisko dyrektorskie — droga do wyższego poziomu w ICT jest pełna szans… i min.

Jak więc przygotować się na kolejny krok, nie spalając się po drodze i nie tracąc tego, co doprowadziło cię do sukcesu? Jak rozwinąć swoją obecność jako lider, zrozumieć nowe oczekiwania i faktycznie pomóc zespołom — a przy tym nie stać się tym menadżerem?

Przejdźmy przez trzy najczęstsze scenariusze awansu w ICT, trudności, które się z nimi wiążą, i sposoby na ich opanowanie, korzystając z jednej z moich ulubionych książek o przywództwie — „Pięć dysfunkcji pracy zespołowej” Patricka Lencioniego.

Ta książka towarzyszy mi od lat przy projektowaniu struktur organizacyjnych, kultury pracy i rozwoju liderów. To nie teoria — to praktyczne narzędzie do zrozumienia, do jakiego zespołu należysz, a jakim zarządzasz.

Pierwszy awans: z developera na team leadera

Moment, w którym przestajesz tylko kodować, a zaczynasz prowadzić ludzi, to potężna zmiana.

Od teraz nie jesteś oceniany za piękno swojego kodu ani liczbę zamkniętych ticketów. Liczy się to, jak działa cały zespół.

Co się zmienia:

• Twój główny zespół się zmienia. Już nie jesteś tylko członkiem zespołu delivery — teraz należysz do zespołu team leaderów.

• Twoi nowi „koledzy z zespołu” to nie programiści, lecz inni liderzy, którzy również mierzą się z planami, wydajnością i nastrojami zespołów.

• Teraz jesteś odpowiedzialny również w górę — twój przełożony oczekuje, że to ty prowadzisz zespół, a nie tylko powielasz jego głos.

Typowe pułapki:

• Nieumiejętność odpuszczenia klawiatury. Trudno przestać kodować i zacząć wspierać innych. Ale jeśli nie dasz miejsca zespołowi, by się rozwijał — wypalisz się.

• Chęć bycia „kumplem”. Nadal emocjonalnie jesteś związany z zespołem. To naturalne. Ale jeśli nie ustawisz relacji od nowa, zwłaszcza w zakresie odpowiedzialności — wszystko się rozmyje.

Drugi skok: z team leadera na menadżera

Ten awans jest subtelniejszy — ale bardziej niebezpieczny. Oczekiwania znów się zmieniają. Nie zarządzasz już tylko zadaniami — teraz zarządzasz ludźmi, którzy zarządzają zadaniami. Rekrutacja, planowanie, strategia, oceny — teraz są na twojej głowie.

Co się zmienia:

• Twój nowy zespół to nie twój dawny zespół techniczny, ale liderzy, których wspierasz.

• Należysz teraz do zespołu menadżerskiego — grupy, która ustala priorytety działów, a nie tylko wykonuje zadania.

• Musisz zacząć patrzeć poza swój zakres — zacząć działać międzydziałowo.

Typowe trudności:

• Brak umiejętności spojrzenia szerzej. Nadal próbujesz gasić pożary tylko w „swoim” obszarze. Ale lider musi patrzeć w poprzek, nie tylko w dół.

• Trzymanie się operacyjnych detali. Jeśli nadal mikrozarządzasz JIRA-boardami — nie prowadzisz. Tkwisz.

• Unikanie trudnych rozmów. Na tym poziomie nie wystarczy feedback — trzeba budować kulturę szczerości. Zaufanie i zdrowy konflikt stają się obowiązkowe.

Ostatni etap (a przynajmniej tak ci się wydaje): z menadżera na dyrektora lub CTO

Tu robi się naprawdę poważnie. Teraz oczekuje się, że myślisz jak właściciel. Nie tylko optymalizujesz swój dział — masz chronić i rozwijać wartość całej firmy.

Co się zmienia:

• Twój główny zespół to teraz zespół zarządzający firmą. Zespół, którym kierujesz, staje się wtórny — i to mentalne przestawienie się jest najtrudniejsze.

• Twoje decyzje mają konsekwencje daleko poza twoim działem.

• Skupiasz się już nie na wykonaniu, ale na kierunku, długofalowym wpływie i budowaniu kadry.

Pułapki:

• Myślenie plemienne. Nadal walczysz tylko o zasoby „swojego” działu? Nadal widzisz świat tylko przez pryzmat własnego zespołu? To nie jest myślenie lidera firmy.

• Oczekiwanie, że ktoś ci powie, co masz robić. Na tym poziomie inicjatywa to waluta wartości.

Dwa zespoły: ten, do którego należysz, i ten, którym zarządzasz

Oto zasada, do której stale wracam — i która zmienia sposób działania:

Do jednego zespołu należysz. Innym zarządzasz.

Jeśli jesteś developerem — należysz do zespołu delivery.

Jeśli jesteś team leaderem — należysz do zespołu liderów.

Jeśli jesteś menadżerem — należysz do zespołu menadżerskiego.

A jeśli jesteś dyrektorem — twoim zespołem jest leadership team całej firmy.

Dlaczego to ważne? Bo to w tym pierwszym zespole buduje się zaufanie, otwartość, podejmowanie decyzji, kierunki działania. Jeśli ten zespół kuleje — jego dysfunkcje rozchodzą się po organizacji jak wirus.

Lencioni opisał to perfekcyjnie. Brak zaufania, lęk przed konfliktem, brak zaangażowania, unikanie odpowiedzialności, niejasność co do wyników — to wszystko zaczyna się na górze i spływa w dół.

Dlaczego awanse „łamia ludzi”

Nazwijmy rzeczy po imieniu:

• Tracisz swoją starą „paczkę”.

• Nie masz jeszcze nowej.

• Twoja lista zadań się zmienia, ale twoja głowa — niekoniecznie.

Kilka przykładów z mojego życia i obserwacji:

• Nieodcięcie się mentalne od starej roli. Nadal działasz jak developer, będąc team leaderem. Nie eskalujesz bo chronisz kolegów. To wprowadza chaos.

• Zbyt wąska perspektywa. Nadal walczysz tylko o „swoich”? Lider patrzy szeroko.

• Zbyt duża lub zbyt mała delegacja. Albo boisz się oddać, albo zrzucasz wszystko bez wsparcia.

Kluczem jest reset oczekiwań — swoich i otoczenia. Zrozum zakres nowej autonomii. I weź odpowiedzialność.

Lekcja od generała Klisza

Podczas jednego ze spotkań zapytałem generała Klisza, czy w wojsku istnieje feedback i czy żołnierze mogą przychodzić z tematami do swoich przełożonych, a nawet do niego.

Odpowiedział:

„Oczywiście, że mogą. Ale jeśli ktoś przyjdzie do mnie z tematem typu ‘mam złe buty’ — czymś, co powinno być dawno rozwiązane trzy szczeble niżej — to wiadomo, że go pogonię.”

To pokazuje, że im wyżej awansujemy, tym bardziej musimy filtrować tematy, z którymi wychodzimy w górę. Musimy myśleć kategoriami naszego przełożonego. Patrzeć z jego perspektywy. Wychodzić z inicjatywą — a nie szukać potwierdzenia w oczywistościach.

Na koniec: nie zawiedź tych, którzy ci zaufali

Awans to nie tylko nagroda. To transfer zaufania.

Ktoś zobaczył w tobie potencjał. Ktoś uwierzył, że jesteś gotowy. Chce ci oddać część swojej pracy i odpowiedzialności.

Więc nie zawiedź.

Nie zmuszaj CEO do gaszenia pożarów po CTO. Nie każ CTO uczyć w kółko liderów, jak motywować ludzi, jak egzekwować cele, jak stawiać granice.

Myśl w górę. Pracuj w górę. Odwdzięcz się tym, którzy zaryzykowali, dając ci więcej niż tylko nowy tytuł.

Polecana lektura:

„Pięć dysfunkcji pracy zespołowej” – Patrick Lencioni

To jedna z moich podstawowych książek przy kształtowaniu struktur i kultury organizacyjnej. Obowiązkowa pozycja dla każdego, kto buduje coś więcej niż zespół wykonawczy.