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.

One of the big effects of AI is its impact on the SaaS ecosystem.

Using AI as a means to leverage coding is creating an image that some solutions might be built in-house instead of being bought through a procurement process.

It doesn’t matter who is right or wrong. What matters is how we navigate this uncertainty, and how we pull the best strategy for our teams and solutions.

An important alert: We are all saying that AI is speeding up development.

However, this might not be true. A study conducted by METR in 2025 concluded that development was 19% slower, while developers had the perception that they were 20% faster.

However, METR revised the same study in 2026 without finding conclusive productivity gains yet.

The reason: AI is too fresh, too new, and people are still adapting to AI.

My advice: Hold off on deep structuring of the IT department (layoffs or starting to replace SaaS with massive in-house built solutions).

The SaaS Apocalypse

We are starting to read everywhere that SaaS will have a hard time because of AI.

Why do I need to buy your SaaS if I can build it in-house cheaper?

The reasoning behind the SaaS apocalypse makes sense. However, some companies might not have the IT structure to have multiple complex products built in-house.

It’s a valid management consideration.

However, I strongly advise being cautious when making these decisions.

It is not clear what are the impacts of AI are on the development process as of today. Making too many rushed decisions can cost the company strategic momentum.

Also, it is not clear how much development is being sped up with AI.

It is important to mention that code production is only one part of the complex challenge of building software: Stakeholder management, business requirements, and testing strategies are key pieces as well.

Agreeing on how to approach a problem, testing it, with a strategy that conveys to multiple stakeholders, is still a complex problem that AI barely scratches the surface of.

Code production is just one variable of many in Software Engineering.

The idea that AI can be leveraged to replace SaaS subscriptions is valid and should be analyzed. However, it is important not to take on a challenge too big to handle.

In the meantime, the SaaS ecosystem is indeed challenged by the possibility that many of its customers will replace its offer with in-house solutions. Or, their competitor leveraging AI could move faster than before, outpacing their current solutions with better features and overall products.

The uncertainty is high, and you (as client) should take advantage.

Negotiate Your SaaS First

Before moving in any direction, just assess how much your current vendor is offering. It is possible that the price might not change, and maybe you can get a more competitive offer.

Gaining time to see how AI will move next is your best option right now for a conservative approach.

If you have systems that you feel are too expensive for what you are paying, maybe it’s a good opportunity to evaluate the idea of launching an RFP process and maybe switching vendors.

For this last option, we should calculate the cost of such a project: How much CAPEX (investment is needed) and how much OPEX (operational costs) the vendor will be offering.

This provides a good overview of what the financial costs of switching vendors would be and the payback period of such a move.

An important consideration while negotiating your new price is also to adjust the timeframe.

What I call “Forever Systems”, which are systems that are core but don’t require any investment in innovation, make sense to have extended contracts (3 to 5 years).

However, for other systems, it would make sense to negotiate the terms for short periods (1-2 years).

The goal of these shorter periods is to assess how AI will impact the market, if there are different vendors with a more competitive offer.

Or if, in the meantime, the company gets the internal capability and conditions, it might be worth analyzing if the product can be built in-house.

Let’s Do It In-House?

While you are running numbers, maybe it is interesting to check internally how feasible it is to build the solution yourself.

However, be mindful:

• Do you have the internal development teams capable of producing the software at the required level?

• Do you need to recruit developers during the “Project Phase”?

• How many developers would you need to maintain the new system?

• What are the custom-built requirements you would like to have in an in-house solution?

• Where will the solution be hosted? Is the support and infrastructure team sized to maintain the new platform?

• Are there any extra licenses required to build and maintain the new system?

There are a lot of questions to be asked about the decision to build in-house.

Mostly, the goal is to answer these questions and transform the answers into a figure that you can calculate in a spreadsheet.

The greatest advantage of having an in-house product is that you are building your custom, tailor-made solution, which can greatly leverage the company’s added-value and better distinguish it from the competition.

However, is this new set of features worth the investment? Add a 10–15% delta to the financial figures to absorb any misfortunes.

These decisions need to be made pragmatically.

Overall, use the shadow of the SaaS apocalypse to your advantage as a client.

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

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.

We think AI coding assistants are helping our developers. In reality, they can potentially crush them under an unprecedented wave of cognitive overload.

In the “old school” way of doing things, one of the key ways to protect a team or an individual developer was to ensure they didn’t have to constantly jump from subject to subject unannounced.

For example, managers avoided giving a task to a developer in the morning only to ask them to switch to a different task just a few hours later.

Keeping things steady avoided mental overload, since context switching makes it much harder for a person to pick up an unfinished task later.

Cognitive Load Management

Cognitive load management is one of the key environmental factors I try to protect developers from.

Even if I assign multiple tasks to a developer, those tasks are ideally part of the same project, product, and context. The overload happens when a task forces the developer to switch contexts entirely.

I strongly believe that “vibe coding” (or vibe engineering) will become the norm in a few months or years. Developers will move away from being strictly a Java, C#, or [insert coding language here] developer. Instead become AI-driven developers.

We are heading toward a scenario where technologies are chosen less based on technical requirements and more on non-technical needs.

I understand this is a controversial statement.

However, the true winners in IT are the ones who build products that are actually used, not the ones with the fanciest features in a PowerPoint presentation.

In the near future, it will be normal for an AI-driven developer to work on multiple tasks at the same time. The main issue I want to raise is that those tasks might belong to entirely different projects or products. High cognitive load will become the norm in IT once again.

The Agents Do All The Work

Yes, it’s true. However, it is humans who must verify and validate the work these agents are doing.

Overseeing work across multiple different contexts is a skill traditionally expected of those in leadership positions, but it is very new to developers.

Context switching has always existed in Engineering Teams, but I fear AI will turn this into a serious issue in the near future.

The amount of mental energy required to validate and verify completely different subjects within a single day, at an accelerated pace, is something that is not being discussed.

AI is a new tool, and everyone is excited and playing with it like a new toy. However, this novelty will fade soon, and the enjoyment of seeing AI do a lot of the heavy lifting will start to wear off.

Simply because the heavy lifting will shift from producing code to reviewing and validating AI outputs. AI will not remove the pressure on IT development teams to deliver more features, faster. It will simply accelerate the processes around IT development.

Tomorrow, the new norm will be to deliver more and more features. The pressure to deliver won’t ease, and any buffer that AI generates will quickly vanish into the ether.

Developers will once again be loaded with different tasks, with the added aggravation of continuous context switching.

Cognitive WIP As New Metric

Development capacity might not be the only high-level metric management should use to assess internal IT delivery potential. Processes need to be adjusted to take cognitive load into account, ensuring we avoid mistakes and deliver high-quality work.

Kanban has the notion of “WIP” (Work in Progress) guardrails. It shows how the amount of work relates to the team’s actual size. Triggering a WIP alert means either the team is starting too much new work without closing previous topics, or there is a bottleneck somewhere in the process.

I would advise implementing “Cognitive WIP” metrics within teams to ensure developers don’t work on too many different topics at the same time.

Parallel work is not great for quality. Mistakes happen, and focusing on the task at hand will produce fewer errors, building confidence in both the product and the team’s output.

Switching between radically different, high-effort topics creates a level of fatigue that is difficult to explain.

To convince management, we need to be factual and use concrete metrics to show how trends in user confidence, production stability, and other relevant areas justify a cognitively safe environment for the team.

Developer's Cognitive WIP = [Sum of Project Complexity] / Number of Projects 

More Focus On The Process

AI is not a magic tool that automatically builds software products faster, better, and stronger. While it can indeed accelerate parts of the software creation process, the core constraints remain the same:

• Getting stakeholders to agree on a solution and a common strategy.

• Gathering a set of requirements that are validated by end users, or at least receiving some feedback on their validity.

• Following an implementation process (from wireframing and prototyping to building and releasing the product) while keeping constant feedback loops at every step of the way.

AI can facilitate code production to the point where prototyping is incredibly easy nowadays.

For example, a click-through prototype can be built within a few hours to gather user feedback at record speed.

This means the focus is shifting from the code generation itself to how well we execute the process of getting the right information from the right people.

Coding used to be a complex task that could take weeks, only for the business to realize later that they had made a mistake with the requirements.

Sometimes, pushing something through the pipeline was done simply because the business was running out of time to properly define requirements and gather feedback.

Now, building easier prototypes straight from wireframes (sometimes “developed” by the business stakeholders themselves without involving IT) is making these feedback loops much more productive.

AI helps with code production. It does not solve stakeholder alignment.

Oversight Is Now A Developer Skill

A developer is like a Master of Puppets now (imagine a Metallica track playing while reading this part).

Agents are doing the work, and the developer is evaluating and assessing the results of that work.

As mentioned earlier in the article, context switching might become a real issue if teams are pressured to deliver multiple projects across multiple business lines or products.

At the bare minimum, developers will need to improve on a skill that was typically linked to people in management: oversight.

This is the ability to gather information in various formats and act on or share information across multiple topics when requested.

This is not something people are born knowing how to do: It comes with territory and practice.

The challenge is no longer just reading code, but challenging the logic and finding the loopholes behind it.

It is about understanding the security implications and common mistakes AI makes, and finding architectural solutions to address them.

It requires constantly challenging outputs and assessing previous decisions to understand if execution needs to pivot to a different path.

Now imagine doing all this in several different contexts at the same time. The thread is real. The solution is to measure cognitive load.

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

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.

If you are leading an engineering team in 2026, you are likely handling a fascinating transformation.

In the pre-agentic era, the primary bottleneck in software engineering was code generation. Developers spent their energy writing code, translating logic into files, and trying to respect the team’s guidelines.

Today, AI agents have reduced the cost of creating code to almost a free experience.

But in doing so, we are watching a profound and historical transformation of the IT landscape. Especially on how we are building our new systems.

Technology No Longer Matters

Being an expert in a specific technology, writing code, migrating legacy systems, or writing simple unit tests are quickly becoming skills of the past.

Instead, the premium engineering skills of 2026 have shifted toward three core competencies:

• System Architecture: The ability to design clean, highly decoupled boundaries between modules. Having a good starting architecture is now the primary prerequisite for AI leverage.

• Context Engineering: The discipline of indexing and mapping the codebase so that AI agents have the exact, high-quality context they need.

• Vibe Coding: Conversing naturally with our favorite agents is fast becoming the new standard for how we produce software.

Naturally, hardcore technical leaders complain about this shift toward vibe coding.

They argue that developers are losing agency over their own code, that repositories are being flooded with legacy debt, and that these systems are becoming incredibly difficult for a human to debug or maintain.

They are entirely right!

However, for the vast majority of business applications, vibe coding is proving to be more than enough.

High code quality was historically a human prerequisite to keep a codebase maintainable by other humans. It is not a machine prerequisite.

This is a monumental paradigm shift, and our mindset needs to adapt rapidly.

Juniors Don’t Need To Learn Code Anymore

This brings us to the biggest discussion point in modern engineering teams: how to properly train and onboard junior profiles.

Traditionally, junior engineers learned the craft by doing the “boring work”.

They wrote basic code, fixed simple bugs, and handled unit tests. Essentially, the tasks senior developers wanted to avoid. Under the guidance of mentors, they gradually leveled up their skills and system knowledge.

Today, AI does almost of that.

Consequently, companies have largely stopped hiring juniors, or they expect them to operate at a significantly higher level immediately by leveraging AI tools. Junior developers are no longer traditional developers. They are AI Developers now.

They are designing AI-oriented systems from their very first real-world projects.

This represents a massive opportunity (assuming they can manage to land a job in the first place).

If these juniors maintain a critical eye toward the systems they build, they will become the elite AI experts of tomorrow.

There is no longer a strict need to understand every line of code running behind a solution. Instead, the value lies in finding the perfect orchestration between AI tools, their integrations, and how they apply to a concrete business need.

In the future, developers will ultimately become technical business analysts.

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

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.

I always cherish the moments when I facilitate elaborate workshops to shape product or company strategy, resulting in agreed-upon and actionable outcomes.

However, working in non-technological companies, I already anticipate the hurdle of getting business or operations-oriented staff aligned with an action plan that is more than 50% technological.

One of the major challenges of working with non-technological teams is that IT and its strategy are rarely a true priority.

Today, with the rise of AI, we see every company demanding an increase in its usage, but deep down, we all know that Operational and Business teams are fundamentally not interested in IT.

Technology is viewed as a commodity. From the end-users perspectives, the main goal is simply that platforms work, and major transformational projects only happen if the company’s operating environment shifts immensely. When this happens, Ops and Business teams expect IT to quickly and agilely execute the transformation as fast as possible.

The overall message is clear: in practice, IT is not a priority. And it never will be.

This presents an additional challenge for IT teams trying to collaborate and truly help transform the company.

How can IT manage such a lack of engagement?

Bring IT Closer to Ops/Biz Teams

It is incredibly important to invest in the relationship between IT and Operational teams.

This can be achieved by running small, simple, and well-designed workshops with these teams to truly assess and understand their daily operational needs.

Be mindful that these teams are rarely interested in new features unless they have no choice.

For Ops and Business teams, changes in PROD mostly mean potential regressions, operational setbacks, and, in some extreme cases, massive manual workarounds while IT takes its sweet time to fix an issue.

Building a bridge of trust between these two critical areas of the company is key. While IT is mostly focused on the “new” (new features, new technologies, and new challenges) Ops is laser-focused on stability and getting their job done before the day is over.

Language also creates a massive gap. IT often uses highly technical terms that Ops has absolutely no interest in. The reverse happens too, but the onus is on IT to learn and incorporate operational language into their own dictionary.

This is where Business Analysts and Product Teams play a vital role. One of their primary missions is to keep the relationship between IT and Ops healthy, facilitate a smooth flow of information, and actively improve collaboration.

Is key to highlight the achievements in both formal and informal communications:

• Show impacts on new features (in a measurable way: Time saved, fewer errors in PROD, etc).

• Track KPIs and demonstrate the evolution of the product or application stability in PROD.

• Time-to-market on key features.

• Track overall user satisfaction: Is IT getting fewer complaints from the end-user? How is the VoC (Voice of the Client) captured and measured?

• Highlight the most innovative approaches in internal ceremonies and/or in a simple coffee talk with businesses.

Find Common Goals

In order to have engagement on projects and initiatives, it is important to map what the current priorities and goals are between the different structures.

Companies (hopefully) have objectives for every department. Leveraging those objectives with dedicated IT perspectives may offer a way to facilitate the engagement of non-technical teams.

It is important to have a perspective on the company’s political landscape to figure out levers that can be useful to leverage IT initiatives. It is important to notice that Operational teams are focused on day-to-day business. IT, in its projectized fashion, is visualize wider periods for its strategy.

The key is to find and match IT-related objectives with business-oriented ones. Having feedback from end-users (built from the relationships mentioned in the previous point) is key.

For example, today, all companies have an AI-related objective. IT is very much focused on AI subjects currently. An “easy” way to align and work on common goals is to help non-technical teams leverage their tools with AI. This can be from a cost-cutting perspective, but also by focusing on ways to increase processes’ output quality and maybe produce new products, which can potentially create new revenue streams.

Avoid IT Hallucinations

If Product Teams have a healthy relationship with Ops and a deep understanding of the operations their product supports, it is crucial for the overall alignment of an IT department to defend certain operational constraints and visions within IT itself.

Depending on the size of the company, there may be internal IT teams that have little to no interaction with the operational layer.

Left in a bubble, these teams often design day-to-day processes and workflows that are completely incompatible with real-world operational requirements. This mismatch is a massive source of conflict.

For that reason, Product Teams must take a firm stance against internal IT processes that are completely out of touch or inherently inefficient for the business. Or help internal IT teams improve their processes to actually deliver value to end-users.

The most common symptom of this is bureaucracy: like when an isolated IT team creates a “beautiful” document filled with dense technical terms, yet expects non-IT staff to fill it out.

The severity of these cases depends heavily on the company’s structure and how distant these backend teams are from the real business activity. However, it is vital to call this out and ensure that internal IT processes do not become so detached from reality that they end up burning internal communication bridges and destroying trust.

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

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.

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

9 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