Realizing I’m better at connecting dots than finding problems - where does this fit in engineering?

Posted by that-pipe-dream@reddit | ExperiencedDevs | View on Reddit | 26 comments

I have \~12 YOE and have operated as a Staff Engineer at a mid-size org, and more recently at a startup (which didn’t work out). The expectations there felt borderline 'superhuman' for a senior IC which has been mentally taxing and exhausting, which pushed me to reflect more deeply on my strengths and gaps.

One pattern I’ve noticed:

I’m not very strong at independently finding problems through deep, hands-on exploration (digging into code, logs, systems, running spikes, etc.).

Instead, I tend to:

- pick up signals from different sources (engineers, product, incidents, data)

- connect those into a bigger picture

- identify more fundamental problems or cleaner system/product directions that weren’t explicitly called out

I used to think of this as 'long-term vision' or 'North Star thinking'. But when I introspect, most of those ideas come from picking cues/signals from what people around me are reporting, not discovering problems in isolation.

At the same time, I’ve observed a clear gap:

- I don’t have a strong hands-on depth presence as an IC.
- People see me as 'technical' because I can hold conversations and reason about systems, but I’m often not the person going deep first when something breaks or anchoring the hardest parts of execution. This is also an area of lack of confidence for me (maybe fixable).

This feels like a real risk if I continue on the IC track, where depth and/or execution ownership are table stakes.

So I feel like I’m in an in-between spot:

- Not a strong bottom-up problem miner

- Not consistently a strong hands-on execution driver

- But strong at synthesis, abstraction, and cross-team/system thinking

I don’t want to move away from technical work. I enjoy systems thinking, can engage deeply in design discussions, and (from feedback) am easy to collaborate with.

My questions:

For someone with this profile, what’s the more stable path?

- Double down on the IC track (Staff > Principal > Distinguished) and deliberately build depth/execution credibility?

- Move toward the management track (EM > Director > VP) with a strong technical bias?

Where does this skillset fit best, especially in the current AI-driven environment?

Would appreciate perspectives from people who’ve:

- seen engineers like this succeed or struggle, or

- been in a similar position themselves

[-]

kuntakinteke@reddit

Isn't what you described the exact expectations of a staff engineer, is this a troll post?

[-]

demchaav@reddit

I think it depends on what you're snapshotting. HTML/JS snapshots — yeah, mostly noise. But for API contract testing (snapshotting JSON responses), I've actually found them useful as a quick regression signal during refactorings. They're not a replacement for proper integration tests, but as a guardrail they can catch accidental breaking changes before anything hits staging.

[-]

SlechtValk2@reddit

Sounds like an Architecture role would fit you.

In our organisation we have Solution Architects that design changes to the applications of a single team. Or "Principal Engineers" (which I find a confusing term) that help the SAs of a group of teams with designing larger changes. The SAs still code at least 50% of their time. The PEs code very little, but are still expected to have deep system and code knowledge.

[-]

rwilcox@reddit

Same here too. Step one may be find a company where Architect roles are still valued…

[-]

Sufficient_Dig207@reddit

Have you tried to use coding agent to help? I am not train as a software engineer but ended up in a software engineer role. Can only work with Python to debug existing system, but now I can work on any software task, front end, backend, cloud, in any language.

[-]

jayvasantjv@reddit

i would strongly reckon to put 6 months, focus on becoming really good in any sort of IC role.

Then you'll be in a state to take the right call, be it a managerial role. If you ignore this and move away, it'll keep haunting you, and you'll be forever be indebted.

This will also help you to have confidence in switching roles back and forth.

Also, as a side q, can you tell which kind of companies have you worked for... would help in framing the context of kinds of skills required if you wanna go via IC route.

[-]

Longjumping_Feed3270@reddit

I'll jump right to your second question because as I've been reading this, I kept thinking this seems to be a very good fit for the new world of AI.

AI is very good at the digging down, getting its hands dirty, sifting through logs. If you can provide the bigger picture, you + AI are a very strong team.

If you want to continue on the technical track or move on to management is still up to you, I guess.

[-]

that-pipe-dream@reddit (OP)

Appreciate your take on how AI is going to change the work stream here. Personally I tend to take time with my tasks because I like to weigh options and do a clean job. While this might sound obvious, pace has been a challenge for me for the longest time, and I'll admit AI has broken down some of these barriers I perceived previously. However IMO debugging, getting into the weeds of things - are a perishable skill and need constant honing. So I am a bit careful about associating this improved productivity due to AI as readiness for IC track. Doesn't feel like something that can be offloaded to AI if I want to excel at being IC?

[-]

Longjumping_Feed3270@reddit

Debugging is like 100x faster with AI once it has the right context and access to all the tools.

It's not even close.

[-]

CodelinesNL@reddit

There is nothing more dangerous than "big picture people" writing production code with AI that they can't maintain without AI.

[-]

CodelinesNL@reddit

I'm going to be a bit harsher than others here. Because I think you need to hear it, and also because I have experience with software engineers that had the same gap.

But when I introspect, most of those/my best ideas/projects come from picking cues/signals from what people around me are reporting, not discovering problems in isolation.

To me this sounds like a red flag. Being a "big picture" person is one thing, but this sounds like using information from other engineers to improve your own visibility.

I know a few developers who have a strong focus on "big picture" stuff, but it's mostly a lot of shallow stuff you see at conferences. They get hired to build things, and then somehow try to focus on "improving CI/CD".

But strong at synthesis, abstraction, and cross-team/system thinking

Are you though? Because drawing boxes in powerpoint is easy. Getting those boxes running in production is the hard part. Given enough time, would you be able to create these systems completely by yourself?

Because that is the different between a very senior software engineer, and an ivory tower "enterprise architect": being able to actually carry the responsibility of getting things into production.

If the answer is "no"; you should consider a move towards people management. As long as you are able to let senior engineers do the "system thinking".

[-]

_sw00@reddit

I'm willing to give OP the benefit of a doubt - doesn't sound like they want to be an "ivory tower" architect or a machiavellian manager.

let senior engineers do the "system thinking".

The problem with this perspective is that in most orgs senior engineers/ICs are usually never the ones empowered to actually solve systemic issues: ICs are mostly judged by their productivity - how quickly they can close tickets.

OP as a manager would be able to advocate for them, being sufficiently technical. Most of the time this looks like "drawing boxes in powerpoint", unfortunately...but it needn't always be the case. It's really possible (often necessary) to be a hands-on implementer if you're in technical leadership.

They get hired to build things, and then somehow try to focus on "improving CI/CD"

This is the right problem to solve a lot of the time, in my experience.

[-]

that-pipe-dream@reddit (OP)

Thanks for your perspective - 'ivory tower architect' is the exact stereotype that I'm trying to avoid, to that end evaluating my performance thus far. You have solid points here.

> To me this sounds like a red flag. Being a "big picture" person is one thing, but this sounds like using information from other engineers to improve your own visibility.

I Wouldn't certainly phrase it as my strength in this post if I had ulterior motives :) But to answer your point, often times I have had people solving the effect and not the cause. I've had a good track record at connecting these dots and identifying the right approach at systemic level/involving cross teams, and be able to build concensus/buy-in for such projects.

> As long as you are able to let senior engineers do the "system thinking"
If I were to transition to an EM role I believe this is something I'd have to consciously put an effort - I'm trying to also understand how much can an EM weigh in/influence the architecture. A pure people management role is not the most exciting opportunity and I plan to apply to opportunities where it's useful to have technically inclined engineering manager.

[-]

Huge-Leek844@reddit

Why do I feel a bit of arrogance in your post?

It sounds like you’ve rebranded "losing touch with the trenches" as "North Star thinking." There is a fine line between being a strategic synthesizer and being an architect who only draws boxes on PowerPoint because they can no longer navigate the codebase or the logs.

In a Staff+ role, being able to "connect signals" is valuable, but if those signals aren't backed by your own ability to occasionally dive deep and validate them, you’re not a technical leader, you’re a proxy. The reason you felt the startup expectations were "superhuman" might be because, in that environment, synthesis without execution is seen as overhead.

If you can’t anchor the hardest parts of execution or run a spike to prove your "big picture" direction, you risk becoming the person who identifies "fundamental problems" that are actually technically unfeasible or divorced from reality.

My advice: Don't move to management just to hide from the technical depth you’ve lost. If you want to stay on the IC track, you need to rebuild your "execution credibility." You don't have to be the fastest coder, but you must be the one who understands the system’s constraints better than anyone else.

True "North Star" thinking isn't just about picking up cues from what others report; it’s about seeing the signals in the data and the code that everyone else missed because they were too busy "mining." If you're only synthesizing what people tell you, you're just a glorified router. Get back into the "how" so your "why" actually carries weight.

[-]

BoBoBearDev@reddit

I am curious. Why does the post felt like a lot of random jargon thrown together? Like, signal, running spikes, synthesis. Does eveyeone else just understand what those term means immediately? Is it just my first gen immigrant English not good enough?

To OP, I can only comprehend 90% of what you said. And yes, that missing 10% is still very crucial for me to make suggestions. I don't know what other companies are requiring, but I am a tech lead myself. One of the most important aspect of managing a development team is to use verbiage that is ultra easy to understand. Thus, there is no misunderstanding. Even if you go for the management route, you have to talk to the developers in the end. And many developers are also first gen immigrant, you need to use a language that is easy to understand.

[-]

uniquesnowflake8@reddit

Probably manager track

[-]

_sw00@reddit

Totally. But since management is such a broad category, I'd add two more descriptors: +technical, +product

Big picture thinking, integrate many cues/signals and surfacing fundamental problems/opportunities is the perfect profile for someone who ought to be making product decisions.

2) Perfect fit with AI. You get to present your ideas as prototypes and working software instead of slide decks.

[-]