How Many Titles Does It Take to Run a Software Engineering Team?

A semi-scientific analysis of senior SWE job titles, and an unscientific set of opinions about them.

Group Projects Continue

I hated group projects in school. My teammates and I could never agree on scope, nothing had a clear owner, and mature conflict resolution was off the table (I guess I’ll just do the WHOLE THING MYSELF). Little did I know at the time that I would spend my entire career working in teams and thinking about how to structure them. I often imagine how much smoother those projects could have gone if we had clearer roles and responsibilities. With titles like “Book Report Cover Designer” or “Chief Crayon Officer” we would have been unstoppable.

Software development is just a scaled-up version of this classic problem, but instead of a diorama about the water cycle, we’re tackling projects like “Make compliance training people will actually like.” And it begs the question, how should one divvy up the work of running a software development team, and what should we call each type of person? Sure, you’ll have Software Engineers writing the bulk of the code, but defining the roles, responsibilities, and titles of the more senior engineers on the team can be a real source of confusion. Should we have Tech Leads or Engineering Managers? What do Staff Engineers do and are they different from Principal Engineers? What’s an Architect, and don’t they work on buildings?

To break the problem down, I first identified the three major skillsets required to operate an effective software development team: project management, people management, and technical know-how.

Project Management → Just figuring out who should do what at any given moment can be an all encompassing task on an agile software development team. A strong project manager will nail down requirements, maintain clean and up to date tickets, as well as find ways to unblock their team at every turn.

People Management → People managers who genuinely care about the success and happiness of their direct reports are essential to the long term success of any team. Great people managers can see the strengths and weaknesses of each individual and provide relevant and actionable feedback on a regular basis. And in my experience, engineers prefer managers who work directly with them every day, not an HR representative who swoops in for a 30 min check-in once a month or someone with 20 direct reports struggling to keep track.

Technical know-how → Technical expertise at the team level is about understanding trade-offs and driving alignment on decisions that will affect the team in the short, medium and long terms. Should we use a framework or roll our own in this situation? How much should we nit-pick pull requests before we deem them production-ready? Ideally, a technical leader knows how to listen to other engineers on the team, while ultimately taking responsibility for making the final decision when there’s disagreement.

A late-night analysis

Confession time: this entire article is the result of an existential crisis I had a few weeks ago. As the VP of engineering at Ethena, it’s my job to decide what roles we hire for in the engineering department, what we call them, and what is expected of the people in those roles. I became worried that I was simply throwing around titles and terms I’d picked up throughout my career, without truly knowing if they were descriptive of how we’ve chosen to run our teams at Ethena.

But I’m a scientist at heart, so to better understand which titles implied which skill-sets and which are more common in the industry, I decided to embark on a semi-scientific journey of discovery on my favorite social media network: LinkedIn. I took the first 40 tech or tech-adjacent companies I could think of and documented which roles they had advertised on the platform. This is not a perfect science. For example, some companies may only promote internally to certain roles, or they might not have had an opening at the time of my search. After some initial research, I broke the roles into the following six archetypes:

• Principal Engineer/Architect
• Staff Engineer
• Lead Engineer
• Tech Lead
• Engineering Manager
• Program Manager/Project Manager

And here is the result:

The entire spreadsheet can be found here.

I had a ton of takeaways from this exercise, but here are some of the highlights:

• Engineering Manager: Every company has them, but they seem to mean very different things. Some companies have Engineering Managers take on reports across multiple teams and focus almost entirely on people management. Others see the Engineering Manager as the core leader of a single team of engineers, handling all aspects of team leadership.
• Tech lead: It’s not nearly as common a role as I expected it to be, and it’s less senior than I expected. I did get a sense that Tech Leads are expected to code a meaningful percentage of the time, while helping delegate to and project manage other engineers. I’ve even seen the term “Managing Tech Lead” used as a stepping stone to the Engineering Manager title.
• Program Manager: They are prevalent, but Program Managers seem to focus on managing projects that fall outside of any one team, often requiring coordinated work from many teams. This makes a ton of sense to me, as without clear ownership from a program manager, the tragedy of the commons can leave these types of initiatives dead on arrival.
• Staff Engineer: This role seemed to have multiple interpretations, either leaning in the project management or senior technical direction. Some companies directly equate this title with Tech Lead.
• Principal Engineer: Everyone seems to agree Principal Engineers are technical know-how focused, and a few companies call them Architects.
• Lead Engineer: I still cannot tell you what this title is supposed to mean. I’m only more confused than when I began.

Context is key

At Ethena, I’ve chosen to have two positions in our Engineering staff in addition to our Software Engineering ones: Engineering Manager and Principal Engineer. But my biggest takeaway from all this is that titles alone don’t communicate nearly enough information. People need context. Hiring managers need to paint a clear picture of how the role they’re hiring for fits into the larger puzzle of the organization. Therefore, in addition to my existing pledge to make our salaries public, I see a need for another type of organizational transparency at Ethena: making our product development organizational structure and the responsibilities expected of each role completely public. If you want to join Ethena as an Engineering Manager, Senior Engineer, or Principal Engineer, wouldn’t you want to know more about what’s expected of you ? Stay tuned, as I can smell a new page on our public website brewing . . .

Ethena is hiring, especially for Senior Backend Engineers, come work for a growing org that’s being intentional in how we operate!