How I find problems to solve as a staff engineer

However I still see a lot of "work theater" where directors couldn't care at all about changing the bottom line but just care that work that sounds plausible enough is executed in a predictable way that makes them look good (in fact they get pretty disappointed if something happens TOO fast [like half the estimate] as it illustrates they are out of touch the work they are claiming to represent). What I'm saying is that "do more top-down-product" in theory makes sense as a direction, but in practice I usually see it as wasted energy.

In most of my career, especially when in a Staff role, it has been up to me to propose the direction and priority of work within my scope. Usually, this is based on my estimation of the impact to the business (possible new features, security) or operations (devx, efficiency $$$). Obviously I still have to work with product to get things scheduled as they have needs that must be met, but it was as an equal partner. As a very creative person thats usually the space I enjoy the most.

tldr; this advice is probably impractical for a bigger chunk of industry.

Even outside projects and general work condition it is worse. 10 years back I could just decide when to work from home, or do a few interesting projects show to managers get approval afterwards. Today I have to explain myself to managers and get proper approvals for same thing. And I have been in same place for quite some time so it is not even the case that I have to prove to my new employers first.

Being not much ambitious I use to think after these many years and multiple successful project my win is to be a kind of made guy in that same mid-level position. Supporting , fixing project which I delivered over years and just take it easy, start day late, leave early until retirement.

Turns out things I assumed, don't exist. And even if they do they are above my level. Not worked in big tech, no massive RSU based compensation and with AI flattening difference (in employer's view ) between 2 vs 20 years of experience, story is not going to end great for people like me.

A bit over a year ago, I joined that same company again, as lead of what's technically the same team, this time as an employee, but everything had changed. It was very hierarchical, very top-down, very little freedom, lots of red tape and office politics, and a tedious, slow pace.

There are lots of different routes via staff and above level engineer. However, what they do have in common is working on really hard problems that take a lot of other people to work with. You will typically find your staff and higher level engineers rarely are actually writing code themselves. They are all management, but it's a technical management part.

The thing is, it's really hard to be there because management will constantly assign you various product-focused things and you end up being a widget. And so you have to figure out how to break out of that to say, no, this is the wrong widget and you have to show them that, look, I delivered this widget and when they see it, they should realize, wait, this guy was right. I assigned the wrong widget and he did it and so I need to trust this guy and give him more time to do things that give us the right widget.

Remember, the real goal is to make money for the company. As an engineer, you might say your salary is, say, $200,000 a year. But that is only a small part of it. For every dollar they spend on you, they need to spend $10 on other things to make it work. To pay your salary, you need to make not just enough product to bring enough to pay for your salary. You also have to pay for marketing, sales, product support, other managers, HR, and a bunch of other things I can't even think of off the top of my head. So the real question you should be asking is how do I earn, by actions I do, more than $2 million a year for my company. If you're earning your company $2 million a year as an engineer, they're breaking even on you at best, you should do widgets they trust will work. If they are earning $10 million, that's something that you should be putting on your resume and saying, look, this is why you need to give me a promotion. I am earning this $10 million every year. If you want to do even better than that, make it not $10 million that you're personally doing, but things that, because you're assigning other people to do them, are earning hundreds of millions. If you can earn the company hundreds of millions of dollars a year, you can justify a large salary for yourself, and you keep dozens of other engineers busy doing things.

Or you can take the lazy way out and just be a widget producing what they need you to do. That's good enough.

Like a woodworker building his own jigs, I always build my own tools whether the company wants them built or not. When I'm in a supportive environment, I work on and share those tools loudly. When I'm not, it's over lunches, behind closed doors, pulled out during emergencies, or just snuck into the CI pipeline without comment.

Frankly, the fact that not everyone does this has always been a cultural disconnect for me. The whole point of our field is to take repeatable tasks and write code to replace them. The fact that only about one in six of us does this for the tedious or error-prone parts of our own work is just maddeningly bizarre to me.

Nevermind the overly large fraction of people who have to be dragged kicking and screaming into using tools written by others. That number has gotten smaller over the last couple of decades but it started too high and the slope of that line says something awful about the industry. I don't know what, but it's something I'm sure nobody wants to hear, so I haven't poked at that bear too much (I have plenty of other bears to poke.)

I asked my manager if I should be creating tickets for the work I'm coming up with, and he answered a question I didn't ask, saying he doesn't count sprint points. So I clarified, shouldn't I at least be creating tickets so that we're accounting for it in our sprint planning? And he didn't seem to care.

IMO, it's a 180 degree shift to go from trying to accomplish assigned work to creating new work and accomplishing (or delegating) it / adding it to roadmaps / etc. To me, it wasn't at all obvious that this was what I should be doing, so it was strange to sort of stumble upon it when asking an adjacent question.

It would have been very useful to get an explicit instruction such as "hey, only spend 1/4 of your time on planned work" or similar.

I'm sure there are plenty of people out there who spent their entire career trying to avoid doing assigned work so it's an easier transition, but for rule followers it's a weird change.

  Struck me that the staff engineer 'finding problems to solve' might be (whether for better or worse) manifesting that same tendency.

If a company is bootstrapped by a few engineers, where would the business acumen come from exactly?

I've been part of tiny startups, medium size, and large ones. I've been at state agencies and ancient private organizations.

The more people, the more corporate the culture. The more cooperate, the more the business needs & wants drive choices.

In BigCo. finding problem and the technical solution dwarfs in comparison to the effort and skill required to find the people who you're going to offend with your brilliance, the beneficiaries of said problems and who their reporting chain is and their incentive structures and the art of framing solutions using terms that they and their bosses understand in entirety.

Companies are no different. During company growth, it's all about hiring, and giving tasks and some responsibilities to subordinates, setting up the right channels for communication etc. But at what point do company leadership actually say "You know what,that department would work better without direct instructions from us. Let's facilitate communication, act as conflict adjudicators and make company-wide 'North Star' decisions"

I think that's what OKRs are supposed to do, but I've never seen that work well (for very long anyway). It always gets up-ended somehow. Start of quarter optimism, over-promising, not spotting that someone else's stretch goal is actually your blocker. Then mid-quarter you're dealing with production emergencies, database code red and running out of time. At the end of the quarter, two of your team go off on PTO while you desperately try not to "fail your quarter", working late, and delivering shoddy work.

Does true bottom up exist at large companies? Hmmm. Some. We've all heard the legends of IBM's "build the first PC!" skunkworks. And we know about research-only departments at Xerox that led to so many modern computing inventions. But these were brief projects.

I find these days that people have the desire to get out of the way and let us work, but the tiling is in the way. I waste so much fixing time in Jira, slack, doing performance reviews, interviewing...

Even in a big corp there are always problems to solve. The point is to find problems that both:

1) are hard enough that someone junior won't be able to solve them alone, and

2) actually provide value to the company / users

Sometimes coworkers does not like that because they don't see me working on the problem, but on a tool which will resolve the problem and similar problems from our backlog.

So many places only fix a problem after they've already reaped the majority of the pain of having the problem. Like they want to experience hitting every step on the way down.

Some places, do not care terribly, about what you _could_ achieve, or they have garbage internal practices which prevent you from doing this work effectively no matter how much you _care_, or maybe they’re just a garbage workplace but you need the job. In these cases, you may as well ruthlessly go-for-the-title, because they’re not going to change, so you may as well get something beneficial while you’re stuck somewhere shitty.

Now, if it’s a decent org, which looks after its people, produces a product it cares about, has actual career progression, sure, you can afford to do the work first and earn it properly, but let’s not pretend that’s amazingly common, and attempting to do this, in some places will just get you exploited and burnt out, with no pay or title bump to show for it.

Even in projects that could objectively be owned by 1-2 people but are allocated to a 5-10 person team instead, I've encountered cases where velocity gets absolutely obliterated by a sub-domain "owner" dev being on vacation. Now imagine this is not a fairly small sub-domain but half the project, and instead of a vacation your one-of-two dev gets hit by a bus.

I wish people would create more and better docs. Pour as much time into a meticulously written doc details as they discuss indentation and variable naming style.

But instead, just like with your attitude, it's considered second grade or even useless work, and as a result docs always suck if they even exist. They don't get that code is made for people to consume just as much as for the machine, and docs are just an extension of that. That's one reason LLMs are so popular, they actually tell you what you'd have found in the doc, had it existed. But LLMs are restricted to the what and don't cover the why. I some places that makes good docs even rarer. In others it makes them easier since the machine generates the "fluff" and the human just fills in the rationale.

Sure, I can do them faster than others and pretty well. But if they’re truly things I can knock out in a day or two, they’re things that other staff can knock out in a week or two, and learn from the experience, and at that size they likely don’t require the standard of quality that I delude myself that I hold myself to.

At the lead/staff level, it’s far better to look for the kind of problems described in TFA: problems that are complex to identify, and for which the appropriate solutions aren’t always the obvious ones. My time is spent much better looking for those than being a 10x-speed senior engineer or whatever. There are actual senior engineers for that; I’m paid for the kind of work that they don’t or can’t do (yet, and to help model and mentor and train them to be able to do it), not to do the kind of work they already can do—whether I would do it faster/better doesn’t matter.

It’s case-by-case of course; sometimes a simple issue is critical or obscure enough (or tempting enough to override my iffy-at-best self-discipline) that I’ll jump on it. But I generally try to remember that a lot of the stuff I could look heroic for fixing in a jiffy is probably both not worth my salary allocation in the eyes of my grandboss, not critical time-wise, and a potential learning/accomplishment opportunity for others.

> I don’t like being the person who talks and talks but doesn’t push code and ship features

It was fun while it lasted, wasn’t it?

The flip side is people who get and stay too far into the weeds. Solving little problems here and there is a great way to keep your finger on the pulse of what's actually going on.

But if you get totally bogged down in details, you are probably avoiding your leadership responsibilities. You should be observing the structural or strategic opportunities, and then dragging the org(s) in that direction.

Sometimes you do that by writing some code to prove a point, other times you do it by getting the nearest VP to take something on as a commitment. For me, personally, I find that the style of work waxes and wanes. Sometimes I get almost no code committed in a month :(. Other times, I get to go off and do some work that nobody else would have done.

I prefer the latter, but I respect that my job requires the former. Many of the people who you see spending all their time talking believe that's the most responsible use of their time. They might not personally prefer it!

1. Get in all their support or public slack channels, watch for acute moments of freak out or consistent schlep blindness. 2. Meet with the head of the team once a month for 45 mins and get them to list out what just sucks.

You can limit chit chat very well this way.

You’re only going to be able to do so much so broadly picking the problem that is closest to the business’s immediate pains can be a win. Or maybe that’s already being swarmed on so you knock out a bunch of random stuff and get broad recognition.

For technical teams, almost every single thing I ship:

1. cements a new pattern or contributes to a new one that my team can use 2. improves cicd speed or checks

You can usually knock out the non technical team work and pick off 1 from technical team work along the way

Everything I do (except specific bug fixes) force multiplies, otherwise I’m wasting my effort.

I don’t feel like I need to talk too much to my teammates about their engineering problems. I’m doing the same work ultimately, so I have a solid understanding of what moves the needle

Edit: convincing the organization that your work is important gets much much easier when you have metrics and charts that make the case for time well spent. It could be a buggy ass feature, or a meaty pipeline the business relies on. Prove that it’s hurting the customers and ultimately the bottom line. Battling over and convincing of scope becomes less important when you’re talking in the same language as non technicals