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

111–120 of 148 posts

Re: Guide to scaling engineering organizations

#111

Post by patio11 »

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.

Stripe's usage of "lurking" is a bit idiosyncratic. (There are a couple of other words like this, distributed in a glossary, the majority of which is less idiosyncratic word usage and more industry- or company-specific jargon.)

In the sense used here, "Lurking into someone's thread" means sending an unsolicited comment to a thread you were not an expected participant on.

This is something we're broadly supportive of but which, if done poorly, can be socially contentious. You could imagine pathologically bad examples like "Hey thanks for working on this project for the last 8 months, but before you ship it, just wondered if we had considered adding a teal bikeshed? Taking the liberty of CCing seven people for their thoughts on the bikeshed you'll be building."

Re: Guide to scaling engineering organizations

#112

Post by mratzloff »

grandtour001 wrote: post #79

Please no recruiter phone screens. It's just a choreographed dance where everybody knows what's goin to happen. The recruiter sells you the company about x, y, z values that nobody cares about. The candidate says something about looking for bigger opportunities and challenges.

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

Re: Guide to scaling engineering organizations

#113

Post by ebiester »

ChrisCinelli wrote: post #110
physcab wrote: post #92

Earlier quoted context omitted.

This is honestly the best barometer of employee happiness. Managers who want to build political empires, don’t have their employees best interests at heart, who communicate poorly, who make questionable moral judgements, or push work down the pipe for the sake of doing work is what makes employees miserable. Companies who empower these types of managers are terrible to work for.

I also found out that there are a few bad "managers" that end up raising because they are popular with people and their bosses. They usually have a very high EQ. You can see a few people with little technical acumen, shallow knowledge of the latest trends, very bad on processes and no work ethic that still rise in some organizations. These people spend a lot of time "managing up" on a side and on the other side they…

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 from other managers who have their own pain points and are trying to work through issues like whose team has to deal with this ill-defined goal that doesn't really belong in any of the teams but is important. (Or saying that it isn't important after delving into the issue!) Or it's identifying a department-wide problem and working with a small group to have a proposal to solve it.

That leaves 1/3rd of the work on actually "managing down." That is mentoring, performance evaluation, conflict management, 1:1s.

And if your team is hiring, you spend another block on that. Most of us can't work 60 hour weeks consistently.

Are there bad managers? Sure! But some of what makes a good/bad manager is completely hidden. (I'd argue that it's a flaw in our organizational system in general - I'm starting to think we need more people whose job it is to organize the department as a system, and then have the engineering manager as a tech lead++.)

Re: Guide to scaling engineering organizations

#114

Post by kylemh »

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…

The difference between the few companies I've been at has been made to seem like a laying down in a valley versus standing atop a mountain now that I have a good manager.

Re: Guide to scaling engineering organizations

#115

Post by arvinsim »

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…

I agree with this. I have already worked as an individual contributor for 10 years.

I have improved a lot technically because there are a lot of programs that allowed me to learn.

But not once have I been taught to manage people.

After realizing that I am getting nowhere career wise as an individual contributor, I am currently seeking out opportunities to learn management.

Re: Guide to scaling engineering organizations

#116

Post by julianozen »

digaozao wrote: post #109
julianozen wrote: post #34

Earlier quoted context omitted.

I actually recently interviewed at Stripe (did not receive an offer) and though the day was long, Stripe question’s were very fair and relevant to the job. This was true from my first phone call to all my onsite questions. I was very impressed by the preparation they had put into their interview questions. So if you work at Stripe and are reading this, good work improving interviewing process

Can you give examples of the questions?

Sorry! Unfortunately I don’t think that’s be fair to them or other candidates.

To be honest, I’m not even sure how they’d interview me again. It seems like it’d be a lot of work to have multiple versions of their interviews and at this point I know the answers to everything they showed me

Re: Guide to scaling engineering organizations

#117

Post by syntaxing »

o_____________o wrote: post #58
syntaxing wrote: post #29

I really enjoy reading Stripe's posts. I remember they posted one about APIs and it was super fun to read [1]. Though to be honest, I think a title of "Guide to scaling software engineering organizations" seems more appropriate. I dread of a day where it's the norm for foundational engineers to have a similar interview structure as software engineers now. [1] https://stripe.com/blog/api-versioning

What is a "foundational engineer"?

The old four main branches of engineering (mechanical, electric, chemical, and civil)

Re: Guide to scaling engineering organizations

#118

Post by wbc »

mratzloff wrote: post #112
grandtour001 wrote: post #79

Please no recruiter phone screens. It's just a choreographed dance where everybody knows what's goin to happen. The recruiter sells you the company about x, y, z values that nobody cares about. The candidate says something about looking for bigger opportunities and challenges.

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?

Re: Guide to scaling engineering organizations

#119

Post by PopeDotNinja »

deathanatos wrote: post #91
PopeDotNinja wrote: post #31

Earlier quoted context omitted.

> I've only worked with a handful of recruiters that were actually worth anything I learned how to hire & train recruiters to work for me pretty effectively for certain pieces of recruiting. To you, what makes a recruiter good and/or not good? Maybe I can share some thoughts on how to improve the not good parts!

A technical résumé, to a non-technical recruiter, is just technobabble; they have no way of knowing whether the information contained in the résumé is generally good, or just someone BS'ing, or someone who doesn't know what they're talking about. Discerning whether a writer actually understands what they're talking about (particularly in the terse format of a résumé) generally requires a deeper understanding of the l…

Ah, I can see what you mean. I had good luck with making actually resume screening part if inter process for hiring recruiters.

Here's basically how I did it:

- pick one job to focus on, where it's near impossible for a non-technical person to tell if someone is likely to be a fit, such as a full stack web developer with experience in a JavaScript and a backend language

- get 5 resumes, 1 obvious fit, 3 maybes, and 1 obvious no, all of which look great based on keyword soup, so an automated QA person and webmaster might look like a full stack developer, and the waiter who took a programming course 10 years ago has no shot

- provide any additional filtering criteria

- in a verbal conversation, ask the recruiters to rate, and explain, each rating

Try that. It's not perfect, and it's better for positions you can describe discrete hiring criteria. The bar for the recruiter is not filtering out the no and maybes, it's screening in the maybes and yesses into a guesstimate sorted list. You can focus in 3 & 4 list. Then you can start with obvious matches, keep going until the list starts feeling pretty thin, and draw a line based on your judgement call & supply of applicants.

Re: Guide to scaling engineering organizations

#120

Post by mildweed »

fbr wrote: post #42

Some additional great resources related to hiring: How to hire your first engineer - https://blog.ycombinator.com/how-to-hire-your-first-engineer... Convincing Engineer to join your team and a basic structure for the process - https://blog.ycombinator.com/convincing-engineers-to-join-yo... General thoughts about hiring - http://blog.samaltman.com/how-to-hire The book "Who" gives a good idea about a good process. Hard…

How to run a solid, basic technical interview: https://slides.com/scottconnerly/2questioncodequiz
Post reply on HN