CTO day 2: downsizing the team
danlebrero.com
CTO day 2: downsizing the team
1–10 of 112 posts
Re: CTO day 2: downsizing the team
#2While there is lots of useful advise in there, I wonder how do you measure a "successful" termination process? What differentiates a great "we have to let you go" meeting from a terrible one, output wise? What's the metric you want to optimise here? Future references?
Re: CTO day 2: downsizing the team
#3This sounds substantially overengineered way to justify his actions and relieve his conscience. In an organization of 17 people a person in his position would know exactly which people would work together to build a great team and which would not. In such a small team it's as much about the roles as it is about the people themselves, his method apparently completely dismisses that element of the decision.
Re: CTO day 2: downsizing the team
#4This sounds substantially overengineered way to justify his actions and relieve his conscience. In an organization of 17 people a person in his position would know exactly which people would work together to build a great team and which would not. In such a small team it's as much about the roles as it is about the people themselves, his method apparently completely dismisses that element of the decision.
Maybe not if you are on day 2 of your position as CTO?
Re: CTO day 2: downsizing the team
#5This sounds substantially overengineered way to justify his actions and relieve his conscience. In an organization of 17 people a person in his position would know exactly which people would work together to build a great team and which would not. In such a small team it's as much about the roles as it is about the people themselves, his method apparently completely dismisses that element of the decision.
I don’t think the reorganisation into two teams was necessarily obvious.
Secondly, when you are making a decision like this which impacts the course of other people’s lives, I personally believe that you should use a level of structured decision making rather than a gut feeling of who ‘fits into the team’ best.
Overengineered? Probably, but at least it showed a clear thought process. Also he stated he considered team dynamics once he had some candidate options.
Re: CTO day 2: downsizing the team
#6This is difficult. Had to go through this myself last year. Went from 10 people to 2. How people are informed about it,at least initially,is very important. We had to do it over zoom,which is complete shit. It probably made it worse knowing that the people will unlikely to get jobs soon.
Re: CTO day 2: downsizing the team
#7While there is lots of useful advise in there, I wonder how do you measure a "successful" termination process? What differentiates a great "we have to let you go" meeting from a terrible one, output wise? What's the metric you want to optimise here? Future references?
If good news happens a month after they are gone and you want to hire them back are they willing to come back or do they continue to find a job elsewhere?
Re: CTO day 2: downsizing the team
#8One big point that would be useful is to help the fired engineer find another job. A lot of this is, as Aqua mentioned, an exercise for their conscience. The best way to alleviate it is to "do right" by the fired engineer and help them find another position. Likely would have been about as much work as this whole spiel.
Of course, OP has no requirement to do anything for them, but the easiest way to make yourself feel less bad is to make the results less bad for the person affected. Doing all of this did nothing for the person fired, except get them fired.
This would only really be feasible for a small team, such as this.
Re: CTO day 2: downsizing the team
#9> As heartless as this may seem...
It's not heartless, it's just stupid. It's like screwing in a lightbulb with a hammer.
> And I didn’t want to do the task so, consciously ignoring Mr. Weinberg, I transformed the ordeal into an optimization problem, for which I wrote an application to help me with.
Treating people like robots is probably the worst way to solve people ops problems. It's like managers learned nothing from the failures of stack ranking, whiteboard interviews, brain teasers, and other similar "optimization" methods. These ill-judged solutions show a clear misunderstanding of the scope and context of the problem at hand.
In fact, it's pretty antithetical to being a good engineer.
Re: CTO day 2: downsizing the team
#10One big point that would be useful is to help the fired engineer find another job. A lot of this is, as Aqua mentioned, an exercise for their conscience. The best way to alleviate it is to "do right" by the fired engineer and help them find another position. Likely would have been about as much work as this whole spiel. Of course, OP has no requirement to do anything for them, but the easiest way to make yourself fee…
> One big point that would be useful is to help the fired engineer find another job.
If you actually have a likely other job, sure. Otherwise the old "I know guy at Google who can look at your CV" is just a way to make yourself feel good, and it will be seen that way too.
The problem is veterans will see right through you and discount your efforts, unless you have that amazing job. And juniors will think you're helping until they realize you aren't, and they'll be disappointed in you.