A continually updated presentation slide deck that serves as a single, evolving reference. New slides are added at the beginning, and older slides are progressively moved to an appendix at the end of the presentation.
Explanation:
Unlike traditional slide decks, which are typically versioned, published, and then archived, an evergreen deck is continuously maintained and adjusted. This practice is common in Agile projects or rapidly changing environments, providing an ongoing historical record and enabling easy access to past decisions or discussions.
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.
Ownership and responsibility can be a never-ending challenge in large IT organisations. In fact, it’s rare to find a corporation that doesn’t struggle with these issues. Many people want the authority and control that come with ownership, but they’re wary of the overhead involved, especially in complex cloud environments. This post explores why ownership can be so complicated and offers strategies for clarifying and streamlining it.
Why Ownership Gets Complicated
The Cloud Factor
When dealing with traditional on-premises systems, like physical servers, switches, and firewalls, it’s relatively straightforward to identify who “owns” each piece of infrastructure. But cloud systems often lack the same physical presence and involve more abstract services. For instance, setting up networks across multiple cloud environments or even inside a single cloud environment can involve numerous layers of security and function-specific configurations. Because these configurations are invisible and frequently shared across teams, pinpointing a single owner can be tricky.
Support Costs and Billing
Support in the cloud world is more expensive and convoluted. If something breaks, it could be failing in one of many places, a network misconfiguration, a permissions issue, an application bug, or a problem with the underlying cloud service. Finding who is accountable can feel like detective work:
Identify which piece is failing.
Prove that this failure lies in a particular team’s domain.
Negotiate any associated costs (e.g., cross-charging or project billing).
Because support often entails additional expenses, teams may not want ownership if it means they’ll be on the hook for increased costs. This can lead to a cycle where no one steps forward to take responsibility, and “the last person who touched it” becomes the de facto owner.
Three Layers of Ownership
In many large organisations, ownership tends to break down into three informal layers:
Official (Paper) Owner
The person who appears on the org chart as the owner. They often have sign-off authority and budget oversight. However, this owner might not be the one who reacts quickly when things go wrong.
Escalation or “Real” Owner
Often a senior architect or hands-on manager who steps in during a crisis. This person makes quick decisions, coordinates teams, and resolves technical or logistical bottlenecks.
Issue Owner or Specialist
The subject matter experts who actually fix problems. They hold deep knowledge of a specific system or process. Everyone goes directly to them for specialised help, sometimes bypassing formal channels to avoid paperwork and costs.
This layering can create confusion. The “paper” owner might not actively manage the system, while the “real” owner and specialists handle the day-to-day issues without official recognition or the resources to do so.
The Impact of Fuzzy Ownership
When ownership is unclear, or people avoid it, multiple problems arise:
Overburdened Specialists: The same experts get called on repeatedly, leading to burnout and capacity issues.
Budget Battles: Cost centres fight over who pays for support, making cross-charging and billing an administrative nightmare.
Slowed Innovation: If key people are always dealing with “firefighting,” they have less time for new projects or strategic initiatives.
Blame Culture: Support rarely gets recognition for maintaining the status quo, but mistakes draw immediate criticism.
How to Fix Ownership Challenges
Define Clear Boundaries
Document who owns what, especially for cloud services. Even if a service is abstract, outline the specific responsibilities of each team or role. Invite technical architects to clarify details for senior management, ensuring everyone understands the scope of each service.
Establish Transparent Budgets
Make sure that ongoing costs (beyond initial project budgets) are well-defined. If a new service or feature will increase the support burden, communicate this early. Agree on how expenses will be allocated so that nobody is surprised.
Prevent “Sneak-Ins”
Some projects quietly introduce new dependencies, only to leave the supporting team footing the bill. Insist on a formal review whenever something new enters production. Ensure that the project’s budget covers the required support or that the correct owner is identified from the start.
Track and Justify Costs
As environments grow more complex, support will inevitably cost more. Keep detailed records of what each service or system requires to run smoothly. This way, you can demonstrate the value provided and justify budget increases when necessary.
Reward Ownership
People often avoid ownership because support work is undervalued. Leadership should incentivise and recognise the teams or individuals who keep critical services running. Providing career growth opportunities, bonuses, or public praise for effective ownership can shift the culture from blame to appreciation.
Final Thoughts
Ownership in large-scale IT isn’t just about assigning a name on an org chart; it’s about ensuring that the right people have both the responsibility and the resources to manage complex infrastructures. By clarifying boundaries, aligning budgets, and recognising the contributions of those who take on support roles, organisations can foster a culture where ownership is genuinely shared and valued, rather than avoided.
Corporate silos 1 can create subtle yet far-reaching problems within large organisations. Often, these departments act with the best intentions, addressing internal problems swiftly and decisively.
However, the insular nature of their approach can inadvertently harm the broader organisation.
Typically, influential departments like Finance, Procurement, or HR may identify an issue they consider critical. Driven by urgency, they set out to resolve it promptly. While they might make a cursory effort to seek feedback from other departments, this feedback is often viewed through a narrow, departmental lens. Because the feedback deals with external concerns, it is frequently misunderstood, undervalued, or dismissed outright.
As a result, these departments implement changes to processes, policies, or procedures, believing they have effectively addressed their issues. Unfortunately, they rarely realise the negative ripple effects their actions can have elsewhere. The cumulative consequences can be severe, ranging from decreased productivity and widespread frustration to a noticeable slowdown in overall business operations.
Ultimately, siloed thinking undermines the very corporation these departments aim to serve. Yet, because their perspective remains internal and insular, they seldom recognise the broader impact of their decisions. It’s the rest of the organisation that bears the brunt of these unintended consequences.
If you find yourself leading a powerful, influential department, take the time to fully consider the broader implications of your actions. Addressing your internal challenges should not come at the expense of organisational health. Remember, the decisions you make today can either uplift or inadvertently burden hundreds of your colleagues tomorrow.
which are departments or areas operating in isolated, self-contained mental bubbles [↩]
We all have limits, a certain number of hours in a week that we can devote to intense work or other high-effort activities. This “effort threshold” differs from person to person, but understanding your own threshold is crucial for maintaining a healthy work-life balance.
Why Know Your Limits?
By figuring out how many productive hours you can reliably sustain each week, you can plan your schedule, both work and leisure, without burning out. This concept applies holistically across your entire life, not just your job. For instance, if you love sports or have a demanding hobby, those hours count toward your overall “effort load.”
Personal Effort Threshold
To show you what I mean, here are my own effort levels which I have discovered through a somewhat obsessive level of record-keeping over the years:
Consistent Level: 77 hours of effort per week
This is the amount of time I can devote to various tasks week after week, month after month, without feeling overwhelmed be they Work, Sports, Hobbies or Housework.
Surge Level: 85 hours per week
For one to three months, I can sustain a slightly higher workload.
Sprint Level: 100+ hours per week
This is the maximum effort I can push for about two to three weeks before I need to scale back.
Because I keep detailed logs of my time, mainly for client work and personal accountability, I’ve been able to pinpoint exactly what these levels are for me. Everyone’s threshold will be different, but knowing your own is a game changer for work and life in general.
How to Find Your Effort Threshold
Track Your Time
Keep a detailed record of how you spend your hours for at least a few weeks. Use a journal, a spreadsheet, or a time-tracking app, whatever feels most natural. Identify Patterns
Look for when you feel most productive and when you start to feel drained. Pay attention to both work and personal commitments (like hobbies, exercise, social events).
Set Realistic Boundaries
Once you identify a comfortable range of hours for each week, adjust your schedule accordingly. This might involve saying “no” to certain commitments or scaling back to ensure you don’t exceed your personal limit.
Account for Variety
Remember that a hobby or exercise might still demand energy, even if it’s a mental break from your job. Factor this in when tallying your total effort hours each week.
Adapting to Your Own Limits
It’s normal to underestimate or overestimate how much you can do. Often, we think we can keep sprinting forever, until we can’t. Recognise when you’re in a “surge” period versus a “sprint” period, and when it’s best to stick to your consistent level to avoid exhaustion.
Some of these adjustments can be tough. You may have to let go of certain tasks or delegate more. But ultimately, prioritising your health and well-being is the best long-term strategy.
The Bottom Line
If you ever find yourself exhausted and out of time, it could be that you’ve simply exceeded your personal effort threshold. The key to maintaining work-life balance is knowing how many hours you truly have to “spend” each week, and then consciously choosing how to allocate them.
Put another way: Work out how many effort hours you have, and fit your life within those hours. Doing so will help you stay productive, fulfilled, and far less prone to exhaustion .
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. 1
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.
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. [↩]
