6 ms·

In defense of remote work underperformers in general, I work for a company with a lot of tribal knowledge. It shouldn't be that way, but that's how the company

In defense of remote work underperformers in general, I work for a company with a lot of tribal knowledge. It shouldn't be that way, but that's how the company operates and our pleas for time/money to write adequate internal documentation fall on deaf ears (doesn't help that it's legacy software so there's not many people capable of writing said documentation). Result is there are a few wise old (as in 15-20+ years experience) veterans who know the "deep magic" of how the software works, but they also tended to be the least available online during our year of WFH (with some exceptions). In the office the culture for accessing these guys was: Ping with slack DM/skype, if they don't answer in 15 minutes walk over to their desk and bend their ear, unless they were clearly working something more important at the moment. Sometimes there would even be short lines of people outside of their cube waiting for attention. There was an organic interrupt-driven workflow for these experts because they were in so much demand (with occasional pauses in access if they were working on something time-critical). That whole workflow collapsed under WFH, and as these veterans were used to operating on their own/managing their own time roughly half of them failed to be readily available online. This led to issues for people like myself where we needed some piece of their knowledge but just got radio silence for hours, sometimes days. So you pick up some other work to fill in the gap while you wait for a response, but that leads to inefficiencies of its own once they actually do get back to you. Once I had a cascade of about 6 stories going in parallel because I kept picking up alternate work to fill gaps, only to get to a point in THAT work where I needed some tribal knowledge, so I pinged the appropriate SME, waited several hours, picked up another task in the meantime... etc And leadership lacks any carrots/sticks to make these guys accessible aside from asking nicely. They're largely where they want to be for their careers, value their time, and have all the truly vital knowledge so they can't really be punished lest they leave the program. Sadly I suspect my company's organization is closer to the average than yours, so lots of other companies fall into this boat. It's not always a matter of discipline :)

barrysteve 4y ago
I've seen this pattern recently outside of software. This kind of "tribal capture" lead to mediocrity and nepotism. The untouchable tribal leaders fostered an environment where unpleasant roles were left understaffed until 'lower people' were subtly manipulated into taking them, who then left. It created a revolving door of staff that otherwise would have made good contributions. Management in response to the turn over, shut down critical thinking about the staff and just committed to the problematic structure.
- scottLobster 4y ago
  Yeah that accurately describes my workplace as well. The revolving door of "lower people" you mention is very real. I'm one of those "lower people" and I've definitely been shifted into the work no one else wants. To be fair I was fresh out of college and took the "volunteer for the work no one wants to earn respect" route, and it did earn me some respect, even a promotion and a pay bump. But after a couple of years of trying to push further it's clear there's a ceiling, and my only chance of doing any of the interesting work is waiting for the old men to retire/leave, and then I'll likely be dumped into the deep end to figure things out myself, under extreme time pressure because critical stuff's breaking and I have 25% of the knowledge necessary to fix it, which makes me the remaining program "expert" :P I'm sticking around for personal/defensive reasons (it's stable and recession-proof, and I have a one-month old so moving would be extra stressful for the family), but I doubt I'll stick around for more than another year or two. My turn for that revolving door is coming up
bornfreddy 4y ago
Interesting. This aligns with my past experience as well. If I may ask, are you / is the company working on rectifying this, and if so, how? What we did was that we made our internal docs and agreed that whenever we were blocked by something, once we learned it, we would document it. It was a mixed success though because we never had time to work on the docs properly, and the veterans didn't touch it, so I'm curious if there is a better approach.
- scottLobster 4y ago
  Yeah we're trying to do the same, document things organically as we learn them on an internal Confluence. It helps, but we're piecing together fragments of knowledge without context, so information density is low outside of specific tasks. It's enough to solve the same problem again, but not enough to gain much holistic knowledge of the software. And same as your situation most of the veterans don't bother with it (they already have the knowledge and are extremely busy). Doesn't help that some of the engine code dates back to the late 80s, was originally written on a mainframe for a compiler where variable names had character limits, so even if you know the surrounding conceptual terminology it's functionally indecipherable unless you have a lot of experience with it. It's hard to tell what it's doing or why, or even if it's relevant to the problem you're trying to debug. What we really need is something like a dedicated sprint where we stop the presses outside of critical maintenance and just write documentation, free up the veterans to write down their knowledge. But that would require the company to actually invest in what is otherwise seen (wrongfully IMO) as a cost-center. :P And honestly if we had that kind of money there's other software redundancies/inefficiencies that need to be resolved first, that would lower the documentation requirements in the first place.
  - bornfreddy 4y ago
    I hear you! Thanks for sharing.

barrysteve 4y ago

I've seen this pattern recently outside of software. This kind of "tribal capture" lead to mediocrity and nepotism. The untouchable tribal leaders fostered an environment where unpleasant roles were left understaffed until 'lower people' were subtly manipulated into taking them, who then left. It created a revolving door of staff that otherwise would have made good contributions. Management in response to the turn over, shut down critical thinking about the staff and just committed to the problematic structure.

scottLobster 4y ago
Yeah that accurately describes my workplace as well. The revolving door of "lower people" you mention is very real. I'm one of those "lower people" and I've definitely been shifted into the work no one else wants. To be fair I was fresh out of college and took the "volunteer for the work no one wants to earn respect" route, and it did earn me some respect, even a promotion and a pay bump. But after a couple of years of trying to push further it's clear there's a ceiling, and my only chance of doing any of the interesting work is waiting for the old men to retire/leave, and then I'll likely be dumped into the deep end to figure things out myself, under extreme time pressure because critical stuff's breaking and I have 25% of the knowledge necessary to fix it, which makes me the remaining program "expert" :P I'm sticking around for personal/defensive reasons (it's stable and recession-proof, and I have a one-month old so moving would be extra stressful for the family), but I doubt I'll stick around for more than another year or two. My turn for that revolving door is coming up

bornfreddy 4y ago

Interesting. This aligns with my past experience as well. If I may ask, are you / is the company working on rectifying this, and if so, how? What we did was that we made our internal docs and agreed that whenever we were blocked by something, once we learned it, we would document it. It was a mixed success though because we never had time to work on the docs properly, and the veterans didn't touch it, so I'm curious if there is a better approach.

scottLobster 4y ago
Yeah we're trying to do the same, document things organically as we learn them on an internal Confluence. It helps, but we're piecing together fragments of knowledge without context, so information density is low outside of specific tasks. It's enough to solve the same problem again, but not enough to gain much holistic knowledge of the software. And same as your situation most of the veterans don't bother with it (they already have the knowledge and are extremely busy). Doesn't help that some of the engine code dates back to the late 80s, was originally written on a mainframe for a compiler where variable names had character limits, so even if you know the surrounding conceptual terminology it's functionally indecipherable unless you have a lot of experience with it. It's hard to tell what it's doing or why, or even if it's relevant to the problem you're trying to debug. What we really need is something like a dedicated sprint where we stop the presses outside of critical maintenance and just write documentation, free up the veterans to write down their knowledge. But that would require the company to actually invest in what is otherwise seen (wrongfully IMO) as a cost-center. :P And honestly if we had that kind of money there's other software redundancies/inefficiencies that need to be resolved first, that would lower the documentation requirements in the first place.
- bornfreddy 4y ago
  I hear you! Thanks for sharing.