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

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

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

Share

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

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

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

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

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

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

Experience Does Not Always Translate to Credibility

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

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

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

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

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

How to Build Trust

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

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

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

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

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

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

Practical Ideas You Can Use Today

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

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

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

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

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

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

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

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

What If Mistakes Eroded Trust?

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

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

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

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

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

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

Share

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

Cheers,

Artur

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

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

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

Share

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

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

• Increase transparency on salaries for job postings.

• Allow employees to share their salary with their colleagues.

• Disclose salary averages for different roles within the company.

• Reduce the pay gap between men and women.

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

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

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

What Is The EU Directive On Pay Transparency About?

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

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

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

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

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

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

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

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

What is equal value?

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

• Skills: Education, professional experience, and training.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

The Good Stuff

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

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

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

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

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

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

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

The Main Challenges

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

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

HR and their processes

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

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

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

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

There are multiple examples like this in any single company.

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

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

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

The Performance Conversation

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

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

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

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

Roles Comparison

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

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

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

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

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

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

Averages vs Medians

Eventually the analysis will be centered around averages.

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

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

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

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

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

The Outsourcing Loophole

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

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

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

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

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

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

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

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

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

Share

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

Cheers,

Artur

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

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

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

Share

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

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

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

Cybersecurity: Prevention and Impacts

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

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

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

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

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

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

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

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

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

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

IT Budget Impacts

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

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

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

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

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

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

Near-shoring and Far-shoring Risks

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

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

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

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

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

Share

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

Cheers,

Artur

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

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

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

Share

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

The Geopolitical and Market Landscape

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

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

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

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

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

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

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

The Foundational Challenges

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

Scale-up Money

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

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

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

Is the EU lacking the capital to invest?

The reality is actually the opposite.

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

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

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

Market Fragmentation

The second critical issue is European fragmentation.

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

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

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

The Solutions So Far

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

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

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

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

An Opportunity for the US

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

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

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

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

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

Share

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

Cheers,

Artur

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

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

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

Share

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

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

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

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

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

The First Impressions

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

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

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

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

The First Signs That Something Was Wrong

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

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

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

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

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

AI Is Not A Magic Wand

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

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

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

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

Babysitting Morphed Into Micromanaging

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

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

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

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

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

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

The Unicorn Is Available For Testing

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

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

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

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

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

If We Cannot Fire: Shock Treatment

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

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

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

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

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

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

The Pressure Mounts

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

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

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

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

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

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

The Turn Around

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

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

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

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

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

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

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

Share

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

Cheers,

Artur

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

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

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

Share

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

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

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

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

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

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

Cloud Repatriation

What is Cloud Repatriation?

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

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

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

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

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

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

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

Why This Is Relevant?

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

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

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

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

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

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

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

Tangible Argument. Cost.

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

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

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

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

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

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

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

Let’s make a small shortlist of actions first:

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

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

   2. Oversized VMs or other resources.

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

3. Redesign system transfers and storage

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

   2. Add compression

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

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

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

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

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

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

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

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

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

Share

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

Cheers,

Artur

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

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

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

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

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

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

Skillsets mismatch

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

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

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

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

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

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

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

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

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

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

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

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

Being Difficult For The Sake Of Being Difficult

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

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

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

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

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

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

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

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

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

Protect The Stars

Experienced leaders make mistakes. New leaders even more.

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

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

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

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

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

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

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

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

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

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

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

Adversity To Change Is Complex

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

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

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

Some questions to ask yourself while handling Nay Sayers:

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

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

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

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

Share

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

Cheers,

Artur

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

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

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

Why Remote Teams?

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

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

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

Having the Team On-Site - Fast

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

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

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

Faked Online Status

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Share

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

Cheers,

Artur

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

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

The Old Way Of Doing Things

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

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

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

Why It Is Important to Meet Physically

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

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

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

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

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

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

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

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

The Alfredo’s Story

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

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

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

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

Remote Helps Masking Bad Apples

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

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

Share

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

Cheers,

Artur

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

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

Why All These Assignments?

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

• To better coordinate resources within the department or team.

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

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

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

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

How To Navigate As The Informer

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

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

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

How To Navigate As The Project Lead

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

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

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

The Unspoken Tax Of Project Follow-up

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

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

Share

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

Cheers,

Artur

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

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

Pulling Rank Is a Sign of Weak Leadership

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

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

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

• The person doesn’t need feedback or help

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

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

Emotional Intelligence Is Key

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

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

In Case of Doubt, Play Cool

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

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

Share

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

Cheers,

Artur

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

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

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

It’s OK Not Having Clear Feedback Sometimes

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

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

What Reality Shows Us

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

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

The Focus Are The Results. Always.

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

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

Share

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

Cheers,

Artur

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

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

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

They Are Humans With A Significant Amount Of Pressure

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

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

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

Be Careful With Old Wolves

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

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

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

Be Ready To Play The “Behind The Scenes” Game

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

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

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

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

Share

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

Cheers,

Artur

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

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

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

Some Things Inevitably Will Go Wrong

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

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

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

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

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

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

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

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

Challenges Improve Self-Awareness

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

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

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

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

Share

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

Cheers,

Artur

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

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

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

Even Senior Developers Struggle To Address Non-IT Staff

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

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

Smooth The Exposure

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

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

The Gain Is Priceless

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

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

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

Share

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

Cheers,

Artur

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

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

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

Power Is An Illusion

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

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

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

Too Strong a Position On A Matter

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

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

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

Pick Your Battles

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

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

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

Communicate Smartly

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

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

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

Don’t Take It Personally

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

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

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

Share

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

Cheers,

Artur

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.

If you like traveling as a hobby, you might think it would be enjoyable to have a job that sends you off to different cities and countries all the time. While this is indeed a nice perk, it can quickly make a 180-degree turn when done too often.

Unless you’re traveling by private jet and staying in 5-star hotels, this article might not be for you. However, for the rest of us mortals who take commercial planes for work, this endeavor can have some disadvantages.

So, what’s so bad about traveling to different cities and countries for work? What is eroding that fantastic view of an international career? Well, let’s just go through the reasons one by one, shall we?

If Done Too Many Times, It Becomes Routine

While it is fun to get on a plane and meet a new city for the first time, believe me when I say it gets dull the more times you do it. The first time, it’s okay to get out of bed at 6 a.m. to catch a flight and endure the airport’s security measures without your first coffee of the day. You do all that, only to realize that your plane is late, even though you made the effort to be on time. But it’s okay, due the excitement of visiting City X, a place you’ve never visited before and have heard so many good things about.

Well, let’s just say that by the time you visit the same city for the fifth time in a short period, the plane starts to feel like a bus with wings, and the excitement that made the airport’s overpriced coffee bearable is long gone.

On top of that, when we travel for work, we tend not to do the touristy. We might walk around the city to get to know it a little better, but we don’t actually have time for museums or whatever else ticks your fancy while traveling because we are working during office hours. We might go to restaurants and enjoy some of the local food though. However, when this happens multiple times over a short two-to-three-month period, a city, even a cool one, just becomes a place for you to work and enjoy a bit during the evening.

It Messes It Your Plans

If you have a hobby, let’s say pottery classes (not judging, just an example), it’s okay if you need to travel for three days and miss a class or two. However, if you’re constantly traveling for two or three days at a time over several weeks, those business trips start to mess with your progress. You’ll begin to fall behind on techniques or notice other negative impacts on your hobbies and routines. If you just sit on the couch watching Netflix all evening, I guess you’re okay. Hotels typically have good WiFi.

In my particular case, business trips steal time from my gym activities, and I often fall behind on my training plan. The “hotels have gyms” argument isn’t that great because those gyms are typically bad. Very bad. This is especially true when a business trip falls in the middle of a specific weightlifting cycle or when I miss my window for setting a new PR. Whenever you have something consistent going on in your life (let's say, family and kids included), going away for days in rapid succession really messes with your personal life.

Planes Are Always Late

We all try to be on time for the airport, especially to get through security, only to end up at a gate where the plane is half an hour, or even hours, late due to <insert whatever circumstance here>. More often than not, planes are late. All the time. Depending on the destination, the impact might vary. An evening delay might mean arriving after public transportation has shut down for the night (Paris Orly train, looking at you quite angrily). Or, if your plane takes off late, the destination airport might close while you’re mid-flight (Swiss airports are particularly dangerous in this regard).

The consequences of a plane delay can really affect your arrival, and it’s not always a one-to-one relationship. That 30-minute delay might cost you hours, depending on what’s happening at your destination. When a plane is late in the morning, it can mean arriving late to meetings or having to skip them entirely. If you’re traveling for only three or four days, this has a significant impact. And these situations get exponentially worse when connecting flights are involved… (smiling nervously).

Sometimes, you just want to arrive on time. That’s a luxury in this day and age.

It Fatigues More Than Anything

When you’re traveling for work, the agenda is set, and the goal is to accomplish a specific set of things before your time runs out. It’s not like a normal trip to the office. To be sure, these trips have clear objectives you need to meet, and they are not normal workdays. It’s common for them to be more intense than usual, especially when you probably didn’t get a good night’s rest from traveling the day before.

Everything about the trip drains your energy. Even if the hotel is nice, the bed is never quite your own. You never know what annoying sounds will come through the walls. I’ve stayed in 4-star hotels where I could clearly hear the drainage pipes from the floor above me. Those pipes were working much more than I wanted to hear at 4 a.m.

If you’re “lucky”, you’ll also have evening events with colleagues. Yes, it’s great to go to a bar and have dinner with the big boss. However, imagine doing this after a poor night’s sleep and an intense workday, with more activity planned for the evening. You do all that, only to go back to the hotel for another night of too-little sleep before jumping right back into another intense day. Coffee is your best friend.

There Are Cities More Interesting Than Others

Before I first traveled to Milan, everybody told me, based on their tourist experience, that it was a very boring city. They said it only had the cathedral, and there was nothing else to see. I knew Italy very well (Rome, Florence, Naples, and other cities in the south), but I had never been to Milan before. My experience there, however, turned out to be very different. Yes, the cathedral was the only major tourist attraction, but I wasn’t there to be a tourist. I was there to work. On a business trip, what matters is the quality of the hotel and how easy it is to find good places to eat and drink. On that front, Milan turned out to be great!

However, visiting certain northern European cities (I won’t mention any, so as not to anger any Danish readers - evil laugh) can be a totally different story. There are cities that seem to shut down by 8 p.m. In those cases, your trip basically consists of going back to the hotel to use the WiFi until you find the end of the internet.

Depending on the destination, some cities are simply more enjoyable than others. This is especially important because if you had stayed home, you could at least be doing things on your own terms.

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.

There is not enough conversation around the mindset of achieving objectives. Milestones are in place, and the work is all planned out, but the part of actually getting there is sometimes not technical in nature. It is probably one of the hardest soft skills to accurately assess.

If we push the engine too hard, it will obviously break, and as Leaders, we need to pay special attention to when too much is too much. Especially when asking the engine to work too hard for too long. However, we should strive for a “Get It Done” mentality across teams. So, how do we get to deliver challenging objectives?

The Right Tasks

Asking people to work harder doesn’t work. What really makes almost any professional tick is their level of autonomy, visibility, and appreciation. If, for any reason, the person feels they don’t have the right tools, or whatever they are doing is pointless, or somebody would take the credit for their achievements, and they never hear any good feedback, we wouldn’t expect them to be very productive or committed to the project deadlines.

This is the very basic of things to take into account, on which everything else can be built. Even highly talented people won’t perform at their best if they feel the work they are doing is pointless. This can be clearly seen on migration projects, when the business requests a complicated feature on a system that will be decommissioned (even if the decommissioning is a few years on the horizon). Imagine how boring it is to tackle a complex challenge just for the comfort of a set of people who want features for their convenience at the expense of the engineer’s time and patience.

Milestones Are Milestones - Not Guidelines

When a milestone is set, efforts should be made to meet it. The mentality of “we can move this date a few days” is the type of mindset that steals time from the team. Projects tend to have higher pressure at the end than at their beginning, so any days that we move around in the earlier stages for the sake of “nobody really complains now if we move this a week further” will have consequences. The consequence of that mentality is that by the time the project is scheduled to be delivered, having just one extra week would be amazing for the sake of everyone working on the project.

Save time in the early stages as much as you can to have more breathing room when the project arrives at the final destination. Sponsors and higher management might not care much if the intermediate milestones are late by a few weeks or sometimes months, because they are expecting the end result on the same date as was promised. Be mindful of moving away from intermediate milestones, because it might be a reflex that the timeline won’t be met.

Quick Wins Are Buffers For Success

When time is getting short, quick wins taste like chocolate. However, sometimes quick wins aren’t given their own due credit. They are only seen as useful if everything else is failing and the team needs to present results.

If a quick win is part of the project scope, it is scope nevertheless, and therefore should be delivered in the same fashion as a highly complex delivery. Sometimes, quick wins can compensate for the fact that deliverable A was not met in time, because the team anticipated the delivery of B (which was a quick win).

The goal here is to save as much time in the beginning as possible to avoid a big headache on the crucial final days of the project. Getting those victories in early creates buffers of time that can help the team focus on the most complex part of the projects with more time available.

“Is It Urgent?” Pitfall

Well, if it is urgent, then someone is already falling behind. If we manage a project only on “urgent” tasks, we will end up burning out the engine before we arrive at the destination. Sometimes, I get this question about why I ask about progress on task A or B. My strategy is always the same: understand the pressure or the workload that person is currently under, and try to accommodate the task before it becomes truly urgent.

I try to emphasize the advantages of getting something done early, and sometimes I try to influence the planning (even if this responsibility is outside the team) to meet the goals. Of course, this is easier said (or written) than done, but I try not to be too annoying at the same time that I am pushing for something before it actually becomes urgent.

Re-Check On Repeat

There is nothing worse for a sponsor than getting the bad news that the project, which was funded with so much love and a giga amount of money, is not meeting the deadlines just a few weeks before it should actually happen. We should avoid surprises at all costs. However, if worst comes to worst, the bad news should arrive as soon as possible.

Yes, sponsors might have unrealistic expectations, but it is better to factually confront that with time than working on a project for months in a row, only to tell them a few weeks before the deadline: “Sorry, we cannot meet the deadlines and we need 30% more <insert time, money, or both>”.

The sooner people know about the bad news, the more options can be put on the table to address, mitigate, or rethink the entire plan. Committing resources only to learn the team will fall short is a tough place to be in. Re-check the planning every week, every couple of weeks, or every month. Whatever timeframe you feel is feasible for the endeavor to catch those bad surprises as soon as possible.

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.

When I look at different websites and professional commentary, two main topics are discussed: remote working or RTO mandates, and the possibility of working asynchronously from the rest of the team. The dream, the achievement, the pinnacle of success, would be to work on the timeframe that the person finds more suitable for their personal life.

Well, it is a very good objective to have. The only problem is that asynchronous work, or working on different schedules compared with their colleagues, doesn’t work in a project-based approach. Let me explain why

Impossible to be 100% autonomous

In order for someone to work asynchronously without negatively impacting the project, the execution cannot have dependencies on anyone else to go smoothly. For example, if a task is estimated with five days of effort, to make it happen asynchronously, the person must not need anyone to execute it.

In practice, what happens is that the more complex the project is, the more unknowns there are. Consequently, there is always a moment when we need to brainstorm or agree on solutions as a team in order to move the project forward. If people have only a few hours of overlap, they will simply “burn days in the calendar” without any significant progress.

In order for the project to be efficient, the team needs to have a significant overlap of working hours to discuss and exchange project-related topics. If the number of overlap hours is less than six, it is already entering the realm of inefficiency. Even in projects that have people in different countries, I strongly recommend that people overlap their schedules. For example, for everyone to work under CET hours, even if that means I will have a meeting at 8 A.M. Meaning, good luck to those who work with people on different continents, and by lunchtime, half the team has disappeared due to the time zone alone.

It Is Very Easy To Burn Days

One of my biggest problems with freelancers is that they are juggling multiple projects at the same time. If a project has an issue in the morning and the freelancer only sees the Teams message in the afternoon, the chances that the issue will continue for the next day are very high. Without much effort, the project is burning days on the calendar. In essence, the days are passing, and there is not much progress.

There are some fixes you could try, like setting up calls to address issues on the same day, or any type of “making bridges” to just move forward. But the reality is that a significant amount of effort is put into babysitting instead of actual work. So, we need to be especially careful with tasks or activities that are on the critical path. If these tasks are being burned through the calendar, the project overall will be delayed without much being done.

Complexity Is a Group Effort

If it were easy, it wouldn’t be a project, and you probably wouldn’t be called to save the day. Sometimes, a challenge on a project needs brainstorming and people actively looking for the best way to address the situation. Having the team together only in an online mode is already a challenge when trying to overcome and address complex problems. With time, the team learns to become efficient at working remotely with each other, at the cost of destroying each other’s calendars with meetings instead of just having a quick chat over water or coffee near a whiteboard.

Gaining momentum on a discussion is super important and is often overlooked. If a problem is being discussed, and different people are joining the conversation, but all of a sudden the conversation needs to halt because Charles (fictitious character) is offline at 3 P.M., that is a problem. This means that momentum was halted, probably only to be addressed the day after with a further confirmation, I don’t know how many days in the future. The excuse of “Xavier had a personal issue”, which by accident happens each Thursday and Friday during working hours, but “he will compensate the hours”. Yeah, whatever. The momentum was already broken, especially when a group discussion is involved. The consequence? Burning days in the calendar. Not everyone should be allowed to work in a remote setting, but that is another conversation.

Outcomes > Excuses

I understand people want to have their beauty stuff during the day. It’s convenient, I understand. But that might cost you a project. One of the wonders of remote working is that people are more accountable for the results of their work. If the days are passing but the results aren’t there, it becomes evident that a casting error occurred. Hard conversations need to happen, and decisions must be executed. If someone likes to work during night hours, well, I believe there is a team on a different continent that would love to work with him or her.

In today’s reality with remote and hybrid work, having little overlap of working hours with the rest of the people will hurt the results. One of the wonders of remote working is that results have the spotlight, and excuses not so much anymore.

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.

Unless someone is working in a technological company (like Apple, Amazon, Google, etc.), IT is simply another department inside the company. It is far from being the flashy and sexy endeavor that pulls in revenue. Instead, it's a department where users might even mistreat Software Engineers as Tech Support for their issues with email.

A while back, I was invited to a demo of a new web solution, which had some complexity but was far from being the most complex product developed in-house. However, this product was being demoed for all the business stakeholders and external partners. The demo went deep into a conversation about business rules, and people around the table were giving shout-outs to the business’s project lead, offering compliments for the extraordinary work done up to that moment.

The meeting ended with everyone complimenting their business counterparts, but not one compliment was directed toward the IT development team that developed the solution. It was as if they were invisible in the room and the platform was built from thin air.

It’s not the first time I have witnessed such behavior. For non-technological companies, IT is a commodity. Something that happens and people really don’t care how.

How can this perception be changed? And how can an IT department get the recognition it deserves?

C-Level and Business Key-Decision Makers Don’t Care About Technicalities

News flash: Nobody really cares if the tool was done in Angular, or the latest version of <insert fancy technology here>. This is a key focal point of why IT departments are misunderstood everywhere. People outside IT simply don’t care about technicalities, and they don’t want to put in the effort to understand. This is indeed a flawed posture for some key management figures inside the company, but their behaviour won’t be changing anytime soon.

Imagine managing a video shop in the '90s, selling VCRs and DVDs, without understanding how supply management works or the impact of technological progress. They would only have to wait a few years to be out of business, both from Netflix’s and technological obsolescence perspectives. This is how some key people still operate today.

It is not up to the IT department to fix how management sees things overall, but it is important to translate technicalities into real-world consequences. That’s why it takes IT staff years to properly tune their communication with non-IT staff. It is important to have business-oriented people in IT who understand both the operational problems and the tools the company is building or has in-house. These people are the Product Managers, Product Owners, Business Analysts, and other roles oriented to align business needs with the company’s technological priorities. Without these roles, IT would be perceived as a department that just fixes the company’s keyboards.

Increasing Visibility on IT Achievements

In the age of AI, new solutions are being born left, right, and center to ease the challenges companies are facing. IT is sometimes the only innovation hub a company truly has, and it’s important to showcase the new tools the IT department puts out.

IT leadership needs to send more invitations to demos to show new features or tools that the company has made available to the business. If business stakeholders aren’t curious to see what IT has to say, it is probably because they don’t see much value in the new features. This might be a big hint that IT output is misaligned with the company’s strategy.

There is a gigantic difference between using a sexy new technology and that same technology being used in a way that is practical and offers real added value to the business.

Working on feedback, improving the tools, and translating that feedback into valuable requirements is only half of the work. The other half is communicating internally that new features are available and checking for feedback on their usage. If these features are contributing real value, C-Level management should be made aware of these achievements, and they should be communicated in terms of real metrics and outcomes. IT departments should not be shy about showing off new projects and their impacts to build an image as a value-driven department.

Make IT as Sexy as an Apple Product

Coming from an Android user myself, this means a lot. You probably won’t have access to a stage to show off the new in-house development tools (One day it will come, it’s important to chase your dreams). However, once in a while, a breakthrough will hopefully happen that will have a significant impact on the company. When these cases occur, they should be communicated at the highest levels. This means ensuring the achievement is featured in a C-level executive's presentation deck for the next time they address the company or speak at a high-level meeting.

Every once in a while, a brand-new technology pops up (for example, AI). If an initiative is using a brand-new technology and creating value, it should be announced internally, and possibly externally, as part of the company’s appetite for innovation. If no company-wide announcements are made, the IT department, with its teams of Software Engineers, will forever be seen as the people who just help maintain the MS Teams and if the building’s WiFi is working.

From Cost Center to Revenue Stream

Are the company’s IT tools part of its revenue stream? If so, how impactful is that revenue on the big picture? IT departments are often managed as cost centers, even when some of their tools are part of the revenue stream.

The shift from a cost center to a revenue stream needs to happen not just in the company’s landscape, but also in people’s minds. IT solutions should be a way to bring revenue to the company. A web portal is seen as a commodity nowadays, and since everyone is using WordPress or other CMS tools, it offers little differentiation from competitors.

It is important to have unique tools in the company’s portfolio that serve as an engine for bringing in revenue. IT should not work on this challenge alone, since it is deeply connected to the company’s strategy and added value.

There should be conversations within the company to find ways for IT solutions to bring new value. When this shift happens, budget meetings become easier to manage, since cuts are typically made to fixed structures that generate no revenue. Having a keen eye on the business and on the industry will help immensely to accomplish such a shift.

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