what would you do when half of your team quit prior to product launch?
Hanh VuPrincipal Project Manager| solo.ioChurchville, Md, United States
Hi friends, I'm in uncharted territory, a particularly uncomfortable one. I'm looking for advice, insight, words of wisdom or general encouragement.
We've been working on a software development project for about 2.5 years. We are about 2-3 months out from launching our product (web application). Our technical team had 7 people in it. 4 of them has resigned in the last 2 month. The backend of the application is entirely without support. We've documented the heck out of this thing, knowledge transferred as much as we could, where we could...
This came up in much quicker succession than i was expecting. I'm at a loss as to how to navigate this. Expectations with relevant stakeholders can be set, but i'm unsure what to set it to. Clearly, what i need to do next is very dependent on the specifics of my project and team, but i'd love to hear any advice or similar experience that you could share.
Senior Projects Manager | Field & Marten AssociatesNew Westminster, British Columbia, Canada
Hanh
This is indeed a very unsettling situation but it’s not your fault as these days it seems this behaviour is becoming very common amongst employees.
You as a leader, need to handle things properly within your level of authority (I am not suggesting that you aren’t) and this is a situation were you need to escalate to higher management so here is what I suggest you do as soon as possible:
1) Asses the immediate impact of losing the team members on the software development releases, sprints and timelines.
2) Determine if you can get replacement for the team members who resigned and how fast.
3) Based on the above, calculate the loss in productivity and assess the impact on the launch timeline. Even if you get replacement for your team members immediately, there will still be loss in productivity until the new team moves from the Forming / Storming stage to the Performing Stage.
4) Put a mitigation plan together with revised timelines, if needed.
5) Escalate to higher management by submitting your impact analysis and mitigation plan setting realistic revised launch dates if necessary.
6) Higher management will asses the situation based on many factors like how important the launch date is, time to market and other parameters and either accept your mitigation plan and support you with it or suggest an alternative with trade-offs.
Hope this helps.
RK
...
1 reply by Hanh Vu
Jan 04, 2022 12:56 PM
Hanh Vu
...
Hi Rami,
Thank you for you response. This helps tremendously. My head is spinning a little bit (or a lot), this gives me some clarity. I appreciate it!
-Hanh
Saving Changes...
Hanh VuPrincipal Project Manager| solo.ioChurchville, Md, United States
Jan 04, 2022 12:24 PM
Replying to Rami Kaibni
...
Hanh
This is indeed a very unsettling situation but it’s not your fault as these days it seems this behaviour is becoming very common amongst employees.
You as a leader, need to handle things properly within your level of authority (I am not suggesting that you aren’t) and this is a situation were you need to escalate to higher management so here is what I suggest you do as soon as possible:
1) Asses the immediate impact of losing the team members on the software development releases, sprints and timelines.
2) Determine if you can get replacement for the team members who resigned and how fast.
3) Based on the above, calculate the loss in productivity and assess the impact on the launch timeline. Even if you get replacement for your team members immediately, there will still be loss in productivity until the new team moves from the Forming / Storming stage to the Performing Stage.
4) Put a mitigation plan together with revised timelines, if needed.
5) Escalate to higher management by submitting your impact analysis and mitigation plan setting realistic revised launch dates if necessary.
6) Higher management will asses the situation based on many factors like how important the launch date is, time to market and other parameters and either accept your mitigation plan and support you with it or suggest an alternative with trade-offs.
Hope this helps.
RK
Hi Rami,
Thank you for you response. This helps tremendously. My head is spinning a little bit (or a lot), this gives me some clarity. I appreciate it!
-Hanh
...
1 reply by Rami Kaibni
Jan 04, 2022 1:11 PM
Rami Kaibni
...
You’re very welcome Hanh. I understand how frustrating this can be but it’s the new reality and we become better by knowing how to deal with different situations.
There is a solution for everything so do what you have to do and hopefully the issue will be resolved.
Senior Projects Manager | Field & Marten AssociatesNew Westminster, British Columbia, Canada
Jan 04, 2022 12:56 PM
Replying to Hanh Vu
...
Hi Rami,
Thank you for you response. This helps tremendously. My head is spinning a little bit (or a lot), this gives me some clarity. I appreciate it!
-Hanh
You’re very welcome Hanh. I understand how frustrating this can be but it’s the new reality and we become better by knowing how to deal with different situations.
There is a solution for everything so do what you have to do and hopefully the issue will be resolved.
Good Luck.
RK Saving Changes...
Thomas WalentaGlobal Project Economy ExpertHackenheim, Germany
Hi Hanh,
Rami gave you wise advice about how to proceed from here.
Some more thoughts I had when reading your post:
Do you know why they left? Has it anything to do with the product, a manager, the company, yourself - god forbid? Exit interviews could help to find out the causes and avoid/mitigate them in future and the remainder of the project. Controlling the project (team) with a regular morale index might have given you an early warning.
Build a strong connection with the rest of the team. Ask them what they need to do the job, do not push them but be a role model of what you want to see.
As a mental model, I see any organization (project) having to make sure that 3 things are setup well, managed and balanced: 1. the purpose (the SW you want to launch at a specific time to do what?, can you delay, or reduce something?) 2. the work (and maybe you can tweak the work a bit, e.g. rollout in stages) 3. the capabilities including resources (here lies your visible problem, where can you get help from? outside?)
Good luck, and enjoy the learning.
Thomas Saving Changes...
Sergio Luis ConteHelping to create solutions for everyone| Worldwide based OrganizationsBuenos Aires, Argentina
Cry? Run faster than stakeholders? Sorry for the bad joke. While I do not know the approach you take this is one of the
weaknesses of the Agile approach for those people that did not understand that Agile is not "no documentation". But forget Agile, most of the companies do not understand that knowledge is in the head of the people. Except you have implemented knowledge management system. So, nothing to do except to understand this: if you are talking about software then take into account that knowledge is writing inside the code and inside the database structures just in case you are using one. Then, take into account that the important thing for a software is supporting business layer inside the enterprise architecture. Take into account that 80% of business critical functionality is inside 20% of code and database then go for it, document it and extract the critical functionality. After that, continue to understand the business functionality your software support. Obviously, this will add high costs but is obvious the company where you belongs to do not visualize it in advance. Bad risk analysis, indeed. Nothing new below the sun. Saving Changes...
The others have covered the near term steps. From a longer term perspective, it might be worth looking at ways in which the team could move from being a bunch of specialists (I-skilled) to become more generalizing (T-skilled) such that a certain level of attrition won't result in the overall initiative being "dead in the water".
Kiron Saving Changes...
Hanh VuPrincipal Project Manager| solo.ioChurchville, Md, United States
Thanks Kiron, Sergio and Thomas to your responses. I really appreciate them.
As stressful as this is at the moment, it's definitely a valuable learning opportunity.
Thomas: Thank you for laying out very clearly those 3 knobs that we could turn to adapt to the changes. i'll definitely do that. I have close working relationship with the whole team and I did know of these departures were coming. I just didnt know they were so close to one another and over the holidays, so time to react more robustly were non-existent. I guess i should not be surprised. Any software developer in the US that want to have a new job can probably get one right away at this point. unfortunately the frustrations and causes for these departures were above my head. :(
Sergio: I have cried! but no where to run to. thanks for pointing out the critical path to business effectiveness. I'm sure we'll have to cut all the fluff and just keep the bare minimum going. A silver lining in all of this is that we'll get a rebuild a new team, hopefully with a new and improved approach. Risks management is something i really need to get better at.
Kiron: what you said resonate and is interesting. We've swung both ways over the last 10 years with this team. currently we were a bunch of specialist, but moving forward we do need to reexamine that approach. the trade offs are time and efficiencies vs risk of "being dead in the water" like this.
...
1 reply by Kiron Bondale
Jan 07, 2022 3:54 PM
Kiron Bondale
...
I could draw a parallel to the challenges some companies are facing today with supply chain issues. Some of the problem is aggravated by a just-in-time approach which was introduced to create efficiency. The downside of too much efficiency, however, might be reduced resiliency in the face of unexpected crises.
Having a team of "just enough" specialists is efficient, but leaves no bench strength when there is significant attrition.
The short term choice is to reduce the work entering the system to fit the constraint in parallel with the longer term solution of eliminating the constraint.
Kiron
Saving Changes...
Stéphane ParentSelf Employed / Semi-retired| Leader MakerPrince Edward Island, Canada
I agree with Sergio: the beauty of software is you can always reverse-engineer the knowledge from the software.
So go ahead and replace the people. Just build the reverse-engineering effort into the forward-going activities and give your team members the time to get the right amount of knowledge to complete the activity. (You want to avoid front-loading the reverse-engineering, if possible.)
Think of it as a form of refactoring. You "improve" the product as you go along. In this case, the improved product includes your team members. Saving Changes...
Thanks Kiron, Sergio and Thomas to your responses. I really appreciate them.
As stressful as this is at the moment, it's definitely a valuable learning opportunity.
Thomas: Thank you for laying out very clearly those 3 knobs that we could turn to adapt to the changes. i'll definitely do that. I have close working relationship with the whole team and I did know of these departures were coming. I just didnt know they were so close to one another and over the holidays, so time to react more robustly were non-existent. I guess i should not be surprised. Any software developer in the US that want to have a new job can probably get one right away at this point. unfortunately the frustrations and causes for these departures were above my head. :(
Sergio: I have cried! but no where to run to. thanks for pointing out the critical path to business effectiveness. I'm sure we'll have to cut all the fluff and just keep the bare minimum going. A silver lining in all of this is that we'll get a rebuild a new team, hopefully with a new and improved approach. Risks management is something i really need to get better at.
Kiron: what you said resonate and is interesting. We've swung both ways over the last 10 years with this team. currently we were a bunch of specialist, but moving forward we do need to reexamine that approach. the trade offs are time and efficiencies vs risk of "being dead in the water" like this.
I could draw a parallel to the challenges some companies are facing today with supply chain issues. Some of the problem is aggravated by a just-in-time approach which was introduced to create efficiency. The downside of too much efficiency, however, might be reduced resiliency in the face of unexpected crises.
Having a team of "just enough" specialists is efficient, but leaves no bench strength when there is significant attrition.
The short term choice is to reduce the work entering the system to fit the constraint in parallel with the longer term solution of eliminating the constraint.
As Thomas suggested, it seems important to address whatever factors caused the exodus.
I wonder if a different delivery approach could have avoided this and may help remedy things in future. If I'm right in understanding that this is a "big bang" launch after 2.5 years development then clearly that carries an extremely high risk and perhaps would have demotivated the team concerned. Can you move to weekly or monthly releases? Saving Changes...
Community Champion
