Hacker News Reader

I'm in a PE role, and I have to tell myself every day not to go do the POC because that's not how I can maximize my impact. If someone else can do that work, I'm going to try and lean on them.

Strategy is hard. Much harder than I thought it would be. I am unable to make progress on strategy when I'm deep in tactical work.

I do jump in when needed, but every time I get my hands dirty I fall behind on strategy.

Your PE may indeed be useless, but it's also possible they are pretty good at their job. Good strategy is boring and seems obvious when presented because it creates clarity across a diverse company.

This is a fine line for me as a PE. It is good to help the team grow. However, I like to do the PoC sometimes so that I can keep my skills sharp and my opinions grounded in reality.

If I just sit in my ivory tower dishing out advice, the advice will eventually become useless.

+1. And if there are several ways to design or implement something, it is 1000x better to do the one proposed by the people who will do the work. They’ll understand it better, have more context, and be much more motivated.

Unfortunately this has the side effect of making the principal look like an overpaid rubber stamp and cheerleader to the best less-senior ICs who usually have their shit together. :)

I’ve been at this place before even if I don’t have the title formally.

What I have learned to do is to actually do my own flavour of the PoC concurrently with the team. That way I have more material to discuss and am able to give deeper insights like “have you considered X or what happens when Y?”.

It helps getting to know the problem better while letting the responsible get to own the product.

> I have to tell myself every day not to go do the POC

What is a "POC"?

Side Rant : It's really helpful if an acronym is at least expanded in the first use. I don't find the acronym in the article or the parent comment. I am not sure why and how this is a norm but it's frustrating as someone who wants to understand a conversation.

Proof of Concept

Piece of Crap?

Sorry about that. POC was introduced in the parent comment, but as you said without expansion.

If anyone has a hard time empathizing with unexplained acronyms, read a bit of https://www.reddit.com/r/churning/. I think the jargon is okay for the nature of that community (taking advantage of credit card sign up bonuses) but following discussion there can be really confusing until acclimated.

Example sentence: "CSR CL can be lowered. Need $5k CL to PC it to most cards, $10k to PC a(nother) card to CSR. Recon might only be able to drop it to $5k, you might have to SM to go lower than that."

at my work, I'm a principal and my boss is a partner. he spends a lot of his time doing organizational stuff and coming up with plans to solve problems, but he also still writes PoCs. he'll take the downtime he has between meetings, solve the really hard parts of the problem and hand it to the team for incubation. I do the same thing now - I pitched an idea which requires a fair bit of pure research, and I'm going to get a rough prototype going that vets the idea, then build out my team to make it better and turn it into a robust product.

the trick is to keep the PoCs lean enough that it's easy for your reports to flesh out and change the architecture as they need, but developed enough that it's working code, so people can run it and start working from a grounded product.

As someone adjacent to this role, a lot of the time this sort of "hands off" behavior is incentivized; the reason the principal is not jumping in and taking point on making the final decision and implementing is because that severely reduces the agency and ownership of the senior devs below them (and in many companies risk undercutting the latter's career progression, if it depends on them showing that independent ownership).

> There’s an outage on a Sunday morning. A huge Slack thread starts. Devops and devs on call manage to fix the issue. Principal engineer gets involved ACKing other’s people comments, adding thumbs up emojis, and at the end says “Big thank you to all the people involved” (plus a rocket emoji)

Just want to call out how accurate this is. The last place I worked was full of this kind of person (as managers, wecdid not have a principal title), and the description, right down to the emojis is bang on!

If I had such a principal on my team, I’d be happy about that. It means that they’ve contributed to an overall team dynamic where the team does not depend on them personally to perform under pressure.

Far worse is a team of on-call juniors who stand around jabbering cluelessly until someone decides to call in Principal Pat who fixes it in 15 minutes during the 7th hour of outage.

If the team is on the right track, providing non-technical support and encouragement is exactly what a principal/director should be doing, to reinforce that the team is performing and earns the credit.

The principal “owns” the annual downtime and problem-loss figures. The team gets credit for this weekend’s fix.

In other words: “A leader is best when people barely know he exists, when his work is done, his aim fulfilled, they will say: we did it ourselves.” —-Lao Tzu

Not a "Principal", but you guys would rather be followed up by a business person who would come up with their revised requirements and timelines, each day or the other? Or obey the commands of the technological genius that somehow always have the answer to every question, for others to implement exactly as told?

Leading by using technological experience and refraining from prescribing "the meds" all the time, is lighter work, so one can stretch over much more than otherwise. But nobody becomes master of everything, and those places that have those, truly suck without knowing it. Having to go into all the depths, someone else'll need to take point..

Interesting; at the places I've worked, "architects" are more senior and highly paid than "principal engineers". This description is totally unfamiliar to me.

The PE should also be doing a lot of behind the scenes (from senior dev pov) strategy work with leadership team w.r.t identifying long term technical risks and ensuring right investments happen, grooming tech talent bench through perf/promo processes, seeding/sponsoring new tech initiatives etc.

All this is informed by the observations and insights that come from the "support" work they do in those outage huddles or design discussion meetings.

The technical thought leadership work they do with the business/product leadership team is where they really earn their paycheck.

Ok, but are you implying there is no value in that? Wouldn't you need such a person, and wouldn't you need that person to not be clueless and know their stuff to be able to do a good job at it?

You're right about how the role ends up being implemented, but it shouldn't be this way.