I’m a Senior Principal Engineer at a large tech company. My work is to define the 1-3 year future for a $1B slice of the company’s revenue, that 1% of it’s employees work on.

There is nearly zero code in my daily work. The closest I get is being occasionally tagged into a pull request to resolve a dispute or clarify the long term vision, but even then that’s usually API contracts or data schemas that cross code bases-- and not actual code. I spend about 1/5th of my time with the engineers who actually do things and write code, but it’s to talk through math, CS fundamentals, algorithms, or system design on their current project – not code.

Day to day the bulk of my time is trying to convince non technical people, mostly in our Product organization, that we can actually make certain evolutions. Or to drop innovators dilemma type assumptions that add a year to our time to market. I get them to agree and then collaborate with them on large documents that define these futures. I vouch that we can do it, at what cost and on what timeline, and they vouch for how much it will make. We spend months writing documents like this and then pitch them up to the stratospheric leadership of our company to ask for 10-20% more resources to make 20-50% more money 2-3 years from now. I simultaneously do system design for these evolutions and sketch out the high level details of new components or what needs to change in existing components, to make the beginnings of a workable execution plan if we do get resources.

This is all fun and I’m grateful my career has kept changing and being different. Though I do miss the pure joy I find in coding all day, alone. But I am worried that the longer I stay this high level the more I will be full of shit, technically. I’m only effective at finding this intersection of customer desire and engineering reality if I know what is easy, or hard, to do. And I have a lot of examples of high level “technical” people at my company being full of it. It’s usually odd details, like they don’t know that certain problems were solved 10 or 20 years ago. So they twist designs and projects into knots to avoid or re-solve problems that the modern cloud or whatever language or library just has out of the box. Or they prevent profitable market opportunities because they think something is impossible, based on a gap in their knowledge of algorithms or newer tools or realities about how fast computers are these days.

I don’t want to be full of it. People like me eventually get fired if our Big Bets can’t actually be built, or enough people realize we are often wrong about details.

And I also worry that, as an IC, the longer I stay so non-technical the less likely I am to pass the technical portion of any interview. I also think it’s unlikely folks are directly hired into this kind of high level position, anyways, so I need to be able to slip back into a more technical role.

So how do I keep up? How can I be less full of it next year than I am now? I can leetcode, and I should, but that’s far removed from what I feel is the important part of my atrophying technical skills: the small details in tools that determine how large systems fit together and evolve.

  • samus7070
    link
    fedilink
    arrow-up
    2
    ·
    1 month ago

    Similar to the concept of asking why five times, there’s an idea that who you ask should also be six levels deep from the CEO. You’re not going to be able to know everything so cultivate contacts in low places. There are the people that are closest to the problem and have the best answers.

    From a more hands on side, perhaps you can convince your boss to let you embed in different teams for a sprint once per quarter.