I hope this doesn't get buried, because there's something that I feel like I'm a bit of a unicorn about.
> The problem then with that is everyone who is working on those services is usually trying to get off of them. After all, no one wants to work on something that their boss doesn’t care about.
> Yes, your CI/CD system is absolutely critical, but it’s easy for executives to not think about. This leads to a failure mode where you have a lost garden of internal tools.
I love maintaining stuff. I don't care that my boss doesn't care about something. I care about... what I care about :)
I don't mind the "boring" tasks like keeping library versions up to date, being on the latest runtime version, and using a recent version of the framework we've adopted (we're currently running on an ancient version of it). I like doing that stuff. I like keeping things tidy. If things are up to date, I can move on to making our CI better, or improving our test coverage, or really anything that improves the whole team's productivity. There's always something to update or polish or improve.
My dilemma is that as much as I'm willing to do all that stuff, I'm essentially not allowed to. My lead and their boss say my skills are too valuable to be spent on that, so instead I must do things like lead the new team they're forming to build a new service... which I'm not interested in at all. I'm not keen on the whole lead thing. Glad to be a follower. I'm also not thrilled about building new stuff. I like to say I'm more like a car mechanic rather than an engineer: I like tweaking and tuning and fixing existing stuff, not creating new stuff.
Does anyone else feel like this? I've tried bringing it up in chats with coworkers and everyone looks at me like I have two heads.
I have also seen this from time to time. We have a few engineers in my org and another on my wife's team at another company that have interests similar to yours.
I think people with your interests are really valuable. We've changed around what we index on for performance evals/promotions and what work we assign them so that we can better accommodate these sorts of work preferences and skills. If someone is happier working on an essential but unsexy, unloved corner of your systems or infrastructure, and they're also many times more productive in that area than other engineers who have no interest in it, then you might as well take advantage of it!
The key factor is making sure that the work those people are doing is truly high impact (for example, CI improvement might reduce deployment failures, improve team deployment velocity) and not simply maintenance for sake of abstract cleanliness.
> We've changed around what we index on for performance evals/promotions and what work we assign them so that we can better accommodate these sorts of work preferences and skills.
It's really cool that you've that. And I'm glad to see I'm not alone in this.
Reframe what you do as "upgrading legacy infrastructure" or "applying modern best practices to existing products", etc, and it makes more sense. Usually people don't need to build new things, they need to fix their old things. But you have to sell it the right way and throw some numbers at them so they realize, hey, this is actually a better idea (financially and speed-wise). Can't fall victim to sunk cost fallacy or end up with a bad system if you're starting from a working one.
You could probably make a career out of being "the optimization guy". Product isn't working well? Ask the optimization guy to take a look before somebody spends a million bucks trying to replace it.
Consider that while you may care about maintaining something, whoever comes after you likely will not. Just like writing and documenting good code, solutions should last beyond a single engineer.
So yes, your skills are too valuable. All engineering skills are. That's the point of buy vs build.
If you truly feel you aren't being allowed to work on the the things you care about, it's possible you're simply in the wrong role or company.
I feel similarly. I find the most satisfaction in maintenance of an existing system, as opposed to greenfield development. Finding the optimal way to add new features inside an existing system is deeply satisfying. Improving tooling and infrastructure that leads to quality-of-life improvements across the team is very fulfilling.
This is very much how I feel, which is why I've started a dedicated team for this at Wealthfront, with the support of our CTO, our VP of engineering, and our president (who used to be the CTO). My team is specific to the backend but we have equivalent "infrastructure" teams for the frontend platforms too.
If anyone feels like it's hard to get your company to care about this stuff or even let you work on it, maybe it's time to consider a move? :-) You can reach me at andyf@wealthfront.com if you prefer not to reply here.
I more or less feel that way - I don’t have a lot of interest in churning out yet another feature in the never ending treadmill of feature development.
I agree that you need to shop around; some places value this far more than others. But I don't think the company needs to be huge. We have small but dedicated teams for this on each platform (backend, iOS, Android, web) and we only have ~100 total engineers.
> The problem then with that is everyone who is working on those services is usually trying to get off of them. After all, no one wants to work on something that their boss doesn’t care about.
> Yes, your CI/CD system is absolutely critical, but it’s easy for executives to not think about. This leads to a failure mode where you have a lost garden of internal tools.
I love maintaining stuff. I don't care that my boss doesn't care about something. I care about... what I care about :)
I don't mind the "boring" tasks like keeping library versions up to date, being on the latest runtime version, and using a recent version of the framework we've adopted (we're currently running on an ancient version of it). I like doing that stuff. I like keeping things tidy. If things are up to date, I can move on to making our CI better, or improving our test coverage, or really anything that improves the whole team's productivity. There's always something to update or polish or improve.
My dilemma is that as much as I'm willing to do all that stuff, I'm essentially not allowed to. My lead and their boss say my skills are too valuable to be spent on that, so instead I must do things like lead the new team they're forming to build a new service... which I'm not interested in at all. I'm not keen on the whole lead thing. Glad to be a follower. I'm also not thrilled about building new stuff. I like to say I'm more like a car mechanic rather than an engineer: I like tweaking and tuning and fixing existing stuff, not creating new stuff.
Does anyone else feel like this? I've tried bringing it up in chats with coworkers and everyone looks at me like I have two heads.