WWCode Career Nav #17: You Don’t Have to Be a Manager
Stacy Devino, Senior Principal Engineer at Stitch Fix, shares, "You Don't Have to Be a Manager." She discusses career growth opportunities in tech that expand beyond “people management.” She also outlines the responsibilities of staff, principal, and distinguished engineers in key areas like coding, leadership, and technical skills.
You have probably heard, “If you want to move up in your career, you have to become a manager.” That advice is usually from a bad manager. What they're talking about is that you need to become a "people manager", and that's not necessarily the case. Let’s start with the tech path specializations. Where can you go from being a senior engineer? There are staff engineers, principal engineers, and distinguished engineers.
A staff or lead engineer makes platform-level decisions. In this role, you will have more pairing and planning meetings than when you were a senior engineer. You will be spending more time working with folks individually. In terms of technical skills, you are considered a domain expert in your given platform. Regarding coding time, time is spent teaching others and doing core deliverables. You are organizing the core pieces for everyone else to jump into.
In terms of leadership, you're starting to oversee people and products to develop timelines technically. You must pay attention to the quality of work and how people are putting things together to ensure that it aligns with expectations. Regarding responsibility, you are the first to jump on emergency issues in your domain.
You are the primary contact for your domain. Doing the work requires documenting the why, the how, and the result. You are not just implementing, you are planning and strategizing. Regarding the junk drawer, you must monitor crash logs and development tasks, including bug tasks. Regarding soft skills, you're starting to do more internal and external presentations. You must start developing positive communication skills that help unite your group and yourself with the alignment of the company.
I'm a senior principal. This is an area I have a lot of current experience in. A platform leader makes the architecture decisions in their domain and starts to touch on other domains. You might be doing Android and API, not just necessarily in defining schema, but defining standardization. Other things might be touching your platform but are not part of your platform inherently. You're working with other leaders in terms of meeting and pairing, more planning meetings. You're setting tech direction across multiple individual areas. In terms of technical skills, you are a domain expert with knowledge of system architecture. Often, you have had to learn other types of coding to do this and be effective in multiple areas.
You've skilled up in a meeting and pairing technical skills. Still, your coding time is less because you're focusing on core deliverables, coding organization, and some areas around leadership. You are the symbolic leader for your entire platform. You have high levels of responsibility because it's your platform, architecture, people, and teams.
As the one responsible for your entire platform, you better have documentation to back up your decisions and make it easy for people to onboard. The onboarding experience falls on you as a principal engineer; part of that is documentation. In terms of the junk drawer, you're managing different systems because you're doing backup resiliency. You're looking at how well endpoints perform. Regarding soft skills, you represent your platform internally and to senior leadership.
In terms of meeting and pairing, it's high because you're working with other tech leaders to set tech direction. We haven't leveled up technical capability from the principal level. You might build, in terms of architecture skills, but it's not that your technical skill overall is significantly higher. In terms of coding time, it's lower because you are taking on a lot of leadership tasks. You are the technical leader for your entire discipline to the senior company leadership. You have a high level of responsibility because you might have several principal engineers under you managing their platform.
Now you're not just managing a platform, you're managing multiple, doing multiple architectures, managing multiple people in terms of technical actual deliverables. Ultimately, accountability for all of them falls on you in an engineering capacity. There is high documentation because your decisions set everyone else's direction. It has to be very explicitly documented in a very concise way. In terms of the junk drawer, you get the flaming junk drawer. Tech debt is your job to identify and fix. For soft skills, you are the representative basically of engineering to the whole C-suite for your entire area.
Tech domain specializations are open things but maybe aren't obvious. There are so many areas that you can go into from a senior engineering background. Let's start with the technical product manager. This is a product manager with strong tech skills to manage technical aspects of a product and engineering teams. That means you're going to have more meetings and pairings. Your job is people, product management, and timelines.
In terms of technical skills, where you may have been like a three as a senior engineer, you're maybe going down a little bit because you're not physically implementing the solution. In terms of coding time, it will only enable other teams or other pieces of the actual product. It might be some scripting, setting up some third-party libraries or features, or things along those lines.
Regarding leadership, you're the voice in the room that your engineering teams are not in. That means you have to be a strong advocate. Regarding responsibility, you're responsible for the product's success and meeting the timelines you set. That's a big one. You document and present the work on a product level to the whole company. Documentation is key. If it's not documented, it doesn't exist.
In terms of a junk drawer, you will manage and monitor the core systems for trending data and any alerts that are generally non-technical but important to the success of your product. In terms of soft skills, you need to have high verbal and written communication skills to set the strategy and do that actual technical planning work. In terms of a project manager, you are the person who defines the scope and timelines of a project while also being responsible for resourcing and unblocking. The technical product manager manages the product from a technical standpoint, which might mean they work with multiple teams and engineering factions. The project manager is potentially overseeing multiple product managers, which means you will have a lot of meetings and bearing. Your job is the whole project. You will probably be consistently in personal, product, and leadership meetings, just being the voice.
In terms of technical skills, you know enough to be effective for the project and to have the correct perspective. You're not implementing, you're relying on your product managers and engineering leaders to handle the detailed work. In terms of coding time, it is similar. In terms of leadership, it is higher. You're the voice of the entire project, including engineers, designers, and product groups. You're bringing it all together. You'd have multiple product managers. In terms of responsibility, you are responsible for all aspects of the project. Success or failure falls on your shoulders. The ability to push that information, communicate that information and take responsibility where appropriate is key.
You are not necessarily documenting to the same degree as a product manager. Still, you are organizing much of the documentation everyone else is creating and putting it into a more cohesive storytelling style. You have more junk drawer. It is heavy communication to identify and move to eliminate blockers and debt continuously. You are also looking into the future to make sure that you are planning effectively so that these issues are already taken care of before anybody sees them. In terms of soft skills, this is the highest. High verbal, networking, and written communication skills are required to fulfill this need.
Technical sales is a product manager. You know the product and how to sell internal and external meetings. In terms of technical skills, you know how to connect products with capabilities at a technical level. In terms of coding time, this can be pretty variable. Technical sales can be very technical. In leadership, you organize and prioritize, but generally, you don't kind of lead anyone. You might have a small team and work directly on the implementation.
Regarding responsibility, your job is to sell and maintain customer relationships for general follow-through. In terms of documentation, they have a lot of pricing, general accounting, and technical documentation of their solutions. The junk drawer is about maintaining client relationships and being the point person for all the little things. In terms of soft skills, you need communication and networking capabilities.
In terms of meetings and pairing, you maintain relationships and instruct teams while keeping leadership informed. In terms of technical skills, you know how the architecture works together, and each piece is part of the client's solution. You might not be coding very much, or you might be doing a lot in terms of architecting how all of your different products interact. With leadership, you're often organizing multiple teams. In terms of responsibility, you're responsible for everything for your client. It's your responsibility to communicate the real timeline.
If you don't document the implementation details, especially what you did and the technical requirements for the client, it doesn't exist. For junk drawer, maintenance is a daily habit, watching logs, analytics, and staying atop market trends so that you can help the client get the best solution. This last one, since you are the liaison on behalf of the client and behalf of the company, each faction needs to feel that you are on their side.
You're managing relationships, architecture, products, projects, and multiple people in the tech domain tracks. There are multiple paths for your tech career. It's about weighing what you love most and deciding where and how you want to scale up. Everywhere along the path, you're learning and growing. You ultimately define the role, whatever your title is. It doesn't define you or how you can make the role your own.