Firefighting is not Startup Culture
Fair warning: this post starts off as a bit of a rant. It's meant to be a something of a cautionary tale, as well as maybe help some folks avoid some of the pitfalls and perils that befall a lot of us.
I've recently been involved with a mass OS upgrade, which also included a long-overdue hardware refresh for user desktops. This particular upgrade wasn't especially big, around 12,000 desktops, but still a sizeable job. Before I go down this path, let me give you a little back story.
History and Background
The team that I belong to is one that I have relatively recently rejoined after a six year stretch at a different company. I left my current team in 2017 for a variety of reasons. One of these reasons was lack of direction and organization. Not the main reason, but one of the biggies. After I left, I went to a company where I was pretty much doing the same thing, and I was able to build a rock star team to get the mission complete, in an organized and repeatable manner. Then came re-org after re-org. After three of these, I was left without a team, and no direction. Basically, getting paid to do nothing. As cool as that sounds, it pretty much sucks. So I started looking around.
I put out feelers everywhere, including my old team (where I work now), and was rushed through the process. Aced the loop, and given a start date. I was really impressed with the new direction the team had taken, and it seemed like they had really gotten their stuff together. I felt I could really contribute meaningfully to the org. I was ready to do good things for the final eight years or so left in my career.
Back in the Frying Pan
Things seemed good at first. I jumped on some projects, helped out where I could, all the usual stuff. About six months in, I started getting queries from my manager about tasks that hadn't gotten done. I was puzzled, to say the least. I have been keeping pretty rigid time and task tracking records since 2011 (see Ophion), so I was puzzled to say the least. Maybe I missed a communication somewhere? No, he had forgotten to tell me about some "thing" that had to be done, or some project that I didn't even know about. He had a propensity for assigning the same task or project to multiple people, without telling them that so-and-so was working on the same thing. But, I digress. It's not complain about your boss time.
Fine. We had a discussion, and I get everything in writing now. If I don't have an email, Slack message, ticket, smoke signal, or morse code, it didn't happen. I hate having to cover my ass like this, but how the heck is one supposed to perform their job if one doesn't know about a task/project/whatever?
Toward the end of that first year, I got my first review. I've been busting my butt for the year, and my records reflected as such. BUT, I got told that I wouldn't be getting any bonus or other renumeration as I had not met a mysterious ticket quota. Being a senior person, I am project based, and don't work many operational tickets. I mentioned that I would redouble my efforts to meet the ticket quota, and open a ticket for everything I did (more time tracking!), but I needed to know what the target was.
Crickets. He wouldn't tell me what the target was. Fine. I now take an hour or two per week and ticket bash. I found all the tickets in our queue that have been languishing for years, test for viability, and close them if they are no longer valid.
Back to Now
As I mentioned previously, there is an effort to upgrade around 5,000 desktops from Windows 10 to Windows 11. Not an especially big update, but not small either. The team has known this upgrade was coming for years. Microsoft has published the end of support date for Windows 10 for years. The team acquired a technical project manager (TPM) to run various projects, including this one. In March of 2025. I got to say, dude has got his stuff together. He has gone above and beyond to get this project under way. The main thing that is blocking this project is the constant firefighting and tech debt. I've been a part of this project. I'm also on two other high profile projects. When September comes around and we are month away from EOL, suddently we are "all hands on deck" for this update project. They are wanting us to work weekends and evenings to get this done, but not let our other projects slip.
No way. This is the main reason I left in 2017. My marriage is far more valuable to me than my job, and I refuse to spend my life in a little room imaging machines due to a lack of action and organization on the part of management. Work to live, not live to work.
There is a great amount of technical debt on this team. There have been efforts to move forward, but items always end up in the backlog. "In the backlog" translates to "it'll go to a list until it is forgotten, then quietly deleted". There is code that I wrote for this team eight years ago, still being used in production. That code was a stopgap, to get us to a compliant state quickly, later to be improved/removed/refactored. It never happened, even though there is a team of developers specifically for this purpose. Why?
Firefighting. Everything is an emergency. We can make plans for everything. However, when there are constant priority emergency things to do, all those plans and projects get put on hold for emergency operations. And when everything is an emergency, nothing is an emergency.
This particular company likes to claim they have been embracing the startup mentality for the last 31 years. Not a typo - thirty one years. This can be a good thing: Get stuff done and iterate often. The problem lies in relying on that philosophy to cover the fact that there are fires everywhere. Some smoldering, waiting to build in to a full-fledged conflagration, threatening to bring down the entire mansion, simply because the problem wasn't addressed when it was small smoldering coals. This happens way too often. Why was it not addressed? Because there was some other brushfire that had to be addressed. Or someone put it in the backlog to be taken care of during the next fiscal year.
To be fair, we've made progress. In March, we started using a project management and resource utilization tool. I use this app religously, tracking everything in it. I've even been asked by Project Managers (PMs) to stop adding so many items to projects. Where this really useful is that your manager can see all the work you've over a time period. All the projects you are working on. In my case, all the operational work that you are doing (I track that stuff, too). So when he asks why Project X is behind, I can point to the fact that I was in a two day escalation for an issue that took precedence over everything else. In eight months, I've logged 1022 task items, covering 1025.5 hours. But, another digression on my part. Sorry about that.
How to Solve the Burn
There is no one size fits all solution. There are only pointers, tips, tricks and the like that we can use to manage time, and help prevent those smoldering coals from becoming a forest fire. Sorry for the bulleted lists. I like them, and they help get the idea across in an expedient manner.
Prioritize Tasks
- Use the Eisenhower Matrix. The Eisenhower Matrix (also known as the Urgent-Important Matrix) is a simple but powerful time management tool that helps prioritize tasks by dividing them into four quadrants based on two criteria: urgency and importance. The problem with the Eisenhower Matrix (in my case) is an inordinate amount of work gets stuffed in to Quadrant 1.
- Quadrant 1: Urgent and Important
- DO IMMEDIATELY
- Examples: Chrises, deadlines, emergencies
- Action: Handle these tasks right away
- Quadrant 2: Not Urgent, but Important
- SCHEDULE
- Examples: Planning, exercise, learning, relationship building
- Action: Set specific times to do these tasks
- Quadrant 3: Urgent, but not Important
- DELEGATE
- Examples: Some meetings, some emails, some phone calls
- Action: Find someone else to handle these tasks
- Quadrant 4: Not Urgent, Not Important
- ELIMINATE
- Examples: Time wasters, excessive social media, mindless browsing
- Action: Minimize or eliminate these activities
- Quadrant 1: Urgent and Important
- Focus on high-impact activities first
- Learn to say "no" to non-essential tasks. Don't be afraid to say no. Don't be a jerk, but come to an agreement with the requester. Schedule the task, or provide an alternate solution.
Plan Effectively
- Create daily/weekly to-do lists
- Block time for specific activities
- Set realistic deadlines
- Leave buffer time for unexpected issues
Use Time Management Tools
- Calendar apps. I use Outlook for calendaring, both for professional and personal planning.
- Task management software. There are many out there, some free, some not.
- Asana - Free for personal use
- Trello - Free for up to ten collaborators
- Monday.com - Free for up to two seats
- Notion - Free for personal use
- Time-tracking apps. Again, tons of the them out there, but I use the one I wrote myself, Ophion. It fits my needs, and I can modify/update as needed.
- Set reminders. You can do this right in your chosen app, usually.
Apply Productivity Techniques
- Pomodoro Method (25 min work, 5 min break). The Pomodoro Method is a time management method developed by Francesco Cirillo in the late 1980s. It's named after the tomato-shaped kitchen timer Cirillo used as a university student (pomodoro is Italian for tomato). The Pomodoro Technique is popular due to its simplicity and effectiveness in combating procrastination and maintaining focus. It's particularly useful for tasks that require sustained mental effort. The basic breakdown of the method is:
- Basic Structure:
- Work for 25 minutes (one "Pomodoro")
- Take a five minute break
- Repeat
- After four Pomodoros, take a longer break (15-30 minutes)
- Steps:
- Choose a task to work on
- Set the timer for 25 minutes
- Work on the task until the timer rings
- Put a checkmark on a piece of paper
- Take a short break (5 minutes)
- Every four Pomodoros, take a longer break
- Key Rules:
- If a task takes more than four Pomodoros, break it down in to smaller, more manageable segments
- If you finish a task during a Pomodoro, use the remaining time for overlearning (reviewing or improving your work)
- Once a Pomodoro starts, it must ring. No pausing allowed
- Benefits:
- Improves focus and concentration
- Reduces mental fatigue
- Increases awareness of how you spend your time
- Enhances productivity by breaking work in to smaller, more manageable chunks
- Helps balance work and rest
- Adaptations:
- Some people adjust the time intervals to suit their needs, for example 50 minutes of work with 10 minute breaks
- Basic Structure:
- Time blocking
- 2-minute rule (if it takes less than 2 minutes, do it now)
Minimize Time Wasters
- Limit social media use
- Batch similar tasks
- Reduce unnecessary meetings
- Control email checking
Take Care of Yourself
- Get enough sleep
- Take regular breaks
- Don't multitask
- Maintain work-life balance
TPMs are not Operations Managers (and Why It Matters)
One other key issue I've observed in environments like this is a blurred understanding of roles - particularly between Technical Program Managers (TPMs) and Operations Managers. It may seem like a minor distinction, but when everyone is scrambling to put out fires, not having clear role definitions can make the chaos even worse.
In a well-organized setup, TPMs and Operations Managers each play distinct, but complementary, roles. TPMs are focused on the strategic side - coordinating and delivering large technical initiatives across teams. They are the planners and big-picture thinkers, ensuring that complex projects stay on track. Operations Managers, on the other hand, are focused on the day-to-day functioning of systems, troubleshooting, and maintaining operational stability. They ensure that things are running smoothly in the present, so the TPMs can focus on driving the future forward.
But when these roles get confused or mixed up, it can feel like everyone is trying to juggle the same responsibilities, resulting in confusion and inefficiency. For example, a TPM might be tasked with firefighting operational issues, when their true strength lies in managing projects and leading teams through strategic growth. Meanwhile, operational staff might be pulled into long-term planning, which can detract from their focus on keeping systems stable and functional.
This misalignment can lead to even more “urgent” tasks piling up, without anyone taking ownership of the ongoing fires that keep popping up. The result? More work, more stress, and less clarity.
A healthy, functional organization knows the difference between these roles - and so does everyone in it. When you blur those lines, you’re just adding more weight to the fire, without ever putting it out.
Documentation
This is possibly one of the biggest soul crushing tasks for technology professionals. There are some folks who enjoy it, but the majority of us really, really do not like performing this necessary task of our field. Documentation is important. No, really. It's not just something squirt out and put it in a file share or a binder somewhere, forgotten for the remainder of time. Good documentation can alleviate your own workload, and make things easier for those that need the extra help.
Take a look at the Eisenhower Method above, specifically Quadrant 3. That is the Not Important, but Urgent task items. Basically, the task needs to get done, but it doesn't make a huge splash. It might be a small cog in a big wheel, where other tasks are dependent on it being done. The key point is that task can be delegated. That means you can give that task to someone else to perform, thereby freeing you to work on other tasks.
But how does that person know how to do that task? Documentation! If you assign a task to someone, that task should include relevant documentation to get that task done. It could be as simple as "open that app, click this button, be done". Or it could be a full build for a service, that includes sub tasks. I myself have written some "by the numbers" documents that show how to build a service from nothing, and continue to use them to this day (with modifications, of course). Makes for easy success for the team.
Heck, this web site started off way back in 2005 (twenty years already?!) as a way to leave notes for myself, about how to do different things. And here we are.
In short, documentation is a method to get work off your own plate, and put it on someone elses plate. This can also be a good CYA method, in that if you delegate a task or process, and the person you delegated to was not successful, the first thing that you can ask is, "Did you follow the process?" If they didn't follow the process tell them to go do it again, following the process this time.
Alright. Rant over. Sorry for the wall of text and rambliing discussion. Just something I wanted to get off my chest, and maybe some of the things I have shared might help someone out there.
If you have any time management, career development, or general sanity tips, share 'em in the comments. That's what they're their for.
An remember, just because your company claims to have a "startup culture" does not excuse the constant firefighting and technical debt. It needs to be solved, and it can be a big problem. Make the tech work for you, don't work for the tech.
Loading Comments ...
Comments
No comments have been added for this post.
You must be logged in to make a comment.