The Case of the Missing Kingpin: Situation Normal, All Frustrated Uproar
OTW voting is commencing, and there's a lot of stuff going down and a lot of information badminton, and I am very very glad that I am on the sidelines for this, because it sounds like a deeply political situation with hurts decades old getting tripped over and new wounds happening every minute, and those scare the fuck out of me.
I haven't become a member of the OTW yet, although I should at some point; goodness knows I read in the Archive enough, and I am deeply invested in the idea of grabby corporate entities not being able to legally control things done for love and not money.
skud has a very thought-filled entry on some of the practical aspects of running a large project, including some of the ways that the AO3 differs from the norms of the FLOSS community, and why this can be alienating to an outsider and actively bad from a code standpoint: Github, transparency, and the OTW Archive Project. I do wonder if some of that is on purpose (I suppose that making sure that everyone who shows up is committed enough to stick around for a while through the sign-up process is a thing, though it does deter the people who just wanted to fix a typo), but Skud's point about distinct branching and small commits to ensure that if there's a problem it can be rolled back is very very very on the nose.
xb95 wrote On the care and feeding of volunteers. *draws hearts around it* When a person leaves, the team is down a person. They may or may not be down the job functions, depending on who can step in or be trained up, but that person's missing. It's essential to not dehumanize that person by reducing them to their job function, even if people outside the organization only see what they do, not who they are.
elements has a long thing about how a culture where one person steps up and does all the work is not a viable long-term strategy.
I do have thinky-thoughts about large projects and interpersonal dynamics, particularly about projects where a few extraordinarily talented and/or extraordinarily hard-working people contribute a disproportionate amount of the work well after the time when someone else should be there for backup.
"Hit by a bus" is a valid worry. People, even young able-bodied energetic people, die of all kinds of things. More common than sudden death is sudden unavailability -- other projects, sudden illness, vacation, quit, went to Costa Rica with the Peace Corps, new child, something that was thought not to affect availability but suddenly was, won the lottery and no longer interested in this job -- and unless it was a known and planned thing, or unless there was someone trained as backup, suddenly there's scrambling. Open-ended unavailability is especially difficult to deal with.
Getting a new person up to speed takes an adjustment period. Usually it requires more than one person to actually fill the shoes of the missing person, because they were doing two to three people's work. There's social adjustment as all the people get used to the new person and new dynamics.
An organization with scarce resources and/or bad problems may try to replace one person doing a superhuman job with one person doing a human job. They may be baffled when it suddenly doesn't work. In bad situations, they'll blame the new person and say that they're underperforming when there's simply too much work, or the work is too complex, to be reasonably handled in a workday with the given resources, or blame the team when they no longer have the level of support that they are accustomed to.
It's hard to get around one person doing a whole bunch (echoing back to
elements' entry) at the beginning, when everyone is still figuring out what actually needs doing. Once the whole system starts actually functioning is the opportune time to say "All right, I think this is working, now what is everybody doing?" and document what is going on and who is doing what. This includes the little unofficial things: motivational speeches to people who are feeling down, sending pizzas over the internet, monitoring the chat and making sure that all the informal training makes it into the formal documentation. If someone needs a replacement or substitute, the organization should know what they actually do.
Creeping unavailability, where someone vital either has their availability reduced, or is temporarily gone, and continues to be in and out, is more insidious than a sudden departure. When they are expected to be back and fully available Any Day Now, their responsibilities are left mostly untended. They may have no viable backup ready to step in.
Partial availability: this week, the superhuman in charge of Department X is fine, and Department X is running merrily. Next week, this kingpin catches a cold. "No problem," says Department X. "We're doing OK, the supervisor has had a cold before, we will take care of the routine things ourselves, and save the things that it is vital that our supervisor to do for next week, when our supervisor will return to us."
Next week, the kingpin supervisor is amazingly stacked up with the stuff that went down in the sick week, even with the department taking on some of it, so much so that the department decides that it's not appropriate to pile on ALL the things that went down while the supervisor was taking care of the backlog, and they will reserve some of the stuff that they decide is less crucial until a better time. After all, they have seen for themselves what happens when someone comes back and WHUMP, here's an overwhelming load of work, so they take it upon themselves to become human load balancers. Unlike a functioning server stack, there's nowhere else for the human load balancers to turn except to ignore things or save them for later. Team chatter starts to include "let's not worry the supervisor with Y and add to the workload". Sometimes Y is stuff the supervisor is formally expected to handle. Sometimes Y is just something the supervisor handles as an unofficial part of smoothing the team's function. Either way, "We're all adults here, so while Y is bothering us, it's not really important; we don't need to be immature about it, we can work around it," is a team digging themselves deeper.
The backlog's nearly caught up, and boom, another bad cold. The supervisor manages to do all of the things that the formal job description requires, but things remain unreported, and the small above-and-beyond touches that made them the kingpin don't happen. Issue Y never gets addressed, and coping with it without complaining about it to the supervisor becomes an invisible part of the workload of the whole team. Now that it's an ongoing issue, it's no longer a tiny thing not worth disturbing the supervisor with. It's a huge issue, and it's not fair to the supervisor to dump a monster like that upon them while things are still awful. New arrivals to the team get unofficially briefed about issue Y and why we don't talk about it, or get smacked down when they bring it up.
Human issues are particularly likely to build up. One of the team brings their bullet-head buddy to a regular unofficial get-together. Wouldn't you know, the buddy winds up drinking wayy too much and some political discussion in the kitchen leads to him saying something unbelievably racist. The party breaks up in shouting and apologies. Things aren't the same between the team anymore because no one is sure how that person justifies standing by their racist friend. The supervisor wasn't at the party and doesn't realize exactly where the party ended, what got broken, or how it could be mended.
Apologies to They Might Be Giants.
Trust is essential to sharing human issues with a supervisor. Long-running issues that have never been addressed are less likely to be reported when they crop up again, because there's a history of nothing being done. It doesn't matter where the cycle started. When the cycle of leaving stuff unreported gets going long enough, it's hard for the team to start reporting the backlog again. It's especially hard when the supervisor is still very busy, still sneezing miserably, still spending the lunch hour locked in the office with the lights off instead of out mixing with the team and sharing jelly babies.
The supervisor gets out of touch with the team dynamics, and the team may go out of their way to pretend that nothing is wrong in front of the supervisor.
(This also gets harder when the team is close to the supervisor on a personal level, as often happens when a group gets built out of who happens to show up voluntarily -- people are going to make friends, and people are going to bring their friends, and when your friend is complaining when you hang out for weekend coffee that the workload is killer while trying to cope with sick/new baby/etc., you don't want to be the heartless person who says "Oh by the way, here's Issue Y, which started just before the stuff started to go down, and now it is a huge human-eating horror that we have been deliberately concealing for you for three months. Welcome back!")
Even when there's a substitute in, human issues are still hard. With the regular supervisor under normal circumstances, there's enough of a rapport that one can go into the office, shut the door, and say "Hi, I like my teammate B a lot, but he carpools with his skeevy racist friend. I keep running into the racist friend in the break room. Can you make him make his buddy stay in the car?" There's not the same level of comfort with the substitute, and the substitute may not have the whole sordid history and may tell you to suck up and keep ignoring him. They may also say "Sounds complicated, but not urgent. Your regular supervisor will be back soon, and you can bring it up then, is that OK?"
If the substitute doesn't pass the incident on to the regular person when they come in, regardless of whether they told the team member to take it to the regular supervisor, it risks slipping through the cracks, because nerving up to talk about it once is hard enough, and unless the regular supervisor brings it up, it may remain basically unreported.
(Again, when the supervisor is close to members of the team on a personal level, this can prove problematic. However uncomfortable it is to tell your supervisor that teammate B's best buddy and you need to stay far far away from each other, it's more awkward when the person you've got the issue with is closer to the supervisor than you are. So you and teammate C have been working poorly together and furthermore having screaming fights that you're 99% sure are C's fault, and your supervisor and C are drinking buddies. Will your supervisor take you seriously? Will your supervisor do anything about it? Will your supervisor and C both wind up pissed off with the world for a month and make everyone miserable? So you do nothing until you're sure that you've got the documentation to back it up. When C subsequently yells at the receptionist in the lobby which is the final straw and you get fed up and take a swing, you're the one in trouble, twice over. First, you shouldn't punch your co-workers, and second, how did you let things between you and C get to that level without reporting it?)
Once a team stops telling supervisors when stuff makes them uncomfortable, it keeps going merrily on until something acts to change that. It also spreads. If the person in charge says "eh, we're not going to change it" or indicates "I can't handle that now" too often, whether it's policy, process, software, hardware, eventually the team that gets reports of broken and broken-as-designed things stops reporting back up, because nothing's ever going to happen. This is toxic.
Volunteers have an out that regular employees don't. If conditions become unbearable, they can up and quit: without having to find a new position, without notice, even. An atmosphere where volunteers are talking among themselves about how much worse conditions would have to get before they bail is not at all cheerful or helpful. Combine that with pressure from the outside and you get an entrenched ball of resentment, trapped between supervisors who don't listen and users who want all the new features but everything to stay the same.
Missing people cause problems. They took on a project, and then stopped work without actually resigning or giving an update on when they were coming back. This is more of a problem for loosely-organized volunteer efforts versus structured workplaces, especially ones where they're working on a nice bonus extra. If it's mission-critical in a structured environment and the person originally tapped to make them happen doesn't, they get the boot and someone else is pulled in to make it happen.
If it's optional or not time-critical, it's merely awkward rather than a Problem when they disappear off the face of the earth. It gets more awkward when they don't completely disappear. Were they going to knit 500 socks? Well, they knit 50 of them... and now they've got RSI, but they've been seen knitting a baby blanket. Shouldn't they be working on socks? Well, the baby blanket's for a new grandchild, they're allowed. Meanwhile, the original task is still incomplete, and it's unclear whether they'll ever be able to finish it. There may or may not be other people who might be willing to take the task on (in whole or in part). Sometimes the new person's availability is contingent upon clarity of their role. Will they be in charge? Will they be assisting the original person? Whose vision are they following? The person who took up the responsibility originally might get hurt or offended if their pet project gets handed off to someone else.
When the missing person is a project leader, the people under them suffer in a similar way to the team with the supervisor of known limited availability. No one knows why this leader is gone, when they're expected to be back, or whether it's permanent. None of the team is sure if it was due to a problem they caused. If their contributions were more worthy, they'd get attention, right?
When the person doing the work isn't in charge of it, and the person in charge isn't working, you can get a messy little authority/responsibility problem. I don't think I have to elaborate too hard on why authority without responsibility is bad, and likewise responsibility without authority.
In an organization that's still in the forming stages where "right, you, keep doing what you're doing" is how stuff works... roles come to be defined as people, not actual job functions. It's relatively easy to replace a job function. It's impossible to replace a person, especially when they're doing things that have not been fully documented. An actual illustration about what I mean -- laliandra wrote the lovely Another Vision of Us (TSN AU). I was one of her technical consultants for computer stuff that wouldn't make the geeks in the audience scream too much. At one point I advised that the quickest route through electronic security measures was probably the person that people go to when they've got themselves locked out, ideally at an access point to the building. "Like
copperbadge!" I said.
"Stealing their Sam!" Lal said, and laughed a lot (because she'd already written that bit in, and had thought of it in exactly those terms.
Sam is a force of nature, not a job description.
copperbadge appears to have documented exactly what it is that he did as receptionist/Ninja Office Boy very well before moving on, which is what makes him so invaluable, but this is his nature, and he had a proper length of time to wrap up his position tidily for the next holder.
I don't want to say that it is inherently bad or wrong to take advantage of use the extraordinary skills and effort of the people in an organization. A business practice that not just uses, but relies on, the unique abilities of the people is inherently vulnerable to disruption if one of those people leaves, if they cannot find other people with the same skills. An organization who depends on specific people, with little to no documentation of what those people actually do, is entirely helpless.
I recommend that the organization regularly (yearly?) solicit information from their regular people about what they actually do (officially and unofficially), and the points of divergence from the formal job description and/or procedures. This is an opportunity to assess how realistic and effective the current procedures are. Knowing who does what, and how they do it, prepares you in case you need to find a substitute or replacement.
I recommend that the organization have policies in place for handling people who are missing in action or who turn out not to be able to handle tasks they have taken on in a timely manner. Ideally, this would be in place beforehand, so people are aware of the policy before taking on a task. The organization should periodically check in with all of the people who have taken on responsibilities, and make sure that they're present and accounted for, and see if they're having any difficulties.
I recommend that the organization regularly check with their people in search of problems, on an organizational level all the way down to the personal level. The organization should not punish its people for reporting problems. The avenues for communication should be designed so the sudden unexpected absence of a kingpin person does not make a team feel cut off from the organization as a whole. There should be a healthy communication between teams. If a kingpin person has people who stand as backup for them, those people should also regularly check in with the team, to build rapport and get to know them in case they have to stand in.
Good luck.
Crossposted.
comments. Sign in with OpenID (use your LJ URL), confirm an email address, and leave a comment.
I haven't become a member of the OTW yet, although I should at some point; goodness knows I read in the Archive enough, and I am deeply invested in the idea of grabby corporate entities not being able to legally control things done for love and not money.
skud has a very thought-filled entry on some of the practical aspects of running a large project, including some of the ways that the AO3 differs from the norms of the FLOSS community, and why this can be alienating to an outsider and actively bad from a code standpoint: Github, transparency, and the OTW Archive Project. I do wonder if some of that is on purpose (I suppose that making sure that everyone who shows up is committed enough to stick around for a while through the sign-up process is a thing, though it does deter the people who just wanted to fix a typo), but Skud's point about distinct branching and small commits to ensure that if there's a problem it can be rolled back is very very very on the nose.
xb95 wrote On the care and feeding of volunteers. *draws hearts around it* When a person leaves, the team is down a person. They may or may not be down the job functions, depending on who can step in or be trained up, but that person's missing. It's essential to not dehumanize that person by reducing them to their job function, even if people outside the organization only see what they do, not who they are.
elements has a long thing about how a culture where one person steps up and does all the work is not a viable long-term strategy.
I do have thinky-thoughts about large projects and interpersonal dynamics, particularly about projects where a few extraordinarily talented and/or extraordinarily hard-working people contribute a disproportionate amount of the work well after the time when someone else should be there for backup.
"Hit by a bus" is a valid worry. People, even young able-bodied energetic people, die of all kinds of things. More common than sudden death is sudden unavailability -- other projects, sudden illness, vacation, quit, went to Costa Rica with the Peace Corps, new child, something that was thought not to affect availability but suddenly was, won the lottery and no longer interested in this job -- and unless it was a known and planned thing, or unless there was someone trained as backup, suddenly there's scrambling. Open-ended unavailability is especially difficult to deal with.
Getting a new person up to speed takes an adjustment period. Usually it requires more than one person to actually fill the shoes of the missing person, because they were doing two to three people's work. There's social adjustment as all the people get used to the new person and new dynamics.
An organization with scarce resources and/or bad problems may try to replace one person doing a superhuman job with one person doing a human job. They may be baffled when it suddenly doesn't work. In bad situations, they'll blame the new person and say that they're underperforming when there's simply too much work, or the work is too complex, to be reasonably handled in a workday with the given resources, or blame the team when they no longer have the level of support that they are accustomed to.
It's hard to get around one person doing a whole bunch (echoing back to
elements' entry) at the beginning, when everyone is still figuring out what actually needs doing. Once the whole system starts actually functioning is the opportune time to say "All right, I think this is working, now what is everybody doing?" and document what is going on and who is doing what. This includes the little unofficial things: motivational speeches to people who are feeling down, sending pizzas over the internet, monitoring the chat and making sure that all the informal training makes it into the formal documentation. If someone needs a replacement or substitute, the organization should know what they actually do.
Creeping unavailability, where someone vital either has their availability reduced, or is temporarily gone, and continues to be in and out, is more insidious than a sudden departure. When they are expected to be back and fully available Any Day Now, their responsibilities are left mostly untended. They may have no viable backup ready to step in.
Partial availability: this week, the superhuman in charge of Department X is fine, and Department X is running merrily. Next week, this kingpin catches a cold. "No problem," says Department X. "We're doing OK, the supervisor has had a cold before, we will take care of the routine things ourselves, and save the things that it is vital that our supervisor to do for next week, when our supervisor will return to us."
Next week, the kingpin supervisor is amazingly stacked up with the stuff that went down in the sick week, even with the department taking on some of it, so much so that the department decides that it's not appropriate to pile on ALL the things that went down while the supervisor was taking care of the backlog, and they will reserve some of the stuff that they decide is less crucial until a better time. After all, they have seen for themselves what happens when someone comes back and WHUMP, here's an overwhelming load of work, so they take it upon themselves to become human load balancers. Unlike a functioning server stack, there's nowhere else for the human load balancers to turn except to ignore things or save them for later. Team chatter starts to include "let's not worry the supervisor with Y and add to the workload". Sometimes Y is stuff the supervisor is formally expected to handle. Sometimes Y is just something the supervisor handles as an unofficial part of smoothing the team's function. Either way, "We're all adults here, so while Y is bothering us, it's not really important; we don't need to be immature about it, we can work around it," is a team digging themselves deeper.
The backlog's nearly caught up, and boom, another bad cold. The supervisor manages to do all of the things that the formal job description requires, but things remain unreported, and the small above-and-beyond touches that made them the kingpin don't happen. Issue Y never gets addressed, and coping with it without complaining about it to the supervisor becomes an invisible part of the workload of the whole team. Now that it's an ongoing issue, it's no longer a tiny thing not worth disturbing the supervisor with. It's a huge issue, and it's not fair to the supervisor to dump a monster like that upon them while things are still awful. New arrivals to the team get unofficially briefed about issue Y and why we don't talk about it, or get smacked down when they bring it up.
Human issues are particularly likely to build up. One of the team brings their bullet-head buddy to a regular unofficial get-together. Wouldn't you know, the buddy winds up drinking wayy too much and some political discussion in the kitchen leads to him saying something unbelievably racist. The party breaks up in shouting and apologies. Things aren't the same between the team anymore because no one is sure how that person justifies standing by their racist friend. The supervisor wasn't at the party and doesn't realize exactly where the party ended, what got broken, or how it could be mended.
Apologies to They Might Be Giants.
Trust is essential to sharing human issues with a supervisor. Long-running issues that have never been addressed are less likely to be reported when they crop up again, because there's a history of nothing being done. It doesn't matter where the cycle started. When the cycle of leaving stuff unreported gets going long enough, it's hard for the team to start reporting the backlog again. It's especially hard when the supervisor is still very busy, still sneezing miserably, still spending the lunch hour locked in the office with the lights off instead of out mixing with the team and sharing jelly babies.
The supervisor gets out of touch with the team dynamics, and the team may go out of their way to pretend that nothing is wrong in front of the supervisor.
(This also gets harder when the team is close to the supervisor on a personal level, as often happens when a group gets built out of who happens to show up voluntarily -- people are going to make friends, and people are going to bring their friends, and when your friend is complaining when you hang out for weekend coffee that the workload is killer while trying to cope with sick/new baby/etc., you don't want to be the heartless person who says "Oh by the way, here's Issue Y, which started just before the stuff started to go down, and now it is a huge human-eating horror that we have been deliberately concealing for you for three months. Welcome back!")
Even when there's a substitute in, human issues are still hard. With the regular supervisor under normal circumstances, there's enough of a rapport that one can go into the office, shut the door, and say "Hi, I like my teammate B a lot, but he carpools with his skeevy racist friend. I keep running into the racist friend in the break room. Can you make him make his buddy stay in the car?" There's not the same level of comfort with the substitute, and the substitute may not have the whole sordid history and may tell you to suck up and keep ignoring him. They may also say "Sounds complicated, but not urgent. Your regular supervisor will be back soon, and you can bring it up then, is that OK?"
If the substitute doesn't pass the incident on to the regular person when they come in, regardless of whether they told the team member to take it to the regular supervisor, it risks slipping through the cracks, because nerving up to talk about it once is hard enough, and unless the regular supervisor brings it up, it may remain basically unreported.
(Again, when the supervisor is close to members of the team on a personal level, this can prove problematic. However uncomfortable it is to tell your supervisor that teammate B's best buddy and you need to stay far far away from each other, it's more awkward when the person you've got the issue with is closer to the supervisor than you are. So you and teammate C have been working poorly together and furthermore having screaming fights that you're 99% sure are C's fault, and your supervisor and C are drinking buddies. Will your supervisor take you seriously? Will your supervisor do anything about it? Will your supervisor and C both wind up pissed off with the world for a month and make everyone miserable? So you do nothing until you're sure that you've got the documentation to back it up. When C subsequently yells at the receptionist in the lobby which is the final straw and you get fed up and take a swing, you're the one in trouble, twice over. First, you shouldn't punch your co-workers, and second, how did you let things between you and C get to that level without reporting it?)
Once a team stops telling supervisors when stuff makes them uncomfortable, it keeps going merrily on until something acts to change that. It also spreads. If the person in charge says "eh, we're not going to change it" or indicates "I can't handle that now" too often, whether it's policy, process, software, hardware, eventually the team that gets reports of broken and broken-as-designed things stops reporting back up, because nothing's ever going to happen. This is toxic.
Volunteers have an out that regular employees don't. If conditions become unbearable, they can up and quit: without having to find a new position, without notice, even. An atmosphere where volunteers are talking among themselves about how much worse conditions would have to get before they bail is not at all cheerful or helpful. Combine that with pressure from the outside and you get an entrenched ball of resentment, trapped between supervisors who don't listen and users who want all the new features but everything to stay the same.
Missing people cause problems. They took on a project, and then stopped work without actually resigning or giving an update on when they were coming back. This is more of a problem for loosely-organized volunteer efforts versus structured workplaces, especially ones where they're working on a nice bonus extra. If it's mission-critical in a structured environment and the person originally tapped to make them happen doesn't, they get the boot and someone else is pulled in to make it happen.
If it's optional or not time-critical, it's merely awkward rather than a Problem when they disappear off the face of the earth. It gets more awkward when they don't completely disappear. Were they going to knit 500 socks? Well, they knit 50 of them... and now they've got RSI, but they've been seen knitting a baby blanket. Shouldn't they be working on socks? Well, the baby blanket's for a new grandchild, they're allowed. Meanwhile, the original task is still incomplete, and it's unclear whether they'll ever be able to finish it. There may or may not be other people who might be willing to take the task on (in whole or in part). Sometimes the new person's availability is contingent upon clarity of their role. Will they be in charge? Will they be assisting the original person? Whose vision are they following? The person who took up the responsibility originally might get hurt or offended if their pet project gets handed off to someone else.
When the missing person is a project leader, the people under them suffer in a similar way to the team with the supervisor of known limited availability. No one knows why this leader is gone, when they're expected to be back, or whether it's permanent. None of the team is sure if it was due to a problem they caused. If their contributions were more worthy, they'd get attention, right?
When the person doing the work isn't in charge of it, and the person in charge isn't working, you can get a messy little authority/responsibility problem. I don't think I have to elaborate too hard on why authority without responsibility is bad, and likewise responsibility without authority.
In an organization that's still in the forming stages where "right, you, keep doing what you're doing" is how stuff works... roles come to be defined as people, not actual job functions. It's relatively easy to replace a job function. It's impossible to replace a person, especially when they're doing things that have not been fully documented. An actual illustration about what I mean -- laliandra wrote the lovely Another Vision of Us (TSN AU). I was one of her technical consultants for computer stuff that wouldn't make the geeks in the audience scream too much. At one point I advised that the quickest route through electronic security measures was probably the person that people go to when they've got themselves locked out, ideally at an access point to the building. "Like
copperbadge!" I said.
"Stealing their Sam!" Lal said, and laughed a lot (because she'd already written that bit in, and had thought of it in exactly those terms.
Sam is a force of nature, not a job description.
copperbadge appears to have documented exactly what it is that he did as receptionist/Ninja Office Boy very well before moving on, which is what makes him so invaluable, but this is his nature, and he had a proper length of time to wrap up his position tidily for the next holder.
I don't want to say that it is inherently bad or wrong to take advantage of use the extraordinary skills and effort of the people in an organization. A business practice that not just uses, but relies on, the unique abilities of the people is inherently vulnerable to disruption if one of those people leaves, if they cannot find other people with the same skills. An organization who depends on specific people, with little to no documentation of what those people actually do, is entirely helpless.
I recommend that the organization regularly (yearly?) solicit information from their regular people about what they actually do (officially and unofficially), and the points of divergence from the formal job description and/or procedures. This is an opportunity to assess how realistic and effective the current procedures are. Knowing who does what, and how they do it, prepares you in case you need to find a substitute or replacement.
I recommend that the organization have policies in place for handling people who are missing in action or who turn out not to be able to handle tasks they have taken on in a timely manner. Ideally, this would be in place beforehand, so people are aware of the policy before taking on a task. The organization should periodically check in with all of the people who have taken on responsibilities, and make sure that they're present and accounted for, and see if they're having any difficulties.
I recommend that the organization regularly check with their people in search of problems, on an organizational level all the way down to the personal level. The organization should not punish its people for reporting problems. The avenues for communication should be designed so the sudden unexpected absence of a kingpin person does not make a team feel cut off from the organization as a whole. There should be a healthy communication between teams. If a kingpin person has people who stand as backup for them, those people should also regularly check in with the team, to build rapport and get to know them in case they have to stand in.
Good luck.
Crossposted.
comments. Sign in with OpenID (use your LJ URL), confirm an email address, and leave a comment.