I am Artur, and welcome to my weekly newsletter. I am focusing on topics like IT Management, Innovation, and Leadership, with an Entrepreneurial mindset. My goal is to help you navigate the IT corporate landscape. Make better decisions, create awareness, and share real-world stories.

Share

The IT space is undergoing a massive transformation driven by the effects of AI. Leadership is not indifferent to these changes, and it needs to adapt and evolve along with them.

AI ultimately isn’t making engineering teams faster. It’s making them smaller.

While leadership defaults to using automation to slash headcount, they are blindly trading away their operational buffer.

The course is far from steady, which is the number one reason it is so difficult to predict what the future will bring. However, it is important to have a multi-perspective analysis of what the impacts of AI on leadership will be.

AI Is Generally Underperforming

The default modus operandi for management using AI capabilities is to cut costs. Simply because the pressure of reducing operational cost is high, and slashing HC is the easiest way to translate potential AI gains into real numbers.

AI is a tool. Therefore is not empowering companies, but rather empowering individuals. The easiest way to have a winning AI strategy is to have an empowered staff aiming for AI excellence, while maintaining a critical eye on its results.

As Leaders, we should move away from short-sighted AI approaches. We need to build viable arguments, ideas, and strategies to attract capital and budget, aiming to harness the AI disruptive capabilities.

The fundamental aspect is to identify growth opportunities, implement them, and further capitalize on existing solutions.

The pressure to translate AI implementation into tangible success is real. Cost optimization is a straightforward practice to achieve this. However, it risks branding AI solely as a disruptive tool that threatens job security.

A study conducted by MIT, “The GenAI Divide” in mid-2025 concluded that there is a lack of clear results with AI adoption:

The GenAI Divide is most visible when examining industry-level transformation patterns.Despite high-profile investment and widespread pilot activity, only a small fraction of organizations have moved beyond experimentation to achieve meaningful business transformation.

While this study is from June 2025 (which means it risk to become outdated fast given the current pace of AI development), it still highlights the gap between AI pilots and their successful outcomes in companies.

Leveraging AI in products will require creative inspiration from product teams. Unfortunately, current trends lean toward making products and services run cheaper, rather than making them better.

Leaner Teams Focused on Maximizing Impact

For Leaders and from a people management perspective, the future will be easier. Not because people are becoming easier to manage, but because AI will make teams smaller.

Since teams are getting smaller, the value they deliver needs to remain the same, with the caveat that business goals will surely demand ambitious targets with fewer resources.

Below is an article where I dive deeper into this perspective, and where a new opportunity might arise.

There are clear advantages to having leaner teams:

• Fewer friction points between colleagues;

• Simpler decision-making pathways (assuming that management and leadership layers are also becoming leaner);

• Greater ownership of initiatives;

• Easier environment to coach and empower team members;

With leaner teams, professionals will become less specialized and more generalists. With AI handling the heavy lifting, there will be less need for pure specialists.

Consequently, leaders will need to become highly intellectual and strategic, connecting the dots across multiple concepts and domains to figure out effective implementation strategies.

For making your own assessment, use this checklist to evaluate or improve your structure:

• The Basics: Make sure roadmaps are up to date and reassess progress. Basic capacity planning and goal setting requires a roadmap.

• Value Creation: Track initiatives focused on value creation (revenue optimization, upgrading a service or product, etc.).

• Risk Management: Track the risk! If teams are getting smaller, is there an increased risk related to turnover? What backups are in place (if any)? Is the quality decreasing, and are the new standards acceptable?

• Operational Sustainability: Does the team have standby or on-call operations outside of business hours? How sustainable are the rotations? How many incidents happen after hours? Is this slowly burning out the team’s energy? How stable are the applications and infrastructure? How are teams handling the Unknown?

• Strategic Bets: Challenge the structure to have strategic bets using AI as a growth catalyst (not just for cost optimization). What ideas have been discussed lately that is not focused on cost alone? Which existing products or services can we capitalize on with AI? How are those results tracked?

• Voice of the Client: Is the company improving its brand and product awareness, as well as its effectiveness with existing clients? How can AI be used to improve client perception of quality or speed? Prepare a plan accordingly.

AI is all about buzz and hype. Leaders need to remain factual and pragmatic.

Deciding to Go “Vibe” or “Old School”

Without sharing too much outside of an NDA, I recently witnessed a platform withstand a massive spike in traffic over a very short period. That website was built in a old-school way: it used some AI assistance, but it was mostly human-designed and implemented.

AI is still not at a stage where we can trust it with highly critical platforms. However, for a day-to-day internal application built around standard CRUD operations, just vibe code it.

AI is a great auxiliary tool, but for highly critical and delicate applications, human agency is mandatory. Especially to assess the quality of the chosen architecture and make changes as Production evolves.

With the current trend of using AI as a cost-cutting tool, development teams have immense pressure to vibe code solely as a means to faster delivery.

For specific projects, leadership may need to find strong arguments to secure and allocate more budget or time to properly design a new system or architecture. AI can facilitate, but it needs Architects or Senior Engineers to oversee, correct, experiment, and set the course of implementation.

AI is the primary tool developers are using to speed up development, but it often comes at the cost of not understanding what is going on under the hood.

It is no longer uncommon to find developers who don’t actually code anymore. They just chat with Claude daily. They are the vibe coders of the modern age.

However, when a system is pushed to its limits (where we need to know exactly what is happening at each step of the workflow and its configuration), vibe coding can be a death sentence.

Don’t get me wrong: AI-assisted development is the way to go. But AI output is, by nature, very average. It requires multiple iterations to achieve a more challenging goal, especially if the user lacks the foundational know-how in the first place.

Critical, high-stress systems will always need architects and senior developers who deeply understand the requirements and how to implement them. To do that, however, they need the budget and the leeway to explore proper design paths.

One of the biggest challenges from leadership in the future will be finding the time and budget to allow for slower, more reliable software engineering.

Again, I am not talking about your everyday CRUD application. I am referring to tactical applications operating in highly specific contexts that require more human intuition than AI generation.

Strangely enough, securing the time and budget for those challenging requirements might become the hardest thing for a Manager to provide.

There is a lot of buzz and hype around AI. As Leaders we need to remain factual and pragmatic.

Share

It has been a wild ride since I published the first article on the SoW. Exchanging views with you and hearing feedback on how these articles have been useful is what drives my motivation to write. Leave a comment, subscribe to the SoW, and be part of the community.

If this article resonates with you, or you know someone who might find it useful, just share the link!

That’s it. If you find this post useful, please share it with your friends or colleagues who might be interested in this topic. If you would like to see a different angle, suggest it in the comments or send me a message.

Cheers,

Artur

I am Artur, and welcome to my weekly newsletter. I am focusing on topics like IT Management, Innovation, and Leadership, with an Entrepreneurial mindset. My goal is to help you navigate the IT corporate landscape. Make better decisions, create awareness, and share real-world stories.

It has been a wild ride since I published the first article on the SoW. Exchanging views with you and hearing feedback on how these articles have been useful is what drives my motivation to write. Leave a comment, subscribe to the SoW, and be part of the community.

If this article resonates with you, or you know someone who might find it useful, just share the link!

Share

I am writing this article in the midst of Cloudflare’s recent announcement of layoffs affecting 1100 people. AI is widely cited as the primary factor influencing this decision, driven by the technology’s rapid adoption and its subsequent impact on productivity.

Paradoxically, AI is the very reason these roles were eliminated.

Today’s actions are not a cost-cutting exercise or an assessment of individuals’ performance; they are about Cloudflare defining how a world-class, high-growth company operates and creates value in the agentic AI era

However, the overall impact of AI on the labor market remains unclear. While we are undoubtedly at the beginning of a major transformation, the IT job market in both the U.S. and Europe remains stable.

In the US is easier to get data, but evidences show a steady job market in IT despite news of multiple layoffs. In Europe, it is harder to get data specific to IT, however, the unemployment rate remains stable in the euro zone.

Hidden Fallacy on Team Budgeting

Cloudflare won’t be an isolated case. Reducing cost structures due to AI, is becoming a primary goal for companies everywhere. This shift is being enabled by key staff leveraging AI tools, which creates the possibility of leaner organizational models.

However, as talent concentration increases, the structure becomes more fragile: the more centralized the expertise, the higher the impact of a single failure.

If one person with AI is doing the scope of two or three people without AI, the impact of one single point of failure just doubled or tripled.

Who Is Leveraging AI, Really?

This is a question I keep asking myself as I read various use-case articles, and while I analyse and learn the different AI uses. Companies are adding AI into every strategy deck they produce, but it isn’t a tool you can simply broadcast from a mountaintop and expect everyone to capitalize on.

AI is a tool, and like any tool, its effectiveness depends entirely on the person wielding it. Two developers working side-by-side, both powered by AI, can have vastly different performance levels.

This is where the trap lies: you cannot simply mandate AI usage and hope that productivity skyrockets.

There are “star” professionals who have made AI their primary lever, and they are performing brilliantly. Unfortunately, the average use case might have a moderate gain on efficiency while using AI tools like Claude Code. Yet, baselines for cost-effectiveness are being drafted based on these high performers.

AI is not powering teams. AI is powering individuals.

This perspective changes everything.

I recently observed a case where one person handled the workload of two or three different roles, spanning Cloud Engineering to Development. This individual is acing it with an AI tool.

Companies Operate Mostly Understaffed

To say companies operate understaffed is a generalization. Different departments within a large organization often face distinct realities. But as a rule, companies lean toward lean staffing to maximize cost-effectiveness.

This creates constant tension around capacity planning. There is rarely enough FTE availability to meet the demands of the pipeline.

Consequently, prioritization becomes a battlefield, and conflicts arise the moment a stakeholder realizes their request is ranked lower than the “team next door”.

When AI emerged, there was a collective hope that capacity would magically transform. That we could produce features faster with the same number of FTEs.

This would have been a game-changer, providing the margins needed to experiment with new approaches or refine implementations.

Instead, AI is being used as a justification to reduce headcount budgets. In practice, this leaves teams exactly where they were before: understaffed, over-capacity, and drowning in conflicts.

“Why Don’t You Just Use AI”?

The only difference now is the recurring argument for capacity challenges: “Why don’t you just use AI to make it faster?” when this is already the case.

The cycle perpetuates, with the added irony that AI, the tool meant to provide breathing room is being leveraged to shrink the teams even further.

Why Small Isn’t Always Easier

Having managed teams ranging from 3 to nearly 40 FTEs, I can tell you firsthand: managing a small team is often far more difficult than managing a large one.

The primary reason is capacity. When you have less to work with, you spend a disproportionate amount of time negotiating what not to do.

If current trends hold, IT teams will be forced to become leaner and leaner. But small teams face a math problem that AI can’t solve: the work doesn’t adapt to human availability.

In a team of four, if one person takes three weeks for a “once-in-a-lifetime” vacation or maternity/paternity leave, the team instantly loses 25% of its capacity for nearly a month.

Beyond raw capacity, there is the issue of intellectual redundancy.

More Than Just Code

Senior Developers and Architects possess a unique, holistic view of how systems are designed. They are typically the ones best equipped to oversee AI implementations.

In leaner teams, fewer people hold the “big picture” or possess the maturity to “hold the fort” when a key team member is missing. Finding a backup capable of stepping into a Senior’s shoes 100% is rare.

The backup would need to understand both the codebase and the historical business context, all while constantly context-switching to meet demands for his/her own work.

Context-switching used to be a developer’s ultimate productivity killer. Now, it’s risking toward becoming the norm.

Larger teams offer the comfort of overlapping skillsets, which ensures that someone is always there to secure the activity.

Ironically, the way some companies are leveraging AI to justify leaner headcounts is intentionally creating single points of failure and reducing overall systemic resilience.

What Companies Are Leveraging AI For?

This is the fundamental question for assessing how a disruptive tool is being utilized across domains.

Currently, the industry tagline for AI is “increasing productivity and accelerating delivery”. To an extent, this holds true, especially in the beginning when companies decentralize AI usage and star engineers fully harness its potential.

However, my skepticism lies at the leadership level: what will managers actually do with this increased capacity?

Unfortunately, I am seeing a trend where AI is primarily used to suppress operational costs. This includes running cloud systems with fewer resources, avoiding new headcount for critical initiatives, and, increasingly, downsizing existing teams.

Companies lack a proper growth and innovation strategy. When dealing with extended capacity, they lack the vision to understand what to do with it, so they default to cost optimization.

This leads to a pivotal question: If we simply reduce headcount, won’t we just end up producing the same results with fewer people?

If that is the case, the company is negating the true advantages of AI from the start.

This is exactly where I believe an opportunity may arise.

If the overall trend is formed to use AI for reducing the cost structure, the companies that, in contrast, can harness AI to capitalize on existing capacity and find new ways to build and grow, might have found a competitive edge.

Using AI for cost reduction alone will result in static company output supported by leaner cost structures. Most companies are simply using AI to perpetuate the grind with fewer people instead of expanding the ambition. The real winners will be those who use it to build more with the resources they have today.

Share

That’s it. If you find this post useful, please share it with your friends or colleagues who might be interested in this topic. If you would like to see a different angle, suggest it in the comments or send me a message.

Cheers,

Artur

Welcome to a very special edition of The Long Missing Sow.

Today, we have an article by , who is the author of . His articles are pragmatic, with real-world cases above any non-working theory. Alex has decades of experience in engineering leadership and is the very special guest for today’s Project Jam.

While brainstorming topics for this collaboration with Alex, we realized that stress management doesn’t get the honest attention it deserves. Although there is plenty of literature on the subject, stress remains a major “breaking point” for both strategies and careers.

It is often treated as a taboo subject and rarely discussed openly. For today’s Jam, Alex shares his unique views, with practical tips, setting up boundaries, understanding your own pace, and how to manage the invisible work.

Thriving In Engineering

Real lessons, not theory. Alex Ponomarev distills 25 years of engineering leadership into proven frameworks that help you stay calm under pressure, build thriving teams, and lead with confidence.

By Alex Ponomarev

It has been a wild ride since I published the first article on the SoW. Exchanging views with you and hearing feedback on how these articles have been useful is what drives my motivation to write. Leave a comment, subscribe to the SoW, and be part of the community.

If this article resonates with you, or you know someone who might find it useful, just share the link!

Share

Someone walks into your office with a problem. They ask for guidance, they explain the situation, you talk it through. And somehow, when they walk out, that problem is sitting on your shoulder instead of theirs.

It’s an idea I’ve come back to for years from a piece called “Who’s got the monkey?” by William Oncken and Donald Wass. And it’s one I share with many new managers.

The monkey is whatever task or problem someone is carrying, and it’s surprisingly easy for those monkeys to end up with you. Not through one big handoff, but through dozens of small ones, none of which felt like a big deal at the time.

You take on someone’s monkey because you have the energy to handle it and they don’t, and you’re trying to be helpful. Then the next monkey arrives. And the next. Before long you’re running a small zoo while your own work piles up in the corner.

In most companies, “manager” is an abstract role. It doesn’t really matter what kind: engineering manager, product manager, project manager, or anything else. A manager is someone who’s responsible for the result, and to get to the result you always have to do a lot of additional things that aren’t written anywhere.

• Stakeholder issues

• Scope that won’t sit still

• A team member who isn’t getting on with the others

The follow-ups, the chasing, the small things nobody assigned but that someone has to do or else nothing moves. That’s where most of your time and energy actually go, and it’s where most of your stress comes from.

None of this is in your job description, and none of it is going away. The question is whether you let it expand without limit, or whether you draw a line around it.

Start by writing down what you actually do

The first move is to make all of this visible to yourself.

Before you can have any useful conversation about the load you’re carrying, you need to actually see it. Not what’s on your calendar, not what’s in your job description, but what you spent your week on. The real list.

Sit down at the end of a normal week or end of day and write it out. You’ll see two things.

First, how much of your week went on things nobody formally asked you to do, that just appeared and that you handled because you were the one with the bandwidth. Second, how much of what was actually in your plan got pushed aside to make room for that invisible work.

That gap is the conversation you need to have. Without the list, you don’t have a conversation, you just have a vague sense that you’re stretched, and that gets heard as complaining. With the list, you have a description of your reality.

The conversation most managers are avoiding

If your role is going to have edges, you have to draw them, and you have to do it in conversation with the person you report to. Not as a complaint about workload, but as a clear-eyed look at what’s actually happening.

You need to prepare for this conversation, you have to come with proposals, not problems.

If you walk in and say: “I’m overloaded, I’m stressed,” that’s not constructive. It reads as whining, and it doesn’t lead anywhere useful. A junior contributor can get away with that, but a manager can’t. Because part of being a manager is that you’ve already thought about the situation before you bring it up.

So, use your list. Say something like: “Here’s what I’m actually spending my time on. Here’s what’s getting pushed aside as a result. Let’s figure out where my zone of responsibility is and where it isn’t, and what we change.” That’s a conversation any reasonable manager will engage with, because it makes their job easier too.

Now, you have to expect a particular response, because it’s the response you’ll get most of the time. Your boss will say something like: “Well, that’s how it works in our team. That’s the role. Those are the people.” It will sound like the end of the conversation, but it isn’t.

The next move is to name the tradeoffs. What you say is: “Fine. But I have all of this to do, and my time is limited. I can’t do all of it at the same time. I have to choose. So if you want me to keep running this side of things, I won’t be able to do that. You choose what drops.”

You’re not refusing, you’re not making a fight. You’re just being honest that more was dumped on you than is possible to do, and you’re asking the person above you to make the call about what gets traded.

Sometimes they’ll choose. Sometimes they’ll say everything is equally important and nothing can drop. That’s also useful information, because it tells you the expectations aren’t realistic, and now you have to decide what to do with that.

Maybe you prioritise on your own and accept that some things will be done less well. Maybe you start looking for backup options. Maybe you decide the team isn’t a fit for you. All of those are valid responses. What isn’t valid is to keep absorbing silently and hope the load lightens on its own. It won’t.

Nobody is a mind reader

This is the part most find hardest, because it feels uncomfortable. You have to communicate your boundaries explicitly. Out loud and to the people who keep handing you work.

The instinct is to assume people should know better. They should see how much you’re carrying, they should notice when they’re piling on, and they should adjust without being told. None of that happens, and it doesn’t happen because the people around you aren’t bad. They’re just overloaded themselves, focused on their own things, and they’ll keep handing you work until you tell them not to.

It’s like the oxygen mask rule on a plane. You put on your own mask first, not because you’re being selfish but because if you don’t, you’re no use to anyone. The same logic applies here. If you don’t draw your own boundaries, you can’t actually help your team or your stakeholders or your boss, because you’ll be too depleted to do any of it well.

There’s a trap to watch for. In some teams, taking on extra work means you’ve quietly inherited it forever. You picked it up once, so now it’s yours, with no trade and no acknowledgment. In other teams, taking on extra work is genuinely valued and there’s a real exchange in return.

Know which kind of team you’re in. If you keep absorbing work in a team that doesn’t trade anything back, you’ll burn out, and there won’t be much sympathy when you do.

Some weeks are all out, some aren’t

I want to push back on one thing the standard advice gets wrong, which is the idea that there’s a single sustainable pace and you should hit it consistently every week. That’s not how this job works.

Sometimes I work more hours per week because I have a lot going on or because I’m excited about a project. Other times I work the minimum. It’s not about the number of hours, it’s about how I feel and whether I’m depleting reserves I won’t be able to refill.

Energy not time is the real measure. Not whether you’re working hard this week, but whether you can recover by the end of it. If you have a peak, that’s normal. If you have a few weeks of intensity followed by a calmer stretch, that’s also normal. That’s actually how the work tends to come. What’s not sustainable is a constant peak with no troughs.

So pay attention to what comes after the hard weeks.

If you spend a Saturday recovering and then you’re fine on Monday, you’re in the green zone. If you spend a whole weekend wrecked and have nothing left for anything in your life outside work, that’s a diagnosis. That’s a signal that the load shape isn’t sustainable, and it belongs in the same conversation with your boss about what changes.

The standard advice misses the real skill

A lot of conventional advice about overload is technically correct and practically useless:

• Manage your time better

• Set boundaries

• Build a system

• Be more disciplined.

All true, but none of it works on its own. Because the underlying problem isn’t that you’re managing your time badly. The problem is that the role itself doesn’t have edges, and no amount of personal discipline will make an impossible workload possible.

The real skill of senior management isn’t doing more. It’s separating what you have to do from what needs to be done from what someone else is trying to make your problem.

It’s about not silently inheriting other people’s monkeys. It’s about requiring the people who hand you things to prepare them properly first, so you can decide quickly. It’s about helping colleagues when you have room and saying no when you don’t, and being clear about which is which.

It’s a practice you have to rebuild every week, because the load of our work is unpredictable and changes.

The short version

The role doesn’t have edges unless you draw them. Nobody upstream is going to draw them for you, because nobody upstream has a reason to. If you don’t, the role will keep expanding until it breaks you.

Here’s what to do:

• See the invisible work first: Write down what you actually spent your week on, not what was on your calendar. The gap between the two is where the stress is hiding.

• Have the conversation with your manager: Bring the list. Don’t complain, propose trade-offs. When you hear “that’s just how it works here,” say “fine, but you choose what drops.”

• Speak up about boundaries out loud: People aren’t malicious, they’re overloaded too and not mind readers. They’ll keep handing you work until you tell them not to.

• Know what kind of team you’re in: Some teams trade something back when you take on extra. Some don’t. Calibrate accordingly.

• Watch the recovery, not the hours: Some weeks will be all out. That’s fine. What matters is whether you can come back from them.

Do the internal work too. Find the recovery that works for you, the practices that keep you steady, the things outside work that take your mind elsewhere. That work is real and it matters. But don’t stop there, because the agreements you have with the people upstream are the other lever, and they’re the one I see most managers leave untouched.

Pull both, and the role becomes something you can live inside for a long time. Pull only one, and you’ll keep wondering why no amount of self-management ever quite seems to be enough.

Share

That’s it. If you find this post useful, please share it with your friends or colleagues who might be interested in this topic. If you would like to see a different angle, suggest it in the comments or send me a message.

Cheers,

Alex & Artur

Welcome to this special edition of The Leader's Chronicles, where my goal is to share resources and ideas on a specific topic, always featuring a contribution from a guest author.

Today I have the pleasure of introducing Elina Kazantseva from .

is an author and a certified coach and mentor who writes to Leaders about coaching techniques and offers practical insights for aspiring professionals. This collaboration was what triggered the article on Trust and shares Elina’s unique view, which I am excited to share with you.

If you enjoy the content, please consider liking this article and subscribing to ’s work. Your support is important for us writers.

Trust at work is one of those topics everyone knows matters in theory, yet many struggle with in practice. Today, we are taking one question and sitting with it from two different angles.

The question: Can you deliberately build trust, or do you just have to earn it slowly?

Here is ’s viewpoint:

The first lens I would use to answer this question is the subjective experience of trust. We interpret every interaction through a different operating model, shaped by past experiences, beliefs, and personality traits. When you put a group of people in a room, each carrying their own lens, you cannot engineer trust based on just your understanding of the world.

I remember taking a team out for an informal social event, exactly the kind of thing you do to build connection. At some point one colleague made a casual joke, normal team banter, everyone laughed. Later, the person the joke was about told me she felt excluded. The environment had been deliberately designed to create trust, and it still produced something no one intended. You cannot control what a situation means to someone else.

But there is a second lens: what can you actually control? As a leader, you still have a responsibility to create conditions where trust is possible; and that requires capability, not just good intentions.

Early in my management experience, my instinct was to fix situations like that one. What I learned is that the more effective role is not fixer but container creator — someone who observes before intervening, acknowledges everyone’s experience without taking sides, and shows up consistently enough that people know what to expect. Someone who creates enough space for the group to work through friction rather than around it.

That capability takes time to build. But the return is not just smoother team dynamics, it is the ability to prevent serious derailment before it happens.

I would invite you now to visit ’s highlighted article:

Leadership Capability System

It's Not Just About Them: Rethinking Trust

I write about leadership as a set of capabilities. Each month, I explore one capability in depth, breaking it down into patterns, decisions, and practices you can actually apply. If you’re interested in developing these capabilities in your own work, you can explore more…

Read more

8 months ago · 21 likes · 3 comments · Elina

Back to me!

I believe trust must be earned slowly, regardless of your background or past achievements. My approach is similar to a “brute force” strategy: I have a firm conviction that trust is built primarily upon results.

While great communication and stakeholder management go a long way, if a manager takes too long to deliver, trust starts to erode from the top down.

A leader never stands alone. They require the support of those above them in the hierarchy and the commitment of the teams below.

Even a CEO needs the confidence of shareholders to execute an ambitious strategy, just as the teams need to be aligned with the same goals for being able to succeed. Trust may be channeled through words, but it is built upon results.

In a recent article, I explored how trust must be materialized through results, no matter your position. I advocate for taking initiative, breaking silos, and fostering collaboration by integrating ideas from multiple sources.

Together, these actions don’t just build trust, they define a strong Leader.

To conclude this edition, a big thank you to for this collaboration! Find the link to the newsletter below.

Leadership Capability System

Research-backed frameworks and practical tools to help you build leadership capabilities.

By Elina

Share

That’s it. If you find this post useful, please share it with your friends or colleagues who might be interested in this topic.

Cheers,

Elina & Artur

I am Artur, and welcome to my weekly newsletter. I am focusing on topics like IT Management, Innovation, and Leadership, with an Entrepreneurial mindset. My goal is to help you navigate the IT corporate landscape. Make better decisions, create awareness, and share real-world stories.

It has been a wild ride since I published the first article on the SoW. Exchanging views with you and hearing feedback on how these articles have been useful is what drives my motivation to write. Leave a comment, subscribe to the SoW, and be part of the community.

If this article resonates with you, or you know someone who might find it useful, just share the link!

Share

One day, I arrived at my local CrossFit class to find a new coach being introduced. I’m a bit picky when it comes to coaches, but OK, I guess people need to adapt to unannounced changes.

The new coach was a middle-aged man who looked like the last time he did a push-up was before his sons (now in university) were born. Based on first impressions, my hopes weren’t high. His first introduction to his stakeholders wasn’t great. No preparation.

To make matters worse, before the workout started, he struggled setting up the timer, leaving me to guess the rest periods or wait for his instructions.

Why this new coach? I screamed internally as he fumbled with the technology, which is far from rocket science. Clearly, his “Day Zero Readiness” was null.

In an attempt to establish his expertise, he began correcting everyone. When it was my turn to receive feedback, I nodded politely while thinking, “Yeah, whatever”. My trust in him was completely shattered.

The thing about weightlifting folk is that looks can be misleading. Some might not look “in shape”, yet they can lift your body weight and barely call it a warm-up. As it turned out, this coach was a former national record holder in weightlifting.

Experience Does Not Always Translate to Credibility

Despite our achievements and credentials, when we enter a new context (let’s say a new company, a new organization, etc.), we all have one thing in common: we have to prove we know our game. It doesn’t matter if you hold a national record. You need to be prepared to be challenged and questioned.

In the age of AI, regardless of your track record, you cannot afford to be seen struggling with the routine technology of a new job. If you do, your peers’ confidence will be plundered before you even have the chance to show your true worth.

Imagine seeing someone take on a new project, and that colleague is visibly struggling to work with ChatGPT. Or worse, generating a new presentation on AI and sending it to key stakeholders without proper review.

Trust is a big currency in Management. Eroding trust is a cost or tax that you can’t afford to pay. It only takes a few mishaps, especially in a situation where we are new to the context.

We should avoid being the coach who doesn’t know how to operate a timer. If an IT Leader is not following the conversation about the impacts Claude Code is provoking on the Development cycles, how is that Leader supposed to lead an AI transformation? The transformation is happening everywhere.

How to Build Trust

In my experience, trust is highly environment-dependent. I’ve worked in places where newcomers are given an excessively long adaptation period. In others, newcomers are treated as outsiders, met with caution, and gatekept information. I’ve even seen people retreat into silos to prevent anyone from giving their expertise or asking too many questions.

Ultimately, I believe that consistent, high-quality work is what builds trust. While people need time to demonstrate their capabilities, once good work is delivered, trust begins to compound.

This “results-first” approach is more effective than communication strategies alone. Communication can only take you so far if there are no results to sustain the momentum.

A good trust foundation is the base of every IT solution: the engineers. A Manager who doesn't have the team 100% on their side will have a limited range and impact.

A great way for a Manager to build trust and respect with their engineers is to take into account the team's technical improvements on the product roadmap. Technical Debt is the unseen erosion of a team, and a Manager who handles it poorly will have a bad time having the engineers engaged.

The team is the Manager’s strength and tactical reach. A team that is able to handle tough situations can elevate the political reach of its Manager.

Practical Ideas You Can Use Today

The easiest way to cultivate trust is to show confident leadership and results. This can take many forms:

• Facilitating cross-departmental workshops to break down the silos that gatekeep information.

• Gather technical architects and business stakeholders to find solutions to pressing problems.

• Offer action-plans to complex problems with insight from multiple experts and a timeline for execution.

• Facilitate innovative solutions that can achieve agreement from multiple parties and are grounded in the company’s specific market context and constraints.

• Demonstrate how the Engineer’s suggestions impacted the project/product/company. Demonstrate what is next on the technical pipeline and expected results.

Being the Leader who simply “handles stuff” is a currency that compounds trust over time. Especially when challenging issues get solved, with visible results and good feedback from key stakeholders like clients, product teams, etc.

Unfortunately, I met too many managers who hide themselves in the political curtain of vague actions and pretty presentations. Pragmatism and an action-driven mentality are a good strategy to deliver results.

What If Mistakes Eroded Trust?

Mistakes are a risk that needs to be managed. Innovation doesn’t happen in a risk-free environment. The trick is not to bite off more than you can chew, which is why collaboration is vital.

Complex challenges often require the input of different teams or stakeholders, and some of them would need to show ownership.

These events could provide the possibility of shared risk ownership and have multiple parties accountable for the success of a given initiative.

If unfortunate events happen, it is important to maintain a stoic mindset and analyse what happened, what we could have done differently, and how to access the required resources. Then, just move on.

Eventually, with results, trust buys enough goodwill to overcome inevitable setbacks. It compounds over time and is directly linked to the value you bring to the company.

Success is by far the biggest magnet for trust. A proven track record makes it easier to get a green light from a senior manager or influence the outcome of a major decision in a direction you think is best.

Share

That’s it. If you find this post useful, please share it with your friends or colleagues who might be interested in this topic. If you would like to see a different angle, suggest it in the comments or send me a message.

Cheers,

Artur

I am Artur, and welcome to my weekly newsletter. I am focusing on topics like IT Management, Innovation, and Leadership, with an Entrepreneurial mindset. My goal is to help you navigate the IT corporate landscape. Make better decisions, create awareness, and share real-world stories.

It has been a wild ride since I published the first article on the SoW. Exchanging views with you and hearing feedback on how these articles have been useful is what drives my motivation to write. Leave a comment, subscribe to the SoW, and be part of the community.

If this article resonates with you, or you know someone who might find it useful, just share the link!

Share

Hopefully, if everything is on track, this article will be published on a curious public holiday: Workers’ Day.

To be aligned with the theme of the day, I will address one of the pieces that will shake Europe’s professional markets in the coming months. The Pay Transparency Directive is around the corner and has several goals:

• Increase transparency on salaries for job postings.

• Allow employees to share their salary with their colleagues.

• Disclose salary averages for different roles within the company.

• Reduce the pay gap between men and women.

This topic is curious because if I speak with someone in the US or Switzerland, they are sometimes shocked to learn that salaries in the EU are confidential information inside a company.

Meaning, if someone is working in an EU-based company, he or she should not disclose their salary conditions with their peers since is considered confidential information.

This new EU directive will rock the boat in the coming months, and all State members should reflect it into law by June this year.

What Is The EU Directive On Pay Transparency About?

Today in the EU, the “salary negotiation” is like a game played blindly from the candidate’s perspective.

Candidates would probably lie about questions regarding their current earnings to inflate the next salary proposal. Employers would receive a wide range of salary expectations, which provides maneuver for offering a low salary to a good profile.

And once the contract was signed, the salary conditions were confidential.

Discussing one’s paycheck at coffee with co-workers was often a disciplinary risk, hidden behind strict confidentiality clauses that are now being rendered legally void across the EU starting from June 7, 2026.

The EU Pay Transparency Directive will rewrite the social contract between employer and employee.

The change is felt during the selection process. Under the new rules, the candidate can be informed either in the job posting or before the job interview about the position’s salary range.

Recruiters won’t be allowed to ask about the candidate’s current salary, which could lead to discriminatory values, even when switching companies.

From June onwards, the directive would also allow any worker to receive the average pay levels for colleagues doing the same work or work of “equal value”, broken down by gender.

What is equal value?

This will be the tricky part to implement correctly. Every role in the company will need to be classified in four main areas:

• Skills: Education, professional experience, and training.

• Effort: Mental, physical, and emotional, etc.

• Responsibility: Responsibility for people, assets, or data.

• Working Conditions: Factors like stress, environment, or “on-call” requirements.

Each of these areas can have sub-areas that can help better profile a given role.

These attributes would receive a value based on the level of requirements (let’s say 1 for “Basic” to 5 for “Expert”). The role itself would then have a global score based on the classifications across all areas.

The goal is to be able to compare two different roles inside the company, even in different departments, which will provide a view of equal value for the company.

Let’s look at an example: A Project Manager in Marketing and Systems Engineer in IT might have different daily tasks. However, if their roles require equivalent Skills, Effort, Responsibility, and Working Conditions, they are of equal value.

If a 5% gender pay gap emerges between these categories and cannot be justified by objective factors, it will trigger a Joint Pay Assessment (JPA). This must be conducted in cooperation with workers’ representatives, and if the gap is not rectified within six months of the reporting, fixing the gap becomes mandatory.

Even though this targets the gender gap, it will impact other areas of the market.

For example, if a startup wants to pay “whatever it takes” to land a star developer, that decision now needs to be moderated by the need for internal equity, depending on the company’s size.

To fight the pay gap between genders, the EU is now betting on a new set of legislation to increase transparency and mandatory reporting to countries’ agencies dependending on their size (the copy+paste from the directive below):

• Employers with 250 workers or more shall, by 7 June 2027 and every year thereafter, provide the information set out in paragraph 1 [the gender pay gap data] relating to the previous calendar year.

• Employers with 150 to 249 workers shall, by 7 June 2027 and every three years thereafter, provide the information set out in paragraph 1 relating to the previous calendar year.

• Employers with 100 to 149 workers shall, by 7 June 2031 and every three years thereafter, provide the information set out in paragraph 1 relating to the previous calendar year.

• Member States shall not prevent employers with fewer than 100 workers from providing the information set out in paragraph 1 on a voluntary basis. Member States may, as a matter of national law, require employers with fewer than 100 workers to provide information on pay.

The Good Stuff

The spirit behind this new regulation is well-intentioned, aiming to close the EU’s gender pay gap, which currently averages around 12%. It is a serious attempt to address one of the biggest challenges in the professional world, and the IT sector is no exception.

For candidates, salary ranges in job postings and interviews will finally make the process transparent. This saves everyone time by preventing candidates from pursuing underpaid positions that they would only discover later in the process.

In the same line of reasoning, it will be easier for underpaid professionals to identify and apply to more competitive listings.

The impact will also reach beyond gender. Immigration is a vital aspect of Europe’s IT fabric, and these measures will allow those who have immigrated (even withing EU) to factually compare their earnings with native professionals.

Companies can also use this transparency to benchmark against their competitors more easily. In some cases, this will help them offer competitive wages for tactical positions on critical projects.

Finally, star employees will now have the means to understand if they are being paid fairly for the value they deliver. This provides them with a factual, data-backed argument to leverage during negotiations.

The spirit of the law comes from a good place. If implemented correctly, it could solve many of the long-standing moral and professional frictions in the EU’s IT landscape.

The Main Challenges

Putting this regulation into practice is a nightmare, especially for bigger companies.

It is very common to find salary discrepancies among people doing the same work (regardless of gender) due to legacy internal procedures and unique employee stories.

HR and their processes

For example, one of my biggest HR challenges involved a developer who migrated to IT from an Operations team.

He was part of an operational (non-IT) team, but because he did some Excel macros on the side, someone had the “wonderful” idea to transfer him to an IT development team.

Unfortunately, the development skills were not there, and neither HR didn't update his salary when transferring between departments with completely different realities in terms of work and pay expectations.

One day, he learned how much the colleagues seated next to him were being paid. Even though some colleagues were freelancers (not even an apples-to-apples comparison) he realized in shock that his salary was far below his peers’.

There are multiple examples like this in any single company.

Added to these are cases where the conditions under which people signed their initial contracts weren’t updated fast enough to match market values and new hires with the same seniority.

Even if HR has off-cycles processes to address these issues, those processes often take years to properly resolve.

The directive will provide an increased transparency, as companies will have less leeway to make process mistakes.

The Performance Conversation

Salary disputes have always existed, and people have always shared salary values secretly.

The difference now is that Leadership will be faced with factual data. In some cases, they will need to properly explain why two people in the same role are not being paid the same because of mismatched results.

This becomes critical when underperforming staff start to compare their salaries with those of top performers and demand higher pay. The root cause is that in the EU might not be easy to fire underperforming staff, which creates challenges over several years with continuous conflicts and expectations management.

I expect to see a rise in salary disputes initially, but eventually, the dust will settle, and performance can return to the center of the conversation.

Roles Comparison

Another big challenge is to structure and differentiate the roles inside the company under the umbrella of “roles with equal value”.

It will be very interesting to explain to someone leading an non-IT team that their position might receive less pay than an IT Developer. If the company is technological in nature, there is little challenge. However, in other industries, these problems might be exacerbated when comparing IT with other areas.

In order to differentiate these roles, companies will need to build matrices that evaluate different roles based on four factors: Skills, Effort, Responsibility, and Working Conditions.

Errors will be made for sure. One of the most evident is a major pain point with HR: they love their paper credentials, while IT is a practical knowledge and skill set area.

I really don’t care if someone has a PhD if a developer with a Math bachelor’s degree is doing better work.

I won’t be surprised if credentials are put in the matrices just to differentiate roles, potentially harming key employees when being compared with different unrelated roles inside the company.

Averages vs Medians

Eventually the analysis will be centered around averages.

While some star employees will naturally have higher pay, this can become a contentious point. When these employees push the average high while the rest of the team is well under the median, it creates a distorted picture.

This might give the false impression that someone is being underpaid, when in reality, one “outlier” is simply pushing the average up.

It is not uncommon when launching new business segments or opening new branches that tactical staff are relocated. These moves often require much higher pay to incentivize the transition. Even though these situations make sense strategically, they open the door to more points of contention regarding fair payment within the local team.

The new directive won’t simply allow co-workers to speak about their salaries (in reality, this was already happening). The main challenge is that companies must now provide the actual figures when requested.

This allows an employee to see exactly where their paycheck fits inside the company’s organization. This transparency inherently creates conflicts that will have to be managed directly by Leadership.

The Outsourcing Loophole

This is the Trojan horse for many companies, especially those in non-technological sectors.

The use of outsourcing is widespread. Even if a consultant is working 100% for a specific client, that client is currently not held accountable for any pay gaps within the vendor’s team.

In practice, this will put immense pressure on outsourcing vendors whose services are priced consultant-by-consultant.

If a pay gap needs to be fixed within a vendor, there are only two ways to handle it:

1. Internal Absorption: The vendor eats the extra cost and increases the consultant’s salary without raising the rate.

2. Rate Hikes: The salary increase is reflected in the rate, and the client is asked to pay the difference.

In the second scenario, the client will assess if the service is still worth the price. They may simply choose to replace the consultant if they aren’t satisfied with the new costs.

Overall, this will be a very interesting regulation to follow its implementation and study the impacts on the labor market.

For sure, we will read a lot about this subject that is a massive cultural shift happening in the IT workspace.

Share

That’s it. If you find this post useful, please share it with your friends or colleagues who might be interested in this topic. If you would like to see a different angle, suggest it in the comments or send me a message.

Cheers,

Artur

I am Artur, and welcome to my weekly newsletter. I am focusing on topics like IT Management, Innovation, and Leadership, with an Entrepreneurial mindset. My goal is to help you navigate the IT corporate landscape. Make better decisions, create awareness, and share real-world stories.

It has been a wild ride since I published the first article on the SoW. Exchanging views with you and hearing feedback on how these articles have been useful is what drives my motivation to write. Leave a comment, subscribe to the SoW, and be part of the community.

If this article resonates with you, or you know someone who might find it useful, just share the link!

Share

In an increasingly connected world, turbulence in one part of the globe can disrupt global supply chains and cause prices for major hardware components to spike. The recent events in Iran have created a panoply of issues that must be managed moving forward, offering key lessons on how to operate more effectively within the IT landscape.

The goal of this article is not to provide a political assessment (which falls outside the scope of the SOW) but to analyze how we should better manage our IT portfolios and projects. In the following sections, I will outline several considerations intended to raise awareness of the factors that can impact our projects and initiatives.

Imagine a conflict 5,000 kilometers away just added 8% to your offshore payroll and 15% to your cloud bill. IT Leaders should remain vigilant to geopolitical turbulence.

Cybersecurity: Prevention and Impacts

If you have business interests in the Middle East, you may have already encountered sophisticated cybersecurity threats. Recent events surrounding the conflict in Iran and the Strait of Hormuz have led to an increase in cyberattacks targeting companies in finance, retail, healthcare, and technology, among other sectors.

While these attacks are primarily focused on Middle Eastern nations, they can easily spill over into the US, EU, and other regions in the globe.

The overarching message is that companies must strengthen their IT security practices during periods of heightened geopolitical tension, particularly if they partner with entities in affected regions.

Hacktivism is a significant threat that can be orchestrated from anywhere in the world. To mitigate these risks, it is essential to ensure the company adheres to foundational IT security best practices:

• Implement MFA (Multi-Factor Authentication): Require MFA for all applications, even internal.

• Enforce Credential Rotation: Regularly update passwords, access keys, and secrets for both systems and employees.

• Employ Zero-Trust Architecture: Apply Zero-Trust principles to critical software, especially back-end services for public-facing websites.

• Coordinate with IT Security Vendors: Ensure robust DDoS mitigation strategies are in place, particularly for organizations in critical sectors like government, finance, and logistics.

• Maintain Actionable DRPs: Ensure Disaster Recovery Plans are updated, tested, and ready for rapid execution.

• Utilize Offline Backup Storage: Offline backups to protect data from ransomware and wiper attacks.

IT Budget Impacts

Rising energy costs and the global helium shortage have significantly increased the cost of semiconductor manufacturing. These expenses are inevitably passed down to the consumer, leading to higher costs for cloud services and physical server hardware.

Such shifts can disrupt annual budget projections. Depending on the project, organizations may need to re-evaluate their cost structures or, in some cases, pause initiatives entirely.

These inflationary pressures also extend to laptops and personal workstations. Companies may face higher procurement costs, which can become particularly impactful during periods of rapid scaling or high staff turnover.

While utilizing refurbished hardware is a viable temporary measure, it may not serve as a sustainable long-term solution regarding hardware obsolescence and performance.

Plus, internal IT security budgets must be reviewed to account for increased regional exposure. Some organizations, if vulnerable to these events, might need to invest in platform modernization to mitigate rising risks and vulnerabilities.

Be mindful that exploits are becoming increasingly sophisticated due to AI-driven threats. Maintaining a resilient security posture requires investment, particularly where legacy applications and past security practices have led to technical obsolescence.

Near-shoring and Far-shoring Risks

Recent events have served as a significant “eye-opener”, reminding us that the Middle East remains a volatile region. The closure of Dubai Airport some weeks ago highlighted that, despite its modern infrastructure and welcoming business climate, the region is still susceptible to sudden disruption.

On top of that, the impact on fertilizer supply chains and pricing could potentially destabilize economies like India, a primary powerhouse for US and EU far-shoring strategies.

I have never been a big fan of implementing far-shoring for the sake of cost reduction alone (story for a different article). However, it is vital to assess the risk of inflation when a significant percentage of your workforce is concentrated in an impacted country. For instance, if India were to experience a surge in food prices, it would drive up the national inflation rate.

High inflation is the primary catalyst for increased staff costs and higher turnover. If a far-shoring decision was based solely on low labor costs, an unexpected 6–8% spike in payroll expenses could severely undermine the strategy’s projected ROI.

Another strategy involves selecting regions that offer greater security and stability. However, if the company is already in a less stable region, this requires an assessment of the additional investment needed for new offshore implementations. Cost should never have been the main driver for the investment (again, story for a different article).

Share

That’s it. If you find this post useful, please share it with your friends or colleagues who might be interested in this topic. If you would like to see a different angle, suggest it in the comments or send me a message.

Cheers,

Artur

I am Artur, and welcome to my weekly newsletter. I am focusing on topics like IT Management, Innovation, and Leadership, with an Entrepreneurial mindset. My goal is to help you navigate the IT corporate landscape. Make better decisions, create awareness, and share real-world stories.

It has been a wild ride since I published the first article on the SoW. Exchanging views with you and hearing feedback on how these articles have been useful is what drives my motivation to write. Leave a comment, subscribe to the SoW, and be part of the community.

If this article resonates with you, or you know someone who might find it useful, just share the link!

Share

There is significant political noise surrounding EU technological sovereignty. Among the perspectives shared online, there are valid concerns and realistic strategies, but also many irresponsible suggestions.

The Geopolitical and Market Landscape

The political relationship between the US and its European counterparts is becoming a bit tricky to manage. I won’t go into a full political analysis (as it is outside the scope of this SoW), but I want to share the context of the environment in which the EU is currently operating.

Technological Sovereignty is one of many topics currently under discussion in the EU’s political sphere, alongside other subjects like NATO and trade relations.

In practice, technological sovereignty is just another piece of a large geopolitical puzzle that European agents are trying to piece together. As a consequence, a movement has gained momentum in recent months encouraging European companies to rely more on domestic technological services.

However, there is a catch: the majority of critical tech sectors are led by US-based companies. There is a specific reason for this, which I will cover shortly. To give an overview, in Cloud Services alone, AWS, GCP, and Azure (all US-based companies) account for more than 60% of the global market share.

There are virtually no European-based companies represented in the market share graphs.

If I were to attend an industry event in Central Europe and ask IT leaders to name a leading European provider, I bet the majority could only name one, and that company likely holds, at most, a 2% market share. Even then, people usually default to a provider from their own country. (I will leave a link here if you are curious about other European providers.)

A similar exercise can be performed with AI technology. From hardware to LLMs, there is very low market penetration by EU-based companies. As of the writing of this article, the most prominent European AI company is Mistral. But let’s be honest, when was the last time you actually used Mistral AI?

The Foundational Challenges

Currently, the EU faces two major foundational challenges that would require a massive restructuring.

Scale-up Money

When launching a startup, European entrepreneurs can only go so far using European capital.

They can develop a strategy and test products, but when a startup proves its model and needs to scale internationally (typically during Series C funding rounds), Europe fails to offer significant capital solutions. Consequently, entrepreneurs are often forced to look to the US, where they are frequently required to relocate their headquarters.

European countries often mirror this parochialism. If a domestic company wins a public project or receives state funding, a common requirement is to keep the build or the headquarters within that specific country. It is the same restrictive philosophy.

Is the EU lacking the capital to invest?

The reality is actually the opposite.

The European retail banking market is notoriously liquid. The majority of Europeans keep their money in traditional savings accounts rather than investing it (with a few exceptions, such as Sweden).

There is a deeply ingrained, conservative European mindset, and the banking system remains the primary source of corporate funding.

Even in universities, students are taught to build business plans for banks rather than for venture capital funds or private investors. Europe’s funding market requires a structural overhaul, yet this is unlikely to change in the near future.

Market Fragmentation

The second critical issue is European fragmentation.

If you establish a company in Belgium and wish to open a branch just a few kilometers away in Germany, you will encounter entirely different tax codes, administrative processes, and labor laws.

Despite the EU’s mandate for the free movement of people and services, its foundational core remains fragmented by decades of localized legislation. This creates significant hurdles for startups attempting to scale across borders. This fragmentation acts as a ‘tax on growth’ that entrepreneurs simply don’t have to pay in the US.

Doing business in the EU is inherently more difficult than in the US. While the US presents an equally competitive commercial market, it offers a unified regulatory framework that the EU simply cannot match.

The Solutions So Far

The European Union is well aware of these challenges and addresses them in the best way it can: through the launch of public European funds.

The EU’s main effort is to protect data sovereignty, and it maintains stricter GDPR concerns than either the US or China. The development of European AI data warehouses has become a strategic priority for the European Commission. While the availability of this capital is a positive step, it comes at the high cost of heavy bureaucracy.

Initiatives at the European level are primarily state-led. Despite their strategic importance, these projects can only go so far. A mature private sector, supported by alternative investment funds, would be faster and far more accessible from a bureaucratic standpoint.

Ultimately, a significant shift in mindset is required. Europe needs to move more capital into investment funds capable of fueling projects across all stages of growth (from initial seed money to late-stage scaling).

An Opportunity for the US

If US-based companies continue to secure their lead in the technological landscape, Europe will remain one of its primary technological trade partners. Conversely, if Europe manages to turn its technological competitiveness and legislative issues around, it could present an incredible opportunity for US investors.

Today, some US-based companies already maintain a percentage of their workforce in Eastern European countries. Without going into too much detail (a topic for a different article), if a developer in the US costs the company $250k annually (including all taxes and benefits), a developer with the same level of skills in Eastern Europe (like Poland or Romania) might cost around $60k (including all taxes and benefits). This represents a significant opportunity, especially for startups, as it allows for a larger team within the same cost baseline.

Another opportunity lies in the “mindset shock” (and this is where I am hoping for a true impact). Today, a US-based investor’s primary concern is growth, followed by profits.

In Europe, any business plan that cannot turn a profit by year two and achieve an ROI (Return on Investment) within four or five years barely stands a chance.

While the US has a significant market advantage, this mindset is the true “secret sauce” behind its technological lead. Europe would need to fundamentally shift its investment mentality to have any hope of gaining any form of technological lead.

Share

That’s it. If you find this post useful, please share it with your friends or colleagues who might be interested in this topic. If you would like to see a different angle, suggest it in the comments or send me a message.

Cheers,

Artur

I am Artur, and welcome to my weekly newsletter. I am focusing on topics like IT Management, Innovation, and Leadership, with an Entrepreneurial mindset. My goal is to help you navigate the IT corporate landscape. Make better decisions, create awareness, and share real-world stories.

It has been a wild ride since I published the first article on the SoW. Exchanging views with you and hearing feedback on how these articles have been useful is what drives my motivation to write. Leave a comment, subscribe to the SoW, and be part of the community.

If this article resonates with you, or you know someone who might find it useful, just share the link!

Share

Sometimes we get a very bad apple in our project basket. The goal was already challenging enough as it was, but we also had to deal with a “talker” during the project execution.

After a while, I started to see signs that something wasn’t right, despite the status being reported as “Everything is fine, nothing to see here”. When I finally popped the hood, it was a mess: I realized I was dealing with a total pile of sh!t.

This kind of situation happens even to the most experienced managers. It happens because we try to create the right conditions for our team to evolve and improve their skills, accepting errors as a natural part of the learning curve.

However, sometimes enough is enough, and we have to deal with someone who refuses to take responsibility for bad work.

For today’s article, let’s walk through a real case involving a project called “Unicorn of Truth” (fictitious name). It was executed in a fully remote setting by one of our favorite engineers (and I’m using the word “favorite” with heavy irony here), whom we’ll call Francis.

The First Impressions

The “Unicorn of Truth” project required someone with a very specific set of skills (and no, this isn’t a John Wick movie).

These skills are not easy to find on the market, especially with the constraint that we only needed someone for a limited time. It was the kind of job typically given to a freelancer, with the potential to extend into a maintenance contract once the “Unicorn” was delivered.

Francis was dropped in front of us straight from IT heaven, and we quickly felt he was the right person for the job. The interview was great. He seemed to know his “unicorn business” inside and out, possessing both the communication skills and the technical chops to pull it off.

Before the project even kicked off, he delivered a comprehensive SoW (Statement of Work) that felt fresh from an AI generator. Much like every other piece of documentation in circulation right now. We were ready to start.

The First Signs That Something Was Wrong

While we were laying the groundwork and setting up the infrastructure, the first cracks began to appear. Our friend Francis would only connect in the morning, ignoring any Teams messages sent in the afternoon until the following day.

We were now officially burning calendar days, and the project hadn’t even properly started.

Because Francis was fully remote, we couldn’t exactly pull him into an office to assess the “Unicorn’s” progress in person. On top of that, we hit infrastructure issues that required back-and-forth collaboration. Given Francis’s delay in replying, these issues took days to address instead of hours.

We immediately scheduled a call to let him know that the lag between communication and action was far below expectations. The topic was addressed swiftly. We both accepted mea culpas regarding the infrastructure hurdles that shouldn’t have been there in the first place.

The compromise was that Francis would provide daily progress reports. From experience, I already knew this would only work for the first three days before everything reverted to the status quo.

AI Is Not A Magic Wand

In this day and age, AI is everywhere, and it’s great to see it being adopted more routinely. However, AI can also be used to mask lazy work. Because AI provides what appears to be a “clean” output, people often assume it won’t be challenged.

But having the ability to copy and paste from a ChatGPT window isn’t the same as understanding the subject matter. It only proves you know how to prompt, copy, and paste.

AI tools now allow mediocre professionals to disguise themselves as experts who understand the game. Looking back at the end of the project, it was evident that Francis was relying far too heavily on AI without providing any genuine insight of his own.

He was saying and writing what, at first glance, seemed like the right stuff, but in practice, his output was a pile of sh!t.

Babysitting Morphed Into Micromanaging

It’s normal to keep an eye on progress and ask for the occasional status update. The problem starts when you feel the need to hover because you know something is wrong in “Unicorn Land”.

It became part of my routine to check his work every few hours just to see if there was any progress at all.

I kid you not: once the feedback was consistently that the Unicorn would be ready for testing “in a matter of hours”. Those hours turned into three weeks. Every day brought a different excuse for why something hadn’t worked as planned.

He was becoming too comfortable making excuses, and I started to feel like he was just throwing sand in my eyes. He was still facing infrastructure challenges that required another team’s involvement (which complicated things), but the level of trust had plummeted.

For every issue that surfaced, his first instinct was to shift the blame and provide an excuse. Francis was delivering 90% excuses and only 10% actual solutions. His “deep research” usually took about five minutes, just long enough to find the perfect handful of sand to throw in everyone’s faces.

I needed to fire him. FAST. But the project sponsor and some senior managers kept me from hitting the red button: “We just need a bit more time”, they said. “He just needs to deliver this one piece of the project and that’s it”.

The Unicorn Is Available For Testing

Finally, the long-awaited message arrived! The “Unicorn” was ready for testing, and I immediately jumped in to check.

Right away, it was clear this version was missing the very component that distinguishes a unicorn from a horse. Instead of a majestic unicorn, we got a plain, vanilla brown horse Texas-style. Francis had “challenges” with the unicorn part, and it took several more days just to deliver a version of what we actually expected.

By this point, my patience was nonexistent. Communicating with Francis was only possible after five minutes of breathing exercises between every line in the Teams chat.

Dealing with fully remote positions isn’t all rainbows and butterflies.

On the first day of testing, actually, within the first five minutes, the “Unicorn” couldn’t even walk. The application was throwing errors left, right, and center. I couldn’t believe what I was witnessing. I created a series of bug tickets, and Francis gave the same response over and over again: “It is not related to the unicorn features”. The project wasn’t even a functional horse.

If We Cannot Fire: Shock Treatment

An emergency meeting was scheduled, and even the CEO of the vendors insisted on joining.

We laid out exactly how badly things were progressing, using factual cases as evidence. We agreed to a few more compromises, but only on the condition that action would be immediate.

Honestly, I did my best not to explode in pure anger multiple times while witnessing such a level of amateurism from the vendor on such a complex project.

Anyone in a leadership position must control their emotions and clearly state the problem at hand. We have to stay factual. Losing one’s temper is a public admission of a lack of control.

For the next three days, things actually improved. Testing finally began to address the “Unicorn” elements of the project.

Until, that is, even weirder bugs started to appear.

The Pressure Mounts

After several days of unstable progress, I began demanding explanations for the increasingly bizarre bugs we were encountering. I asked for direct root-cause analyses and the specific steps Francis was taking to address them. He avoided sharing the information, and I insisted. Several times. This was the definitive sign that he was hiding something.

To my surprise, I discovered Francis was “fixing” each case manually at the user level. This meant that if a new user connected to the platform, they would experience the exact same issues reported in the bug tracker. He was essentially hardcoding his way out of a testing phase.

Francis then tried to shift the focus to how the tests were being conducted. His suggestions were designed to muddy the waters and disguise his poor deliveries. It quickly became a “Me vs. Francis” situation.

He even started calling out other people to back his opinions in meetings (colleagues who have remained silent to this day) as a way to gain leverage against my stance. As the project Lead, I was the last bastion of quality. I could never agree to proposals that murdered our standards just so Francis could buy more time to hide and “fix” things.

In every management meeting, I explicitly asked to fire him, pointing to massive cost deltas and project impacts. Yet everyone, even the CTO, asked for more time: “We’re almost there, we just need Francis to deliver X.” It felt truly odd. I began to suspect I wasn’t being shown the complete picture.

But all the excuses finally fell short the day a major component of the project was deleted from the database. There wasn’t a better monument to signal a poorly executed job than that.

The Turn Around

Yet another emergency call was scheduled with the vendor, but this time, we started asking the kinds of questions a client shouldn’t typically have to ask.

Since we were working with a freelancer in a fully remote position, we began digging into what other projects Francis had on his plate at the same time. We asked what kind of SLAs the vendor had with him and what kind of follow-up they were providing, aside from my daily “Are we there yet?” status updates.

I interrogated every small detail. Information that the vendor had every right not to reveal. But the objective was achieved: it became clear that Francis was juggling multiple projects, and his contract with the vendor didn’t support the level of service we expected.

We made a lot of people uncomfortable, but we successfully forced the vendor to review Francis’s situation. Despite all the feedback we had provided, the root cause had been hidden from us.

Furthermore, there was a political pain point between my company’s and the vendor’s senior management that was being handled with extreme caution. This was the real reason I faced so much internal resistance to firing him. Extensive negotiations were happening behind the scenes, and my “Unicorn” project was being used as a lever to force prices down.

Once everything was out in the open, it’s not like everything turned into rainbows and butterflies overnight. However, it was enough to speed up the fixes. I was finally able to review Francis’s planning while accounting for his other commitments. I managed to negotiate more allocated time and fewer distractions, allowing him to finally focus on the “Unicorn” we were promised.

Problems still arose, and things remained tense. My relationship with Francis was forever tarnished, but at least progress happened, and a “Unicorn” was delivered. Along with a massive discount, which honestly, cost us all too much.

Share

That’s it. If you find this post useful, please share it with your friends or colleagues who might be interested in this topic. If you would like to see a different angle, suggest it in the comments or send me a message.

Cheers,

Artur

I am Artur, and welcome to my weekly newsletter. I am focusing on topics like IT Management, Innovation, and Leadership, with an Entrepreneurial mindset. My goal is to help you navigate the IT corporate landscape. Make better decisions, create awareness, and share real-world stories.

It has been a wild ride since I published the first article on the SoW. Exchanging views with you and hearing feedback on how these articles have been useful is what drives my motivation to write. Leave a comment, subscribe to the SoW, and be part of the community.

If this article resonates with you, or you know someone who might find it useful, just share the link!

Share

There is a silent shift that is happening, that even though I don’t want to start doing futurology, I just want to “put out there” for the sake of creating awareness.

The first sign appeared when I was at an event, and during the “drinks” (or networking) part, someone shared an interesting story.

This guy (sorry, I don’t remember his name or the company but it’s not relevant for this story) was creating a product for his startup, and in one night, he saw his monthly budget for Cloud services going down the drain.

Why? He pushed a script to production that got caught in an infinite loop during nightly execution. It consumed the CPU and exhausted the entire monthly budget in one night.

People at the event criticised the lack of guardrails for this kind of situation. But the main message is: Cloud can be very expensive.

Even though I am not an infra guy, the infrastructure costs are something that we care much about, until I noticed a new trend is forming.

Cloud Repatriation

What is Cloud Repatriation?

Nowadays, companies tend to implement cloud-based infrastructures, and using a cloud provider is often the first option they consider.

However, some companies are considering doing the reverse for some projects.

They are moving away from the Cloud due to costs, and the technical term for this movement is “Cloud Repatriation”.

Data centers tend to have a three-to-five-year cycle for their infrastructure lifetime. This means that every few years, the hardware being used in a data center should be replaced by a newer (and hopefully better) version. Demand for new hardware increases, and the cost follows this trend.

Especially due to the enormous infrastructure requirements connected to AI and increased investments planned in the near future. Consequently, hardware costs around the world are becoming more expensive.

It wouldn’t be surprising to see hardware in these datacenters being used until its seven-year run, as a Management cost-effective decision.

Actually, one of the theories in regards of AI bubble sits exactly on this topic. In the sense that AI infrastructure requires an enormous amount of investment in hardware, where its profit margins are still short (Not talking about Nvidia). But I guess this is a topic for a different article.

Why This Is Relevant?

The majority of companies have selected a specific cloud provider (typically AWS or GCP), but many companies and executives didn’t realize how vendor-locked they truly are.

Migrating applications to a public cloud provider is not an easy task, and once it’s done, the last thing executives want to hear is to make another cloud migration.

In financial services, the preferred solution is often building private clouds due to privacy and regulatory constraints. Which puts them in a better position for leveraging vendors during contract negotiations.

However, the AI pressure on hardware will signify one thing: Hardware will get immensely expensive. So costs will make a big part of the decision to continue on a public cloud infrastructure. Especially if a company has already some physical servers lying around.

Another point in a more political nature. Our friends on US have decided to put a very mediatized President who is rocking the boat of international politics. My point here is not to make a political assessment (it is out of the scope of this newsletter), but I would need to make a management assessment.

Business requires stability, and we need to have visibility on what is ahead. Dear Mr. Trump, has started a discussion inside the EU about technological sovereignty. Today, there is no actual European competitor for AWS and GCP, but is a topic where we (at EU) are on alert.

The European Union is slow and bureaucratic, but it is stable. This stability is key for doing business and make long term decisions. Compliance can be a very strong argument for infrastructure repatriation, and the companies that have on-prem infra today have it due to obsolescence or regulations. However, we might see some evolution in the near future, depending on how the political landscape evolves.

Tangible Argument. Cost.

AWS and GCP are the kings of Cloud Services, and we need to pay attention to how their services are priced. The cost of hardware has only one trend that is up. Every company should have processes in place to optimize its cloud usage to become cost-efficient.

However, if a system is data or processing-heavy, it is important to start asking the question: What would be the TCO (Total Cost of Ownership) if I put this system on-prem?

However, besides the cost of the physical hardware, it is important to account for the costs of having dedicated people to maintain it and all the IT security requirements on the TCO.

Looking at the hardware alone, it would compensate financially to move away from the cloud for some data/CPU-intensive systems. Even if hardware for on-prem infrastructure can be depreciated in taxes, it is still an important CAPEX (investment) to take into consideration.

Moving back to on-prem today, in any capacity, is primarily a savings decision rather than a strategic or operational shift. Tomorrow the political landscape could stir things up, and to avoid a costly mistake a rigorous analysis is the only way to validate the move.

I won’t be surprised that Cloud costs would be on everyone’s agenda in the next couple of years, as AI increases its hardware footprint in the global markets. Also, is important to keep an eye on how technological sovereignty evolves in the EU.

If Costs Are Getting Too High, What Are The Solutions?

Let’s make a small shortlist of actions first:

1. Use AI to understand where the waste is on your infrastructure:

   1. Instances running 24/7 while there is no need for it (Especially Dev and Testing environments)

   2. Oversized VMs or other resources.

2. Implement cache (Redis, CDNs) systems (Especially over different regions)

3. Redesign system transfers and storage

   1. If we need to store so much data (typically, teams forget to implement data cleanup and purge scripts on new systems)

   2. Add compression

   3. Identify the main egress points and implement ideas to mitigate

AI is a great help for these assessments. I am not a Cloud Architect, but I have seen wonders in terms of savings based on AI analysis to decrease the costs of Cloud infrastructures.

However, even after all these analyses were done and you need another solution: Go hybrid.

Of course, a TCO is mandatory to make a final decision, but it would be possible to design a system architecture where the back-end would be On-Prem while the front-end (or the light part of the system) would be on a Cloud infra.

The majority of the costs rely on Data, Transfer, and Processing. If the heavy lifting of a system is done in the backend, it would be interesting to have this part on an internal server.

In Hybrid architectures is key to ensure the heavy processes are run on the On-Prem servers. Otherwise, it defeats the purpose of a hybrid architecture.

But most importantly, the egress fees. Meaning the cost charged by a cloud provider for the data that leaves the cloud infrastructure. This is a key aspect for making the hybrid approach work.

If a user downloads a file from a web application, and even if that file is coming from the on-prem servers, if the file passes through the cloud to the user, the company would pay for egress fees. For being cost-efficient, that file should arrive at the user without using any cloud services. Otherwise, the system would defeat the purpose of cost optimization.

Making such an investment would require a detailed and careful financial and technical analysis to decide where to go.

Share

That’s it. If you find this post useful, please share it with your friends or colleagues who might be interested in this topic. If you would like to see a different angle, suggest it in the comments or send me a message.

Cheers,

Artur

I am Artur, and welcome to my weekly newsletter. I am focusing on topics like Project Management, Innovation, Leadership, and a bit of Entrepreneurship. I am always open to suggestions for new topics. Feel free to reach out to me and share my newsletter if it helps you in any way.

Projects, by their very essence, are temporary in nature, but their impacts can last for years.

Working actively on implementing transformative changes in corporations of all sizes, we start to learn and become aware of all types of resistance to our projects.

All project playbooks say we need strong governance, and it is very much true. However, there is so much more that playbooks are not telling us.

This article will give different examples of managing people’s perceptions and roles in the event of adversity brought by a project or a wave of change going through the organization.

It will also shed light on other risks that are sometimes not immediately seen during project execution.

Skillsets mismatch

When we set up a new team to handle a project, we are always mindful of casting errors.

It is very, very tricky to have recruitment be 100% on target when we need to set up a team of five people. It’s even trickier when we need to set up a new team of 10, 20, or 30.

On top of this, the company needs to adapt to a new reality. For some functions, it makes sense to reassign people who already work at the company to different roles based on the changes that are coming.

The issue starts to rise when people realise they are being assigned to roles that don’t match their skillsets.

In some cases, these changes happen outside your scope, and you might not have a say in those appointments.

It is not those people’s fault that they are being reassigned. Sometimes the decision is well-intentioned: it is better to re-assign existing staff than to fire the squad and hire new people.

Because the competence is not there, some can be very vocal in their opposition to the project or its goals.

The challenge here is those people will likely hide the true reasons for their posture. It is not easy to say out loud that your skillset is not aligned with the new role.

Especially to Management, where sharing a feedback like this might be perceived as incompetence. Instead, they raise concerns around the project’s pain points and weaknesses to rethink or even sabotage the strategy.

This is where Leadership experience plays a big role, because the signs are in the nuances of the arguments and how people expose the challenges.

When this happens, I like to show the opportunities the new reality will bring and how their work will be valued. I emphasize the advantages of having these new skillsets in the job market.

Of course, the reception of these arguments varies, but it is my go-to tactic. If this is not enough, I prefer to have individualized feedback in a more casual conversation to understand their fears and figure out tailored solutions for their concerns.

Being Difficult For The Sake Of Being Difficult

This is somewhat related to the previous point. However, because this is a complex subject, the real reason might vary.

Having a posture of constant combativeness and heavy resistance to execution strongly indicates the real reason is not the project itself, but something else. Be mindful, these situations happen even in projects and teams with a strong governance. A single opposing person outside the project team can cause damage.

That’s why it’s important to get to the root cause of the behavior, even if we need to dig deep.

I once had a case (let’s call him Marcelo) who had an issue with his management about his pay. Marcelo was a fierce opponent of everything we tried to put in place, even though he was outside the project structure.

I discovered the root cause almost by accident while talking with other managers. The truth was, Marcelo was clearly underpaid for his experience and responsibility.

Of course, we could say Marcelo should be more pragmatic and address this with HR or put his CV out there. However, for people with outdated skillsets, this is easier said than done.

In Marcelo’s case, it was not the first time he was re-assigned, but his salary was never updated to match his performance.

It was a tricky situation since he was not under my direct supervision, and I didn’t want to step on his leader’s toes. In a way, fixing this became one of my project tasks. Doing so I would turn him into an ally, or at least someone easier to handle.

Almost always, when there is a strong opposing voice against a project that is clearly beneficial, the root cause is located outside the initial arguments.

Protect The Stars

Experienced leaders make mistakes. New leaders even more.

When someone is appointed to a Leadership position, they sometimes lack the reality check of how things are actually managed. Having ideas is great, but sometimes reality bites, and some leaders might not recover.

Once I managed a project that changed some internal processes. One of the impacted teams had a recently promoted Team Leader (let’s call him João - ah ah try to pronounce this name out loud). João wanted to show value, and he tried really hard to make things happen. But when João started to fail, he had become a project risk.

On one occasion, “João” was struggling to keep up with the pace of the project. My project was approaching delivery, and his team was supposed to pick up the operational part.

I had already requested from Management the budget to recruit more people to handle the upcoming workload.

The new people were being onboarded, but João made an unfortunate decision to manage turnover by assigning newly recruited staff to old tasks instead of assigning exclusively to the new process. The consequence was clear. The moment the project went live, people were overwhelmed, drowning, clearly understaffed.

Because the project had high visibility, João needed to find justifications for why things weren’t working. He needed to put the blame somewhere, instead of himself.

In the midst of the confusion, there was a newly recruited Engineer (let’s call him Carlos) who was handling things very nicely. Well above expectations. Rapidly, it became noticeable that the new Team Leader felt threatened by this “Star” recruitment.

Suddenly, Carlos was being cut off from meetings and reassigned to tasks outside the product. João was spreading news that Carlos was taking too much initiative and “should only do what he was told”.

I needed to prepare a very careful and subtle campaign in defense of the Star Engineer.

In management meetings, I praised how Carlos was onboarded. I even played a card of asking the Department Manager (João’s boss) how they managed to find such a good professional.

By spreading good feedback in the corridors with key decision-makers, it became impossible for João to “burn” his own Star Engineer. I protected a key element who helped the entire initiative succeed, even against the sabotage of his own Team Leader.

Adversity To Change Is Complex

As you can see, Nay Sayers can come from anywhere. It is a situation that the handling must be tailored to the specific context.

Experience is key and sometimes we need to be the “invisible hand” to push things in the right direction.

Rarely do we have a solution that fits all, but it is important that we at least try. That is how we build the experience to handle these situations in the first place.

Some questions to ask yourself while handling Nay Sayers:

1. Is the resistance coming from technical or personal reasons?

2. Is the person threatened by the changes or just overwhelmed?

3. Is someone saying a lot of “corporate talk” or have practical reasons?

4. Are the arguments valid or are insecurities in disguise?

Share

That’s it. If you find this post useful, please share it with your friends or colleagues who might be interested in this topic. If you would like to see a different angle, suggest it in the comments or send me a message.

Cheers,

Artur

I am Artur, and welcome to my weekly newsletter. I am focusing on topics like Project Management, Innovation, Leadership, and a bit of Entrepreneurship. I am always open to suggestions for new topics. Feel free to reach out to me and share my newsletter if it helps you in any way.

Remote teams require a different approach to management. If a remote team is working in a nearshore or offshore environment, the company typically has structures in place to ensure better follow-up on projects and team members. However, if the team is fully remote, the challenge increases a hundredfold. This isn’t necessarily due to project complexity, but because people management is significantly harder if (and only if) we onboard the wrong staff. Spotting the hints and signs that action is needed is key. However, gathering this information accurately is far from trivial.

I previously wrote an article about a case of bad recruitment that took too long to correct (Link below). However, there are more signs to take into account.

Why Remote Teams?

Remote teams are usually established for one of two reasons: Cost-effectiveness or Quality of Labor.

If a company decides to go “remote-first”, it can access budget-friendly staff more easily. For example, we are currently seeing a trend of Central European companies allocating headcounts to staff based in Eastern Europe. In these cases, it might be difficult to bring ten people under one roof or send leadership to a nearshore country. But without that flexibility, what was intended as a cost-cutting measure can become more expensive over time due to bad dynamics, unpleasant surprises, and poor communication, leading to delays and budget overruns.

If the target is the quality of labor, the risk is mitigated. Nevertheless, “bad apples” always seem to appear, especially in newly formed teams. Having the flexibility to put everyone under the same roof is vital and should be accommodated in annual budget exercises.

Having the Team On-Site - Fast

One key aspect of managing a remote team is ensuring the group works under the same roof for at least a few days. Establishing team dynamics is much easier in an office environment than in a remote context.

Some professionals truly thrive in a remote setting, and we barely feel the need to work side-by-side with them. This is mostly because these individuals take ownership and show the initiative to make things happen. They communicate well and in a timely manner. However, these professionals are not the majority. Other team members may struggle with issues that aren’t communicated to leadership until it is too late.

Having the team on-site for at least three days helps spot “rocks” in the team dynamics and eases the burden for those struggling with specific project aspects. One thing that truly bothers me is the resistance some professionals show toward coming to the office for a couple of days (even when they are clearly struggling). These cases are common, and they prove that some people are simply not ready to work in a remote context at all.

Faked Online Status

The most common trick to spot is the faking of “online” status by future “to-be-laid-offs”. The first sign is when leadership notices project components are late, and the excuses vary. Because projects are complex, it is often tricky to draw the line between “being comprehensive” and “this person is throwing sand in my eyes”.

When things fall behind, we start chatting with the person about status updates. This is when we notice the replies are taking a long time to come. Again, this might be because they are concentrated, or simply because they aren’t there. If it becomes a pattern where someone takes hours to reply despite their status being “green” or “available”, there is likely a trick involved. This practice is not uncommon, a link to a story here.

These issues are exacerbated because good leadership always gives the benefit of the doubt. Delays can be the result of poor estimation, unforeseen complexity, or unexpected events—all of which require support. However, these are the same excuses used when someone is faking it from home. If someone is late on deliveries and constantly takes more than 45 minutes to reply to a chat message, they are likely faking their status.

Another concern is how these fake statuses are achieved. Some companies have policies in place in Software to avoid having too much time set up to “away” status. This means the faking could be achieved by rogue software that is installed on the corporate laptop, which might not fulfill the basic IT security practices.

Be Attentive to Tricks — Especially from the “Office-Resistant”

When hybrid models were first introduced, I fought an uphill battle between people who wanted to work from home 100% and the institution that wanted people in the office a few days a week. It wasn’t pleasant. I had people with “pitchforks” protesting the return while management instructed me to coordinate office days.

During this time, I had a complex case (let’s call her Anna). She had developed a mild case of mysophobia (fear of germs due to the pandemic), combined with allergies she claimed were worsened by the air conditioning. This was a time when people were filing medical papers left, right, and center to justify staying home. Reality was hitting: working from home wasn’t a guaranteed 100% deal, and people were using every trick to avoid that reality. We handled these cases carefully with HR and Legal to ensure no lines were crossed.

We accommodated Anna’s request for full remote work, even though we weren’t legally obliged to do so. The goal was to make people comfortable, and forcing them back didn’t feel like the right decision then.

The risk of accommodating these special requests is the way these exceptions are seen by the rest of the team. Not only do we need to accommodate the special situation, but we also need to prepare a justification that can be accepted by the team. Unfortunately, these justifications are not easily perceived by colleagues.

However, as feared, a new issue formed. As the rest of the team came to the office, Anna stayed home. Working dynamics formed among the people coming to the office, and unfortunately, Anna was being excluded. She struggled immensely to coordinate complex matters. When her performance fell short, and she was confronted, she fiercely argued that her absence from the office was unrelated to her performance, but her colleagues.

Noting that these conditions are not great for anyone. Both the team and Anna. Managing exceptions becomes a second level of management on the team, and can be harder to manage with other high-performance staff who also want to work from home under the same conditions.

Eventually, we “agreed” that Anna would come into the office at least one day a week. Her being “left out” by colleagues had transitioned from a social issue into a serious project risk. Anna was an expensive senior hire brought in to take the team to the next level, yet her progress was slower than that of junior profiles. She wasn’t grasping the subjects as quickly as her peers, and it rapidly became a management crisis.

Anna’s seniority created a weird situation for more junior profiles to work with. Having a Junior outperforming a Senior profile is great to watch. But also, it might trigger the will to review the rates of Juniors, since in their view their performance is better than the seniors’ in the team. While in practice, the seniors’ profile is underperforming.

The decision to let her go was on the table, especially due to costs. The good news is that she resigned on her own terms. The lesson: If people are too resistant to coming to the office, they may jeopardize project performance in favor of their own preferences. Whether it is our decision or theirs, the result is the same. We will eventually part ways. If these kinds of decisions are not made swiftly, we are left with a bill of thousands of euros in the form of bad performance and unfinished work. The faster these decisions are made, the cheaper these mistakes are.

Share

That’s it. If you find this post useful, please share it with your friends or colleagues who might be interested in this topic. If you would like to see a different angle, suggest it in the comments or send me a message.

Cheers,

Artur

I am Artur, and welcome to my weekly newsletter. I am focusing on topics like Project Management, Innovation, Leadership, and a bit of Entrepreneurship. I am always open to suggestions for new topics. Feel free to reach out to me and share my newsletter if it helps you in any way.

Working remotely, whether from home or an office in a different city than the client, brings a unique focus to how physical gatherings are conducted. The current landscape has made it possible for us to work with people for months on end without ever seeing them in person. This is a specific challenge of the post-pandemic era. When it works well, it is a great addition to the professional landscape, since projects move forward with happy staff and a competitive advantage in talent retention. However, when things are not going as expected, we need to pay special attention to the moments when the team is gathered under the same roof.

The Old Way Of Doing Things

When everyone was working in an office just a few meters away from the coffee machine, we could spot problems with team dynamics and interpersonal relationships within a matter of days. Information flowed differently (and sometimes chaotically), making it easy to see who was struggling and what the root causes were. We could casually discuss how people were addressing challenges and facilitate solutions for issues project members were facing. These discussions happened naturally over coffee, at lunch, or even while crossing paths in the corridors.

However, it wasn’t all sunshine and butterflies. It was harder to keep people focused on a single task when things were “popping up” left, right, and center. This was a particular issue for “star” team members, who were often seen as the fixers for everything. There is a reason people work better remotely: they are interrupted less. The office was often a curse for the people who magically made things work.

On a different note, it was easy to spot “casting errors”. We would know within the first week on the job if a person might not make it. Setting up project teams is one of the most critical parts of the job. If you have a budget for 5 FTEs and two of them are failures, nearly 50% of your project capacity suffers. We need to be swift, and it was much easier to spot these cases in the “old days”.

Why It Is Important to Meet Physically

When working remotely, we sometimes give people too much “forgiving space”. This is a consequence of trying to be fair to our colleagues (which is good, please continue doing so), but it can be easily exacerbated by casting errors that Leadership fails to notice. While results matter most in a remote environment, the trick is to act when those results sometimes fall below expectations. The benefit of the doubt is often given to people who don’t deserve it, and physical distance only makes things muddier.

In one of my own casting errors, I was struggling with the idea of letting someone go. The project was complex, which was my biggest argument for giving the person more time. The communication with the developer wasn’t great, but that is far from an isolated case in the IT world. It was only when results started arriving too late that I began pushing for the hard decision to let him go. The decision wasn’t final yet, as my colleagues were pushing to give “Alfredo” a second chance, until the day we brought everyone to the office to deliver a big milestone.

If anyone still had doubts, they were completely dissipated that week.

For Remote Teams, It Is Important to Meet Physically at Least Once

Remote work is not a “magic wand” for problem-solving or team culture. Not every employee is suited for (or should be granted) the responsibility of a fully remote role. The cost of a “bad hire” is significant, and identifying performance or cultural gaps is exponentially more difficult in a remote context.

Leadership often lacks visibility into remote team dynamics. We cannot (and should not) monitor every private chat to understand the nuances of internal communication. Success in a remote setting requires a high degree of professional maturity and autonomy. For new hires especially, it is critical to assess how they integrate with their peers before the big challenges arrive.

A proactive way to mitigate risk is to bring new hires into a physical office for a set period (for example one week) to work alongside their colleagues. During this time, leadership can observe interpersonal dynamics and identify “red flags” that remain hidden behind a screen. When project results fall short, the root causes are often behavioral rather than technical. Failing to spot these early leads to the kind of frustration we experienced with “Alfredo”.

In IT, one of the most overlooked aspects of team building is the “vibe check”. The fundamental assessment of whether peers can collaborate effectively. People can build great dynamics remotely, but it requires maturity that not everyone possesses. 

The Alfredo’s Story

The software was delivered with the joy of everyone, but the star of the day was another developer. Not Alfredo. However, on a certain afternoon, I got 2 people who wanted to see me in urgency. It seems Alfredo was playing video games on his phone in the middle of the office. I barely contain my laughter. I was getting reports of a 50ish guy playing on his phone like a f%&/ teenager. To give a context about this project, the team was working in different cities all over Europe, and it was reunited in the headquarters’ office for a big delivery. Since everyone was working remotely, it made sense for the big day to have everyone together. In some cases, it was the first time we were meeting some people physically.

This is not yet over. On the day we went live, a bug was reported later in the evening. It was not sufficient to do a rollback, but we needed Alfredo to spot what was missing because the software was working properly during tests. This was a clear case of a missing setup on PROD somewhere. It was not that critical for calling an all-nighter either, that’s why we agreed to see on the next day. The next day arrived, and by 8 am in the morning everyone was in the office. Except Alfredo. The guy arrived a few minutes after 9 am. He was literally the last guy to arrive at the office that day, while everyone was asking, “Where the F is Alfredo?”.

We can argue that I should be clearer to Alfredo to come to the office early the next day. Yes, is a valid argument. But the moment we need to babysit a grown man is when we probably are better off without that person.

The cherry on top to conclude this story is what happened on a Friday afternoon. See, we all traveled to the office for this big milestone. For Alfredo’s case, it was the first time he was in the city, so he had booked a hotel to stay for the weekend and be a tourist for a couple of days. No harm there. The ridiculous part came when Alfredo left the office at 15h in the afternoon. Well, an issue happened on PROD at 15h10… Which made me call him on the phone straight away. He was heading to the hotel to drop off bags, and he told me he would see the problem at the hotel. The issue is that Alfredo only reported back later in the night, while some of us were already on planes to go back home.

Remote Helps Masking Bad Apples

The reality is: Remote work is excellent for masking poor attitudes and throwing sand in Leadership’s eyes. That is why some leaders prefer to have everyone in the office, even if only for a few days a week. There is immense value in fully remote positions, but these roles should be given to people who can be trusted. Otherwise, it requires an exhausting amount of management and leads to hard decisions down the road.

While remote work offers a great competitive advantage, it still makes sense to have moments where the team meets physically. The sooner this happens, the better. It allows you to catch potential problems before they derail the project timeline.

Share

That’s it. If you find this post useful, please share it with your friends or colleagues who might be interested in this topic. If you would like to see a different angle, suggest it in the comments or send me a message.

Cheers,

Artur

I am Artur, and welcome to my weekly newsletter. I am focusing on topics like Project Management, Innovation, Leadership, and a bit of Entrepreneurship. I am always open to suggestions for new topics. Feel free to reach out to me and share my newsletter if it helps you in any way.

A major company-wide initiative is started, and almost every department assigns roles and responsibilities within its scope. A dedicated Project Lead is appointed, and before we know it, different department heads assign a dozen more people responsible for following up on parts of the same project. It is like having all hands on deck, but with an excess of management responsibilities and overlapping scopes. The fun starts when the first issue occurs, and meetings are scheduled with a series of managers and technical staff. Before we realize it, everyone is chipping in with opinions and “best moves forward”. The project leadership might seem obscure and all over the place.

Why All These Assignments?

Different people are assigned to lead various parts of the initiative or project, simply because major stakeholders want to have their own “eyes and ears” on the ground. Nobody openly expresses the real reason for these assignments. Instead, they mask them with different objectives to fulfill:

• To better coordinate resources within the department or team.

• To ease complexity by bringing in expertise that will greatly improve visibility.

• Person X has years of experience with this type of project and will help the team push the initiative forward.

The problem with these assignments is that they are not centrally decided. They are primarily defined by a series of higher and middle management across the company with one objective in mind: if the project fails, they need the right arguments to save their own “backyard” from the storm that will follow.

Understanding this is key, but in order to preserve our patience through endless conflicts, let’s prepare some guidelines on how to navigate these scenarios.

How To Navigate As The Informer

If you have been tasked to assist on a major project, congratulations! You are likely the “informer” for your management. You are probably also expected to follow this particular project on top of other initiatives already within your scope. Consequently, the chances that you are less than thrilled about this assignment are high. However, your role is viewed as vital, especially given the criticality of the assignment. Your main objective is to ensure the scope you are tasked with runs smoothly. Meaning no surprises, everything delivered with the expected quality, no cost overruns, and on time.

The best way to avoid surprises is to spot potential risks or issues as early as possible. However, attending a meeting simply to report that “Risk A” or “Risk B” is a potential liability is not enough. It is crucial to report these issues alongside mitigation actions. While these actions may be debated by the project team, the risks are at least identified and accounted for.

Check in with the team daily on execution, and pay particular attention if everything seems to be going too smoothly. Technical staff often avoid bringing bad news to management at all costs. That is why such news usually surfaces only when a task is days away from its deadline. Behind the scenes, ensure you account for buffers in the timeline and keep tabs on project meetings and the performance of other teams. Remember, the primary reason you were assigned to this project is to be the “eyes on the ground”. Gathering information is key to providing your management with the necessary visibility and safeguards when critical moments arise. The closer you are to the project leadership, the better your information and the quality of your insights.

How To Navigate As The Project Lead

Congratulations! You have a series of “spies” on your project, and execution is being monitored very closely by various stakeholders. Some of whom are not transparent about their intentions. This is a reality of corporate life. Everyone is simply doing their best to protect their scope and reputation.

The most important thing is not to take it as a personal attack every time an idea or action you propose is dismissed. Everyone is managing their own risks and ensuring that execution doesn’t blow up in their faces. My suggestion is to listen first to the ideas others are proposing and the reasoning behind them. Then, propose your own ideas and actions. Listening first ensures you possess the information beforehand, providing you with the right arguments against potential opposing views. However, in the end, what matters most is taking the best action forward. It doesn’t matter who proposed it. What matters is that the next step is the most effective one. You are simply better informed.

Your success is tightly linked to the success of the project. Be mindful and avoid micromanaging every aspect of it. In fact, make good use of all the “spies” the project structure has provided you. In theory, they are assigned to the project, so they are all working for you. Do not be wary of seeing too much initiative across the staff. Cultivating initiative is one of the most challenging aspects of leading complex projects. If this initiative is a given, simply navigate it. Stay close to those who are making proposals and tap into decisions you deem important. Influence those decisions. Influence is superior to authority. Navigating what people will do is far more effective than telling people what to do. Navigation implies the initiative comes from the individual, meaning they are trusted with a set of actions and feel their voice was heard. Conversely, authority implies that you have told them what they are supposed to do. Influence instead of giving orders.

The Unspoken Tax Of Project Follow-up

The meetings. All these overlaps in project follow-up (representing multiple views and interests) inevitably create a burden of meetings. It is critical to protect technical staff from meeting overload. For every minute an engineer spends in a meeting, the project loses a minute of progress. This has a direct impact on the timeline and is a cost frequently overlooked by less experienced management. To reduce this “tax”, I recommend establishing direct lines of communication with various stakeholders. I am a big fan of using dedicated MS Teams channels with relevant individuals to exchange information, or casually jumping on a quick call without the need to involve the engineers.

If formal meetings must be scheduled, a “Management Call” every two weeks is often sufficient. People tend to normalize weekly cadences, yet a bi-weekly frequency is enough to maintain alignment. However, be mindful that scheduled management calls do not replace the need for casual touchpoints with key stakeholders throughout the week. If you are in the office, schedule a coffee with these stakeholders to discuss ideas and progress. If you are working remotely, a simple message on Teams to share information can be just as effective.

Share

That’s it. If you find this post useful, please share it with your friends or colleagues who might be interested in this topic. If you would like to see a different angle, suggest it in the comments or send me a message.

Cheers,

Artur

I am Artur, and welcome to my weekly newsletter. I am focusing on topics like Project Management, Innovation, Leadership, and a bit of Entrepreneurship. I am always open to suggestions for new topics. Feel free to reach out to me and share my newsletter if it helps you in any way.

It was a summer afternoon, and my Teams was blinking with endless conversations around a project. One of those particular threads was an exchange between two members of management sharing feedback, which rapidly escalated into a conflict. One party was providing updates on recent progress for a vital company initiative, while the other was raising alerts about potential issues that could jeopardize it. Before anyone realized what was happening, a phrase was typed into the chat: “Are you the one managing the team?” followed soon by, “Check with your manager before checking with me.” Well, that escalated quickly.

Pulling Rank Is a Sign of Weak Leadership

People make mistakes all the time, and sometimes emotions get the better of us. When people are emotionally invested in a project, and progress is not meeting expectations, tensions may rise, and people might end up saying things they regret.

For a leader, having little control over their emotional intelligence is detrimental to the team and the project. Having a hard time finding good arguments against opposing views is more common than people might think. That’s why the exchange of ideas should be encouraged to find the best path forward. When a discussion ends abruptly with an “I am the one in charge” stance, it is more often than not a sign of weak leadership. Doing that too often will deteriorate stakeholder engagement. Or worse, discourage people from providing honest feedback or alerts due to fear of repercussions.

A leader should always maintain healthy information flows from different parts of the company and ongoing projects. The better the information is, the more solid the decisions can be. Pulling rank sends the wrong messages:

• The person doesn’t need feedback or help

• Opposing views are not valued, or instructions are being passed down the chain of command without a clear view of the goal.

Regardless of the case, engagement will soon be affected, and significant issues may occur with little to no prior notice. It’s like someone warning there is a chance that a certain meteorite is heading our way, only for the leader to dismiss it by saying they know better. When the meteorite is about to hit the project, part of the team has already checked out or has an escape plan in progress, being the leader the only one surprised by something that could have been prevented weeks ago.

Emotional Intelligence Is Key

If someone is working on a complex project, one thing is certain: things will go wrong. There is no human way to prevent or predict every instance of undesirable events from happening. What is under our control is how we react to those undesirable situations. Better emotional control tends to lead to clearer, more informed decisions. Of course, this is easier said than done, but it is important to highlight that managing our emotions (and our reactions) plays a massive role in how bad events are handled by everyone involved.

Leaders are expected to guide teams through tough situations. If a leader appears desperate or overly emotional, the team may have a hard time following their lead due to a perceived lack of authority or competence. In complex situations, having the team truly “on board” to navigate out of a storm makes the path much smoother than a team simply forcing itself into action and reacting blindly to what is happening.

In Case of Doubt, Play Cool

If you are working in an unstable environment and someone pulls rank or dismisses an initiative, the first step is to avoid reacting to provocations. At least until you understand what is actually happening. Gathering more information is vital to drawing a clear picture of the situation. Believe me when I say that staying “cool” during turbulence is perceived as a sign of strength. In the example I shared earlier, it was important to understand why people were behaving that way before the situation escalated further.

No C-level executive wants a leader in their organization who reacts emotionally to negative events. The leader who stays calm and articulates their point of view is the one who gains the most trust and influence over decisions. Remember, some leaders might actually be in a “testing period” before they fully settle into their roles. A lot may be going on behind the scenes. Therefore, it is key to read the environment and ensure information flows healthily, providing high-quality insights to those who need them.

Share

That’s it. If you find this post useful, please share it with your friends or colleagues who might be interested in this topic. If you would like to see a different angle, suggest it in the comments or send me a message.

Cheers,

Artur

I am Artur, and welcome to my weekly newsletter. I am focusing on topics like Project Management, Innovation, Leadership, and a bit of Entrepreneurship. I am always open to suggestions for new topics. Feel free to reach out to me and share my newsletter if it helps you in any way.

While managing professional services (such as consultants, freelancers, or software providers), you will eventually be asked to provide feedback on the services rendered. Sometimes, that feedback is straightforward: “It has been great” or “It is not meeting expectations.”

However, the most challenging part is the “in-between” feedback. It becomes tricky when you don’t have a clear-cut answer, or worse, when you find yourself terminating a contract months after providing positive reviews. This lack of clarity can be damaging down the road. Even as a paying client, it is important to remember that no vendor wants to navigate a partnership with little visibility or stability beyond the invoices they generate.

It’s OK Not Having Clear Feedback Sometimes

Let’s get this straight right off the bat: Depending on the project, some objectives take months to take shape. If you are asked for feedback too early in the process, it is perfectly fine not to have a definitive “status quo”. For example, it is common to have major milestones set six months out, yet be asked for feedback halfway through. If you are results-oriented, you might look at intermediate milestones, but the problem is that they rarely provide a bulletproof picture. They offer a potential assurance of a future result; the milestone might be hit, but failure isn’t off the table yet.

Some time ago, on a very complex project, my team was asked for feedback on a vendor’s service. The request came three months in, but the product wasn’t in production yet. We needed another month or two to provide anything solid. In this case, we informed the vendor that our initial feedback was “good with remarks”, but that we would reassess in a couple of months. Having remarks isn’t a sign of bad feedback (even five-star services have room for improvement). The key here is to prioritize achieving the goal first and foremost. Once the objective is met, you finally have the solid data needed to provide a truly meaningful evaluation.

What Reality Shows Us

Unfortunately, what I often see in these cases is project teams sharing a “snapshot” of feedback based on a single moment in time. Then, when the milestone finally arrives, it highlights massive points for improvement that can potentially lead to contract termination. I am not a fan of surprises. I always advocate for visibility and clarity, even in situations that could go either way. It is damaging to the client-vendor relationship when a vendor is blindsided by a termination (whether it’s the entire project or a single consultant in the outsourcing world). Especially if they received positive feedback just a few weeks prior. As clients, we should strive for genuine partnerships and be mindful of our vendors’ financial impact and risk calculations.

The clearest examples of this occur in the outsourcing world. Imagine your team is onboarding one person who is expected to deliver the first patch of meaningful software in five months’ time (meaning: code used by real humans in Production). If we provide positive feedback from months one through five, only to realize in months six and seven that the software barely fulfills the objective due to serious performance and quality issues, using that as the trigger to let the consultant go, is simply poor people and vendor management.

The Focus Are The Results. Always.

When we don’t yet have tangible results, our approach must remain cautious. Even when the energy is high, communication is flowing, and things appear to be rolling along nicely. Results are what matter most. Sometimes, it is only when the final deliverables are due that a vendor’s hidden issues finally come to light.

Remaining cautious and keeping your eyes on the goal sends a clear message: your project is not managed on BS, but on hard, real, and tangible results. If those results arrive on time and at the right level of quality, everyone wins. Otherwise, you need to have a direct conversation about those gaps with the vendor.

Share

That’s it. If you find this post useful, please share it with your friends or colleagues who might be interested in this topic. If you would like to see a different angle, suggest it in the comments or send me a message.

Cheers,

Artur

I am Artur, and welcome to my weekly newsletter. I am focusing on topics like Project Management, Innovation, Leadership, and a bit of Entrepreneurship. I am always open to suggestions for new topics. Feel free to reach out to me and share my newsletter if it helps you in any way.

Managing conflicts is one of the major parts of the job. These conflicts could be from different sources and contexts, especially with different people in the command chain. One of the most dangerous conflicts to have is with the C-level, due to their incredible decision-making power and mandates. There are multiple types of C-levels: it could be a CEO, CFO, or a CTO, but what matters is if the person is seated on the administration board of the company (it’s the subtext behind the “C” part of their job title).

Having a conflict with a C-Level staff member is no joke, and a significant degree of experience and emotional intelligence is required. Therefore, I will just highlight some strategies and words on how to navigate these conflicts from a better position.

They Are Humans With A Significant Amount Of Pressure

Let’s start with the obvious. Not all people who rise to a C-Level position are star leaders, or got there with a significant amount of grit and knowledge. However, since these positions are very results-oriented, the amount of pressure these positions hold is no joke. As imperfect human beings that we all are, the reactions and strategies vary widely from person to person.

For example, some C-level persons are very political, and they attach themselves to an image of proximity with the base of the company, feeding an image of a “Leader who listens”, while behind closed doors, they don’t like to have their ideas challenged. Other C-level managers like to build an image of strength and can even become intimidating for the base of the company. However, they can be very pragmatic and receptive to new forms of doing things. For others, we secretly don’t even understand how they manage to land the job in the first place, since they offer zero added value, and are simply managing without any vision or strategy.

What is important is to try to understand the personality behind the position and how open they are to new ideas. Also, get a grip on how they react if you don’t agree with them, and what their main concerns and ambitions are. This is key for understanding how to navigate the relationship, with conflicts or without conflicts.

Be Careful With Old Wolves

There are C-level staff from different backgrounds, and notably, for IT, the department might be under the scope of someone who doesn’t have an IT degree. Not every company is a technological company that needs a leader with a strong technological background.

From another angle, there are some C-level staff in their 30s who managed to rise through the ranks, but it is most common to witness people with decades of professional experience in this kind of position. Therefore, they have seen a lot and probably were managing companies already, while some of us were still finishing university. So we need to be aware of the delta in experience and how politically savvy they can be. In other words, they can say one thing to an audience, and an hour later, say the opposite to a different audience. Some of these staff have been playing the game for decades, and they play it very well.

For example, I had a situation where we stressed how poorly a project was being run by one of our providers, and we got a meeting with the CEO. He was very astute commercially, and he said all the nice things we wanted to hear, some of which, to the detriment of his own team. This is where some red flags popped up in my head. He knew how to navigate a difficult conversation, and he chose the arguments and the positions very wisely. His goal wasn’t to fix the problem. His goal was to buy time. Therefore, he was saying all the right things, and he shifted the conversation in a direction for us to understand the learning curve his team was tackling (which, in practice, shows they weren’t the right people for the job). Everyone in the room was pleased with his speech, except me, who needed the deliveries to be on time, and I just got excuses instead. But kudos for his political expertise, it was impressive to watch.

Be Ready To Play The “Behind The Scenes” Game

The power of influence is one of the most overlooked aspects of leadership. Leadership positions are seen as executive decision-making, but their reach and easy access to other decision-making staff are largely overlooked. The power of influence is hugely important, and even more so in the “Behind The Scenes” game.

A lot might be discussed behind closed doors, and instructions are being given to the people on the company’s base. Having access to these flows of communication is important, as is access to key decision-makers.

There is a lot of information that isn’t shared, and therefore, some decisions might come across as weird (at the very least). So parallel conversations might be happening before the big meeting even happens, and we all know that a successful decision-making meeting is based on how much preparation work is put in before it even starts. Avoiding surprises is paramount, and the more people are aligned towards a decision before the meeting starts, the better.

This is where influencing decisions is important. It requires having access to the right information and knowing how to display it to convey a message. A well-structured idea is difficult to beat. A well-structured idea, discussed beforehand with multiple decision-makers and incorporating their feedback, is unbeatable. This means, if there is a particular C-Level staff member that would be against a certain idea, it is important for him or her to be aware, and have his or her views and inputs somewhere in the solution. Avoid the surprise altogether. Of course, this is easier said than done, but the “behind the scenes” games with multiple sources will help you find allies to push the idea forward, while avoiding a “headfirst” confrontation that will benefit no one (Especially the ones lower in the chain of command).

Share

That’s it. If you find this post useful, please share it with your friends or colleagues who might be interested in this topic. If you would like to see a different angle, suggest it in the comments or send me a message.

Cheers,

Artur

I am Artur, and welcome to my weekly newsletter. I am focusing on topics like Project Management, Innovation, Leadership, and a bit of Entrepreneurship. I am always open to suggestions for new topics. Feel free to reach out to me and share my newsletter if it helps you in any way.

Impostor syndrome is real, and it gets to every one of us. Especially if we keep adding changes to our lives that push us to new heights. I strongly believe there are two side effects to ambition: One is perceived arrogance by others and impostor syndrome. One is an externalized effect, while the latter is a constant conversation in one’s mind. If someone is ambitious and tries to find new ways of achieving goals, eventually, given enough persistence, he or she will be successful. With success comes the pragmatism of knowing what is working and what is not. Therefore, the person could strongly cut through the noise and philosophies of how to accomplish those goals. This posture might be perceived as arrogance by others who didn’t achieve the same goals.

Impostor syndrome is a conversation inside our heads, which is a reflection of the fear of failing. It is the construction in the mind that we don’t have what it takes, and we are very keen to identify the gaps in our skills and mindsets to achieve a certain goal. What is interesting about this syndrome is that it’s a great self-analysis tool to understand which parts of us need work, and with constructive thoughts, we can even define a plan of improvement. This article will cover how I personally manage my own impostor syndrome in the hopes that it helps you in any way to manage it better.

Some Things Inevitably Will Go Wrong

If you thought this article would be all rainbows and unicorns, well, nope. If we are trying to achieve something challenging, it is impossible that every single step will go as planned. Reality is cruel, and it will hit us in the face. The mindset here is accepting and knowing in advance that some things will go wrong and trying to maintain peace of mind. That peace of mind is important to figure out other ways to navigate the issues that are occurring, and accept it as a normal modus operandi.

Even when following a detailed recipe in the kitchen for preparing a glamorous dinner, there will be some steps that will fail. Maybe you don’t have enough cheese (criminal! ), maybe the brand of an ingredient that you are using creates a different texture. The main message here: Our plans will not go 100% according to expectations, and we need to acknowledge it and create a mindset of navigating through the problems.

I am a very “gather feedback” type of guy. If I am preparing some sort of plan, I try to have the input of colleagues before I present it to a wider audience. This methodology allows me to get ideas and inputs on what can go wrong, and have a small brainstorming on how to mitigate or address some events. Which means, I know who to consult and exchange ideas with when the bad stuff happens. Because it will happen. It’s a matter of time.

But simply accepting that things will go wrong is only half the battle. We also have to learn how to emotionally handle it when they do. This is where I start the philosophical section of the article...

This Part Will Be A Bit Philosophical, But Hear Me Out

We are the sum of our experiences. One thing I learned in the past decade is about some philosophies around Stoicism and Karma Yoga. While Stoicism revolves around the ability to improve emotional intelligence, I think for this topic, I can share with you some words regarding Karma Yoga. Without entering the rabbit hole about what Karma Yoga is, I will just highlight a general misconception. Karma is not like the sum of our good vs bad deeds, in an effort to maintain a positive balance, as if it were a bank. The concept of Karma Yoga centers around the detachment from the ownership of the results of our actions.

Let’s go through an example. If you want to cook a fancy dinner, an idea would be to search on YouTube for a fancy dish that you would prepare and cook. Once the dinner is served, is the result of the cooking owned by you? Well, the answer is no. You own the effort put into that dinner, however, the end result is not owned by you. The result is the consequence of multiple variables that contributed to that result. It also includes the contributions of the chef who created the YouTube video, who he or she was influenced by someone else who created the recipe, and even the recipe itself was influenced by many other people. This is a mindset shift, first and foremost, that detaches us from owning the results of the actions (good or bad). Which comes quite handy for handling imposter syndrome.

One of the key aspects related to Karma Yoga is that we should put all our intentions and give our best in all our actions. This, in practice, is asking us to do our best and detach from the result of those actions. So, if we are doing a task and for some reason the result is below expectations, we should be mindful that we gave our best. This creates a detachment within ourselves and helps with a better emotional intelligence while analyzing events or tasks that didn’t produce the desired outcomes. Therefore, it allows us to be more analytical and factual in addressing situations, without having the fear of whether we are good enough or not.

Challenges Improve Self-Awareness

Once we get more experienced and start to win some important projects and achievements overall, we start to get a track record of hands-on experience. With that, we are in a key position to analyse each context and determine which aspects of ourselves helped and which aspects we would need to improve to produce better outcomes. This helps build self-awareness of the aspects we are good at and others that we are lacking and need improvement.

When something goes terribly wrong, this self-awareness is a baseline to understand how we could improve and compare ourselves with different situations in our past. Let’s imagine a football coach who won several Champions League titles across different countries (let’s imagine, Jose Mourinho). He is, factually, one of the best coaches of all time in the history of football. However, if he failed miserably at a club, he has the experience to make a retrospective and analyse what went wrong this time. Maybe he was overconfident? Maybe he lacked the motivation of his previous successes? Maybe he didn’t address situations in the best fashion?

The result is less about us feeling like impostors and more about having a factual analysis in our heads and understanding that past successes show us that we can do it, changing the focus to trying to understand what could have been done differently. Overall, the strategy is to move away from the impostor talking inside our heads and have a constructive conversation around what could have been done differently.

My philosophy is that the feeling of being an impostor is a sign that you’re ambitious. You’re pushing yourself into new territory. My strategy is to focus on the work itself and accept that failures are an inevitable part of any challenging project, which needs to be overcome with facts and intelligence.

Share

That’s it. If you find this post useful, please share it with your friends or colleagues who might be interested in this topic. If you would like to see a different angle, suggest it in the comments or send me a message.

Cheers,

Artur

I am Artur, and welcome to my weekly newsletter. I am focusing on topics like Project Management, Innovation, Leadership, and a bit of Entrepreneurship. I am always open to suggestions for new topics. Feel free to reach out to me and share my newsletter if it helps you in any way.

One of the trademarks of Leadership is communication, and even for technical roles, sometimes we get Tech Leads with very poor skills in handling subjects with Business stakeholders. These Tech Leads slip through the cracks, especially on newly assembled teams to deliver a project where it is important to define a structure from day 1.

When I am involved, I try to delay the decision of nominating a Tech Lead as much as possible, to give the different Senior Developers a chance to prove themselves and give me time to make a good decision. However, sometimes I don’t have the luxury of waiting, and the project demands a clear hierarchy and structure for the development team. This is when mistakes can happen.

Even Senior Developers Struggle To Address Non-IT Staff

There are, of course, some exceptions. When managing ERP, CRM, or RPA consultants (or any other form of developers who have a very functional aspect to the role), these profiles tend to be good at handling the Business Stakeholders. The wanna-be senior consultant assigns the same attention to building the skills to handle non-IT stakeholders, as well as to their technical skills. When it comes to C#, Java, PHP, or other types of developers, there is a significant portion of the population that is not even interested in the matter.

The result is that we end up having Senior Developers with decades worth of experience, but we cringe every time they open their mouths in a meeting with Business stakeholders. The root cause is that they weren’t exposed and coached long enough to train this part of the job. This is the result of years and years of hiding developers behind their laptops and having other people do the talking.

Smooth The Exposure

When I have a project of a short duration, and I notice the Tech Lead has challenges communicating with non-IT stakeholders, I typically cover for him. I try to understand the technical issues or constraints behind them and try to translate those to non-IT personnel. However, this is a quick fix at the cost of postponing a problem to be solved in the future. This is a calculated measure because projects might have tight constraints, and we only have time to execute. When the project is delivered, we can “flip the chip” and focus on improving some communication aspects for the maintenance part of the product.

Developers should be exposed and coached on how to navigate and expose technical issues. They need the help of their manager, but they also need hands-on experience. In a previous team, I had prepared PowerPoint templates so the Developers could present some components of the project themselves. In the beginning, some developers struggled a bit, and we needed to prepare practice runs before meeting the Business stakeholders. However, one year after the fact, those developers had immensely improved their interactions with the Business, and they were much more confident in communication in general.

The Gain Is Priceless

Having a Developer (not necessarily the Tech Lead, I mean, any developer) with the ability to understand an opposing view, see beyond the technical aspect, and offer solutions that might not even require a code change, is phenomenal. Some might argue this should be the job of the project or product manager. However, in today’s IT landscape, the team should be able to propose solutions, and many developers’ solutions are too far from the overall picture in brainstorming sessions.

When we look closer at very good technical teams, one commonality is clearly seen: They have a good working relationship with their business counterparts, and they collaborate to work towards fixing their problems.

I once witnessed a Developer who himself presented a solution for a complex problem, where the business analyst, the client, and everyone else weren’t even close to solve. The Developer at the time was more of an expert on the subject matter than his colleagues working on the project. His solutions were spot on, addressing the complaints from the business with clean, straight-to-the-point technical solutions. Given the conditions, the developers can become the experts that nobody else in the project can even dream to reach.

Share

That’s it. If you find this post useful, please share it with your friends or colleagues who might be interested in this topic. If you would like to see a different angle, suggest it in the comments or send me a message.

Cheers,

Artur

I am Artur, and welcome to my weekly newsletter. I am focusing on topics like Project Management, Innovation, Leadership, and a bit of Entrepreneurship. I am always open to suggestions for new topics. Feel free to reach out to me and share my newsletter if it helps you in any way.

Some time ago, I witnessed a newly appointed team leader make a few mistakes, which triggered the idea for this post. For any rookie, making mistakes is a natural part of the learning process. Leading a team is an ambition many hold for years, and when it materializes, the reality can present difficult contradictions and expectations to manage.

The goal of this article is to explore some common errors that new Leaders might fall into. If you are an experienced leader reading this, feel free to comment with other common mistakes new Leaders make. I am a strong believer that Leadership is a skill that is learned and evolves through hands-on experience, and it is important to be prepared for what is to come.

Power Is An Illusion

In the corporate world, the one true source of decision-making is the person who pays for the project. Everyone else’s authority is delegated through chains of command and aligned with the expectations of the one paying the bills. New Leaders often have the illusion that when they are promoted to “Team Leader”, they can make a lot of changes and will have the last say in any matter. Wrong.

When I was first promoted, I was under the illusion that I was finally in a position to fix things and bring order to the team. I soon started to notice that my management was becoming afraid of me (lol). I was the subject matter expert, and I only got the lead position because they feared the application would suffer if I left the company. In practice, I learned to align myself with my peers and, most importantly, with my upper management. No one wants a Leader going rogue. In fact, I quickly realized I didn’t have much power to begin with. I was just another cog in the machine.

Yes, it’s great to have ideas and the ambition to improve things, and a promotion is just a step closer to implementing that vision. However, until the right level of authority is delegated to them, newly appointed leaders have little say in most matters. They might even be in a “trial period”.

Too Strong a Position On A Matter

Good leader material, wants to protect his or her team and ensure everyone has the best conditions to perform their work. However, it’s highly important not to make too many strong positions early in the career. The typical case is when a colleague is underperforming and the Leader is providing arguments to avoid the inevitable.

Playing the political game is a combination of having the right information and presenting the right arguments. The issue with newly appointed Leaders is that they typically don’t have all the information, and they will learn that some arguments don’t matter at all.

Making too strong a position, and coming out with weak arguments and seeing them dismantled with 2 phrases, it shows the Leader is green. In the example above, if you want to protect that colleague, go ahead, present your arguments. But make sure you don’t get dirt on you. Don’t let it become personal. It is more important to have the right information. I have seen cases where arguments are destroyed because the new Leader wasn’t aware of major episodes related to a story. Go with caution, and try to get the complete picture before setting a strong position on a weak foundation.

Pick Your Battles

You can’t win every fight. When you first step into a leadership position, you’ll start to navigate political waters. It’s important to save your energy for the topics that truly matter and let go of those that have little impact. Many years ago, I worked with someone (let’s call her Marta) who had a naturally confrontational personality. She would fiercely defend her position on anything that didn’t align with her expectations.

Marta could have become a strong leader if she had survived the first few months. Unfortunately, she wasn’t experienced enough and chose the wrong battles to fight. The consequence was a string of conflicts with peers, clients, and even her own management. For some reason, Marta seemed proud of challenging people left and right, until she was “demoted” (aka moved to another team to produce less damage), and eventually fired.

There will always be a bigger fish. Some battles cause friction and can create long-lasting animosity between people. Some of those people might not react in the moment, but they will never forget. Because some leaders play the political game better than others, they only had to wait for the right time and the right battle to push Marta out, along with all the trouble she had created. Of course, this is an extreme scenario. The key takeaway is that you can’t win every battle, and each conflict can have unintended outcomes. With experience, you’ll learn to navigate these situations and mitigate the fallout.

Communicate Smartly

This is an especially important topic for me, as I’ve always had an informal approach to leadership. Once you get promoted, you need to pay close attention to how you say things, especially when reporting problems. You might still be close with your team in the trenches, but your real value comes from how you report on the project’s progress to stakeholders. You should always work to improve the way you communicate, no matter your position.

I’ve seen many new leaders adopt different communication styles. Some want to present themselves as politically savvy, while others try to be informal and easy-going. But if someone is investing 2 million euros in a project, they don’t want an egotistical leader or a “cool guy” managing their money. They want someone smart. Be that person.

Your use of language is the first indicator of intelligence that others will notice, so choose your words carefully to fit the situation. When you’re handling a problem, it’s crucial to communicate calmly and factually. If a leader lets too much emotion seep into their communication, they’re no different from a foot soldier in the trenches. It’s important to gather the facts, see the whole picture, and present solutions instead of showing up empty-handed with a problem.

Don’t Take It Personally

When you’re starting out, you will make mistakes. Everyone does. Impostor syndrome is a very real thing, even for experienced leaders. I’ve often been given projects where I thought, “This is too big for me to handle.” I’m glad and lucky to say that I’ve won far more battles than I’ve lost.

In the beginning, when something doesn’t go your way, you might think it’s your fault or that someone is attacking you. It’s not. It’s important to detach yourself from the role you’re performing. There’s a difference between the Artur who goes to boardgame events and the Artur who has to annoy everyone about their tasks. In my job, I’m performing a role and ensuring everything stays on track. Inevitably, I’ll create discomfort, and people will become less than excited to see me. But that’s my role. It’s not personal.

With experience, as you build your own leadership style, you will learn to manage these situations and distance yourself emotionally. If someone is angry because application X isn’t performing due to Y, and accuses you of being responsible, well, that’s their opinion (and they might be wrong). If they are right, it’s important to learn from it and move on. Most likely, they are attacking the role, not the person. But in the event that they are attacking you personally, it only reveals how small-minded they are. Don’t mind them. Just do your job.

Share

That’s it. If you find this post useful, please share it with your friends or colleagues who might be interested in this topic. If you would like to see a different angle, suggest it in the comments or send me a message.

Cheers,

Artur