(this is a very me-centric post. I decided to post it in case it helps other senior/staff level engineers think about their career path. It can be hard to find examples of this reflection process online)

I have a pattern with jobs. I build up, over a period of a year and change, to some level of ownership over something interesting. I function in that capacity for another year. Eventually, I get bored. I keep delivering while boredom accumulates, then I eventually leave for somewhere else to repeat the cycle. This usually comes as a surprise to my management. In a sense, it’s a surprise to me as well. There’s no one obvious thing to bring up in a 1:1, no moment where I decide to quit. Rather, I slowly get more open to get to know you calls from recruiters, old coworkers from my network, etc. One thing leads to another, and suddenly I have a new job based on a positive interview experience or a good gut feeling.

I’ve been at my current job for almost 3 years now. I’m in the twilight of the middle “owner” phase; still effective, still mostly engaged, but I can see the last boredom phase on the horizon. I also want to stay at this job longer than 3 years, even though common wisdom may say not to. ¹ So, lately, I’ve been trying to dig more into this pattern.

Above, I characterize what I build to as ownership. In past roles, this has been pretty broad. At peak effectiveness and satisfaction, I’m usually responsible for:

• All or nearly all actual hands on implementation work.
• Technical architecture, infrastructure, alerting, monitoring, etc.
• Proposing a lot of my own features while working with a PM to collaborate on a roadmap.
• Representing the project to other internal stakeholders (business, reporting, etc).

In other words, I’m the x guy, for some nontrivial x that has increased in size/scope as I’ve changed roles. My past companies and projects were a good match to my abilities, and I was able to do fine in all of these different areas (stronger in some, weaker in others). ² Silo is another word for this, and is what I’ll use going forward.

The Perks of Being a Silo

There are, to be sure, downsides to engineers functioning as silos – both to the engineer and to the organization that employs the engineer. I’ll talk about these later. That said, it’s important to acknowledge that, for many, being a silo is a deeply, even profoundly satisfying way to work.

I’ve always been a good coder. When former coworkers introduce me to other engineers, they often lead with that. To them, it means I can pull rabbits out of my hat, building something big and important very quickly. To me, it means getting to vanish into a big problem for hours or days. Readers who have been fortunate enough to do this a few times on large problems will appreciate how satisfying and unique an experience it is on its own; having it be your job is even better. I don’t really get this when working closely with others. I wouldn’t be a good teammate if I went off in a corner and built the whole thing myself, and the division of work among a team seldom allows for deep flow or for variations in speed/coding ability to shine through.

I also crave variety. I’m a lot less happy in a job if I only have a steady stream of more or less the same type of task to do (make this change to your codebase, now make this other similar change to your codebase, …). If I’m a silo on the right kind of project, I’m responsible for a wide variety of work. I pay a price for that sometimes (lots of urgent requests that I need to context switch on), but I rarely lack variety. This, too, is harder to find when working honestly as a member of a team.

Finally, there’s a sense of pride that comes with being the silo. On a large team, I can say that I contributed to a particular feature or led a key initiative. On a project where I’m a silo, I can point to the project and say “I did that.” That’s a pretty cool feeling on a project that is a key item in a sales pitch, or that makes the company a bunch of money.

None of that is to argue that one should be a silo, or that it’s something a company should tolerate, or that it’s a healthy way for an engineering team to work. I just think it’s important to acknowledge that people who do enjoy working this way aren’t just antisocial or secretly incompetent or something. Similarly, if you (like me) are someone who really gets a kick out of this style of work, you’re not wrong to feel like you’re giving something up if you move away from it.

The risks of silos for a company

Engineers who are able to do it all to a good enough standard are very valuable to certain companies at certain times: as very early engineering hires at startups, in companies that want to test the waters with an MVP without compromising delivery of other things, etc. It’s certainly a skillset I’m thankful to have. That said, having a silo for an important project is necessarily a compromise for the company.

No matter how talented, there’s a limit – simply in terms of time and energy – to how much a single person can do. The demands of a successful product are likely to exceed that limit. The output of a single person is also more variable and less predictable than a team. If a silo overworks and needs a couple weeks to recover, that’s a couple weeks of nothing getting done. One engineer taking time off in a large team might reduce overall work velocity slightly, but not to anything like this extent.

Even a talented generalist engineer will be weaker in many areas than a specialist will ³. That may not an issue for a project getting off the ground (when no specialist is on offer), but it is likely to be a limiter eventually. A backend-leaning generalist developer might be able to hack together a UI, or manage a product roadmap, but will probably be a lot worse than a frontend engineer and product manager at those tasks.

An engineer functioning as a silo is quite literally a single point of failure (this is one of the ways the term is most often used). Even if they have the skill and work capacity to deliver all of the items on the roadmap by themselves, it’s a huge risk for a successful or important product to depend on a single person. If that engineer burns out or leaves, the business is in a really tough spot.

Finally, a silo acts as a crutch around processes that are required for an actual team to function. This is the point in some cases, but doesn’t tend to age well.

Maybe a silo developer has built something interesting, useful, and successful. As argued above, their capacity is limited, and the demands of their product will eventually grow beyond that capacity. A simple, obvious and somewhat naive answer at this point is to add more engineers. It may not be that simple, though. Maybe internal customers have gotten into the habit of DMing the original engineer associated with a project for feature requests, bug reports, or deadline/roadmap questions. Maybe the deploy process (such as it is) is undocumented because only one engineer ever does deploys, or the alerts are just hardcoded to go to someone’s phone, there’s no escalation policy or official process for reporting a problem with the application, etc. Imagine trying to bring a new engineer onto a project like this. This isn’t a hopeless situation, but it takes dedicated effort to fix. Correcting these issues may even require a temporary reduction or pause in feature delivery to truly resolve ⁴; hardly what management wants to hear when feature delivery is already lagging.

Being a responsible silo

None of the above diminishes the sense of personal satisfaction and pride I get out of total ownership of a project. I imagine readers who’ve experienced a similar level of ownership or engagement can relate to this. And, despite all the doom and gloom above, there are situations where being a silo is both personally rewarding and beneficial to a company. In my experience, this is mostly small startup companies. If they’re successful, they’ll grow out of the phase where having a single key person on a project makes sense, sometimes quite quickly. I can still have fun on the way there, though. Being responsible is, to me, keeping all of the points above in mind, and leaving at the right time & in the right way.

What to do

In the previous paragraph, I argue that responsible siloing is keeping the limited useful life of a silo in mind and acting accordingly. Some examples of specific behaviors that come from this:

• Documenting key technical things about my project. How to deploy it, how to pull it down and get it working on a new workstation, whether there’s a test environment and how to use it, etc. Periodically take a slow Friday to actually run through these and see if they work. If I’m the only person who has Heroku, AWS, GCP, etc credentials for my project, see if there’s someone I can store a hard backup copy of those with. I won’t get this perfect, but even a little effort can really help someone who’s coming in after me.
• If my project is mature enough to have a well thought out architecture ⁵, document that too. I might not ever meet future readers, so use a variety of ways to convey this information – diagrams, prose, etc – to meet them where they might be.
• If I use Slack, try to train people to use public channels to ask things about my project, even if I’m the only person in those channels from engineering. Try to avoid having substantial or important conversations solely in DMs.
• If I can, use a tool like PagerDuty as a layer of indirection between problem reports and my phone on evenings/weekends.
• Try to cultivate a trusting and honest relationship with my manager. This will hopefully feel like a safe environment to bring up concerns with my capacity/workload, and the need to bring on others to help.
• If I’ve gotten to the point where I’ve disengaged from the project and have a foot out the door, try to do right by the company. Have someone shadow me and see what I do on a daily basis, make sure others are onboarded onto the different aspects of my responsibilities, and create opportunities for others to do things that I’d ordinarily do. If there are tech debt fires, make an effort to either put them out or show how they might be put out. I won’t be perfect at this either, but by trying I’ll leave my company and team in a much better spot than otherwise.

What not to do

While there’s not necessarily a single right answer, there are plenty of wrong things to do. Some that I’ve seen (often reflecting on my own behavior in hindsight):

• Cling to the role, and all its initial responsibilities. This is selfish and quite often harmful to my employer. If I’ve taken pride in helping to build the company, I shouldn’t hurt it on my way out.
• Delegate away small, inconsequential parts of a work stream to others. For example, giving trivial engineering tasks to other developers, retaining all architectural, infrastructure, “interesting” work, etc for myself. This is essentially clinging to the role; others can’t learn much about the system if all I give them are crumbs.
• Delegate away a certain class of tasks, in a way that makes me a gatekeeper for most work. For example, writing low-level implementation tickets for other developers without also sharing the responsibility of breaking down larger features into those tickets. If I feel like I do have to do this in the short term due to the composition of my team, I should also strive to bring them to the level where they can share in those other tasks. If I don’t do this, the team still depends on me in some singular way.
• Feel threatened or competitive with other people start to emerge as leaders on the team.

Going against the tide to maintain what I had before isn’t going to help my long term job satisfaction or make me any more likely to stick around, and is going to make the company worse off.

Can I have a career as a silo?

If my only career interest is remaining gainfully employed, I don’t think I have anything to worry about. As mentioned, there are roles where silos make sense, and plenty of companies hiring for them. I hear from more recruiters now than at any point in the past, and I have a network of people I’ve worked with in the past I can lean on for these types of roles. That said, seeking out this type of role to the exclusion of others is limiting.

Aside from a few exceptions, expecting total ownership of a large product dramatically limits the size of the companies I can work for and the problems I can work on ⁶. I might get lucky with the next startup, but realistically I don’t expect to ever be the sole owner of anything much more complex or technically challenging than what I’ve already worked on in my career. Future jobs might let me learn a new domain, new tech stack, maybe even just work with a fresh group of people, but probably won’t help me grow much in terms of engineering skill or impact.

There’s also a compensation angle to this. Startups – for me, the most reliable source of this work – pay well enough to live comfortably, but significantly less than the FAANGs of the world. I tried a year in a company that was far smaller than a FAANG but big enough to have very little ownership and was bored to tears. There’s a pretty big part of me that wishes I wasn’t.

Another option, though harder to actually do, is the lifestyle business. Create a software product and sell it for a living. If successful, this can provide far better compensation than most startups will, and give a greater variety of work than working as a software engineer for someone else. Much easier said than done, though.

So, kind of mixed on this section. Will I have a job? Probably. Will I enjoy that job? Probably. Will there be a lot of novelty in terms of new/changing engineering responsibility if I just keep jumping from startup to startup? Likely not, or so it seems.

Finding fulfillment in a more traditional career path

For those who are willing to step away from code and embrace team dynamics, the path up is clearer. Hardly a sure thing, but I can at least see it. It lacks the visceral satisfaction of whole product ownership, and feels less natural to me. I’m trying to learn to enjoy that and find satisfaction in it. It’s harder to do than to write.

Acknowledging what I’m giving up

As I mentioned earlier, I’m a good coder. It wasn’t ever something I had to work hard at; it just clicked, from that first Java class in high school, in a way that very few things ever have for me. As someone who didn’t have a lot of self esteem boosts in high school, being immediately good at something that a huge number of people struggle with was a big win. I still get a mood boost from writing something elegant or fixing a quick bug. I’ve already given up a lot of this in my day to day going from senior to staff, and I’ll give up more as I move up the ladder. Frankly, that’s a really uncomfortable transition, and I’m not looking forward to giving up even more as time goes on.

My internal measurement of productivity is also pretty closely tied to ownership. I’m used to a fast pace, which I pretty much always have when I’m a silo. I may feel overworked sometimes, but I get lots of quick wins and affirmations that I’m doing well from that fast pace. A more specialized team often feels slower because requests are more evenly distributed. I have to remind myself that I’m not falling behind or being lazy if I’m not getting pestered with a bunch of different requests or urgent features throughout the day. As someone who really wants to excel at work, this can be a downer if I don’t catch it. ⁷

What I want to get in return

My current role is the first where I’ve spent significant amounts of time supporting other people with reviews, ticketed work, design discussions, etc. This turns out to be pretty satisfying in its way. I particularly enjoy working with less senior engineers, and watching them improve over time. It’s cool to think that I’ve played some small part in helping them grow.

Working and leading in a large organization, like mine, is also challenging. I don’t know that I’d call it fun, exactly, but it definitely takes a different set of skills to convince 20 or 30 or more people of something than a handful, and I’m thankful to have learned some of those. I do feel a sense of accomplishment when a presentation goes well, or when someone thanks me for explaining something clearly.

I’m also learning how to work with leadership in a different way than I’m used to. The purpose of some of the discussions is the same (how do we do this? when can we have it ready?), but the asks are often much less clear, much larger, and the discussions are farther removed from code and the people who’ve worked with it. Doing this well is something I still struggle with, but I have no doubt that it’s time well spent.

Another side effect of a larger company is the amount of technical complexity involved in projects. Projects themselves may be more ambitious in terms of company-level goals (because the company is better resourced and can do more), and even projects that look no more complex than those from a year or two ago may actually take a lot more to get done (due to the number of products that need to be changed, teams involved, reporting requirements, etc). I won’t be in the weeds actually doing the implementation, but I will get to see how these are broken down, the questions that are (or should have been) asked when scoping them, etc. I’ve learned a lot from watching this in the past on a smaller scale, and have no doubt that I’ll continue to learn by watching larger, more complex projects unfold.

There’s work life balance. Focusing on what I can provide to a team and not feeling compelled to take on more work than I otherwise need to do leaves me more time and mental space to build an identity outside of work. Ownership makes this very difficult. The work expands to fill whatever time I have, and the amount of my satisfaction and self-image tied up in that work makes it really hard to step away.

I want to advance beyond staff engineer – to principal and beyond. Aside from being interesting for their own sake, those skills and others like them will be essential for that advancement.

Ownership in small places

It’s also worth noting that it’s not an either/or distinction in a large company.

Much of my hands on work at my current employer is on forgotten/neglected quality of life projects. I “own” these, they produce value for the team and are satisfying to work on, they’re not so big that they distract from my official job, and they wouldn’t pose a risk to the business if I left and stopped maintaining them. My investing in staying with the company longer term helps me identify these projects, and buys me some indulgence from my management to work on them.

Aside from coding, there are always curveballs that come to even the most mature team. As someone who has taken on broad ownership of projects in the past, I can often help take care of these so the rest of the team can focus. I get some variety and excitement; the rest of the team avoids a distraction. This is easy to take to extremes (where I’m taking work away from a specialist who should really be doing it), but often enough it’s OK for me to take the task.

This will read like a consolation prize, and maybe it is a consolation prize. That said, I’m often surprised how far a little time spent on these projects or curveballs goes toward giving me the sense of ownership I miss.

Does it work?

I started this post wondering why I switch jobs every 3 years, and wondering whether I’d end up leaving my current job later this year, around the 3 year mark. Through much navel-gazing, I know the following:

• Working as a silo is a very comfortable and rewarding place for me. It’s where I’ve spent a lot of my career and I’m good at it.
• For various and sundry reasons, this isn’t a role that makes sense outside of a specific type of company.
• It’s also not a role that’s likely to give me much growth in engineering skill/effectiveness beyond where I already am.
• There is a happy path for engineering growth beyond where I am now, but it means stepping far outside my comfort zone.

I can keep doing this, and keep following a path that up until now has provided consistent rewards. Knowing myself and how I tend to get bored, I assume I’ll one day get bored of this. Whatever novelty I now see in performing the same organizational function at different companies seems doomed to wear off at some point. In that case, I may regret chasing personal gratification.

The final bullet point – stepping outside my comfort zone and onto that happy path for growth – is where I am now. I’ve been trying, in fits and starts, to convince myself to move onto the happy path in my current role (aided by supportive peers and management who help nudge me in this direction). I’ve had that opportunity in past roles; I think the main difference with my current role is that I’m actually giving it a chance.

Is it as immediately satisfying as being a do-it-all engineer? Well, frankly, no. I doubt I’ll ever be as comparably good at it as I am at coding; it certainly didn’t click immediately the way coding did. I think I can learn to be effective enough, though, and maybe with that effectiveness will come a deeper satisfaction. It’s a bet, anyway. The upside is career growth: more impact, the ability to function at a high level in a large organization, a bigger variety of jobs I’d enjoy and, last but not least, more compensation. The downside, if I hate it, is going back to what I’ve always done (hopefully with some new skills).

I realize I’m probably speaking to a small subset of readers, but I’m curious how others with silo instincts have approached this. Did you find some way to advance beyond senior/staff while keeping a significant level of technical control? Did you end up liking more traditional leadership more than you thought you would. Any regrets?