This has been a recent learning for me. In my experience, there are two broad styles of project management:
The teeth-gritted, head-down “just get it done” approach.
The status heavy, constant updates, emails to stakeholders, meetings and escalation approach.
These camps tend not to like each other. I’ve spent most of my career firmly in the first: solve the problem, keep moving, minimal noise. That’s often exactly what clients want, a fix, quickly, with as little fuss as possible.
Historically, I saw the “status update” camp as unhelpful: lots of escalation, senior management getting dragged in, tempers frayed, and, in the end, someone still has to grit their teeth and fix the thing. But I’ve come to appreciate that they provide a vital function: awareness.
If you can resolve an issue quietly, without additional cost and with no material risk, then yes, get it done and move on. However, if the fix will incur more than minimal cost or expose the client to more than minimal risk, there must be full awareness. Simply generating noise isn’t useful; it just makes people anxious, but silence in the face of material impact is worse.
A competent manager does both. Do the head-down work to understand the problem and shape a solution. Once you have a plan, validated with subject-matter experts and the business, raise awareness calmly and clearly. Make stakeholders aware of the implications and the risks, alongside the proposed path to resolution.
A note for anyone hiring PMs: you want people who can do both. Perpetual flappers add little value. Perpetual silencers can cost you dearly over time. Aim for professionals who are strong on delivery and strong on communication. This isn’t an either/or. It’s both.
In the world of project management, we often focus on timelines, budgets, and stakeholder communication. However, there’s one critical skill that frequently gets overlooked:
The ability to do your own footwork and status checking. When you can independently investigate, gather insights, and verify information, you become far more effective in your role and less of a burden to your team.
As a project manager, you should be able to:
Track and raise issues and tickets with whatever system your client uses (ServiceNow or what have you).
Track sprints and work allocations in Jira (or any other tool) for any team, not just your own.
Review automated business process statuses (success or failure) after a new release goes live.
Understand logs at a high level, even if you’re not the one managing a system.
You might not need to dig into every technical detail (like sifting through Apache logs), but you should know where to look and what to look for.
Most modern project management and cloud-based tools offer robust logging, reporting, and monitoring features. If you have the right access, you can keep tabs on your project without constantly interrupting your team.
How Research Skills Make You a Better Leader
Stay Informed
Having the ability to quickly pull reports or check logs means you’ll have a real-time understanding of your project’s status. You’ll be the first to notice if something looks off, which gives you a chance to investigate further and proactively address issues.
Avoid Getting Deceived
When you rely solely on others to inform you of problems or progress, you risk missing critical details. By verifying information yourself, you’ll be much harder to mislead, intentionally or unintentionally.
Ask Better Questions
Instead of starting a daily stand-up or group chat with, “Where are we today?” do some quick research beforehand. This allows you to ask more targeted questions, which leads to more productive discussions and less frustration for everyone involved.
Earn Your Team’s Respect
Your project team members are often subject matter experts; they expect leadership that understands (at least on a basic level) how systems work. By showing that you can pull a quick report, interpret the data, and escalate issues properly, you’ll gain credibility.
Getting the Right Access
One of the biggest barriers to doing your own research is lack of access. If you’re unsure of how to proceed, follow these steps:
Request Reader Rights
Even if you can’t edit or contribute to certain systems, having reader rights allows you to see logs, ticket details, and reports. This is usually enough access to get an overview of what’s happening.
Learn Basic Navigation
Make sure you know how to navigate the tools your team uses: ServiceNow, Jira, etc. Practice pulling standard reports and locating the areas where jobs or tickets might be flagged.
Stay Updated
Tools change frequently, and new features are added all the time. Keep yourself updated on any new views, dashboards, or analytics that might help you monitor your projects more effectively.
Contributing During a Crisis
In critical situations, like a production outage, tensions run high. Instead of interrupting your team’s efforts to fix the issue:
Dive into the logs yourself.
Check job statuses, error messages, or recent updates so you can give higher-level managers real-time updates.
Consolidate Findings.
Summarise the situation for senior stakeholders, reducing the time your team spends reporting.
By doing so, you become a valuable contributor rather than an extra layer of overhead. You free up your technical experts to focus on solutions, while you handle stakeholder communication and status updates.
Final Thoughts
Doing your own research doesn’t mean you need to become a full-fledged developer or system administrator. However, by taking the initiative to learn basic investigative skills, you’ll:
Make more informed decisions.
Command greater respect from your team.
Present clearer updates to stakeholders.
Minimise downtime in a crisis.
Ultimately, self-sufficiency in information-gathering is a game-changer for any project manager. Challenge yourself to gain basic reader access in all key project tools, and practice using that access daily. The payoff in efficiency, respect, and overall project success will be well worth the effort.
Welcome back to part two of our real-life series on moving technology from on-premise systems to the cloud. This post follows up on my previous entry, highlighting additional hidden challenges often encountered during cloud migrations. Many of these issues can in recent years, stem from the maturity of cloud infrastructure, which is now complete with its own established processes and methodologies. Let’s get started:
1. Outdated Methods May No Longer Be Supported
One common challenge arises from previously acceptable practices or technologies becoming obsolete, especially concerning security protocols. Methods that evolved naturally over the years in an on-premise environment may now be explicitly disallowed in the cloud. Whether it’s due to new compliance regulations or discovered security vulnerabilities, practices you’ve relied on for decades might no longer be viable. It’s essential to collaborate proactively with your security team. Security departments often focus strictly on what is disallowed rather than proposing alternative solutions. Engaging them early in the migration process ensures practical and secure solutions are developed, especially when dealing with existing system integrations and established support procedures.
2. Loss of Assumed Features
When operating on-premise servers, many built-in features are taken for granted, such as logging, connectivity, remote access tools, and even physical infrastructure integrations. Virtual servers, Docker instances, or cloud-based platforms often lack these default features, requiring additional setup or third-party solutions.
A notable real-life example includes systems that rely on physical hardware integrations, like emergency pagers plugged directly into servers. Transitioning such setups to the cloud can become complicated and costly, potentially requiring extensive system rewrites or redesigns.
3. Hidden Re-coding Costs
Migrating legacy systems often involves substantial rewriting. In some cases, the original platform or coding language is unsupported in modern cloud environments, necessitating a full rebuild of the application. These hidden recoding costs can escalate quickly, making a simple “lift-and-shift” virtual machine approach sometimes the only feasible short-term option.
4. Bandwidth and Communication Chatter
On-premise systems often generate substantial communication noise, particularly regarding data storage and retrieval. Because bandwidth was essentially free and readily available locally, efficiency wasn’t a priority. However, in cloud environments, such frequent communication can incur significant costs and performance issues.
Evaluate how your existing systems communicate and store data. Modern cloud solutions may require optimised, efficient communication patterns to avoid inflated expenses and ensure long-term sustainability.
5. Day-to-Day Maintenance Costs
On-premise systems often conceal maintenance costs within periodic capital expenditures, typically every three to four years, covering licenses, hardware, and infrastructure. Conversely, cloud environments shift to recurring monthly costs, which can accumulate unexpectedly if not accounted for upfront.
To avoid financial surprises, thoroughly analyse the ongoing costs of cloud infrastructure, licensing, and resources before migrating. Accurate budgeting helps mitigate unexpected expenses and ensures smoother operational planning post-migration.
Summing Up
Sorry to add more items to the problem of moving to the cloud, but these are worth considering when you work out how you will move an older application to an existing and established cloud platform.
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.
