One thing guaranteed to upset your project manager is uncertainty. It’s not the duration of a task that creates anxiety, it’s the lack of clarity around that duration. Whether you’re coding, fixing an issue, or designing something, managers become anxious when they’re left guessing about progress.

Managers usually aren’t overly concerned with how long a task will take, unless there’s a firm deadline looming. Instead, their stress stems from uncertainty and ambiguity. ¹

The solution to uncertainty? define timelines as much as you can, break down tasks if the manager cant understand the complexity of the task or to highlight bottlenecks in the time to completion , and communicate openly about progress and obstacles.

By providing details and clear updates, even if the timeline is lengthy, you significantly reduce their stress and, in turn, cut down on constant check-ins and nitpicking.

Remember, clarity is your friend. Keep your project manager informed, and you’ll keep them off your back.

1. if you do have one that constantly challenges the time estimated to complete a task by a subject matter expert, then you have a whole different problem that probably comes from someone else underestimating the task publicly. [↩]

There’s a persistent phenomenon I’ve observed across nearly every corporate client I’ve ever worked with, which is particularly noticeable within IT and technical support teams, and it revolves around retaining genuine high performers, or “rock stars.”

Strangely enough, even with effective management, continuous challenges, and engaging work, these exceptional talents rarely stay in permanent positions for long, which in turn wrecks a lot of multi-year IT plans.

But why should businesses care about losing these top performers? Primarily, it’s because organisational stability often hinges disproportionately on a few highly capable individuals who deeply understand core systems and processes. When these essential people leave, the disruption is severe, and companies frequently experience significant operational setbacks, particularly if they are doing something that will put them ahead in the marketplace.

The standard corporate solution to this problem usually involves complete documentation and process redundancy, aiming for systems so simplified that nearly anyone can operate them. While this strategy ensures stability, it unfortunately also results in inflexible and overly simplified systems. Users find themselves boxed into rigid frameworks that stifle innovation and adaptation. It’s essentially designing processes for the lowest common denominator, which might reduce risk but certainly doesn’t encourage excellence.

In contrast, smaller companies and startups tend to thrive because they foster teams composed entirely of high achievers. Such teams collaborate naturally, continually push boundaries, and build genuinely impressive solutions. These environments fuel continuous innovation and engagement.

So why can’t large corporations replicate this environment? In my view, one critical factor holding back corporate IT teams is HR’s reliance on the bell curve for performance evaluations. Designed to distribute evaluations fairly, this method inherently restricts recognition and rewards for genuine excellence. Teams are generally forced into predefined categories: a small group at the bottom requiring improvement, a broad middle performing adequately, and only a select few “exceeding expectations.”

What happens when a team naturally has more high achievers than the model allows? HR policies typically prevent recognising all deserving individuals, thereby inadvertently penalising genuinely talented employees. Over time, this practice inevitably breeds resentment among those repeatedly overlooked, making them easy targets for recruiters and competitors who promise fairer recognition and rewards.

I’ve even seen corporations unofficially adopt a “rotational excellence” system, where recognition and rewards cycle through team members regardless of actual performance. While superficially fair, this approach only fosters cynicism, demotivating the people really performing

Admittedly, addressing this issue isn’t straightforward. Simply allowing unlimited “exceeds expectations” ratings would undoubtedly lead to inflationary evaluations across departments. Yet, maintaining the status quo clearly undermines team morale, retention, and long-term organisational growth.

Currently, it seems only startups and community-driven projects successfully maintain groups of high achievers for extended periods. Corporations ¹, however, have yet to discover a sustainable solution.

While I don’t have an immediate remedy, I’m eager to explore how corporations might better nurture and retain exceptional teams without fueling internal resentment or compromising fairness. How can large organisations sustainably reward genuine excellence without falling victim to the limitations of rigid HR models?

This challenge is a little devil, especially in IT, where the difference between retaining or losing top talent can dramatically influence organisational success.

1. outside of the major Tech ones[↩]

If you work in a support, technical, or specialist role, you’ve probably felt the urge to dismiss a project manager’s status or planning demand with “I’ll get to it later.” or “FFS” but before you do, it helps to remember what drives their behaviour.

Project managers are hired to deliver one outcome, nothing more, nothing less.

Especially in contract roles, their performance is judged almost exclusively on whether the project’s scope, timeline, and budget are met. They aren’t rewarded for keeping infrastructure stability long term or for preserving team morale. They’re rewarded for shipping.

Because of that narrow mandate, they will:

• Relentlessly pursue status updates: Frequent check‑ins aren’t harassment; they’re risk management.
• Prioritise deadlines over comfort: If a subject‑matter expert is at capacity, the project manager may still push, because slipping the schedule is costlier to their success and thus them than your overload.
• Ignore peripheral fires: Issues that don’t directly block the project often fall outside their remit, even if they matter to you.

Understanding this incentive structure doesn’t excuse poor behaviour, but it does offer practical ways of working with them:

• Clarify capacity early: Spell out what’s realistic, agree on trade‑offs, and document them.
• Frame updates in impact terms: Explain how delays or scope changes affect the critical path; PMs will adjust if the risk is explicit.
• Escalate strategically: When workload or morale is at stake, involve sponsors who balance delivery with sustainability, even offer to talk to the sponsors directly to help fight your case.

A project manager’s laser‑focus can feel abrasive, yet it’s the same focus that keeps initiatives from drifting. Recognise the problems they face, communicate to them within that context, and you will be able to get a better working relationship.

Ever notice that project estimations seem unusually slow or hesitant? Especially when working with a team with a lot of newly hired people in it, one overlooked factor might be the team’s level of historical experience with the specific implementation of this technology or system .

New team members, even if highly skilled and technically competent, may naturally hesitate due to unfamiliarity with the nuances of your particular implementation. They’re often cautious, aiming to avoid mistakes on their first significant project, leading to slower response times or overly conservative estimates.

On the other hand, experienced team members familiar with your systems quirks can quickly assess situations, drawing from past knowledge to provide faster and more accurate quotations.

As a manager or project leader, always factor in the team’s familiarity with your systems when evaluating timelines and performance, not just the raw platform. Offering additional support, training, or pairing new hires with experienced team members can significantly speed up the quoting and decision-making processes.

One persistent challenge faced by technical professionals in many organisations is the pressure to quickly provide project estimates and quotes before adequate information is available. If you’ve found yourself frustrated by unrealistic timelines and vague project scopes, you’re not alone. so here is a guide to help navigate this common issue effectively.

Why Technical Teams Are Asked for Premature Quotes

Typically, this situation arises from organisational structures where business needs are quickly escalated to IT management, who then require immediate answers. The usual questions from management include:

• Can this be done?
• How long will it take?
• How much will it cost?

Realistically, detailed and accurate answers to these questions can require extensive work: proof of concept development, regulatory checks, and feasibility studies, all of which take considerable time and money. Yet, management and the business often expect preliminary estimates within a very short timeframe.

How to Handle Early Project Estimates

Instead of frustration, here’s how you can approach providing an early, preliminary quote:

1. Use Realistic Assumptions

You will inevitably need to make assumptions. To do this well, aim for assumptions that reflect realistic scenarios. A helpful analogy is the question, “How long does it take to travel to Australia?” Although many variables exist, your immediate reaction should not consider extreme scenarios like walking. Instead, you naturally think about common methods, such as flying, use widely available flight times and costs as your baseline.

2. Clearly Document Your Assumptions and Contingencies

Explicitly document all assumptions and known contingencies. For instance:

• Clearly state if the quote assumes completion only up to a specific milestone (e.g., arriving at an airport versus a specific city or location).
• Highlight known potential blockers such as regulatory or security restrictions.
• This approach helps manage expectations and protect against future misunderstandings.

3. Provide a Reasonable Margin of Error

Include explicit language that highlights the preliminary nature of your estimate. Use clear, standardised statements like:

• “This estimate has a potential variance of up to ±20%.”
• “Final quotation requires a proof-of-concept phase of approximately two months.”
• “Security approvals and regulatory checks may significantly impact timelines.”

If you find these notes are frequently removed from presentations by management, formally document these conditions elsewhere (e.g., in emails or follow-up notes).

Common Pitfalls to Avoid

Avoid Extreme Responses

Resist giving overly pessimistic or overly optimistic quotes, as both extremes tend to be ignored or cause pushback from management. Instead, offer balanced, evidence-based estimates.

Don’t Delegate Estimates to the Most Optimistic Team Member

While it’s tempting to delegate unpleasant tasks like estimation to the most helpful person on your team, this often results in overly optimistic estimates. It’s better to have slightly sceptical or more conservative team members lead estimate preparation to ensure realism and accuracy.

Handling Negotiation and Scope Creep

Be prepared for negotiation. Management teams naturally approach quotes as negotiable, even when your technical estimate is realistically calculated without any intentional padding. Counteract potential scope creep or budget reductions by clearly outlining consequences, such as failing compliance or security standards if corners are cut.

Final Thoughts

Early quoting isn’t ideal, but with thoughtful handling, you can provide meaningful preliminary estimates that guide decision-making effectively. Clearly articulated assumptions, contingencies, and evidence-based reasoning can position you as both helpful and realistic, qualities that reinforce your credibility. This means that when inevitable changes need to be made to quotes further on, people are more likely to assume they are reasonable needs.