Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Guide to scaling engineering organizations

stripe.com

Post reply on HN
Print view View original

141–148 of 148 posts

Re: Guide to scaling engineering organizations

#141

Post by vonmoltke »

Shaanie wrote: post #77
jhpriestley wrote: post #68

Earlier quoted context omitted.

Why are bad hires so damaging? I've encountered very unskilled coworkers, they didn't do any serious damage, just wasted some people's time and money. I'd actually say the opposite: standout engineers can be very valuable, I'd rather work on a team with a couple lemons and one really good engineer than 3 middle of the road engineers. So I think that false negatives can be damaging, especially because it's probably th…

Lemons can significantly impede a team's velocity and, more importantly, the team's overall happiness. It's difficult to enjoy and take pride in your work when the code base either looks like shit or require that you spend most of your time reviewing/cleaning up the mess the lemons create. Will your standout engineers enjoy working with the lemons?

I could substitute "the business" for "lemons" above and describe many (most?) companies. In that case, what effect are these lemons really having?

Re: Guide to scaling engineering organizations

#142

Post by allenu »

ChrisCinelli wrote: post #138
ebiester wrote: post #113

Earlier quoted context omitted.

Here's the part of management that is hard to understand as an IC: 1/3rd of my job is "managing up," that is, getting my boss what they need to get their job done. This can be defining a hiring process, or writing part of a powerpoint deck or getting them the information they need to write it up for their presentation. 1/3rd of my job is "managing across," or working with other managers - the "shit shield" is often f…

I do not call defining a hiring process managing up. Hiring is part of creating a great team and in my own experience can take more than 1/2 of the manager time especially when you are "building a team from scratch" and you cannot delegate things like screening interviews to other people. Back to the "managing up" I was talking about in my previous comment. I have seen some people spending more than 1/2 of their time…

These are very astute observations and ones that I've seen as well after many years of work in tech. In a sense it's a case of "you get what you measure" where what we're trying to measure is how effective a manager is at deriving and delivering value from a team. However, a lot have found a way to "hack" how this value is communicated to their superiors.

A lot of poor managers I've worked with have a knack for taking work that is actually quite easy and communicating it as very challenging such that they (or their team) receive a lot of credit for it. As you stated in the other post, they may also be good at making their employees feel that there is great value in work that is also fairly trivial or non important. In a micro scale, this looks like a good thing (people are happy), but in a macro scale, it may not actually move the business forward very much.

At the end of the day, it often sadly boils down to "it's not what you did but what people think you did" that matters.

Re: Guide to scaling engineering organizations

#143

Post by vikiomega9 »

sytelus wrote: post #134
munchbunny wrote: post #90

I think this post missed one extremely important point. I almost never see it in blog posts, and yet the successful heads of 100+ engineer organizations all know this. Find good managers! Or groom them. Whichever. Just make sure you have good managers. I see endless posts about recruiting, and I see tons of posts about engineering culture, but I almost never see posts from these same sources about the nitty gritty of…

Thing is that you are never going to be able to hire good managers 100% of the times if you are scaling. So entire focus of scalable process should be on how to minimize, defend against and eliminate bad apples as fast as possible. The primary mistake that many companies make is to have manager implicitly trusted without validations and give them almost dictatorial powers. The good process would add checks and balanc…

And then you've forgotten about the product and will end up with a culture like Google that focuses on technical complexity as opposed to adding value towards the business and focusing on building products.

Re: Guide to scaling engineering organizations

#144

Post by inimino »

jhpriestley wrote: post #68
avip wrote: post #8

Earlier quoted context omitted.

That's the logical tradeoff for any company. Bad hires create an incredible amount of damage that can sink a whole team. It is x10 better to have no hire than a bad one.

Why are bad hires so damaging? I've encountered very unskilled coworkers, they didn't do any serious damage, just wasted some people's time and money. I'd actually say the opposite: standout engineers can be very valuable, I'd rather work on a team with a couple lemons and one really good engineer than 3 middle of the road engineers. So I think that false negatives can be damaging, especially because it's probably th…

Mostly because of bad management and an inability to fire people even when it is clear that they should.

Generally a hiring process is a good hint to the dysfunctions of a team before you join. Panic about bad hires and a quintuple-filtered pipeline is a good sign of weak management and a structural inability to fire.

Re: Guide to scaling engineering organizations

#145

Post by inimino »

rizzom5000 wrote: post #36
ppeetteerr wrote: post #16

Earlier quoted context omitted.

I've worked in companies that struggle to hire any candidate, let alone top candidates. Stripe is amongst the top employers. The vast majority of smaller shops (banks, b2b software companies, agencies) just need to staff up and would rather hire and fire than miss out on a good candidate.

Maybe, but hire and fire is also a great way to show the team that you don't know what you're doing as a hiring manager; not to mention how firing a team member, who may be incompetent but still well-liked, affects morale. Then, there is the problem where you fail to fire when you should. To me, this is just not a good way to build an effective team.

> hire and fire is also a great way to show the team that you don't know what you're doing

It's an expensive (painful) signal that you actually do know what you need to do and are capable of it.

Re: Guide to scaling engineering organizations

#146

Post by darkarmani »

scarejunba wrote: post #43

Nice post, guys. Would you mind saying what you mean by 'lurking'? In all my life on the Internet, it's a positive thing when joining a community. You're invisible to everyone and just read. Why should people not do this? It seems harmless to be in read-only mode.

I think they made up/redefined that term. The rest of the world calls lurking someone that mostly reads a forum/thread but doesn't say anything.

I've seen the opposite by senior management called the "swoop and poop". They haven't followed the thread at all, but they will swoop into a meeting without any context and poop all over the ideas because they are missing the context around the complexity of the problems.

I'd sooner have a lurker that read all of the conversation speak up than the opposite.

Re: Guide to scaling engineering organizations

#147

Post by ChrisCinelli »

allenu wrote: post #142
ChrisCinelli wrote: post #138

Earlier quoted context omitted.

I do not call defining a hiring process managing up. Hiring is part of creating a great team and in my own experience can take more than 1/2 of the manager time especially when you are "building a team from scratch" and you cannot delegate things like screening interviews to other people. Back to the "managing up" I was talking about in my previous comment. I have seen some people spending more than 1/2 of their time…

These are very astute observations and ones that I've seen as well after many years of work in tech. In a sense it's a case of "you get what you measure" where what we're trying to measure is how effective a manager is at deriving and delivering value from a team. However, a lot have found a way to "hack" how this value is communicated to their superiors. A lot of poor managers I've worked with have a knack for takin…

That is definitely one of the things I observed some manager doing. Slightly related situation is when an engineer does that and can do it because the manager does not understand at all how the system that is under his responsibility work.

Re: Guide to scaling engineering organizations

#148

Post by mratzloff »

wbc wrote: post #118
mratzloff wrote: post #112

Earlier quoted context omitted.

If it's rote for you, you probably aren't using those calls effectively to filter based on your dealbreakers.

mind sharing how you use these calls to filter companies?

Company size, team size, role functions, salary range, culture...
Post reply on HN