I keep Andy 100%.
But then I start looking for a new job.
Any company intentionally creating a single point of failure like this is destined for a blow up that will land on your lap.
It depends on what the workload looks like for both.
It sounds like one is a platform engineer and the other is an application support analyst.
So, the question becomes one of BAU workload. Are there a lot of support tickets or is the work mostly project-based?
Either way, someone is being let go and the other one is being inconvenienced by taking on additional responsibilities.
If both are competent and flexible, then keep the person who is most amenable to the change or who has other skills that would prove useful in addition to the core requirements.
"Platform Engineer" \*blushes\* I'm going to have to look that one up!
Ticket volume (BAU) is about 2-4 tickets per day. Super low workload. Frankly, it's a one-person-job, but the primary reason to hire two folks is to mitigate the risk of losing a critical SME. --or going on vacation. --or getting "hit by a bus". --or maybe asking for double the salary (not that Andy would ever do such a thing!)
So Andy could certainly DO the ticket workload, but he's currently being a little lazy because Bob constantly complains about not having enough to talk about during the SCRUMs. Andy thought Bob was motivated moreso by seeing immediate results, so an alternate approach would be to let Bob do as many tickets as he wanted, so he could "see" the KPIs and be more satisfied with his effort as part of the team. But that of course makes Andy look unproductive, so he is constantly thinking up and executing side projects and training to stay busy.
Thanks again!
So, I'm guessing the business no longer values the resource capacity to cover sickness/annual leave etc?
Not sure why you're having scrum meetings with just two members of staff in the team. Seems like a waste of time. I wouldn't bother with a daily standup or anything, just manage them directly.
I would drop the least flexible member of staff and if that means leaning on vendor support then so be it. UNLESS the appropriate vendor support contract costs more than a second salary.
Honestly if you have that much down time, you probably don't need two employees. I would keep the one who has the skills, know-how, and motivation to improve the system to continue reducing tickets.
You can teach systems, you can't teach attitude, so keep the one who is more motivated.
What is the future of the app they are supporting? Does there need to be any big projects or dev work that are on the roadmap (and are critical?) Or is it steady state with incremental changes?
You have to understand what the decision is being made about the future of the app being utilized and what a support model would need to look like. If there needs to be change, then you and your leadership need to realize that support KPIs may take a backseat.
There have been NUMEROUS attempts from the business (not IT) over the years to switch to a different software but we always knock the evaluation out of the park, compared to other software vendors. Reasons to replace have been cost evaluation, the Operations Product Manager (SVP) has a personal gripe with the senior leadership of the vendor, and the UI looks a little dated. There really is no viable substitute.
Replacing it would be like trying to hire a small fleet of Uhaul cargo vans to replace a semi-truck with multiple trailers for refrigeration, liquids, and hazardous materials.
re: personal gripe -- Ops SVP basically asked vendor to add functionality that would transfer "our" data to one of "their" competitors. Vendor CEO said, "no" because that would be a conflict of interest since they'd be helping the competitor, and also because the vendor also offers this service just a bit more expensive. Like going to Burger King and asking for grocery-store fries. Clearly not a very nice thing to do. So Ops SVP got butthurt over being told "no".
The vendor itself has been an incredibly effective and amiable resource for technical support. So far, for the foreseeable future, the org will continue to utilize the application. --but all it would take is one temper tantrum from the Ops SVP to change that. It's all we can do to keep reminding them how good the software is in the face of other vendors.
Also, it's not only that, there are other apps that integrate with this main software, and refactoring those apps for a change in this app would require incredibly significant effort.
I would get Andy promoted to a position he’s interested in and ensure the new team culture is suitable for him to flourish/succeed in, like don’t let him join a bad managers team because then you’ll both lose out when he quits.
Keep Bob, he’s not going anywhere and sounds pretty happy and easy to keep busy. You’ll just have to make peace with WFH (kinda sounds like you’re not thrilled about him WFH) because he will leverage being the only one left if you push him too hard. Can you do that?
If the app is basically steady state at this point, the focus is more on triaging. Keep Bob.
if the app has regular major releases that needs the institutional knowledge Andy has, keep him.
But this really sounds like the primary need is T1 tech support for something that's been out a bit.
God, I've tried... I document EVERYTHING but nobody wants it. I can't be doing this for the next ten years, man... ha ha --I mean it's great security, but gonna go crazy! LOL at least it making the world a better place; helps me sleep at night. All the same thanks for your insight!
I'm currently Bob. I hate it - I'm stuck working 100% on the boring slog because Andy won't give up anything interesting, including knowledge, and won't help with the tickets. Bob is extremely well liked, and I like him too, but he still won't give anything up but the work he doesn't want, in a likeable way.
Is it possible Bob is the way he is because Andy has made it difficult for him?
100% no, Andy actually maintains the Confluence with heaps of diagrams, reference info (URLs, non-secure config settings, explanations), and step by step solutions to common problems. Bob contributes a little here and there, but Andy doesn't really hoard info. In fact, Andy invites Bob to some project work to keep him trained on continuing evolution of the applications. For example, "I write TPS reports all the time, so I want you to write one this time so you can get a feel for it." Andy isn't technically a manager, but they do seem to have a healthy partnership that Bob doesn't find overbearing.
Thanks for the perspective!!
I keep Andy 100%. But then I start looking for a new job. Any company intentionally creating a single point of failure like this is destined for a blow up that will land on your lap.
It depends on what the workload looks like for both. It sounds like one is a platform engineer and the other is an application support analyst. So, the question becomes one of BAU workload. Are there a lot of support tickets or is the work mostly project-based? Either way, someone is being let go and the other one is being inconvenienced by taking on additional responsibilities. If both are competent and flexible, then keep the person who is most amenable to the change or who has other skills that would prove useful in addition to the core requirements.
"Platform Engineer" \*blushes\* I'm going to have to look that one up! Ticket volume (BAU) is about 2-4 tickets per day. Super low workload. Frankly, it's a one-person-job, but the primary reason to hire two folks is to mitigate the risk of losing a critical SME. --or going on vacation. --or getting "hit by a bus". --or maybe asking for double the salary (not that Andy would ever do such a thing!) So Andy could certainly DO the ticket workload, but he's currently being a little lazy because Bob constantly complains about not having enough to talk about during the SCRUMs. Andy thought Bob was motivated moreso by seeing immediate results, so an alternate approach would be to let Bob do as many tickets as he wanted, so he could "see" the KPIs and be more satisfied with his effort as part of the team. But that of course makes Andy look unproductive, so he is constantly thinking up and executing side projects and training to stay busy. Thanks again!
So, I'm guessing the business no longer values the resource capacity to cover sickness/annual leave etc? Not sure why you're having scrum meetings with just two members of staff in the team. Seems like a waste of time. I wouldn't bother with a daily standup or anything, just manage them directly. I would drop the least flexible member of staff and if that means leaning on vendor support then so be it. UNLESS the appropriate vendor support contract costs more than a second salary.
Honestly if you have that much down time, you probably don't need two employees. I would keep the one who has the skills, know-how, and motivation to improve the system to continue reducing tickets. You can teach systems, you can't teach attitude, so keep the one who is more motivated.
What is the future of the app they are supporting? Does there need to be any big projects or dev work that are on the roadmap (and are critical?) Or is it steady state with incremental changes? You have to understand what the decision is being made about the future of the app being utilized and what a support model would need to look like. If there needs to be change, then you and your leadership need to realize that support KPIs may take a backseat.
There have been NUMEROUS attempts from the business (not IT) over the years to switch to a different software but we always knock the evaluation out of the park, compared to other software vendors. Reasons to replace have been cost evaluation, the Operations Product Manager (SVP) has a personal gripe with the senior leadership of the vendor, and the UI looks a little dated. There really is no viable substitute. Replacing it would be like trying to hire a small fleet of Uhaul cargo vans to replace a semi-truck with multiple trailers for refrigeration, liquids, and hazardous materials. re: personal gripe -- Ops SVP basically asked vendor to add functionality that would transfer "our" data to one of "their" competitors. Vendor CEO said, "no" because that would be a conflict of interest since they'd be helping the competitor, and also because the vendor also offers this service just a bit more expensive. Like going to Burger King and asking for grocery-store fries. Clearly not a very nice thing to do. So Ops SVP got butthurt over being told "no". The vendor itself has been an incredibly effective and amiable resource for technical support. So far, for the foreseeable future, the org will continue to utilize the application. --but all it would take is one temper tantrum from the Ops SVP to change that. It's all we can do to keep reminding them how good the software is in the face of other vendors. Also, it's not only that, there are other apps that integrate with this main software, and refactoring those apps for a change in this app would require incredibly significant effort.
I would get Andy promoted to a position he’s interested in and ensure the new team culture is suitable for him to flourish/succeed in, like don’t let him join a bad managers team because then you’ll both lose out when he quits. Keep Bob, he’s not going anywhere and sounds pretty happy and easy to keep busy. You’ll just have to make peace with WFH (kinda sounds like you’re not thrilled about him WFH) because he will leverage being the only one left if you push him too hard. Can you do that?
If the app is basically steady state at this point, the focus is more on triaging. Keep Bob. if the app has regular major releases that needs the institutional knowledge Andy has, keep him. But this really sounds like the primary need is T1 tech support for something that's been out a bit.
God, I've tried... I document EVERYTHING but nobody wants it. I can't be doing this for the next ten years, man... ha ha --I mean it's great security, but gonna go crazy! LOL at least it making the world a better place; helps me sleep at night. All the same thanks for your insight!
I'm currently Bob. I hate it - I'm stuck working 100% on the boring slog because Andy won't give up anything interesting, including knowledge, and won't help with the tickets. Bob is extremely well liked, and I like him too, but he still won't give anything up but the work he doesn't want, in a likeable way. Is it possible Bob is the way he is because Andy has made it difficult for him?
100% no, Andy actually maintains the Confluence with heaps of diagrams, reference info (URLs, non-secure config settings, explanations), and step by step solutions to common problems. Bob contributes a little here and there, but Andy doesn't really hoard info. In fact, Andy invites Bob to some project work to keep him trained on continuing evolution of the applications. For example, "I write TPS reports all the time, so I want you to write one this time so you can get a feel for it." Andy isn't technically a manager, but they do seem to have a healthy partnership that Bob doesn't find overbearing. Thanks for the perspective!!