161–170 of 287 posts
It's something I've personally seen and have read about so many times. Some make it through this stage but it's extremely difficult because it requires a very different set of skills and experiences. It becomes less about grinding, which in theory is very simple to explain and encourage.
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…
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 th…
> This always results in rest of the team losing will to go far and beyond.
The logic chain here is not very clear, I'm wondering if you actually understand what's going on.
The goal of the company was to provide standard ways to calibrate engineer levels for promotions and performance management.
Guess what happened: Most managers started rating engineers on exactly that rubric. If you miss something in the rubric, you get a lower rating. So engineers started following the rubric precisely. Which meant, every senior engineer spent more time on managing 2-3 junior engineers. Wrote at least 1 RFC every 6 months. And basically checked boxes on the sheet so as to not miss out anything during a performance review.
Nothing got delivered from the team. Morale in the team dropped. And nothing really mattered except the career ladder document.
Engineers spent more time managing the career ladder document than actually delivering anything.
Managers spent more time rating people than actually delivering anything.
Features were half-assed, customers started getting frustrated. And clueless upper management started putting more pressure on engineers instead of looking at themselves and asking how they can improve processes.
I disagree - as someone who has started up small companies and worked in megacorps, including FAANG and major banks, it’s entirely possible to build that intoxicating environment anywhere. It’s more about having a dynamic leader who assembles teams into collections of individuals who know precisely why they are there - and are given the work they excel at and the work they don’t the manager ensures someone who does h…
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…
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. Writi…
Big +1 for #1. A brilliant IC that has an impressive contribution history tells only a small fraction of the story. Skeletons may lay behind that green square matrix!
Also big +1 for #4. It may slow growth for some start-ups, but I think it's always better in the long term if hiring is deep, versus shallow.
As for compensation, those certainly are controversial. I believe in honesty, but your extent of it is quite...towards one end of the spectrum? Certainly interesting.
The failure modes I've encountered: 1. Toxic team members who can't be fired. These people will reduce morale down to zero and force your best people to leave. In one case it was the CEOs long-time friend, and in the other case it was one of the technical founders. If you find yourself as an employee in a similar situation, then go ahead and pack things up because it will never get better. 2. Selling to Fortune 500s…
How do you bully people into joining a company?
Earlier quoted context omitted.
Importantly, this requires mature engineers and managers. Nothing worse (from personal experience) than working at a place that hires experienced engineering talent and then has a bunch of junior "leadership" telling them what to do. That's how you end up inundated with meetings and frameworks and blablabla. Obviously you need experienced developers to get stuff done without handholding, but you need managers that ca…
Absolutely. To start with, leaders must not be afraid of their teams making mistakes. Copying from another comment: "Netflix's culture demands very strong leadership and probably works only when the company is small enough. From CEO and down, leaders in every level need to know how to set context for their teams, give enough freedom to their teams, while making sure failures are manageable and success rate are maximi…
That does not sound like the right question. How about: have we vetted our dependencies' licenses?
I really like the approach of Netflix of 10 years ago when it was still small. They hired mature people so they could get rid of processes. Indeed, they actually tried to de-process everything. As a result, things just happened. Non-event was often mentioned and expected in Netflix at that time. Case in point, active-active regions just happened in a few months. A really easy to use deployment tool, Asgard, just happ…
Importantly, this requires mature engineers and managers. Nothing worse (from personal experience) than working at a place that hires experienced engineering talent and then has a bunch of junior "leadership" telling them what to do. That's how you end up inundated with meetings and frameworks and blablabla. Obviously you need experienced developers to get stuff done without handholding, but you need managers that ca…
Hiring extremely good engineers is hard, but hiring good managers is far harder. They also are much better at driving out the good talent tan a bad engineering hire is.
Earlier quoted context omitted.
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. Writi…
Hey Bryan! Liked what you have done. Big +1 for #1. A brilliant IC that has an impressive contribution history tells only a small fraction of the story. Skeletons may lay behind that green square matrix! Also big +1 for #4. It may slow growth for some start-ups, but I think it's always better in the long term if hiring is deep, versus shallow. As for compensation, those certainly are controversial. I believe in hones…
Earlier quoted context omitted.
> The arguments articulated are entirely false: ex. N^2 communications. This is reductionist and absurd I think you’re being unnecessarily harsh and reductionist of the article’s arguments. I’ve experienced exactly this failure mode in startups. The counter-example you described is an example of properly managing the N^2 complexity, not an example of it not existing.
But it doesn’t exist. For any task the number of contact points is almost always fairly small. Just because the possible N might be large most are occluded by lack of relevance to any specific task. I would note that the author categorically says it’s not possible for a startup like environment to exist in a large company. That’s what I disagree with.
