What Should Software Engineers Work on as They Grow?
A plethora of outstanding literature exists with the goal of helping software engineers make a greater impact and grow in their careers. Just a few examples include:
- Staff Engineer by Will Larson
- The Staff Engineer’s Path by Tanya Reilly
- The Coding Career Handbook by Shawn Wang
but there’s many others. These books and others like them are excellent resources to help engineers develop within the technical aspect of their job.
However, I have an extremely short framework that I like to share with folks early on in their careers (usually in one of our first 1:1s). The first VP of Engineering I ever worked for, Ankur Goyal, is the one who taught me the general strokes of this framework. And I still refer to it 7 years later.
The Framework
- Taking on tasks that have a clear solution. Usually, the solution will be written out for you already.
- Taking on tasks that have multiple known solutions or worse yet, no known solution. Choosing the solution is up to you.
- Taking on problems or “situations” (not “tasks” anymore), that are extremely unclear. You have to reach out to others, do a lot of research and figure out what we should do and execute on it.
- Identify the problems or “situations” we should tackle (and then you may or may not lead the resolutions). The main thing at stake here is staying in tune with the business. You have to put on the hat of a product manager and figure out the ways in which we should change course (we may be under or overinvesting in different areas).
Let’s briefly dissect the framework. In general, engineers should progress from very obvious to extremely non-obvious work. At the same time, engineers’ impact on the business is expected to grow linearly in the first years of their careers, and then almost exponentially as they take on higher-level work.
This framework applies to a variety of roles across companies, not just engineers. However, it is especially applicable to engineers working in companies that expect a lot of them outside of writing code. In a company such as SingleStoreDB (my current employer), where the product is a tool for software developers, engineers are expected to contribute a lot to product ideation, strategy and even vision. Of course, consulting companies or companies building non-technical products usually expect engineers to be more focused on flawless execution and much less on business strategy. That’s totally fine, but the framework presented above is definitely biased towards organizations building tech products.
Of course, I’m happy to hear any thoughts on this matter. Just reach out on Twitter!