Live data from Hacker News

On Becoming a VP of Engineering pt. 2

honeycomb.io

31–40 of 67 posts

Re: On Becoming a VP of Engineering pt. 2

#31
post #15

> While engineering teams often thrive on routine and ritual (sprint planning, on-call rotations, recurring retros, etc.) My eyes rolled back so hard I'm not sure they'll ever face forward again. Lotta good stuff in this essay, but that one missed the mark a bit.

Yep. In my experience, the only people who like sprint planning and retros are the PMs.

If we have to have a manager, I like retros as they’re a way to give feedback to our manager on things we don’t like about our operational process.

Re: On Becoming a VP of Engineering pt. 2

#32
post #5

Lots of haters on the part1 segment of this article wondering "wtf does this VP even do?!" > I have friends who are line managers at larger companies who take home more than I do in my current role I wonder if this is the "liquid" portion of Emily's comp. If it's the "total" comp then that tells me a VP Eng at a Series D startup makes < $400k all in??

I was one if them. This post is what I was looking for in part 1.

Re: On Becoming a VP of Engineering pt. 2

#33
post #15

> While engineering teams often thrive on routine and ritual (sprint planning, on-call rotations, recurring retros, etc.) My eyes rolled back so hard I'm not sure they'll ever face forward again. Lotta good stuff in this essay, but that one missed the mark a bit.

I skimmed this article, and it is basically IMO garden variety IT management perspective that could be dropped into an org from the 70s/80s/90s/00s/etc, aside from the agile namedropping.

Which leads me to: great, you are a "VP of Engineering" but there is little to justify why I should believe you are an exemplar of that title/position. The LinkedIn isn't a fraud, but it isn't full of any formal management degrees, IT coursework, IT Management coursework. I don't see companies whose products are on the front lines of foundational technology, scale, or quality.

Frankly, the resume is full of 1 year hopscotches. That... doesn't really tell me they are battletested. I get IT is an industry with zero respect for the neckbeard, and yeah they went to Yale, so they are of a minimum floor of hard work and intellect.

There are people out there with 40 years of experience in IT, and probably 30 years of management, with stories of massive failures, grace under fire, and the usual stories Machiavellian fake smiles to navigate.

And plugging a "Organizational Health" book is hilarious when you are a startup. Yeah, there are lots of unhealthy startups, but the really hard organizational health problems are long standing companies with the "dead pool" effect that chased away the best people, long standing feuds/grudges, sociopathic/paranoid wars over diminishing resource pools and budgets, and deep problems with legacy systems that need to be updated.

A startup? That's peanuts in comparison.

Re: On Becoming a VP of Engineering pt. 2

#34

Say no to things, have meetings, play telephone between layers of management. Got it. I think I'll stick to being a lowly producer.

Yes that's a good chunk of the day to day. But there's also laying out strategic vision for where products and the company goes, what sorts of people get hired, doing the culture curation/setting. It's not for everyone that's for certain. I've met many many people that would struggle with this role (and vice versa).

Re: On Becoming a VP of Engineering pt. 2

#35
post #15

> While engineering teams often thrive on routine and ritual (sprint planning, on-call rotations, recurring retros, etc.) My eyes rolled back so hard I'm not sure they'll ever face forward again. Lotta good stuff in this essay, but that one missed the mark a bit.

Yep. In my experience, the only people who like sprint planning and retros are the PMs.

Seriously, the retro each week should be two questions:

1) Is this process working to the satisfaction of the team?

2) Anyone have anything else to discuss about it?

And it should be perfectly fine for it to be less than one minute most weeks.

Re: On Becoming a VP of Engineering pt. 2

#36

This reads like one big case study on why small teams outmaneuver companies that are big enough to have management hierarchies.

That's a good point.

It likely gets worse in larger companies in that misalignment between groups can be significant and very expensive given the sheer number of people involved.

Re: On Becoming a VP of Engineering pt. 2

#37

This section describes a tremendous amount of bureaucratic overhead for a company that appears to only have 200 employees. It feels like they have adopted processes that are really only needed for much larger orgs

In defense of the dudeperson, 7 years and 200 people is precisely when toe-dipping into a maturing/stratified/annoyingly process centric IT org probably should begin. It is really annoying to ICs, but the stuff exists for a reason, in every substantial company, for the last 50+ years.

If you're looking for a revolutionary approach, this article does not describe it. It is very very very unlikely any article titled "I am VP of XXX" will describe anything highly divergent from the general managerial consensus on how to run things.

A hierarchy and "salaried emmployees" (which a 7 year / 200 person company will now start to have because there is no tangible ownership % available) are going to involve the usual monetary-extraction / exploitation model of companies: employees take salary and some (actually:none) security and forgo any real economic incentive/reward if they deliver truly valuable/transformative work.

If an employee makes a company a billion dollars, he gets a plaque. If an executive does it, they demand stock options and other "rewards".

Thus, employees cease to care about the company. The next step is the creation of middle management, which ALSO have no aligned incentives except the more abstract "one day will be an exeuctive" but have no real production / creation to point to.

But, orgs and execs know that this hierarchy can be somewhat controlled with "bureaucracy and ceremony" and with sufficient scale, rent seeking, and regulatory capture, will produce an effective profit extraction system.

Re: On Becoming a VP of Engineering pt. 2

#38
post #15

> While engineering teams often thrive on routine and ritual (sprint planning, on-call rotations, recurring retros, etc.) My eyes rolled back so hard I'm not sure they'll ever face forward again. Lotta good stuff in this essay, but that one missed the mark a bit.

I've had the opposite experience.

Several dev teams I've been on want retrospectives to help review and make things better. But those places are where devs have a lot of autonomy and ability to change how things operate in the team.

I've seen and been on teams that align more with your reaction but those are at jobs where where the dev teams have very little say in how they do things. Well that or it's filled with a lot of cynical people that don't actually care about what they are doing and don't have much desire for things to improve (they actively fight to keep the status quo).

Re: On Becoming a VP of Engineering pt. 2

#39

This section describes a tremendous amount of bureaucratic overhead for a company that appears to only have 200 employees. It feels like they have adopted processes that are really only needed for much larger orgs

In defense of the dudeperson, 7 years and 200 people is precisely when toe-dipping into a maturing/stratified/annoyingly process centric IT org probably should begin. It is really annoying to ICs, but the stuff exists for a reason, in every substantial company, for the last 50+ years. If you're looking for a revolutionary approach, this article does not describe it. It is very very very unlikely any article titled "I…

Sure toe dipping. At 200 people you’ve hit a Dunbar number and you need some process.

Some kind of lightweight performance cycle for instance. If it takes more then a day offsite you are probably overkilling it

Similarity for quarterly planning. You better be doing it at 200 people but the people that need to be there for that will fit in a room and you should get it done in a day

This doesn’t sound like toe dipping it reads more like a full on swan dive. Like someone said “hey shit is getting crazy we need some processes” and just whole hog adopted “what google does” or some such. The processes that are evolved for a 20,000 person org are overkill for a 200 person one

Re: On Becoming a VP of Engineering pt. 2

#40

Earlier quoted context omitted.

You’d be surprised how many layers there can be even in a small org.

Oh I know it happens, but that doesn't make it good. The only way to get a lot of layers in a small org (200 people) is to have very low fan-out, which is inefficient. For simplicity, imagine a company with 4 C-level executives at the top. Each of them manages 4 reports, and each of their reports manages 4 people, and so on down the layers. In this simplified example you could have 340 people in a company and still o…

Generally in a healthy org it’s more like 8-10 direct reports per line manager.

At 200 people you should probably be still at around 3 levels deep. The VP Eng with 8 line managers could easily run a 70 person engineering team

Maybe throw in a single director to help share the load and for succession planning

But I agree likely what is happening is too many managers with smallish numbers of directs creating a lot of unnecessary layers and then all the extra management work that comes with that

Post reply on HN