TECHNICAL OPERATIONS · SUPPORT · DELIVERY

Marcin Połog

Turning pressure into working systems.

I work where technical complexity, customer expectations and field reality meet.
International telecom operations taught me to make decisions with incomplete information, recover delivery when plans fail, and build trust through outcomes.
My career has gradually moved from solving technical problems myself to coordinating the people, priorities and decisions that keep operations moving.

14+

years in telecom & technical operations

4–6

support engineers led directly

~25

field specialists coordinated

countries worked across

01 / PROFILE

Technical judgment you can see in the decisions.

A conventional CV says what happened. This portfolio shows how I think: when to protect delivery, when to challenge an assumption, when to take ownership, and how to keep people moving without performing leadership for appearance’s sake.

I am looking for a team that values reliable outcomes, direct communication and getting things right.

02 / CAPABILITIES

What I bring to a technical organisation.

Technical operations

Keeping complex technical activity moving across support, field execution and customer delivery.

Incident recovery

Fast, evidence-based decisions when equipment, schedules or assumptions fail in the real world.

Team leadership

Direct leadership of support engineers and practical coordination of distributed field specialists.

Capability building

Turning repeated support dependency into knowledge, autonomy and scalable field competence.

Customer accountability

Clear ownership of errors and calm communication when conversations become difficult.

International delivery

Experience working across ten countries, adapting decisions to local operational reality.

03 / EXPERIENCE SIGNAL

14 years, viewed as a progression of trust.

The employers and client names stay in the formal CV. Here, the progression is expressed through responsibility: from solving technical problems personally to becoming the person others chose for difficult decisions.

01 — FIELD EXECUTION

On-site measurements, equipment troubleshooting and delivery under real-world constraints.

02 — RELIABLE ESCALATION

Complex or stalled problems increasingly reached me because colleagues trusted that I would move them toward an outcome.

03 — TEAM ENABLEMENT

Informal mentoring became structured capability building: training field teams and reducing unnecessary support load.

04 — TEAML LEADERSHIP

Supporting 4–6 engineers and coordinating approximately 25 field specialists.

04 / FIELD NOTES

Six moments that reveal more than a task list.

Real situations from international telecom work. Employer and customer names are intentionally omitted; the reasoning and accountability are what matter.

FIELD RECOVERY

The Equipment Swap

Went with what was already proven, not the new option

A customer deployment was scheduled under a hard deadline, using newly introduced equipment. Field testing surfaced reliability concerns with no time left to fully diagnose the cause. A shaky rollout was not worth risking, so I made the call to fall back to equipment already validated in prior deployments.

OUTCOME / LESSON
The deadline was met, the customer got a working system, and the newer equipment returned for proper evaluation.

LEADERSHIP

The Informal Mentor

Was not my team or my job, but I knew the material

Junior technical staff outside my reporting line were struggling with concepts that affected their performance. Nobody asked me to step in, but I had the knowledge and time, so I began running informal training sessions.

OUTCOME / LESSON
Months later, several of those people independently said they would want to work with me again.

CAPABILITY BUILDING

Training the Field

Field technicians could have handled it all along

Support was absorbing tasks field technicians could perform but had never been trained to handle. I proposed a tiered training structure, despite initial management pushback, to build that capability in the field.

OUTCOME / LESSON
Support capacity increased while field teams gained autonomy and a broader skill set.

STAKEHOLDER PRESSURE

The Blame Game

Owning your part without absorbing someone else’s

During a tense inter-team escalation, I fully owned my team’s part of the root cause while remaining factual about a missed checklist step on the other side.

OUTCOME / LESSON
We added a second-level control to close our gap, while the shared-responsibility point remained clear.

LESSONS

The Assumption That Did Not Carry Over

Familiar is not the same as confirmed

I assumed a scope detail from a similar engagement would apply again without explicit customer confirmation. It did not, and the fixed-time test had to be rerun.

OUTCOME / LESSON
Now every engagement scope remains unconfirmed until it is explicitly confirmed, regardless of similarity.

ACCOUNTABILITY

Called In to Explain

Owning it was the whole strategy

My team made a genuine error that created roughly a week of rework. I explained it directly to the customer: a human mistake, ours, with no excuses or deflection.

OUTCOME / LESSON
The relationship remained intact. Delivering bad news plainly proved more effective than softening or hiding it.

05 / WORKING PRINCIPLES

How I operate when the script stops working.

Protect the outcome

Novelty is not a virtue if proven equipment is what safely delivers the customer result.

Confirm, do not assume

Similarity between projects is useful context, never a substitute for explicit scope confirmation.

Own the real part

Take responsibility without excuses — and without accepting a false version of shared root cause.

Build autonomy

The best support improvement is often teaching capable people to solve the next problem themselves.

LET’S CONNECT

Let's talk about technical operations, support and delivery.

MARCIN POŁOG · TECHNICAL OPERATIONS · SUPPORT · DELIVERY