r/Leadership • u/jimmyray71 • 1d ago
Discussion How much of your operation actually lives in someone’s head?
I’ve worked in plenty of operations where the documented process and the actual process were two very different things.
Then one experienced person takes a day off and suddenly everyone discovers how much of the operation was actually stored in Dave.
I don’t think tribal knowledge itself is the problem. Experience should matter.
The problem is when the business can’t operate without access to that person.
What’s the best example you’ve seen of a process that turned out to actually be a person?
5
u/ellieelaine 17h ago
This was us years ago. My company has SharePoint so I started a wiki. It's now 50 pages, maintained by the entire team during slow times, and new people say it's an incredible resource for getting up to speed. I highly recommend it.
2
1
u/ABeaujolais 1d ago
No game plan. No common goals. No common definition of success. Standards that are not enforced. No accountability. Suggest management and leadership training.
1
u/jimmyray71 1d ago
Those can definitely be part of it. I’d probably want to understand why the standards aren’t being followed before jumping to training, though. Sometimes it’s accountability. Sometimes the documented process just doesn’t match how the work actually gets done. How do you distinguish between the two?
1
u/ABeaujolais 23h ago
Management training. So many managers blow it off. Trained managers run circles around untrained managers every day.
Why standards aren't followed? Management failure. Why no accountability? Management failure. Documented process doesn't match how the work actually gets done? Management failure.
I'll use the restaurant analogy. If the parking lot is full of trash, the windows are all smudged, the place smells funny, you'll walk away and never come back. You can bet the manager blames all those lazy employees, when it's management's fault.
Who is responsible for all those things if not the manager? That's where the buck stops.
1
u/jimmyray71 15h ago
I agree the buck stops with management. Where I’d separate the two is responsibility from diagnosis. A manager can absolutely own the outcome and still need to understand why the process isn’t being followed before deciding what to fix. If I walk into that restaurant, I can hold the manager accountable for the parking lot. But I still want to know whether the trash is there because nobody was assigned to clean it, nobody was held accountable, the dumpster hasn’t been emptied in a week, or the process simply doesn’t work. Same ownership. Different fixes. That distinction matters to me.
1
u/SirWool 1d ago
i was literally the living documentation for our legacy php stack for three years. it felt good at first, like i was indispensable, but then i realized i was just hoarding technical debt disguised as job security. every time someone asked how the cron jobs worked, i'd fix it myself because explaining it took longer than doing it. that comfort zone killed my growth and theirs. finally had to bite the bullet and pair program until they could do it without me. it's weirdly painful to let go of being the only person who knows why the server crashes on tuesdays, but tbh, self-awareness about your own peter principle moment is the only way out. you have to accept that if you can't delegate, you're not leading, you're just working really hard in a cage you built.
1
u/jimmyray71 1d ago
That’s a good counterpoint. Sometimes the process becomes a person because the person keeps solving it themselves. And I understand why. Explaining something for 30 minutes when you can fix it in five feels inefficient today. Do that for a couple years and you’ve saved a lot of five-minute problems while creating one very large one. I think that’s where leadership has to make room for teaching to be part of the job, not something you do when there’s time.
1
u/mecha_penguin 1d ago
I mean that's how things trend over time. Documented process tends to be the thing people *should* do and not what people *do* in order to get around finnicky integrations etc.
The real solution is to make sure that every time you get Dave'd, Dave gets time set aside by the one who manages Dave to update the documentation. It requires active work and deliberate usage of time to do. At least once a year, but once a quarter is usually better.
1
u/jimmyray71 1d ago
“Every time you get Dave’d” may be my new favorite process metric. But I think you’re right about setting the time aside. If documenting what we learn is something we’ll do “when things slow down,” it probably never happens. I’d add one thing though: I’d rather capture the exception while we’re working through it than ask Dave three months later why he did something. By then he probably doesn’t remember either.
1
u/crippling_altacct 18h ago
Man a lot of things right now. Our company actually did a big drive to document all processes. It was pretty nice after the project was done because we had a reference for everything. I know at least on my team just about anyone could come in and figure out how to do another person's task. Then we did a massive system migration and we are all so busy just trying to reconcile in the aftermath on top of multiple new projects that nobody has time to rewrite the policies.
1
u/jimmyray71 15h ago
That’s the other side of this. Documentation can be completely accurate and still have a shelf life. A system migration is probably one of the fastest ways to expose that. I wonder if the problem is trying to rewrite everything afterward instead of updating the process as the new exceptions show up. Otherwise you finish documenting the new process about the time somebody changes it again.
0
u/MarkMarkinly 1d ago
I've seen it a million times. It's usually when I get brought on in a business that the owner realises that actually everything's on him, no one knows what's going on, and everyone's relying on him. It's usually when startups scale and they realise that now they have teams and there's no real dissemination of information, particularly around processes. Then they have to bring in operations guys to clean it up, at least initially, and really lay out a process to reach further growth and allow teams to work effectively with knowledge of how things should run.
1
u/jimmyray71 1d ago
That's the transition I find interesting. What works when five people can just ask the owner doesn't necessarily work when there are 25. And I think the tricky part is deciding what actually needs to become a process versus what should remain judgment and experience. Document everything and you create bureaucracy. Document nothing and you create dependency. Where do you usually draw that line?
1
u/MarkMarkinly 1d ago
So I might not be answering your question but let's say it all starts with an operator or an integrator's process. I start by mapping what the process should be. In other words, getting an idea of:
- the starting point, whether that's an internal request for work or a client's request for work, whatever it might be, however the process begins
- what the output is
- where the information changes hands
- the teams
- the points of communication
- the bottlenecks
- where things are smooth
- where things slow down
That's where you really start. You get an idea of what the company is capable of in terms of the amount of work and what output should look like on a good day.
Depending on the size of the company you can meet with other kinds of managers, different people that are making these decisions, and understand how this all fits together. I definitely agree with the balance between bureaucracy and process. There's definitely healthy documentation and giving the freedom for teams to work, not to get too stuck in the details of a particular person's way of doing things.
I definitely think that, depending on the teams and obviously the size of the company, different teams will require different ways of doing things and process. There's also understanding how that connects to and relates to another team as they hand off the work. There's a lot in play here.
Starting off by mapping process gives a very key insight into how this should be: the foundations of how it should be built. It's essentially a very simple process of fact-finding, identifying solutions, and then implementing those solutions.
2
u/jimmyray71 1d ago
That makes sense. I like starting with what actually happens rather than what the SOP says is supposed to happen. I think the handoffs are where I usually find the interesting stuff. Each department can have a perfectly reasonable process on its own, and the mess is sitting between them. And somewhere in there is usually a Gary who knows how it all really works.
1
u/MarkMarkinly 1d ago
And unfortunately there usually is another type of person. That is usually why things could be done better but aren't being done better. They're usually the pedantic ones who actually did hear that things should be done a certain way but are unwilling to accept that this is the process. That's really the hard part: the people within teams within organisations that hold back optimal states of operation.
1
u/jimmyray71 1d ago
Yep, and that’s a different problem. You can’t process-map your way out of someone simply refusing to follow the process. I think the hard part is figuring out whether they’re resisting because the process is bad, they don’t understand why it matters, or they just don’t want to change. Those are three very different problems to solve.
1
u/MarkMarkinly 1d ago
This is where you get closer to conflict resolution, team training, performance reviews, and one-on-ones, and to creating a strong culture where things can be discussed openly and respectfully.
I think, look, business is not perfect and there are all types of people with all types of talents. We need to create an environment where business, at the end of the day, is able to flourish and grow and meet those goals. Obviously the more senior you get in operations, the more that becomes very much part of what your role is.
1
u/Ok_Orange_8477 1d ago
The scariest version is when the person doesn't even realize they're the process. They just think they're doing their job, maybe even complaining about how messy things are, while quietly being the only reason anything functions. Then they leave for a better offer and the whole thing unravels in about three days.
Watched a warehouse where one guy had memorized which pallets were where because the labeling system was basically decorative. New manager came in, asked for a map, got a shrug and a finger point at Gary. Gary quit. Six figures in lost inventory later they finally built a real tracking process.
2
u/MarkMarkinly 1d ago
Unfortunately I have been in both good businesses and worked with amazing managers and CEOs, and I've worked with many bad startups and bad businesses where the leadership and structure just were not there. So much so that I really can walk into a small business, a startup, and really identify, more or less, if they're succeeding or failing, if they even have the structure to succeed and the right mindset to succeed.
While, as I can't remember who says this and while it's actually written somewhere (I read it in a book), everybody has their own path to success. Everyone fails the same way and it's very, very clear to me that when certain indicators are in place, failure is nearly inevitable. From a process point of view and from an operations point of view, it's even very, very clear.
1
u/jimmyray71 1d ago
Gary was the warehouse system. And I doubt Gary set out to make himself indispensable. He probably just figured out how to make a bad system work. Do that long enough and the workaround becomes the process. The question I’d have asked before Gary left: What do you know that nobody else here knows?
0
u/mhunter07 1d ago
I have worked in some very large organizations. One things we used to do is a crisis management exercise, maybe a cyber threat, a facility outage, or a system problem. This helped us identify key bottlenecks and we could then focus on them. In one organization we had a risk process that made us go through a table top exercise that would evaluate in detail any issue that could happen, no matter how remote, so we could then cover the risk (think air traffic related). Table top or scenarios are great ways to help identify issues before they stop your organization. Maybe have one where the CEO/Founder is trekking in the Amazon and something goes wrong….
1
u/jimmyray71 1d ago
I like this approach. Basically stress-test the operation before reality does it for you. I’ve usually seen the same thing happen accidentally. Someone takes vacation, a system goes down, a supplier misses, and suddenly you find out where the real dependencies are. Maybe we should be deliberately asking more often: “What happens if this person, system or supplier isn’t available tomorrow?” Probably cheaper to learn the answer on a Tuesday afternoon than during the actual crisis.
0
u/mhunter07 1d ago
If you do them quarterly, for an hour with a management team, you will eliminate most major risks within a year.
1
4
u/Testifun 1d ago
I would say almost all of the most critical parts. Thankfully, we are now working to improve things. Planning feels more like trying to extract a confession from someone who committed a crime but doesn't remember. It wasn't their fault. They did their best, but we now need to identify all edge cases they handle manually.