Take a look back at your tech career so far. Have you ever broken down the exact sort of work you were doing? I don’t mean “writing code” versus “finding the Zoom buttons”—I mean who was gaining value from your work? What sorts of teams were you supporting? How was your impact being measured, and on what?
Many of us don’t ask these questions. Especially early in your career, you’re likely more focused on taking any work offered to you, or on finding projects that pique your interest. As you grow and gain more experience, you might start looking at the folks around you and wondering how your paths differ. Maybe you’ve done a lot of solo work and are curious about team dynamics. Maybe you’ve been at large organizations and seen folks come and go on shorter engagements.
It can be helpful to consider the work you’re doing and how it compares to the work you’d like to be doing. What could it look like to change your responsibilities and build the job you’ve always dreamed of?
Separation of concerns
Let’s talk about two large categories of work: Product Engineering and Consulting. We’ll be focusing on these classifications in mostly technical roles, though you can find them in other disciplines too. For many of us, the decision to work as consultants is driven by the chance to try something different. But what does “different” mean? Let’s talk about the ways working for an agency differs from working on product teams, and why you might choose one over the other.
First, some definitions. Many folks hear “consulting” and think “freelance”: working entirely for oneself. This isn’t always the case! At Test Double, we work full-time for the agency and do work for our clients. You may hear this referred to as “contracting”, too, but we use the word “consulting” intentionally: we do more than drop in just to complete a project, though many engagements start off that way. This contrasts with “product engineering”: working full-time on a team dedicated to a product or feature at a company.
Product engineering (or: “I work for the company!”)
Product engineering roles are the easiest to classify and tend to be more common. As a product engineer, you’re involved in building a software product (hence, the name). Early-career product engineers are likely writing code to satisfy tickets, and as you advance you may start taking ownership of certain features, or working more closely with product managers & company stakeholders to identify the work that needs to be done.
You might switch teams or products, but the common thread for product engineers is your focus on a particular product, tool, or team. Titles are significant in these roles as well! You might grow from a Junior Engineer to a Senior, Staff, or Principal Engineer with longer tenure and greater impact.
Consulting (or: “I work with companies!”)
Let’s now try to define consulting. Here’s where things break down: consulting roles are highly fluid and differ from team to team. Consultants generally join a project for a specific purpose, but their contributions can quickly pivot as the team’s needs change. For example, let’s say you sign on to code a feature that’s fallen behind schedule. While you’re working, you notice a process issue that’s slowing the whole team down. You take that to the team’s manager, and spend a few weeks working with them to refine that process and speed up all your teammates along the way! While that process improvement work wasn’t part of your original assignment, it’s all a part of consulting: helping bring new perspective and expert guidance, and exercising your role in whatever way provides the most value.
Consultants usually work for one group (often called an “agency”, like Test Double!), and are assigned to work with clients of that group. So instead of saying “I work for Test Double”, I might say “I’m consulting at Kerry’s Tax Service via Test Double.” This relationship can create all sorts of confusion, and makes titling consultants more difficult than product engineers.
Compare and Contrast
Let’s look at the general responsibilities for each role. Both product engineers and consultants follow their teams’ workflows around delivering features. In either role, you’re likely to be assigned tickets and have deadlines to meet for submitting code. You’ll also likely share responsibilities for team rituals: things like code reviews, daily standups, and one-on-one meetings with a manager & other team members. Depending on your relationship with your team, you might be part of cross-team meetings or internal huddles.
For product engineers, that’s likely the end of the schedule. As you advance you might take on more senior responsibilities around team order and code quality. You’ll probably do some mentoring of more junior engineers as well.
For consultants, those general responsibilities are only part of the job. Consultants prioritize bringing value, and this means working across multiple levels of the team. You might schedule meetings with managers, or even higher-level stakeholders, to learn more about the team’s process. You’ll probably ask lots of “why” questions to help guide your decisions. As you get more comfortable, you may make suggestions or work with entire teams to smooth out the rough edges you find.
A perfect match
Together, product engineers and consultants grease the wheels for company growth. The product-focused folks can focus on keeping code moving along, while a good consultant can clear the product team’s path and help power them to even greater results. Both product engineers and software consultants are valuable, and double agents at Test Double have experience working across the spectrum.
If consulting sounds like an interesting path, our own Landon Gray has a few things to say about why he loves this role. And if you’re ready to do some consulting yourself, Test Double is hiring!
If you’d like to learn more about how our consultants can help power up your team, let’s talk more.
