Corporate term: “The grandfather trap”

Definition

The Grandfather Trap is the slow erosion of an organisation’s ability to perform essential tasks because long-standing users retain legacy permissions while new users cannot obtain them. Over time, fewer and fewer people can actually do the work.

Explanation

“Grandfathering” is common in sales: long-time customers keep their original pricing as a loyalty perk. In corporate IT, a similar pattern appears with access and permissions.

A group of users who have “always done the job” may hold rights that are now discouraged or outright forbidden such as local admin rights, access to deprecated tools, or exemptions from modern controls. They keep the lights on because those privileges let them work around new constraints. But when new staff join, they can’t get the same rights. Processes and security settings have moved on; the forms have changed; risk appetites have tightened.

Crucially, when those changes were introduced, few had the time, or the courage, to retrospectively remove legacy rights from existing users. Grandfathered users often hold soft power, and if you pull their access and something breaks, the blame lands on the person who removed it. So the path of least resistance wins: change the form for tomorrow, leave yesterday untouched.

This creates a time bomb. People leave, get promoted, or move teams. The population of users who can perform essential functions shrinks until, one day, the last “grandfather” goes, and something critical fails. No one else has the permissions (or the old tool) to fix it. You get a major incident and real financial impact. And because each step towards tighter controls was individually justified, accountability is diffuse, even though the outcome harms the organisation.

Disclaimer: As always these posts are not aimed at anyone client or employer and are just my personal observations over a lifetime of dealing with both management and frontline associates.

 

Time for Some Paperwork

One of the core differences I’ve found between the highly technical work I did for most of my career and the more managerial, higher-level work I’ve focused on in the last decade is the need for certifications.

When you’re purely technical, certifications are often slightly looked down on. Think back to the old MCSE days: we’d do boot camps, pass them in droves, and they became less and less relevant. On top of that, so much technical work is done in ways the vendor never intended. Salesforce and IBM are both particularly famous for this.

In integration work I often found ways to do what they didn’t want you to do or to get round things without paying extra. Certifications mattered very little. You went to technical interviews, had proper conversations, and your reputation for solving problems, plus the evidence on places like this blog, proved you were worth the money.

In the managerial space, it’s harder. Almost everyone can talk the hind legs off a donkey. People are very good at making a case because they’ve sold projects and big ideas for years, and they’re used to selling themselves. So when I reviewed my CV (as I do every six months) and asked, “What can I update to show I’m better at my job for a client?”, there wasn’t a great deal I could change. I had more projects under my belt and more experience, of course, but it didn’t give me much I could actually update. Unlike technical roles, much of management has been, frankly, the same for decades, if not centuries.

So what to do? Well, I’ve sounded out clients informally and looked at what potential roles are wanting, and I’ve landed on a list of qualifications, courses, and bits of paperwork I should complete to demonstrate the progression I want to show as an individual and a consultant. Quite a lot of them are stuff I have been actually practicing for many years, so passing should hopefully be a case of phrasing my existing knowledge in the format the examiners want, but some will be genuine learning, and that is always fun.

This post is mainly a line in the sand for me, something I can update over time, but it should also give others an indication of what you might need if you’re heading down a similar path. They are as follows:

Then the Big boys that will take some time to complete

  1. This one is more an in-passing item [↩]

Retaining Control of Your Management Work (Part 1) – email still runs the enterprise

We can celebrate chat tools, Slack threads, and the return to in-person collaboration, but in most large, traditional organisations, email is still the system of record. Official statements, warnings, approvals, notifications, and anything that needs a defensible paper trail almost always arrive by email. If you want to stay in control of your work, you have to stay in control of your inbox.

Why email still matters

Email is the channel leaders fall back on when something must be traceable and unambiguous. “I’ve emailed you about this” is shorthand for “this is now formally on the record.” Lose grip on your email, and you lose grip on decisions, timelines, and, ultimately, credibility.

Signs you’re losing control

  • Only reachable on chat. People default to pinging you because email responses lag.
  • Meeting overload. When someone books meetings for everything and involves large numbers of people in these calls, it often means they can’t manage the information flow via email and so are having to get it repeated to them in person.
  • And, obviously, the fact that you have thousands, if not tens of thousands, of unread emails in your inbox.

These are symptoms of the same problem: your inbox is just overflowing.

If you can’t keep up, something must move

If maintaining your inbox feels impossible, don’t just keep drowning; make a change:

  • Get support. Ask for assistance with triage or admin.
  • Delegate other work. Free up time to handle essential communication.
  • Reduce optional involvement. Skip non-essential meetings to protect focus time, even if that triggers a little FOMO.
  • Set expectations. Tell stakeholders when you process email (e.g., twice daily) so they know when to expect replies.

Practical inbox habits that work

Thankfully one of my LDC Via colleagues, Matt White, has recently done a blog post on this and provided a good set of tips and ways of dealing with a heavy inbox.

Bottom line

Managers and subject-matter specialists who lose control of their email rarely have a happy work life; they’re permanently reactive. Whatever method you choose, treat your inbox like the operational cockpit it is. Stay on top of it, and your life will be a little less stressful.

Are unpleasant jobs easier to do in an office?

This is one of my rare posts where I’m genuinely after feedback. to discover if I’m just being daft, or is this something more people quietly recognise?

When I’m dealing with tricky client situations or work I find stressful or dull, I gravitate to an office. If the client doesn’t have one, I’ll book a workspace. Making the environment more austere seems to make it easier to knuckle down 1. At home, when the work is unpleasant, I don’t tackle it as well; there are too many nice distractions. The difference between work I enjoy and work I don’t becomes stark, so I remove the comforts and go somewhere “all business”.

That’s my personal pattern. But is it generally true? Setting aside “people only work hard when monitored” (that’s a different debate), is difficult or unpleasant work simply more efficient to do in an office than at home?

It could explain a few things. You often hear aggressive, control-heavy managers say, “People work best in the office.” Well, if the work feels unpleasant, perhaps the lack of distractions helps you just get on with it. Conversely, inspiring leaders and organisations, where the work feels meaningful and motivating, may find remote working thrives, because people want to do the work and can benefit from less commuting and more flexibility.

Are we missing this nuance in the broader conversation? Perhaps some kinds of work , or some leadership cultures, make the office more effective precisely because the work feels less rewarding. If your only option in the office is to work, you might as well get it done.

Has anyone else seen this? Is this a conclusion you’ve come to? I’d love feedback, especially from engineers and delivery teams.

Note: I’m assuming all else is equal, same type of work, similar pay structure, and comparable teams. If the people or the work are fundamentally different, the comparison falls apart.

  1. I have since learnt that part of this is the known effect that you work harder when you feel you are monitored[↩]

The mystery of the disappearing contingency

 

This is a relatively new pattern I’ve seen across vendors and clients, and it seems to track with the rise of strict, goal-based projects with fixed-prices and tighter costing controls. Contingency has seemingly “disappeared”, but the prices of the contract have not gone down, in fact, they tend to have gone up.

Here’s how it tends to play out.

In order to keep a firm grip on fixed-price spend and avoid variance on any given deliverable, the client or central finance team insists contingency is held centrally rather than on the vendor’s estimate. On paper, that’s fine: if something goes wrong, you dip into the central pot. In practice, two problems appear.

First, finance teams are often reluctant to release contingency. They treat requests as overspend or evidence of poor project management/implementation. People don’t like losing control or inviting blame, so approvals get sticky. Second, removing contingency from the vendor’s scope strips away whatever flexibility the vendor or delivery team might have to address issues quickly.

For as long as I can remember 1, there was usually a simple contingency line at the bottom of an estimate. It might have been in hours or a percentage, typically 10–20% (sometimes ~5% on a well-scoped waterfall project).

Now, many quotes simply cost about 20% more by default, and any challenge to time or scope turns into a long justification and a tussle over release of funds. Everyone knows the contingency hasn’t really gone; it’s just been moved and hidden. and that’s not much of a win for any of us.

The net effect is less transparency in our quotes and vendor interactions. If a project goes really well, we still “spend the contingency” because it’s already included in the bill. I’d much rather see contingency brought back as a clear line item. But while the push for ever-tighter fixed-price deliveries continues, I don’t expect that transparency to return any time soon.

  1. ,20+ years[↩]