In the beginning, you are on an island, you have an idea to go on an adventure, so you start building a raft with the other guy on the island. The other guy has no building skills, but he procures food, water and wood. The resources on that island are dwindling but you manage to finish the raft just in time.
You begin to sail the raft, you start fishing while out in the open seas. You reach another island and sell the fish, figure out that is the way you can have an easy life since you can pay other people to procure food, water and wood with fish. You build a better boat, hire more people and repeat the process.
You now have a huge rowing boat that goes very far out at sea since there are no fish left close to land, you now fully depend on the people on that boat to make it alive to the next island. There are people who row, people who fish, people to cook, people that are on the lookout for fishing spots and islands.
Your partner notices a guy who eats more than the average rower on the boat, but rows less. You throw him overboard. A fire starts near the rowers, but the rowers continue rowing. Turns out the guy you just threw overboard he always put out fires. You find another rower, tell him to put out the fire. He throws water over it. It is now worse. You figure out the fire is the cook's fault for using too much oil. He only used so much oil because the lookouts thought fish oil is good for their eyes so they can see more ahead. You know this to be only partially true, but they don't seem to understand and even though the fire happened they still demand their food fried in fish oil.
You throw one of the lookouts in the water to make an example. The lookouts stop eating deep fried food. Now the people who fish complain they work too much. Turns out the deep fried food gave the lookouts energy to shout at the people who fish where to fish at. Now, the people who fish need to stop what they're doing and go to the lookouts for information. Because of all the extra effort the people are doing, you are now out of fresh water in the boat.
Congratulations, you now know how a CTO feels like.
This makes me wonder, considering the cost of acquisition of talented staff why I don't hear about more large companies with lots of capital on hand requiring that people instead of being fired, just asking them to take a period of paid leave.
It would have to be for a while to shake out issues, but if you suddenly discover you need the person, then they're not gone. You also get to experiment with different team combinations to see if the problem was a management issue, or if they would be better suited in a different role?
Obviously you still need to fire people now and again, but this large scale firing followed by huge hiring cycles always seemed a bit odd.
The bar to be fired in large bureaucratic companies is usually pretty high. Like you'd have to physically assault your coworkers or steal money from the company account.
It makes zero sense to keep people who are being fired, they are being fired for a reason.
If you're talking about normal employees. They can take holidays anytime (what's the holiday allowance in the US?). Large companies usually have a concept of sabbatical, you can take a large break (let's say 3 months) after some years of service.
> It makes zero sense to keep people who are being fired, they are being fired for a reason.
The problem addressed here was "is my reason valid".
If you fire someone for the wrong reason, and then everything crumbles, having them on paid leave for 1 month or 2 won't hurt the company financially, and allow to test "how are we doing when X is not there anymore".
And that's exactly why middle managers in large companies have zero power to fire. They can't be trusted to fire for valid reasons so they don't get the ability to fire.
Gotta go through HR and due process, that typically sets the bar to assaulting coworker and stealing from the company.
1) It'd all be better or at least the same without any external interference from you
2) The positive outcomes to the business are more a result of external factors like market expansion, word of mouth, a new fad, rather than your own contribution
The impact you can make as a CTO is bringing an engineering perspective to the board and keeping engineers happy (either by doing it personally or by delegating to someone else, eg. a VP).
Both are important tasks because it's easy for business to start thinking of engineering as just a cost centre (which is the easiest way to make sure your company will never use technology efficiently to multiply its revenue) and because hiring engineers costs can be a significant part of your company spend
As an engineer speaking to someone who is clearly also an engineer - you're highly discounting the levered impact proper, high quality leadership makes on a business.
I put myself in those shoes and wondered what doubts I'd have about the contributions I could do. The OP was a great illustration of the chaos it can be. I wasn't saying that leadership has no impact, that's crazy.
Sounds like a bad captain, entirely reactive and not proactive at all. Those people were brought onto the boat to perform these duties but were given no oversight? Why didn't the captain have any knowledge of the fires that were happening so often? The captain had no idea what was being used by the cooks? He didn't talk to the people who bought the fish oil? Never had a meal with any of the lookouts or fishermen?
The captain should be the one to jump overboard in your story.
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.
He needed to evaluate the team based on some criteria one way or another. He chose certain criteria and used the computer to assist him in the evaluation.
Another option would be to choose the team on who you just "like the most". Maybe this would have been more to your liking? It's more human, I guess. However, notice that there is still a criteria and still an evaluation phase, you can't avoid it (unless you pick by random).
None of this means that you have to use text-to-speech and have the computer read out the list of names who were fired. You can still go to each team member and talk about it, like a human.
He should have realized that he lacked the knowledge and experience to tell his boss to fuck off because on day #2 on the job you simply can not make this decision in a way that won't kill the company.
The author was promoted to CTO, he worked for the company before. Given that the company has less then two dozend people, he likely knows it in and out, including everyone working for it. Also "Day2" is likely a metaphor for "story series entry number 2" and probably does not literally mean 2nd day at work.
The story does not give that background, I'm assuming he is an outsider because of his choice of words in the beginning and the fact that he seems to treat his apparently former buddies suddenly as cogs in a machine. Maybe that's just another way for him to fortify his own mind about doing callous things to other people. Regardless, the second day on a job you are not ready to make decisions like this until you have had a lot of conversations with different people in the organization. Any CEO that tasks a just-promoted former team lead, project manager or other non-manager to first time CTO and MT member and that then expects that person to take the axe to the team in a way that will not destroy the company is out to lunch.
This article is proof positive of that, it misses a whole slew of important considerations and will likely result in a mass exodus of the people that keep the company running within the next couple of months.
I've had to lay off people before, this is not how it is done.
In a way that just makes it even worse. Because a newbie that lands in a situation like that might be excused, a former team member isolating himself from his own responsibility by asking his computer who he should fire is an even bigger insult than if he came in as an outsider.
This company is dysfunctional. They have a CTO that doesn't report to the CEO but where the CEO will cross their lines of command to give direct orders to the CTO anyway, they treat their employees like they treat their docker images (like cattle, instead of like pets), they promote people internally and make their first marching orders to take the axe to the org chart, specifically the team from which they got promoted out of.
I was only pointing out the context and that the first sentence is a rather obvious tell that it is part two of a series and should not be interpreted literally.
I have a pretty simple rule for evaluating articles: if not indicated otherwise I assume they stand on their own and that the article writer means what they say. It's on them to communicate any circumstances that are required to be able to read the article, at a minimum a link should be provided to such context if it is available.
Just read this thread and see how many people are wrong-footed by the article.
You can come up with a better reply of course. But can you really beat the "are we aligned in the same direction" from the CEO and the other executives? Especially on the 2nd day.
You can spin it however you want, come up with some great arguments, but if the CEO decided to fire people, I don't think he takes that decision lightly so when he/she presents that decision you can count that it really is the last option he has.
It all comes down to trust. Trust your CEO that he has no other choice, maybe explore alternatives. But if he is a really good CEO, even if you fight it and argue for it, you'll wind up at the same conclusion he did. In fact, 9/10 you'll wind up at the same conclusion he did. Remember, it's his job to convince and lead people so he's probably better than you at that.
CTO: "This is an important and disruptive decision. I feel that we need X more time to gather information and make sure we don't kill the company doing it incorrectly. What do you suggest?"
It's the CEO's job to be able to weigh different kinds of risks and make a decision. So bubbling up your concerns is the correct answer.
Spot on. This is surgery and requires precision, not axe work, and definitely not something that you're going to solve by coming up with some clever algorithm.
Intra-team relationships are super important, as are the degrees to which the team members have arrived at the company, how long they have known each other, whether they knew each other prior to their arrival and so on. Before you know it you have a mass walk-out on your hands with those that have options leaving first.
The best way to deal with this is to do it very gradually and taking great care to not inadvertently wreck the core structure of the tech department.
Basically any reply that buys you more time so that you can make an informed decision: this demonstrates you can act in the best interest of the company instead of blindly following CEO's orders in order to keep your post, with potentially disastrous consequences.
It's absolutely fine to face à situation that is new and that you feel you lack knowledge and experience on. But as a leader and the guy in charge you should not refuse to deal with it, you need to find a way and people to advise you. Don't think that CEOs, Generals, Heads of States, etc know everything, no they know how to seek information and advice but the final decision and responsibility is on them.
Such refusal is a sign of maturity in an MT member. Taking a stand to protect your department from unrealistic requests is part and parcel of being a responsible person to begin with, at the management level it starts to make the difference between a company that will continue to function and one that will be dysfunctional soon - if it isn't already.
The complete lack of empathy on display here is proof positive for me that this person does not have what it takes to be a successful manager.
I've just taken my company through a 50% drop in revenues and we've survived, stronger than ever, not a single person got laid off and all our bills are paid. That didn't happen because I treat my co-workers, partners and employees as replaceable cogs and if I would give my second in command the order to get rid of 50% of our workforce I would expect some serious pushback on that. Not that I would ever do that.
If you don't agree with a course of action then by all means do make your point in a constructive way.
But once the decision is made then you cannot shun your responsibility and refuse to implement it. Either "disagree and commit" to the best of you ability or quit.
You can disagree with a course of action and still implement it in a way that won't gut the company. This isn't that. But let's give it six months, assuming they'll make it that far.
That's not refusing to deal with it, merely saying that you may need some time to do exactly what I suggested (seek information and advice) but you are dealing with it.
I assumed that it was an internal promotion. If it was an outside hire, yikes. Although to be fair, we don't know how much time he was given to make the decision.
Liking each other is a pretty huge part of a positive team dynamic. The line to unfair favoritism is thin but a team of high-skilled engineers that don't like each other will most likely perform worse than a team that likes each other but has a bit worse average skill level.
Sometimes a person that is regarded as low skill can motivate other team members to hugely increase their productivity by building a positive atmosphere.
>>Sometimes a person that is regarded as low skill can motivate other team members to hugely increase their productivity by building a positive atmosphere.
Umm - Isn't that just part of the job? Most workers are expected to at least not _negatively_ impact the working environment, while being at least as competent as their co-workers.
This actually sounds more like someone trying to get co-workers to cover their short-comings for them...
> He chose certain criteria and used the computer to assist him in the evaluation.
I used better evaluation criteria when figuring out who to kick out of my World of Warcraft guild than this guy used on his employees. Anyone that defends OP's post clearly has never led a team of anything or been in charge of people.
Writing a program to "optimize" who to fire is bonkers and shows a clear lack of leadership strategy.
I don't think he treats people like robots.
The way he "delivers the message" is humane. And the way he selects who must go is totally an optimization problem.
You cannot boil down humans to 5-6 attribute points.
What about personalities/coordination/how people actually interact.
Product A might be filled with people who are use to taking charge, and Product B might be filled with people who are more reserved about their opinions.
This is a dreadful way to solve this problem. If it were that easy, his job as CTO wouldn't exist and we could simply plug it into a SaaS AI that spits out optimal hiring strategies.
Nonetheless, I appreciate the insight/sharing publicly.
Did you read the article? He specifically says: "Most important, the application gave me a few starting points. Of those, I still had to consider the team dynamics, existing teams, personalities, seniority, potential, personal situation, future needs, …"
And totally missed on the friendship angle. So, here is my prediction: the people that got fired will find new places to work at where the management is a bit more mature, and will then pull their capable buddies left behind at their old company with them. That's how it usually goes when a new junior manager goes to town with an axe.
Friendships can transcend teams, personalities are not going to be modeled in software and 'personal situation' is a great way to accidentally make a bad situation worse, for instance: by deciding to keep someone who has a family in favor of someone who does not but who is instrumental to the company in non-obvious ways.
So no, I don't see that particular part addressed well or even at all through those three sets of keywords and I've seen companies be utterly destroyed because they fired a guy they thought wasn't contributing enough who just happened to be the glue holding the whole thing together.
This is not a software problem, and it can't be approached with the same toolset that you would use to figure out register optimization, it is first and foremost a people problem. The OP is seriously out of their depth and too full of themselves due to their recent promotion to realize this.
That realization won't be long in the coming though, I predict that within six months there will be another blog post about how he left this toxic company behind to go somewhere else without realizing that he was part of the problem all along.
For reference, I give you his blog post from six months ago:
And yet we hire based on people's achievements and previous success. And the world keeps on turning.
It's very hard to build the perfect team from the get-go. However, you can probably build a pretty good team over time. In my opinion, it's better to make an average decision than no decision at all; you can improve from average to something better as you go along.
Yes but what tends to happen is - the risk is - youll probably just end up with a stable team, but not a good team. The best will have left or been pushed out. The ones that stay, desperate enough to be unethical to keep their positions, to lie to cover their asses. A barely functioning but stable entity floating in space not producing anything of value until the company slowly withers and disappears.
This 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.
Precisely. On day 2 you are still taking stock and figuring out the lay of the land, and you're in absolutely no position to start making decisions with far reaching consequences. The first thing you will want to figure out is what happened with the previous CTO and why that person left.
He built some software that told him to fire himself.
He then fired someone else based on Role & Salary parameters.
Then gives advice on treating people like adults when firing them.
Does anyone else find this whole thing macabre and absurd?
( I'm not being negative - Im not against the great / funny article and an attempt at a novel approach, the whole thing just seemed completely unethical dystopian and useless -
highlighting what a hard problem this is to solve - I would do no better - infact I would have been the problem - I think I just wouldn't fire anyone ).
You're misreading the article. He put himself on the list of people to optimize, but admitted he is sufficiently biased about his own skills that he wasn't realistically going to end up as one of the cuts.
Junior CTO shows how to create short term value without realizing the long term consequences of his actions, and proceeds to grandstand to help create his own personal brand so that he can get invited to do the same elsewhere. I give this company another 3 months at best before it implodes.
For me it read like somebody is trying to emulate "The Phoenix Project" but massively lacking experience, empathy and about everything necessary to be (good) in such a position.
I wasn't sure if I was reading a satirical take on a lot of grandstanding out there. But reading the comments here the author probably means it to be taken at face value.
I read a lot of criticism of Daniel's approach in this discussion.
People don't like the fact that he wrote an app and tried to deal with the problem objectively. But, really, how is this so different to any other objective approach?
Here in the UK there is a significant body of legislation around the process of making people redundant, so it would have worked differently, and particularly it will work differently for larger numbers of redundancies.
There is always some sort of objective scoring criteria. For larger redundancies these are agreed with employee reps as part of the consultation period. You might be able to get away with less rigour if you're only making a handful of people redundant. Regardless, those scoring criteria and the scores associated with them are going to end up in some sort of model, which might be as simple as an Excel spreadsheet, but there's nothing to stop you implementing it in code. The model is generally published as part of a consultation pack so that staff can understand how they are being evaluated, and provide feedback via their employee rep.
The end result is that the people sorted at the bottom, however many you need, are made redundant. It isn't nice. But it is objective, and it's important that it be so, because that's as close as you can get to any sense of "fairness" - not that it's going to feel fair to the people losing their jobs. You have to be able to justify these decisions, to demonstrate that you've gone through a fair and objective process to arrive at them, because you might land in court if somebody challenges your decisions.
It's not nice, and it's always going to seem heartless to some people. But that's part of leadership: sooner or later you are going to have to make decisions that some (or even many) people don't like, and that you don't like either. In many of these cases there will be no perfect choice and no perfect outcome. There is no avoiding it. If you aren't willing to deal with this, don't become a leader.
> But it is objective, and it's important that it be so
But it's not objective at all. He still subjectively evaluated each individual employee, and fed this into the program as an input, in order to help him find configurations that fulfill certain conditions.
And this is a good thing. I'm not 100% sure what you mean by:
> There is always some sort of objective scoring criteria. For larger redundancies these are agreed with employee reps as part of the consultation period.
...but if I am guessing correctly, then this is fortunately NOT what he did here.
Any objective metric in a field where there's no clear way to measure performance will always be extremely poor, despite employee reps' / unions' love for them. What would this metric be? I can remember one example (not in CS but in another hard-to-measure-output field), where it is just how long you've worked there. So if there are 5 people doing job X and 2 need to be fired, the newest 2 get fired.
I'm entirely confident in a former team lead, now CTO's ability to beat the accuracy of that metric with his subjective evaluation of each individual's abilities (regardless of whether he uses a program to help him optimize based on that information).
The problem people have with this is that they think the person making the subjective decision might have some kind of bias. And some bias definitely exists, pretty much 100% of the time. But in reality, even a biased boss who's worked with those people for a while is likely to evaluate SD employees more accurately than some arbitrary metric. If you don't deserve to be fired, but get fired anyway, it's equally unfair whether it was because the boss really likes a shitty employee who should have been fired instead, or because the shitty employee has more tenure at the company and they're firing the newest people, or because they threw a die to pick whom to fire.
I would make a distinction between "objective" and "explicit". Daniel's model is product of his judgment. It's his perogative and responsibility as a leader, and he's well intentioned, etc, but his judgment is subjective. I am not familiar with the UK system but providing explicit criteria and an oppty for feedback seems like a step forward relative to the US. It's a question as to what else would need to change in US industry for that approach to play well.
Pooling diverse judgments is a way to produce more robust predictions. An explicit model can help multiple people engage. Daniel did not mention discussing the re-designed org with any of his team. A less top down approach than his might have included seeking feedback about direction and team composition from members of the team itself.
One 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.
> 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.
This is not impossible to pull off. Especially if you have some networks in tech, who may find the idea of hiring performing engineers from you but just junior or too much of role, to be valuable.
> A lot of this is, as Aqua mentioned, an exercise for their conscience.
Just as important to build (some...) trust and preserve culture among remaining employees.
Imagine this from the lens of remaining employees:
A) The new big boss wrote an algorithm to fire our friends
B) The new big boss had to make a tough decision to fire our friends but went out of his way to do right by them
Which one sounds better? I think the algorithm was a good idea to explore possibilities, but I'm not sure about the subsequent blog post.
There are recent examples of these layoffs among tech companies who had to make a pivot due to Covid and took approach B. Ritual is the one that immediately comes to mind for me.
> Just as important to build (some...) trust and preserve culture among remaining employees.
This reminds me of how Toyota did it: they calculated roughly how many workers they'd need in a plant (counting expected future optimisations), then they went ahead and just said, "This is how many we think are needed to do the job. As you can see, we have been forced to fire 25% of you. The rest of you have a lifetime guarantee of employment with us."
And, critically, they didn't back down on that guarantee. That always struck me as really understanding how important it is to build trust among the ones that remain.
There's a common consequence to staff cuts that OP did not seem to consider: when cuts occur, OTHERS take that as a signal to leave. He just blindsided his staff on "day 2", it could easily happen that another 2,3,4, or more people are now planning to GTFO before they're next. All that careful planning will then be for shit because he just cut to the bone, and then the bones will start leaving.
There's no easy way to do this stuff. It's ugly no matter how you approach it.
Exactly. Everybody that is able to move is going to move and this organization will collapse in a couple of months when the last people that have knowledge will leave. The only people that won't leave are the ones that can't leave and usually those are not the ones that keep the lights on.
Dumbest move ever. If on day #2 you think you know enough about an organization to start hacking away dead wood then you are way out of your league.
Yes, that was the bigger failure here. The CEO is clearly incapable as well, but that was more or less a given taking the context communicated in the article into account. No CEO would farm out their responsibility like this. At best he would have asked the new CTO for some input.
> Senior: creates the plan.
> Mid-level: follows the plan.
> Junior: needs to be taught to follow the plan.
This person is a horrible leader and failure if they think this way.
This tells you all you need to know about the rest of the article.
And indeed:
> “The ideal team would be one that has all disciplines covered at a senior level with multidisciplinary people working in just one team, and with enough overlap to avoid a bus factor of one. Additional people will bring additional capacity.”
It’s just the tired old foolish mirage of fungible full-stack teams where there’s no such thing as specialization of labor.
This article is basically a farce of bureaucratic management mediocrity.
Some of the best product strategy in my org has consistently come bottom up from junior and mid level engineers. Some of the most out of touch product strategy has come from principal / staff engineers and senior product managers.
All engineers, whether junior or senior, need lots of autonomy to propose and try plans. No engineers needs to be “taught to follow the plan” - that is career death.
Meanwhile, the risk of political motives and malicious intent or self-preservation is much higher among senior staff, especially as they become ex-technical.
Finally, many products need teams of specialists in various areas, and their team structures don’t resemble fungible full-stack wishful thinking. A good leader tries much harder to give them what they need instead of imposing the fiction they are fungible.
So, overall the leader of this post is
- overly reductionist
- failing to protect autonomy
- failing to protect specialization
- failing to deal with reality
- mentally representing “senior” vs “junior” as “creates orders” vs “follows orders” which puts political authority as a central cultural value.
These are all classic, well-known leadership mistakes.
I guarantee the company in this example is full of under-appreciated engineers treated like cogs.
Even the overall premise of the layoffs is suspect. Nowhere does the article even ask the question of why the critical project failed in the first place. Why was staffing preemptively overallocated?
If you fire these people, will you have to hire and retrain new people later when things change again? How costly would that be relative to retaining them now?
Why aren’t there senior leaders being fired? The failure of a project with such wide spread ramifications surely isn’t down to a bunch of little guys.
Here’s what happened:
Using the same overly reductionist, chain of command failed ideas described in this post, other leaders pursued a bad strategy and allocated resources poorly. Now, to avoid being punished and paying the consequences of their failed strategy, i.e. actually firing executives and senior leaders who caused this problem, they need to scapegoat it as an IT downsizing and they need some inexperienced twerp (this CTO) to spas out pretending like some critical calculus was applied to make the heartbreaking least-bad fewest cuts they could.
It’s disingenuous to the core. Absolutely this is shitty, low-accountability leadership.
Is your complaint that instead of looking to see "who are my mid-levels who can create a plan", he just assumes by their level that they cannot create a plan? Without detailed knowledge, I think most places hire senior/mid/junior based on exactly the criteria he describes.
Every team is fungible in the long run. If you have someone who is specialized labor, either they handoff to someone who is non-specialized now, or they do it later when they leave the company.
Edit: I think your response to dmak covers this, thanks.
> In a couple of days follow up with another more informal meeting. The news would have sunk, and the conversation would be more forward-thinking and productive.
That makes no sense to me. If I’m laid off, what could we possibly have to discuss? I’m sure HR would have all practical severance, benefits, legal information. What else are we gonna talk about?
I’ve been through a round of layoffs at a bank, and seen many more. Once you go down to HR you never go back to your desk. I’ve been on both sides of that, and honestly it seems the most sensible way to do things.
This 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.
While 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?
They're still your friend in 5 years or more, long after that job.
I did a mass termination many years ago, and those guys are still in touch with me. I made sure to telegraph that things weren't going well for the company.
One guy had a pregnant wife at home, he still laughed it off. Wrote to me the other day.
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?
Lots of people dunking on this guy may have missed the fact that this was day 2 on the job. I don’t necessarily agree with his approach, but it is an impossible situation to be in.
You don't seem to realize that having a lot of senior developers on a team can cause problems because there's no hierarchy. That's why junior developers and especially medior developers are very useful. Medior developers have quite a bit of experience too, they just haven't become leaders yet. Especially if your team size is a bit larger you will not want it to consist of only seniors. Also having explicit leadership positions for dev teams is questionable, especially for senior developers, product managers who are used to calling some of those shots.
This is one of the very few posts I would downvote if I could. More and more I feel we could do away with the entire C-Suite and be all the better for it.
Seems like an excuse for the high performers to start applying elsewhere. This company is clearly going nowhere, might as well trade it out for a nicer one.
The only ethical and correct decision was to resign.
First, he’s likely close to 15% of the budget, so problem solved.
Second, you join a company either so incompetent or venal that they didn’t give you notice they were on the verge of a substantial revenue loss. You’re the CTO, you are one of a small team of leaders with biggest stake in company, and supposed to be part of these discussions. Even before your official start day and especially day one.
So what was it? They knew this was likely to happen but didn’t tell you because they were afraid you’d back out? They are unethical, liars, untrustworthy, I quit.
They didn’t see this coming because the VP of Sales never flagged it as a risk? Ok, the Vp of Sales is either not being transparent or us incompetent, either way fire them, or I quit.
The execs at the top of a small startup need to be a team, brutally honest and transparent with each other. No hiding information, working together to solve problems.
You begin to sail the raft, you start fishing while out in the open seas. You reach another island and sell the fish, figure out that is the way you can have an easy life since you can pay other people to procure food, water and wood with fish. You build a better boat, hire more people and repeat the process.
You now have a huge rowing boat that goes very far out at sea since there are no fish left close to land, you now fully depend on the people on that boat to make it alive to the next island. There are people who row, people who fish, people to cook, people that are on the lookout for fishing spots and islands.
Your partner notices a guy who eats more than the average rower on the boat, but rows less. You throw him overboard. A fire starts near the rowers, but the rowers continue rowing. Turns out the guy you just threw overboard he always put out fires. You find another rower, tell him to put out the fire. He throws water over it. It is now worse. You figure out the fire is the cook's fault for using too much oil. He only used so much oil because the lookouts thought fish oil is good for their eyes so they can see more ahead. You know this to be only partially true, but they don't seem to understand and even though the fire happened they still demand their food fried in fish oil.
You throw one of the lookouts in the water to make an example. The lookouts stop eating deep fried food. Now the people who fish complain they work too much. Turns out the deep fried food gave the lookouts energy to shout at the people who fish where to fish at. Now, the people who fish need to stop what they're doing and go to the lookouts for information. Because of all the extra effort the people are doing, you are now out of fresh water in the boat.
Congratulations, you now know how a CTO feels like.