Software engineers typically don't stay anywhere for very long. If you're not moving, you're losing out on opportunities¹. And yet, I've made the choice to join and stay at one company for seven years. That's more than half my career to date. Why did I do that? And would I do it again?

Why have I stayed so long?

People change companies for a lot of different reasons. The factors I see most often are:

• To get more money or a promotion
• For better work conditions
• Because they're bored
• To change roles (into or out of management, into product, etc.)
• To get a better culture or different team.

When I look at why people typically change jobs, it's very clear why I've stayed at this particular company. I don't think I'd have a better job anywhere else.

Here's what we've done to build that department such that I didn't want to leave, and so that few people do leave the company: our turnover has been remarkably low for a software company, especially one hiring very good engineers².

We paid enough and promoted people actively

I've not set salaries, since my one stint of management still had my direct reports formally reporting to our VP for compensation purposes. But I've played the Salary Game³ with coworkers past and present, and I've had deep discussions with my various bosses about compensation strategy. Unlike many companies, we understood from the early days that if you don't raise salaries as market conditions change, many of them will leave for those other roles⁴. For me, while the pay isn't what I'd get at a big tech company, it's always been enough that pay wouldn't be a driving factor for me to leave.

The same is true with promotions. It frustrates me to no end that at many companies, the best way to get promoted from mid to senior, from senior to staff, etc. is to change companies. You've build all the knowledge already at your current role, and that knowledge walks out the metaphorical remote-work door when your employee shuts her laptop for last time. All because another company recognizes that yes, she is a senior software engineer now, and yours didn't.

Obviously this isn't always possible. Sometimes there isn't budget for raises. And sometimes people want a role that we simply don't have available. For example, one of our long-time engineers left when we had no management openings available. We had a going away party, because he was a cherished member of the team, and we genuinely wished him the best. He needed a change, and he got it. He also learned what he was leaving behind (harder to appreciate it without a change), and he's become a stronger engineer for seeing multiple companies.

You can't always satisfy what people need or want, but it's foolish not to try. If you pay people more when market rates raise and promote people when they're on the verge of a new role, they'll stay. If you don't, you'll leak out your best employees.

We have great working conditions

I've worked for companies where the expectation was that you get in before 9 and leave well after 6, staying late regularly to ship things on time. At those companies, I did my own thing, riding on my talent to just walk out the door when 5:30 pm. No one questioned it, because I was that productive and that skilled (in a niche role), and I could set my working conditions without repercussions.

But it really sucks to work on a team where everyone is expected to work late except one person. It's bad for that one person, it's bad for the whole team. The entire team deserves to work reasonable hours with a workspace that promotes their productivity instead of destroying it.

Our work environment has changed over the years, but we've always shaped it with a mind toward what our engineers need to be productive and content. When we had a physical office space in Manhattan, we had a partition put up to separate the engineering desks from the louder departments, so we could focus. We had focus time rules to build space and time for deep work. And now with remote work (and a team that was mostly hired to work remote from the outset) we've shifted our patterns but still worked deliberately to be mindful of what folks need.

And in 2022, we started doing four day workweeks. We don't do four 10-hour days, we do four 8-hour days. Just a shorter week! We still get at least as much impact done with fewer hours, and we're all happier and less drained as a result.

I haven't gotten bored yet (mostly)

At some previous jobs, things became routine after a while. You end up specializing in one area. For me, that doesn't really work out: I need a constant drip of dopamine from learning new things or I'm unable to make myself work on tasks⁵.

Not everyone can bounce between different areas, but I've had the luxury of having exposure to a lot of different things here. As a Principal Software Engineer, I oversee technical direction across our company. This means I see aspects of almost everything we do with computers. I've done lots of backend work. I've done some ML work. I've done frontend bug fixes⁶. I've worked with Salesforce (once, never again) and helped fix people's laptops. I've helped us step up our application security game, and helped our platform scale by 50x capacity.

I'm not lacking any dopamine at work. One of my favorite things is that I've got a reputation as great debugger so I get pulled into the trickiest bugs and the trickiest incidents. It's a lot of fun!

I've learned so much and grown a lot

When I started this job, I knew much less than I do now, despite being a pretty good engineer then. The nature of my roles has led to me being able to have continuous growth during my tenure, and I'm deeply proud of my growth and learning.

I've gotten a lot better at working with people by getting some management experience, and a lot of leadership experience, and growing to understand the difference between the two. Kind coworkers who explain how others think has been tremendously helpful here.

I've learned a lot about web development. My frontend development skills were much weaker before. I've dramatically improved at backend web development (focusing previously mostly on data engineering). I've learned so much about investigating and improving application performance. And my understanding of application security has deepened.

This might have given me unreasonable expectations of what I'll be able to learn in future roles, but I guess that means I'll have to craft those roles myself to foster continuous learning!

My role has changed

I was hired initially as an individual contributor on a team of three engineers. My manager intentionally asked what my goals were (management vs. individual contributor track) and ensured that we found opportunities for me to try things out. I've had the opportunity to change my role a few times.

The major shifts were from senior software engineer to tech lead manager, then tech lead manager to staff engineer (our individual contributor track was established for me), and then eventually from staff engineer to principal engineer.

Those shifts led to doing my first ever management, then learning about leading without authority, and eventually into being a company leader rather than just one for our department. We've fostered role changes in our other engineers, as well. One of our long-time engineers started as a marketing intern, and people have moved into management or into the technical track. And one of product designers started out in a different department, too! This has been an intentional approach at the company.

There aren't many better cultures (but I'm biased)

Culture is relative, and it's hard to pin down. We've built the culture we have as deliberately as possible. It's characterized by kindness and genuine feedback, by compassion and helping people grow. And it's characterized by a focus on excellence paired with a recognition that we're fallible humans, and that when we make mistakes it's usually not our fault.

As part of team, department, and then company leadership, I've played a strong role in shaping what our culture is. Rather than patting myself on the back, I'd like to demonstrate a few of the ways I've made mistakes and how other leaders at the company used those as teaching moments. These made me a better engineer, employee, and person, ultimately improving the company.

• I made an awful negotiation mistake, and our CEO taught me how to negotiate better. When we were still under 20 employees, I was negotiating for a raise. I'd asked for one number, then later asked for a different one. I'd done more research but I didn't present it as a change, or have any explanation. He taught me how to handle that situation better, recommended a book, and gave me the higher number I asked for alongside the lesson. Many managers would've stuck to the lower number, and few would have given the lesson. This helped me not have to go look at other companies to get money, which means they kept a great employee longer.
• I approached collective action poorly. Another time, I helped organize collective action when we were upset about the potential approach to a benefits change. I made a horrible error, though: I was in the room where that approach was previously discussed, then sprung collective action on my leadership team colleagues instead of talking directly to them about my concerns first. The biggest reasons were that I didn't feel welcome to speak up, and also that I truly didn't understand how they would feel about it. Instead of in any way penalizing me, our CTO worked to understand why I approached it that way, then he (and my therapist) helped me understand how to approach it differently next time⁷. He also made sure that there was space for me in the leadership meeting, allowing me to bloom more as a leader. And the benefits change? We got much of what we asked for.

I haven't so far deleted any production databases, but we've had some "whoopsies" in production and we've handled those by looking at where the system went wrong to let it happen. We do blameless post mortems to understand what happened and where things were able to go off the rails. Then we fix that, rather than blaming individuals. As a neurodivergent person, I'm very glad this approach has extended into mistakes with human interactions, too. We've worked to fix the system instead of penalizing people for not understanding the nuances of how people interact.

As our principal engineer, I've been at the company since we were 11 people and 3 engineers, and I've seen our practices evolve and grow as the company expanded and severely contracted. Our culture has changed, but it has kept this core brightness that is special. Not many places have that spark.

I'd do it again

When I joined this company, I thought it was a short-term thing to get us a mortgage, settle into a house, and then go back to my consulting work. But now? I'm in no hurry to leave. I want to see where we go and help us get there, but most of all, I just love this environment where I've grown and thrived.

If I knew what I know now, I'd do things differently and avoid some mistakes, but I'd join this company again and enjoy it just as much. I've made some friends for life, and I've learned more than I dreamed I could.

My hope for each of you reading this is that you'll find your own company like this. You deserve a team where you have a home base you never want to leave, where you have great working conditions and fair pay and as much (or as little) growth as you want. And if you are a leader? Please make this sort of culture happen.

Thank you to Dan Reich for the helpful feedback on a draft of this post!

• Both people have to share their salary with the other.
• Neither of you are allowed to get mad at the other about it.
• You can use the information but not attribute it in negotiations.

Note that you are allowed to get mad at your employer, just not the other person.