11 ms·

I'll raise your spark for complete destruction. Here's an incomplete list that I keep around of the mechanisms that I've observed so far that have played a big

by samhuk 3y ago

I'll raise your spark for complete destruction. Here's an incomplete list that I keep around of the mechanisms that I've observed so far that have played a big part in the decline/destruction of an engineering team (and product thereof): 1. Too-technical leaders: As startup scales, there can sometimes be a mad dash to fill new leadership roles (e.g. VP of Eng, Arch, CTO, etc.). Super-star engineers present at startup phase sometimes move into these when they are not the leadership type, causing engineering team to devolve into a visionless, directionless zoo. 2. Non-technical leaders: Inverse to the above - as startup scales, in desperation, new leadership roles are filled with non-technical individuals who have little to no engineering experience. This causes similar outcome to #1 (albiet slightly different, but equally perilous). 3. Problem engineers: Small number of leaders lack a spine, conducting shallow interviews and let in "problem engineers" who spoil the party and wreak havoc. Lax hiring practices almost always are reflected into non-existent firing practices, leading to them lingering around. From experience, it only takes around ~5-10% of a team being this type for it to have a large negative impact, as they tend to derail progress, dodge responsibility, reputation farm, push rubbish, all that nonsense. It harms morale, and the skies turn grey in the office... 4. Micromanagement: Speaks for itself. Leads to red tape, demoralization, timeline slippage and frustration. EDIT: I'de love to hear how these foot-guns have been avoided. From experience it seems really challenging, as if like magic; as if cultivating and maintaining a good engineering team and culture therein is like balancing a pencil on it's nib...

endorphine 3y ago
Maybe by avoiding fast scaling, which implies avoiding VC money.
- WJW 3y ago
  From experience I can say that these problems can occur just as well in bootstrapped companies when they reach a certain size. It's a problem with the number of employees regardless of how fast the company gets there IMO.
- Aurornis 3y ago
  The first startup I worked for was a slow-growth company that had slowly expanded over 7 years to only about 50 people. A dinosaur in startup terms. It still had the same problems as above. Expanding slowly doesn’t automatically protect you from these things.
  - brabel 3y ago
    Are you being sarcastic? To grow to 50 people in 7 years is probably only for the top 5% successful startups.
- re-thc 3y ago
  > Maybe by avoiding fast scaling, which implies avoiding VC money. There are still things you can do, e.g. don't pick the offers in a round with the most $$$ - instead pick the 1 that will help you the most. Set the right expectations. Most of the time it's not the VC money that's the problem but the founders being consumed by suddenly being "rich".
Aurornis 3y ago
As a corollary of these people problems, I would add: 1. Not correcting problem hires fast enough. First time founders are often too hesitant to give negative feedback, demote a too-technical manager who should have stayed an IC, or remove a problem employee who isn’t working out. The anecdote that comes to mind is a local startup that hired a C-level executive’s UI designer friend into their VP of Product role. He was wholly incapable of doing the job but they kept him in the job for 2 years to “give him a chance to grow into it.” Everyone below VP level openly talked about how the VP of Product was incompetent and how to work around him. The company’s product initiatives ultimately failed to even get started and they had to pivot to entirely services based work. Do not stay at a startup that insists on keeping unqualified people in leadership positions long after everyone in the company has given up on them. 2. Firing the wrong people The same startup was forced to downsize, largely because their product plans failed to even become defined enough to start under the incompetent VP of Product. It was the perfect opportunity to fire the VP of Product and his sprawling empire of people who did very little, but they avoided that due to his connections to a C-level executive. Instead, they started cutting engineers. They focused on cutting engineers with the highest compensation out of a misguided effort to cut as few people as possible. In the process, they lost their key engineers who were holding things together. They sent a message to everyone that incompetence is tolerated if you know the right people. And they lost even more core engineers who quit in the months after those layoffs. Everyone makes hiring mistakes. It’s how you respond to those hiring mistakes that will seal the fate of the company.
- samhuk 3y ago
  Thanks for your comment. Totally empathize with your experiences there.
- halkony 3y ago
  Ray Dalio talks about this in his book "Principles." The specific advice he offers is "hire slowly, fire quickly."
  - bcantrill 3y ago
    Terrible advice (from a broadly terrible book, I hasten to add). The reason that this is terrible advice: if you "fire quickly", it is because something is either grievously wrong (a mishire) or you are firing based on limited evidence. If the former, you have a hiring problem, not a firing problem; if the latter, you will generate a fear-based culture. Now, if you're running a prison, a fear-based culture may be exactly what you're after -- but fear is anathema to innovation, and if your endeavor requires any creativity whatsoever, you should be seeking to build mutual trust, not foster institutional fear.
yafbum 3y ago
Big +1 on too technical leaders. Seen this a couple times with brilliant engineers who, once they became in charge of 50 different teams, appeared to try to just do the same work they did in one team but "scaled". Put every team in a spreadsheet and try to automate management through uniform metrics instead of focusing on managing and growing his direct reports. And another time, seen a less technical leader step in, see engineers around me roll their eyes a couple of times at the lady (with maybe a smidge of male chauvinism blended in), but then see her actually fire bad hires, hire star players, and get everyone to align their priorities so they could be productive. Leadership is a very different job from the kind of technical excellence that too often gets rewarded by promotions (vs raises or bonuses).
- kevin_nisbet 3y ago
  Another +1, I left a startup over exactly this, all the managers, directors, and VP of engineering were IC engineers maybe 2 years prior. It was a shame, because I really enjoyed my role at that company in general, but ended up opting to leave after getting a really terrible leader.
- Mistletoe 3y ago
  I've seen this in science as well. Analysts get promoted to managers and managing is a completely different skill set that involves social skills, communication, empathy- all people skills that they didn't need to be a good analyst. They were promoted because they were good at being an analyst- meticulous, quiet, just do their job and don't interact with others. Unfortunately almost none of this carries over to being a good manager. I wished many times that they just hired people with management skills from some field completely outside of science, a manager doesn't really need to know the intricacies of the work to do their job well. My last industry job saw the company implode from this cycle as everyone got pissed off and left the company. My old ex co-worker sent me a letter from the CEO last week saying layoffs were starting because revenues were down and they keep losing clients...
  - ghaff 3y ago
    That's true. It's also the case that, if you polled people here, you'd find no shortage of people with zero respect for managers without technical backgrounds.
liquidpele 3y ago
Don’t forget: Hiring remote contractors to “speed up” things. Dev will slow to 50% and meetings will double as you attempt unsuccessfully to teach them how to code.
- WanderPanda 3y ago
  More general hazard: Treating engineers as fungible resources
  - ricardobayes 3y ago
    Absolutely. If you have a software company, literally 100% of your company valuation goes home after 6PM. If a key engineer leaves, you lose a _lot_ more than 2-300k. In opportunity cost, you lose tens of millions, possibly.
- gochi 3y ago
  Anytime a leader sees new hires or contractors as a "speed boost" is when it all goes to the dump. The sooner we get past this idea, and start viewing new hires/contractors as "speed bumps" the better. Bringing anyone new into the fold should always be a slow process!
  - tstrimple 3y ago
    Depends on the scope of the change and the objectives of the company. This is more true in larger organizations than startups, but not all technical problems you’re working on are directly linked to your value prop. I’ve seen good results in many cases where some systems are handed off to be managed by contractors so the FTE devs can focus their attention on improving the product which actually makes them money. What I haven’t seen work is (which is what I think you’re describing more specifically) bringing on new hires or contractors to a project in flight in an attempt to deliver it more quickly. That’s where we get into Mythical Man Month territory.
Zetice 3y ago
I think your question about avoiding these mechanisms isn't the right one; the real question is, how does one succeed despite these inevitable problems? In other words, I don't think you avoid these, I think you understand they're coming and accept the trade off, making sure it's worth the issues you invite when you do have to promote those engineers/non-technical people, for example.
- samhuk 3y ago
  I think another comment made a good point - It's all about rapidly determining when the hires and promotions aren't right.
steve76 3y ago
[dead]
dasil003 3y ago
After 25 years in the full range of IC and management positions, I'm convinced there's no substitute for expertise, maturity and judgement. I could come up with some rules of thumb (eg. ICs need the maximum amount of agency they are capable of handling), but every rule has its exception. Distilled wisdom is easily misinterpreted, taken out of context, and cargo culted by those with insufficient experience to apply it. I've seen how small dynamics resulting from individual personalities and nuances of org structure have led to massive dysfunction and productivity loss, even though everyone was well intentioned and doing their job to the best of their ability. I could list out hundreds of behavioral "flaws" that individuals exhibit, but there's no way to fix them all directly, good engineering can't be done by top-down edict and central planning. Instead, you need a critical mass of people, including engineers on the ground, with a good end-to-end understanding of the product and business so that micro-decisions can be suitably informed by the big picture, and the right concerns can be escalated for leadership attention. You need to be able to weigh the cost of product, design, legal, financial, support, security, and operations across both short and long-term to make the right decisions. This is only possible with a high degree of mutual trust and safety for experts to voice their opinion and find the right tradeoffs. It's very easy for egos and personality conflicts to come in the way, hence the need for maturity in leadership. Balancing a pencil on its nib is not a bad analogy.
- YZF 3y ago
  "Distilled wisdom is easily misinterpreted, taken out of context, and cargo culted by those with insufficient experience to apply it." - so true. The surprising/unfortunate thing is that dysfunctional unproductive organizations can survive and even thrive. There isn't an obvious cause and effect and the time it takes until effects are seen can be measured in years or decades.
bcantrill 3y ago
That's a great taxonomy of foot-guns! As to how they can be avoided, I can only describe some of what has worked for us so far, with the caveats that we are still small (~60 employees); that none of this is formulaic or perfect; and that there are many reasons why what we have done might not work for others -- or may not work for us as we get larger! That said, here is some of what has broadly worked for us: 1. Writing-intensive hiring process This is controversial for some, but I have the personal advantage of having previously made The Worst Hire of All Time -- one that forced me to accept that using resume + interviews as the sole (or even primary) criteria left me extraordinarily vulnerable to Problem Engineers. We ask candidates not just for a portfolio of their work (and analysis samples and so on), but also ask them values-based questions[0] -- the answers to which are astonishingly revealing. Our review of candidate materials constitutes the bulk of our hiring process. 2. Transparent compensation Another one that is surely controversial, but in my professional experience, an amazing number of anti-patterns arise from the scramble compensation -- and usually not for itself per se (that is, not for the marginal dollars), but rather for what it represents in terms of validation, power and so on. Making compensation transparent forces some measure of organizational health -- to say nothing for the bright light it shines on any institutionalized inequities. 3. Uniform compensation One that even more people will find controversial. ;) When we wrote our blog piece on this 2+ years ago[1], we assumed that it wouldn't last as long as it has -- but it honestly is more important to us now than ever before. Especially as we go to expand the team with roles that are often less well compensated (e.g., customer-facing roles), the fact that we explicitly compensate them as well as everyone else allows us to attract extraordinary folks to the company. We still don't know if this is going to last forever, but we have seen so many incredibly benefits from it that we have stopped burdening it with asterisks. 4. Very, very careful hiring We are deliberately lean. We add people to the company very carefully, and we have no one inside the company who is incentivized by the size of their team (see #3, above!). When we add people, we keep a sharp eye on versatility and intrinsic motivation. This allows us to do more with relatively fewer people -- helping us avoid the foot-guns you've outlined. That said, it is also not without side-effects: a consequence of this is that we are extraordinarily selective, which means we have many more people that want to work at Oxide than we can reasonably accommodate -- and it can be really, really hard to turn down someone who you think will likely be successful! [0] https://docs.google.com/document/d/1Xtofg-fMQfZoq8Y3oSAKjEgDQCRHx-GMSmPcxdEea4A/edit https://docs.google.com/document/d/1Xtofg-fMQfZoq8Y3oSAKjEgD... [1] https://oxide.computer/blog/compensation-as-a-reflection-of-values https://oxide.computer/blog/compensation-as-a-reflection-of-...
lr4444lr 3y ago
Here's an idea I've seen work: stop assuming people over 35 aren't a good fit for a start up. People who've been in leadership for a while but have the chops and in their day did on the ground work, and who can - given enough time and guidance - understand the minutest detail of a new tech stack or financial maneuver, command the respect of the super stars doing the day to day for their contribution of far seeing leadership.
- samhuk 3y ago
  Preface: I'm not saying that this norm is necessarily right, rather just explaining the mechanism that I believe is at play here. Isn't part of the issue that early on in a start-up, everyone is indispensable, and often that comes with putting in extra hours and going the "extra mile" for the viability of the company? When you are over 35, 30 even, you are much more likely to have a spouse, children, etc., and all these command more of your time that the business wants to capitalize on. Personally, I've seen some real rock-star engineers both at 20 and at 40, however more often than not for different reasons. Honestly, not once have I ever learned a decent life lesson from engineers around my age (I'de say I'm on the younger side), however it's been several highly memorable times that an engineer on the older side has pulled me away, given me some real hard-hitting, incredibly valuable engineering and life lessons, and changed my career and sometimes life for the better. It's a complex world!
  - aardvark179 3y ago
    > Isn't part of the issue that early on in a start-up, everyone is indispensable, and often that comes with putting in extra hours and going the "extra mile" for the viability of the company? There seems to be a strong culture in American companies, and especially in startups, of rewarding heroic efforts. But if I see people putting in heroic efforts to get things done I tend to look for ways to not need those efforts in the future. Good experienced engineers can help ensure that you don’t keep having to go that extra mile to get the job done in the first place.
pojzon 3y ago
Im seen as a problem engineer even if its never my intention. Im a bit anxious and introverted and thus like to get my part done and focus on other things. This always results in rest of the team losing will to go far and beyond. I dont know what to do about it, beside aknowledging it exists. Do you say that ppl like me should simply quit and go working at sewege? I dont think I like that idea. So what can I do if thats just how I am ? I cant seem to change how others see ppl like me.
- ghaff 3y ago
  >So what can I do if thats just how I am ? Most things are not written in stone. You can probably change even if it's not comfortable to do so. Maybe a different role or organization would be a better fit. But typically just getting your part done and moving on isn't the best fit for a lot of jobs and, even if you work for yourself, you probably even have more interactions with clients at that point.
- Tainnor 3y ago
  Well, nobody has the intention of being a problem engineer. That said, from your comment I haven't really understood why you're considered (or are considering yourself) to be a problem engineer?
- ricardobayes 3y ago
  You can either educate others why you see things in a certain way. If it's unexplainable, or the majority doesn't accept it, move on: change your ways or accept they are going to see you as such.
- samhuk 3y ago
  From somebody who, perhaps sometimes can be quite full-on about software quality, craftsmanship, and just generally doing good, here's what's helped me in the past when faced with a company/team that has morale, skill, or other problems: 1. "The extent to which you publicly complain about something should be proportional to the robustness of your solution and your confidence in it." 2. If you think things need to be done better, lead by example. I've found that you will be hated for saying things are bad, but loved for proving how things can be good (by example). 3. Note down your concerns (Notion is free!). Wait on them, then talk about them >=1 day later if you still feel like they are valid. 4. Ensure you have enough employable skills on the side so that you can jump ship if the company or your place within it is totally DOA.
jotato 3y ago
One thing I'll add - or maybe it expands on too technical of a leader - is when a brilliant outside hire is brought in to fill the arch/principal/whatever role. Then they start looking at the app and questioning every decision calling everything they don't have context on "technical debt" I've seen it a few times. I told a new VP of Eng he was being asinine because he wasn't there for the original problem, decision, or timeline and saying we made a bad call is just showing ignorance. Thankfully, He pulled me aside later to thank me and asked for more background on it. After hearing the whole story he agreed. We did the right thing. Now, that could have gone the other way. And I've seen it happen. When it does, it sucks.
- Aurornis 3y ago
  It sounds like the VP Eng was actually a great leader if he could take feedback like that in stride and admit when he was wrong. Bad leaders would have dug in their heels and sidelined the person with abrasive feedback (you).
  - jotato 3y ago
    Absolutely. My point is that it doesn't always go that way. He had his faults, but he could take string feedback. If I recall, he said something to the effect of "not many people speak to me like that. I forget how helpful it is to be challenged"
- samhuk 3y ago
  I agree with sibling comment. Also, wow, that took some courage. Personally, I deeply value this way of direct communication when everybody feels free to speak up when things go wrong, and nobody has precious egos they feel need protecting.
- OJFord 3y ago
  It could go the other way though, to be along the the ride and hope for the 'brilliant outside hire' to come along and point out the problems.
- p_l 3y ago
ricardobayes 3y ago
Re: 3. "Problem engineers" are a similar problem to those users in a forum who don't actively break the rules but destroy the community. And for 4, the opposite is even worse, aka "no management". So when you develop something but it turns out the outcome was not needed or in a different way.
Tainnor 3y ago
Problem engineers are not necessarily all new hires. It could also be people who were there initially but fail to transition into a role more suitable for a growing company. A classical example, which I've seen before, is a cowboy coder who can be a useful asset in the very early stages, but who later demonstrates a total lack of teamwork ability. Such people are even worse than bad new hires because they have a certain clout with management who is therefore more willing to turn a blind eye.
- jonas21 3y ago
  This sounds like the opposite of what the author had in mind. The cowboy coder is the one with spark, and the need to "transition into a role more suitable for a growing company" is the problem.
  - Tainnor 3y ago
    Companies change, and if you can't adapt then the problem is you. Being able to work together with your peers and not alienate them is not too much of an ask.
    - StackOverlord 3y ago
      > the problem is you Scapegoat mechanism.
      - Tainnor 3y ago
        Avoidance of responsibility.
extr 3y ago
What is to be done if you find yourself in the first situation (too-technical leader)? I found myself there before a few times...reporting to someone who was no doubt a brilliant IC but has no concept of things like communicating vision or even basic project management. Would be curious to understand if anyone has been able to "fix" this from the IC side.
- samhuk 3y ago
  I find it hard to imagine that it's possible to, in all likelihood, improve a too-technical leader problem from the individual team member position. There's only two ways through which that I can conceive it being solved: 1. Too-technical leader realizes they aren't fit for purpose, perhaps due to indicators like stress, missed targets, team morale, etc. 2. Higher-up leadership notices aforementioned issues and give them the ultimatum: leave or side-/demote to more technically-focused role.
elric 3y ago
I'll throw in greed as another factor. Being ambitious is fine, but being greedy will wreck a startup in no time flat. Or in the case of my previous employers, in about 13 months ...
- samhuk 3y ago
  I've always assumed that greed, particularly when it's egregious and endemic, would more rapidly unwind a start-up. My OC was more focusing on those mechanisms that tend to be at play at start-ups that cause them to gradually decline/implode. However, I totally agree with your point. Also, sorry that happened to you!
duxup 3y ago
Yeah that 5 to 10 % seems about right. I recall a teamwork study that found few if any superstar team players can really make any given team better, but they did discover that one bad apple can easily kill a team’s productivity, happiness and etc. I once worked for a company that was really great about “no finger pointing” and lots of trust of employees to do the right thing. We acquired a small troubled company along the way, they were a mess with finger pointing and empty accusations. Within a year they had infected our entire department:(
srvmshr 3y ago
Elaborating a tiny bit on #2: It is a dangerous situation when non-technical leadership comes up with very specific technical opinions - based on hearsay & evangelists on their Twitter/Instagram. "I saw X on his Reel telling changing everything in our frontend to purely Coffescript will be more durable" is a kind of advice which does not bode well generally

by samhuk 3y ago

endorphine 3y ago

Maybe by avoiding fast scaling, which implies avoiding VC money.

WJW 3y ago
From experience I can say that these problems can occur just as well in bootstrapped companies when they reach a certain size. It's a problem with the number of employees regardless of how fast the company gets there IMO.
Aurornis 3y ago
The first startup I worked for was a slow-growth company that had slowly expanded over 7 years to only about 50 people. A dinosaur in startup terms. It still had the same problems as above. Expanding slowly doesn’t automatically protect you from these things.
- brabel 3y ago
  Are you being sarcastic? To grow to 50 people in 7 years is probably only for the top 5% successful startups.
re-thc 3y ago
> Maybe by avoiding fast scaling, which implies avoiding VC money. There are still things you can do, e.g. don't pick the offers in a round with the most $$$ - instead pick the 1 that will help you the most. Set the right expectations. Most of the time it's not the VC money that's the problem but the founders being consumed by suddenly being "rich".

Aurornis 3y ago

As a corollary of these people problems, I would add: 1. Not correcting problem hires fast enough. First time founders are often too hesitant to give negative feedback, demote a too-technical manager who should have stayed an IC, or remove a problem employee who isn’t working out. The anecdote that comes to mind is a local startup that hired a C-level executive’s UI designer friend into their VP of Product role. He was wholly incapable of doing the job but they kept him in the job for 2 years to “give him a chance to grow into it.” Everyone below VP level openly talked about how the VP of Product was incompetent and how to work around him. The company’s product initiatives ultimately failed to even get started and they had to pivot to entirely services based work. Do not stay at a startup that insists on keeping unqualified people in leadership positions long after everyone in the company has given up on them. 2. Firing the wrong people The same startup was forced to downsize, largely because their product plans failed to even become defined enough to start under the incompetent VP of Product. It was the perfect opportunity to fire the VP of Product and his sprawling empire of people who did very little, but they avoided that due to his connections to a C-level executive. Instead, they started cutting engineers. They focused on cutting engineers with the highest compensation out of a misguided effort to cut as few people as possible. In the process, they lost their key engineers who were holding things together. They sent a message to everyone that incompetence is tolerated if you know the right people. And they lost even more core engineers who quit in the months after those layoffs. Everyone makes hiring mistakes. It’s how you respond to those hiring mistakes that will seal the fate of the company.

samhuk 3y ago
Thanks for your comment. Totally empathize with your experiences there.
halkony 3y ago
Ray Dalio talks about this in his book "Principles." The specific advice he offers is "hire slowly, fire quickly."
- bcantrill 3y ago
  Terrible advice (from a broadly terrible book, I hasten to add). The reason that this is terrible advice: if you "fire quickly", it is because something is either grievously wrong (a mishire) or you are firing based on limited evidence. If the former, you have a hiring problem, not a firing problem; if the latter, you will generate a fear-based culture. Now, if you're running a prison, a fear-based culture may be exactly what you're after -- but fear is anathema to innovation, and if your endeavor requires any creativity whatsoever, you should be seeking to build mutual trust, not foster institutional fear.

yafbum 3y ago

Big +1 on too technical leaders. Seen this a couple times with brilliant engineers who, once they became in charge of 50 different teams, appeared to try to just do the same work they did in one team but "scaled". Put every team in a spreadsheet and try to automate management through uniform metrics instead of focusing on managing and growing his direct reports. And another time, seen a less technical leader step in, see engineers around me roll their eyes a couple of times at the lady (with maybe a smidge of male chauvinism blended in), but then see her actually fire bad hires, hire star players, and get everyone to align their priorities so they could be productive. Leadership is a very different job from the kind of technical excellence that too often gets rewarded by promotions (vs raises or bonuses).

kevin_nisbet 3y ago
Another +1, I left a startup over exactly this, all the managers, directors, and VP of engineering were IC engineers maybe 2 years prior. It was a shame, because I really enjoyed my role at that company in general, but ended up opting to leave after getting a really terrible leader.
Mistletoe 3y ago
I've seen this in science as well. Analysts get promoted to managers and managing is a completely different skill set that involves social skills, communication, empathy- all people skills that they didn't need to be a good analyst. They were promoted because they were good at being an analyst- meticulous, quiet, just do their job and don't interact with others. Unfortunately almost none of this carries over to being a good manager. I wished many times that they just hired people with management skills from some field completely outside of science, a manager doesn't really need to know the intricacies of the work to do their job well. My last industry job saw the company implode from this cycle as everyone got pissed off and left the company. My old ex co-worker sent me a letter from the CEO last week saying layoffs were starting because revenues were down and they keep losing clients...
- ghaff 3y ago
  That's true. It's also the case that, if you polled people here, you'd find no shortage of people with zero respect for managers without technical backgrounds.

liquidpele 3y ago

Don’t forget: Hiring remote contractors to “speed up” things. Dev will slow to 50% and meetings will double as you attempt unsuccessfully to teach them how to code.

WanderPanda 3y ago
More general hazard: Treating engineers as fungible resources
- ricardobayes 3y ago
  Absolutely. If you have a software company, literally 100% of your company valuation goes home after 6PM. If a key engineer leaves, you lose a _lot_ more than 2-300k. In opportunity cost, you lose tens of millions, possibly.
gochi 3y ago
Anytime a leader sees new hires or contractors as a "speed boost" is when it all goes to the dump. The sooner we get past this idea, and start viewing new hires/contractors as "speed bumps" the better. Bringing anyone new into the fold should always be a slow process!
- tstrimple 3y ago
  Depends on the scope of the change and the objectives of the company. This is more true in larger organizations than startups, but not all technical problems you’re working on are directly linked to your value prop. I’ve seen good results in many cases where some systems are handed off to be managed by contractors so the FTE devs can focus their attention on improving the product which actually makes them money. What I haven’t seen work is (which is what I think you’re describing more specifically) bringing on new hires or contractors to a project in flight in an attempt to deliver it more quickly. That’s where we get into Mythical Man Month territory.

Zetice 3y ago

I think your question about avoiding these mechanisms isn't the right one; the real question is, how does one succeed despite these inevitable problems? In other words, I don't think you avoid these, I think you understand they're coming and accept the trade off, making sure it's worth the issues you invite when you do have to promote those engineers/non-technical people, for example.

samhuk 3y ago
I think another comment made a good point - It's all about rapidly determining when the hires and promotions aren't right.

steve76 3y ago

[dead]

dasil003 3y ago

After 25 years in the full range of IC and management positions, I'm convinced there's no substitute for expertise, maturity and judgement. I could come up with some rules of thumb (eg. ICs need the maximum amount of agency they are capable of handling), but every rule has its exception. Distilled wisdom is easily misinterpreted, taken out of context, and cargo culted by those with insufficient experience to apply it. I've seen how small dynamics resulting from individual personalities and nuances of org structure have led to massive dysfunction and productivity loss, even though everyone was well intentioned and doing their job to the best of their ability. I could list out hundreds of behavioral "flaws" that individuals exhibit, but there's no way to fix them all directly, good engineering can't be done by top-down edict and central planning. Instead, you need a critical mass of people, including engineers on the ground, with a good end-to-end understanding of the product and business so that micro-decisions can be suitably informed by the big picture, and the right concerns can be escalated for leadership attention. You need to be able to weigh the cost of product, design, legal, financial, support, security, and operations across both short and long-term to make the right decisions. This is only possible with a high degree of mutual trust and safety for experts to voice their opinion and find the right tradeoffs. It's very easy for egos and personality conflicts to come in the way, hence the need for maturity in leadership. Balancing a pencil on its nib is not a bad analogy.

YZF 3y ago
"Distilled wisdom is easily misinterpreted, taken out of context, and cargo culted by those with insufficient experience to apply it." - so true. The surprising/unfortunate thing is that dysfunctional unproductive organizations can survive and even thrive. There isn't an obvious cause and effect and the time it takes until effects are seen can be measured in years or decades.

bcantrill 3y ago

That's a great taxonomy of foot-guns! As to how they can be avoided, I can only describe some of what has worked for us so far, with the caveats that we are still small (~60 employees); that none of this is formulaic or perfect; and that there are many reasons why what we have done might not work for others -- or may not work for us as we get larger! That said, here is some of what has broadly worked for us: 1. Writing-intensive hiring process This is controversial for some, but I have the personal advantage of having previously made The Worst Hire of All Time -- one that forced me to accept that using resume + interviews as the sole (or even primary) criteria left me extraordinarily vulnerable to Problem Engineers. We ask candidates not just for a portfolio of their work (and analysis samples and so on), but also ask them values-based questions[0] -- the answers to which are astonishingly revealing. Our review of candidate materials constitutes the bulk of our hiring process. 2. Transparent compensation Another one that is surely controversial, but in my professional experience, an amazing number of anti-patterns arise from the scramble compensation -- and usually not for itself per se (that is, not for the marginal dollars), but rather for what it represents in terms of validation, power and so on. Making compensation transparent forces some measure of organizational health -- to say nothing for the bright light it shines on any institutionalized inequities. 3. Uniform compensation One that even more people will find controversial. ;) When we wrote our blog piece on this 2+ years ago[1], we assumed that it wouldn't last as long as it has -- but it honestly is more important to us now than ever before. Especially as we go to expand the team with roles that are often less well compensated (e.g., customer-facing roles), the fact that we explicitly compensate them as well as everyone else allows us to attract extraordinary folks to the company. We still don't know if this is going to last forever, but we have seen so many incredibly benefits from it that we have stopped burdening it with asterisks. 4. Very, very careful hiring We are deliberately lean. We add people to the company very carefully, and we have no one inside the company who is incentivized by the size of their team (see #3, above!). When we add people, we keep a sharp eye on versatility and intrinsic motivation. This allows us to do more with relatively fewer people -- helping us avoid the foot-guns you've outlined. That said, it is also not without side-effects: a consequence of this is that we are extraordinarily selective, which means we have many more people that want to work at Oxide than we can reasonably accommodate -- and it can be really, really hard to turn down someone who you think will likely be successful! [0] https://docs.google.com/document/d/1Xtofg-fMQfZoq8Y3oSAKjEgDQCRHx-GMSmPcxdEea4A/edit https://docs.google.com/document/d/1Xtofg-fMQfZoq8Y3oSAKjEgD... [1] https://oxide.computer/blog/compensation-as-a-reflection-of-values https://oxide.computer/blog/compensation-as-a-reflection-of-...

lr4444lr 3y ago

Here's an idea I've seen work: stop assuming people over 35 aren't a good fit for a start up. People who've been in leadership for a while but have the chops and in their day did on the ground work, and who can - given enough time and guidance - understand the minutest detail of a new tech stack or financial maneuver, command the respect of the super stars doing the day to day for their contribution of far seeing leadership.

samhuk 3y ago
Preface: I'm not saying that this norm is necessarily right, rather just explaining the mechanism that I believe is at play here. Isn't part of the issue that early on in a start-up, everyone is indispensable, and often that comes with putting in extra hours and going the "extra mile" for the viability of the company? When you are over 35, 30 even, you are much more likely to have a spouse, children, etc., and all these command more of your time that the business wants to capitalize on. Personally, I've seen some real rock-star engineers both at 20 and at 40, however more often than not for different reasons. Honestly, not once have I ever learned a decent life lesson from engineers around my age (I'de say I'm on the younger side), however it's been several highly memorable times that an engineer on the older side has pulled me away, given me some real hard-hitting, incredibly valuable engineering and life lessons, and changed my career and sometimes life for the better. It's a complex world!
- aardvark179 3y ago
  > Isn't part of the issue that early on in a start-up, everyone is indispensable, and often that comes with putting in extra hours and going the "extra mile" for the viability of the company? There seems to be a strong culture in American companies, and especially in startups, of rewarding heroic efforts. But if I see people putting in heroic efforts to get things done I tend to look for ways to not need those efforts in the future. Good experienced engineers can help ensure that you don’t keep having to go that extra mile to get the job done in the first place.

pojzon 3y ago

Im seen as a problem engineer even if its never my intention. Im a bit anxious and introverted and thus like to get my part done and focus on other things. This always results in rest of the team losing will to go far and beyond. I dont know what to do about it, beside aknowledging it exists. Do you say that ppl like me should simply quit and go working at sewege? I dont think I like that idea. So what can I do if thats just how I am ? I cant seem to change how others see ppl like me.

ghaff 3y ago
>So what can I do if thats just how I am ? Most things are not written in stone. You can probably change even if it's not comfortable to do so. Maybe a different role or organization would be a better fit. But typically just getting your part done and moving on isn't the best fit for a lot of jobs and, even if you work for yourself, you probably even have more interactions with clients at that point.
Tainnor 3y ago
Well, nobody has the intention of being a problem engineer. That said, from your comment I haven't really understood why you're considered (or are considering yourself) to be a problem engineer?
ricardobayes 3y ago
You can either educate others why you see things in a certain way. If it's unexplainable, or the majority doesn't accept it, move on: change your ways or accept they are going to see you as such.
samhuk 3y ago
From somebody who, perhaps sometimes can be quite full-on about software quality, craftsmanship, and just generally doing good, here's what's helped me in the past when faced with a company/team that has morale, skill, or other problems: 1. "The extent to which you publicly complain about something should be proportional to the robustness of your solution and your confidence in it." 2. If you think things need to be done better, lead by example. I've found that you will be hated for saying things are bad, but loved for proving how things can be good (by example). 3. Note down your concerns (Notion is free!). Wait on them, then talk about them >=1 day later if you still feel like they are valid. 4. Ensure you have enough employable skills on the side so that you can jump ship if the company or your place within it is totally DOA.

jotato 3y ago

One thing I'll add - or maybe it expands on too technical of a leader - is when a brilliant outside hire is brought in to fill the arch/principal/whatever role. Then they start looking at the app and questioning every decision calling everything they don't have context on "technical debt" I've seen it a few times. I told a new VP of Eng he was being asinine because he wasn't there for the original problem, decision, or timeline and saying we made a bad call is just showing ignorance. Thankfully, He pulled me aside later to thank me and asked for more background on it. After hearing the whole story he agreed. We did the right thing. Now, that could have gone the other way. And I've seen it happen. When it does, it sucks.

Aurornis 3y ago
It sounds like the VP Eng was actually a great leader if he could take feedback like that in stride and admit when he was wrong. Bad leaders would have dug in their heels and sidelined the person with abrasive feedback (you).
- jotato 3y ago
  Absolutely. My point is that it doesn't always go that way. He had his faults, but he could take string feedback. If I recall, he said something to the effect of "not many people speak to me like that. I forget how helpful it is to be challenged"
samhuk 3y ago
I agree with sibling comment. Also, wow, that took some courage. Personally, I deeply value this way of direct communication when everybody feels free to speak up when things go wrong, and nobody has precious egos they feel need protecting.
OJFord 3y ago
It could go the other way though, to be along the the ride and hope for the 'brilliant outside hire' to come along and point out the problems.
p_l 3y ago

ricardobayes 3y ago

Re: 3. "Problem engineers" are a similar problem to those users in a forum who don't actively break the rules but destroy the community. And for 4, the opposite is even worse, aka "no management". So when you develop something but it turns out the outcome was not needed or in a different way.

Tainnor 3y ago

Problem engineers are not necessarily all new hires. It could also be people who were there initially but fail to transition into a role more suitable for a growing company. A classical example, which I've seen before, is a cowboy coder who can be a useful asset in the very early stages, but who later demonstrates a total lack of teamwork ability. Such people are even worse than bad new hires because they have a certain clout with management who is therefore more willing to turn a blind eye.

jonas21 3y ago
This sounds like the opposite of what the author had in mind. The cowboy coder is the one with spark, and the need to "transition into a role more suitable for a growing company" is the problem.
- Tainnor 3y ago
  Companies change, and if you can't adapt then the problem is you. Being able to work together with your peers and not alienate them is not too much of an ask.
  - StackOverlord 3y ago
    > the problem is you Scapegoat mechanism.
    - Tainnor 3y ago
      Avoidance of responsibility.

extr 3y ago

What is to be done if you find yourself in the first situation (too-technical leader)? I found myself there before a few times...reporting to someone who was no doubt a brilliant IC but has no concept of things like communicating vision or even basic project management. Would be curious to understand if anyone has been able to "fix" this from the IC side.

samhuk 3y ago
I find it hard to imagine that it's possible to, in all likelihood, improve a too-technical leader problem from the individual team member position. There's only two ways through which that I can conceive it being solved: 1. Too-technical leader realizes they aren't fit for purpose, perhaps due to indicators like stress, missed targets, team morale, etc. 2. Higher-up leadership notices aforementioned issues and give them the ultimatum: leave or side-/demote to more technically-focused role.

elric 3y ago

I'll throw in greed as another factor. Being ambitious is fine, but being greedy will wreck a startup in no time flat. Or in the case of my previous employers, in about 13 months ...

samhuk 3y ago
I've always assumed that greed, particularly when it's egregious and endemic, would more rapidly unwind a start-up. My OC was more focusing on those mechanisms that tend to be at play at start-ups that cause them to gradually decline/implode. However, I totally agree with your point. Also, sorry that happened to you!

duxup 3y ago

Yeah that 5 to 10 % seems about right. I recall a teamwork study that found few if any superstar team players can really make any given team better, but they did discover that one bad apple can easily kill a team’s productivity, happiness and etc. I once worked for a company that was really great about “no finger pointing” and lots of trust of employees to do the right thing. We acquired a small troubled company along the way, they were a mess with finger pointing and empty accusations. Within a year they had infected our entire department:(

srvmshr 3y ago

Elaborating a tiny bit on #2: It is a dangerous situation when non-technical leadership comes up with very specific technical opinions - based on hearsay & evangelists on their Twitter/Instagram. "I saw X on his Reel telling changing everything in our frontend to purely Coffescript will be more durable" is a kind of advice which does not bode well generally