How Generalists Win by Seeking Problems, Not Just Solutions
Master identification and be able to defend how you choose work
In the last few weeks, we've covered several archetypes of engineering roles, including multifaceted enablers, program facilitators, solvers, and architects. We also spent some time talking about shapes, from our depth-focused specialists to our broad generalists, and then our T-shaped generalists, who are a blend of both.
If you're more of a generalist or a T-shaped generalist, I believe the key is investing in problem seeking and gap analysis patterns that don't rely solely on code or your "deep" technical skill (e.g., for me, this would be security stuff like application security assessments, penetration testing, and red teaming).
When I say doesn't rely solely, my expectation is that you are still bringing your domain of expertise with you. Instead, we turn our heads to identifying problems and performing gap analyses on areas that matter to the business. Your technical depth becomes the lens through which you view broader organizational challenges and identify unique opportunities you can solve.
As you grow throughout your career, especially as a generalist, you’ll face organizational, processual, or strategic opportunities, sometimes with a keyboard and other times through technical leadership. And here's where generalists and T-shaped engineers have a massive advantage: you can connect dots across domains where team charters often constrain thinking.
What matters?
This depends on your role and where you sit. If you report to a manager, it might be your team's charter, which gives you a sense of the areas to go after and solve. If your scope covers an organization, it may include the organizational goals as well as the main business stakeholders they enable. Stepping up in scope, you may be studying business-level priorities and considering how your work either accelerates or derisks those projects.
As a systems thinker, I tend to believe that looking at a system and identifying patterns is where I can provide the most leverage. When you understand how your technical decisions can be informed by product delivery, customer experience, and business outcomes, you start making different choices about the priority of what you work on.
For anyone, regardless of reporting chain, get deeply curious about how the broader business, product, and engineering functions work. One way to do this is to subscribe to business and product newsletters and regularly review QBR memos and product launch emails. I have an email filter set up, and all product and tech launches go to a single folder. As a security person, I can quickly assess those product briefs to look for patterns/trends (e.g., I see multiple teams using a new deployment pattern, worth looking into if we can integrate secure-by-default practices).
I believe that when you read enough product briefs, incident reports, and business updates, you start seeing the meta-patterns. It’s a bit like practicing ciphers on a mic. You start with simple end rhymes, but over time, flow with complex cadence and multisyllable rhymes.
With practice, you can quickly identify where your expertise could be activated proactively rather than reactively. In these moments, speaking with key stakeholders or engineering managers can build a lot of trust because they see you are someone who understands the business and acts proactively before problems become costly.
Now That I've Got The Rhythms, What Do I Listen For?
The art of problem-solving is really about developing an ear for organizational dissonance or also organizational harmony. What are the gaps we need to address, and what are the untapped opportunities we should all swim towards? Its best to ask some leading questions:
Is everyone facing a similar challenge?
Every product launch mentions fragmented tooling. Is there an engineering-wide solution to facilitate integration across tools? This is often a sign that we've optimized for individual team autonomy at the expense of organizational efficiency.
Is there a pattern/trend at a higher order?
I see that product launches for Team X are becoming more frequent, and there is a higher number of incidents on product X, which may suggest team burnout and accidental risk exposure. Sometimes the pattern reveals itself across time, not just across teams.
What's most important for the business?
I see in our QBR that priority Y continues to be the most important, while priorities B, C, and G are growing in importance. I notice that there is a project that may give us more bandwidth to work on priority B, through automation. The key here is connecting technical capabilities to business leverage points.
The Problem Seeking Framework
When I hone in on something, I usually aim for it to check a few of these boxes:
Reduces Risk – What could go wrong, and how do we make it less likely or less impactful?
Reduces Uncertainty – Where are we flying blind, and how do we get better visibility?
Reduces Complexity – What's harder than it needs to be, and how do we simplify?
Improves Resilience – How do we bounce back faster when things go wrong?
Improves Preparedness – What scenarios are we not ready for that we should be?
Improves Productivity – Where are we spending cycles that don't create value?
Supports Tech Culture – What makes our best people want to stay and do their best work?
Makes Everyone Faster – What bottlenecks slow down multiple teams?
Lowers Costs – What are we paying for that we don't need to?
Tests Our Bets – How do we learn faster about what's working and what isn't?
The best problems to solve check multiple boxes. If you find something that reduces risk AND improves productivity AND makes everyone faster, you've likely found something worth your time.
I've also learned that the highest-leverage problems often sit at the intersection of multiple domains. The security engineer who notices that deployment friction is causing teams to disable security guardrails results in riskier releases. The platform engineer who realizes that monitoring gaps are causing product teams to overbuild redundant alerting. The frontend specialist who sees that design system inconsistencies are slowing down every team. Most importantly, in all these scenarios, there is proactivity and follow-up. You may be wrong…and the problem isn’t that large, or someone is working on it. Or you may be a hero, saving the company from a material incident that could have happened.
These intersection problems are where generalists and T-shaped engineers can create an outsized impact.
Practice Set This Week
Write a one-page problem statement for something you found while doing discovery work on problems. Keep it simple and don't overcook it.
Fork this problem statement template I created. Pressure test your problem statement with a few colleagues, and then pitch it to your manager. Let me know how it goes!