How to decide when to build vs. buy compliance training

A common problem: you’re building out a new team of software engineers, but you don’t know what role titles you need to be targeting. This can be twice as difficult when you take into consideration that not all software engineering job titles have the same job description.

At Ethena, we’ve thought hard about how to build a structure for our growing teams that feels transparent, fair, and easy to understand. And in the spirit of transparency, we’re passing what we’ve learned on to you with the titles you need to be looking for in your software engineer hiring process, the qualities that define each role, and some resources that we hope you’ll find useful as you hire.

The problem with defining software engineering titles

I hated group projects in school. My teammates and I could never agree on scope, nothing had a clear owner, and conflict resolution was off the table. Little did I know at the time that I would spend my entire career as a manager of software engineers 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 " make online training content that plays well with your HRIS."

And it begs the question, how should a manager divvy up the work of running a software development team, and what should we call each type of role? 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.

Some common first questions might be:

• 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?

Define your software engineering roles with three skills

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

1. 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, and find ways to unblock their team at every turn.

2. 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. 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.

3. 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.

How we defined our software engineering roles at Ethena

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. As we began the hiring process, 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.

Which is why we did some research you may find useful:

Using LinkedIn listings for reference material

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, but 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

What we learned about software engineer titles on LinkedIn

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 focus on people management while others handle all aspects of team leadership.
• Tech lead: It’s not nearly as common a role as expected and is less senior than expected.
• Program Manager: They focus on managing projects that require coordinated work across multiple teams.
• Staff Engineer: This role has multiple interpretations, leaning towards project management or senior technical direction.
• Principal Engineer: Generally focused on technical know-how, and some companies refer to them as Architects.
• Lead Engineer: The meaning of this title is still unclear to me.

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. People need context. Hiring managers need to paint a clear picture of how the role they’re hiring for fits into the larger organization. Stay tuned, as I can smell a new page on our public website brewing.