In the lesser known play Romeo and Juliet Go to Bootcamp, Shakespeare tells the story of two star crossed lovers climbing the corporate ladder as they pursue careers in software engineering. My favorite line happens when Romeo is facing imposter syndrome and Juliet says to comfort him:

What’s in a title? that which we call “Senior Engineer Romeo”
By any other title would have the same impact;
So “Senior Engineer Romeo” would, were he not “Senior Engineer Romeo” call’d,
Retain that knowledge of software development which he owes

Who said Shakespeare isn’t timeless?
In this line, Juliet is telling Romeo it’s really the impact he brings, not his title, that defines his worth as a software engineer. But Romeo is at an interesting point in his career, as he’s recently attained the all too familiar “Senior” title. This begs the real question: does “Senior Engineer” convey any specific meaning?

Unfortunately, in my many years as a hiring manager, I’ve found the short answer to this question is “not really,” at least when looking at the industry as a whole. I’ve met senior engineers who have built complex and successful products from the ground up, and others who seem to have barely left bootcamp. In past writings, I’ve tackled the wild world of engineering management titles, but I think it’s high time I offered my thoughts on the most common and misunderstood title of them all, “Senior”!

Luckily, at Ethena, we have a well-defined and impact-based definition of what the senior title means to us that I’d like to share with you all (note that we also publicize our salaries and compensation formula for each title to tackle the underpayment gap for existing employees at tech companies). I’m hoping it will help aspiring senior engineers understand what it takes to make it to the next level in their organization and offer ideas to other engineering leaders looking to make sense of this all-too-vague term.

Setting the stage

Let’s start with a thought experiment: imagine a quintessential Junior Engineer and Principal Engineer tackling the same feature. The Junior Engineer might need guidance to get started, require plenty of support from their more senior colleagues along the way, and ultimately build something that works–but that might require some bug fixes down the line. In comparison, not only will the Principal Engineer accomplish the task more quickly, they’ll also use a simple, resilient and future-proofed design. The resulting feature will require little maintenance and launch without bugs, and they probably didn’t need an ounce of help to accomplish it. The Principal Engineer also remembered to coordinate with the product manager on that other team, because they realized that in certain cases . . . you get the idea!

Most importantly, the Junior Engineer’s lack of experience doesn’t just mean that they’re slower at the same task or that their work may not have all the same bells and whistles, it also means that they are relying on their team’s help to accomplish the task at hand (and to be clear, that’s not a bad thing!).

But in this example, we’ve looked at two extremes on the seniority scale. What about an engineer crossing the boundary from “Software Engineer” to “Senior Software Engineer” who fits somewhere in the middle?

Finding the line in the sand

There is clearly some continuum at play, between the always-learning apprentice, and the often-teaching expert. And we expect to see both archetypes in an effective engineering team where more experienced team members are creating guard rails to empower their less experienced colleagues to effectively get things done. These guard rails take the form of everything from pull request reviews, to best practices documentation, to pair programming sessions and more. They can be about individual projects within a team, or the larger development landscape at your organization. The work of creating guard rails is extremely important to the success of engineering organizations because it’s multiplicative, which means that a single hour of time helping a junior colleague might unblock days of productive work from that person. It’s also incredibly risky. That one senior team member can have an outsized effect and if they themselves aren’t modeling best practices, your entire team is likely to struggle.

At Ethena, we define (publicly) a senior engineer as someone who is capable of creating guard rails for their less experienced colleagues and who themselves doesn’t need input or guidance to successfully own projects from start to finish.

This is an impact-based line in the sand, and exactly how each senior engineer surpasses that line will look different, as it takes a wide range of individual skill-sets to have this broad an impact. For example at Ethena, a frontend, technical-focused senior engineer may demonstrate the ability to set guard rails by creating helpful documentation about how to deal with dates in our react application, including new linting rules that validate these best practices on every pull request. A management-focused senior engineer may work with their product manager to task out a large initiative, thereby creating clarity for the junior engineers working on the project. Both engineers in these examples empowered the rest of their team to be more effective, and at Ethena, this is what it means to operate at a senior level.

So far, we’ve found that this bar is much higher than what some other organizations have for the senior title, but we also give our senior engineers the level of responsibility, compensation, and opportunity for impact we feel they deserve. For example, our processes require senior engineers to sign-off on PRs of a certain complexity, and we look to senior engineers to coordinate with their engineering managers on reviewing design documents and giving technical input on their area of expertise, to name a few. So if you’re looking to join Ethena as a senior engineer, we expect you to have strong opinions (weakly held of course) about how to build great software, be enthusiastic about mentorship, and be prepared to take on the responsibility that your title warrants!

At Ethena, we want engineers to stick with us for the long run, using their ever increasing domain knowledge to build their impact over time. This is why we’ve designed a salary structure that grows predictably year over year and increases even more aggressively with strong performance reviews. Additionally, all future increases we make to our base salaries in order to win top talent in the open market will be given to our existing team, full stop. If you just came for the headline and want to check out our numbers, see below. The remainder of the article will talk through how the formula works in more detail and how we plan to adjust these numbers over time.

Now for the fun part, math! An engineer’s base salary is determined by their current level. Every 6 months, Ethena holds performance reviews, and engineers will receive a raise based on their performance as laid out in the chart above. The interesting part is that this raise is cumulative. So for example, let’s say you were to join Ethena as a SSE I with a base salary of $180,000. You spend 18 months with the company, participating in 3 performance review cycles, meeting expectations with each one, so… checks the chart, multiplies by 3 … your base salary is now $189,750. Now, that might not seem like the largest raise in the world, but if during the next performance cycle you were to be promoted to SSE II, your total compensation would jump to $209,750, keeping all of the performance and tenure base increase you have accumulated so far at Ethena. An engineer who exceeds expectations for 3 cycles before being promoted would have a total cash compensation of $219,500!

The long and short of it is that we want to incentivize our engineers to stick with Ethena, build domain knowledge over time, experiment with different areas of focus, and most importantly find opportunities to grow within our organization. These cumulative raises will also apply retroactively to our early team, and in our humble opinion, they deserve it!

Additionally, every engineer at Ethena will benefit from all future increases to our base salaries. We will adjust them over time in response to market pressures and as the company moves through rounds of funding and matures. The rule is simple: the recruiting team and I can only offer our base salary to candidates, no exceptions. If we find that we are unable to meet our hiring goals with our current level of pay and we need to increase it, everyone on the team benefits. This creates balanced incentives, where on the one hand we have a responsibility to our investors to use capital efficiently, but on the other hand, we need to present competitive salaries to the open market in order to hire great engineers and build amazing things.

One last note: Ethena provides generous equity in addition to cash compensation, but the details of equity are a bit trickier to make public. I can say that we share this information openly with candidates who make it to the later stages of our interview process, including the % of the company that your stock options are worth.

If you’re interested in joining our engineering organization, we’re actively hiring engineers and engineering managers for our remote-first teams out of the US and Canada, and pay does not change based on your location. Canadians, you get the CAD equivalent to the USD in the above chart!

A Public and Transparent Formula for Engineering Salaries @ Ethena was originally published in Marker on Medium, where people are continuing the conversation by highlighting and responding to this story.

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!

How Many Titles Does It Take to Run a Software Engineering Team? was originally published in Marker on Medium, where people are continuing the conversation by highlighting and responding to this story.

Too soon

When news broke that breakout star Regé-Jean Page was leaving Bridgerton after only one season, my initial reaction was that of shock and heartbreak. I couldn’t fathom why Netflix and The Duke of Hastings weren’t able to come to some sort of agreement. But then it hit me: my entire career, I’ve watched talented engineers leave companies for greener pastures after painfully short tenures. I’m even guilty of this myself — I left an amazing company after less than two years to join Ethena as VP of Engineering.

My example aside, I think the larger phenomena is a problem with organizations, not individuals. When hiring someone new, companies are forced to play in the open market, competing for top talent. But internally, they create opaque and informationally asymmetric compensation structures designed to minimize growth for existing employees to save the company’s bottom line. That’s not the type of company I want to be a part of, so at Ethena, I’m working to create career paths and compensation structures that encourage long and happy tenures by paying our engineers generously and in proportion to their impact. Additionally, I’ll be working with our not yet hired Head of People to publish our compensation formula publically.

Let’s break down why this strategy makes sense, and why I believe it will be fundamental to Ethena Engineering’s long term success.

All about the money

With a market this hot, software developers are hopping between companies and raking in enormous pay raises in the process. But let’s think like economists for a second — in a perfect market, this shouldn’t be possible! If a developer of a certain caliber is able to demand a given salary on the open market, why isn’t their existing company paying them that very same amount? In our imperfect world, engineers join a company at a certain level of expertise, spend time learning and growing that expertise within that company, and then for whatever reason find that it’s much easier to get recognition for that growth outside that company.

A graph or two might help illustrate the problem. First, market salary increases with years of experience, assuming an engineer is improving their skills of course!

That one is a bit obvious, huh? Okay, well, let’s look at an engineer’s salary in their job at Acme Corp. Notice the slope of the line is a bit less . . . exciting? In my opinion, it’s likely the short-sighted desire to save money that defines the slope of this line at many companies.

Well, if we’re talking about compensation over time, what about impact? Check out this steep angle!

See, developers don’t just improve their transferable skills while working at their company, they gain domain knowledge that is specific to that company, and that stuff is incredibly valuable. The wild thing is that it’s only valuable to that one company! Let’s put it all together in one graph, and please don’t judge my blending of the units here . . .

The hard truth that many companies struggle to wrap their heads around is that they should be paying their long-tenured engineers above market rate. This is because an engineer that’s been working at a company for a long time will be more impactful specifically at that company than at any other company. Bridgerton casting aside, a company like Netflix understands this, and will always outbid competition for their top talent.

Nothing comes easy

It’s easy to say “pay your developers more,” but it’s never that simple. For one thing, this type of compensation structure is unrealistic for very early stage startups where paying your first few engineers a market salary is usually impossible. Additionally, without an HR infrastructure in place, simplicity and equality can help early stage companies thrive. This is why, so far at Ethena, the entire engineering team, including myself, has made the same salary. The other challenge with a compensation strategy like I’m proposing is measuring everyone’s unique impact accurately and without bias. What happens when the new hotshot junior engineer suddenly starts outperforming the old guard? With an impact-based compensation structure, she would deserve a sizeable raise, but is the company willing to go through with it and risk upsetting the other team members? Plus, not all engineers necessarily increase their level of impact over time. How are these engineers, who still add value every day, compensated in this type of structure? I believe the key to navigating these hard problems is organizational maturity. At Ethena, our track record of transparency, open feedback channels and an experienced management team put us in a position to make these types of bold policies that other companies may struggle to operationalize.

Okay, so what’s the plan?

With the help of our soon to be Head of People, we intend to create a formula that takes into account title, years of tenure, and performance to create a compensation graph that scales with company impact as closely as possible. By making it predictable and public, both existing team members and potential hires can know in advance what they should expect to make at Ethena in the short- and long-term. It also means being comfortable with hard truths — not everyone’s impact grows in the same way and at the same time scale and maintaining talent density means being willing to part ways with underperformers. At the end of the day, if any engineer at Ethena demonstrates they are performing at a certain level, regardless of how many years of experience they have in or outside of the company, they should be rewarded with a title and base salary that matches their impact (in addition to their tenure and performance multipliers!).

So stay tuned for more! I hope the future Head of People knows what they’ll be getting themselves into . . .

Why Don’t Tech Companies Pay Their Engineers to Stay? was originally published in Marker on Medium, where people are continuing the conversation by highlighting and responding to this story.