The other kind of staff software engineer(earthly.dev)
earthly.dev
The other kind of staff software engineer
https://earthly.dev/blog/line-staff/
200 comments
I am a Staff software engineer in a consumer goods company. I got quickly promoted to it manger , head of it and then CIO. The tech is shallow but it exposes me to production, supply chain , sales , finance and pretty much every aspect of the operations. I report directly to CEO. We typically buy erp but small softwares , I choose to write myself so that I got some practice on coding. I go to home before 6 and enjoy my weekends
I think it's an interesting distinction, line vs staff, but I don't think it encapsulates the role of a dev at non-tech companies like myself. Certainly what I do is mission-critical on a 24/7/365 basis, and yet, I'm not working for "Thoughtworks" or a company that sells my expertise as a product. But nor am I "support staff" in the sense that a minor malfunction could go under the radar; in fact it could destroy a revenue stream if I slept on a bug.
The thing is that every non-tech company is now in some sense in the tech industry, whether they mean to be or not; a large part of their business is done online. As opposed to companies that specialize in building tech for other companies, many of them have nickel-and-dimed their way into their own hardware/software infrastructure and the maintenance of that has become crucial to their normal operations, to the point where instead of business logic dictating changes to it, it frequently dictates changes to their business logic. That puts independent devs for those companies in a kind of catbird seat to determine which stacks and which infrastructure are going to drive the next round of growth. Some people (like my friend who's a salesman for Salesforce) call this "technical debt", but really it's bootstrapping and the better and cheaper you can do it through indy devs, the better your bottom line.
So it's quite different than the normal software world, but it's neither what you're calling a staff position nor is it actually a line position.
The thing is that every non-tech company is now in some sense in the tech industry, whether they mean to be or not; a large part of their business is done online. As opposed to companies that specialize in building tech for other companies, many of them have nickel-and-dimed their way into their own hardware/software infrastructure and the maintenance of that has become crucial to their normal operations, to the point where instead of business logic dictating changes to it, it frequently dictates changes to their business logic. That puts independent devs for those companies in a kind of catbird seat to determine which stacks and which infrastructure are going to drive the next round of growth. Some people (like my friend who's a salesman for Salesforce) call this "technical debt", but really it's bootstrapping and the better and cheaper you can do it through indy devs, the better your bottom line.
So it's quite different than the normal software world, but it's neither what you're calling a staff position nor is it actually a line position.
> in fact it could destroy a revenue stream if I slept on a bug.
There are plenty of staff positions where incompetence could be very damaging or deadly to the business. E.g. in-house lawyers or accountants, even HR in some circumstances (failing to act in the presence of a hostile work environment). That doesn't mean it's not a staff position.
There are plenty of staff positions where incompetence could be very damaging or deadly to the business. E.g. in-house lawyers or accountants, even HR in some circumstances (failing to act in the presence of a hostile work environment). That doesn't mean it's not a staff position.
It sounds like you are conflating “support staff” with “inconsequential” or low-value work. That is definitely not what the author says.
By the definitions of the article, the head of engineering at a tech company, or even the CEO, are considered support staff. Their success and failures will 100% map to the success and failures of the company.
By the definitions of the article, the head of engineering at a tech company, or even the CEO, are considered support staff. Their success and failures will 100% map to the success and failures of the company.
The author isn't saying it, but business schools are.
The business school mantra is invest in profit centers, nickel-and-dime cost centers. If you are so unfortunate as to be at a company run by an MBA and are in a cost center, woe to you.
The business school mantra is invest in profit centers, nickel-and-dime cost centers. If you are so unfortunate as to be at a company run by an MBA and are in a cost center, woe to you.
This is what happens to Motorola IT.
Some wise exec had the vision to outsource it to an external company and then Motorola (that was already on the path to its death) realized how much was done outside of the process (which is typical for such companies, fortunately or not).
Suddenly your threat of whatever happening if your thing is not fine had exactly zero value against "raise a ticket". Everything crawled to a stop because of that and "golden tickets" were used.
This is one true example of why you should think 20 times before outsourcing something you do not understand.
Some wise exec had the vision to outsource it to an external company and then Motorola (that was already on the path to its death) realized how much was done outside of the process (which is typical for such companies, fortunately or not).
Suddenly your threat of whatever happening if your thing is not fine had exactly zero value against "raise a ticket". Everything crawled to a stop because of that and "golden tickets" were used.
This is one true example of why you should think 20 times before outsourcing something you do not understand.
The author called out that profit centers and cost centers are similar, but different, to the staff vs line distinction being made.
Why equate them as the same here?
Why equate them as the same here?
Because a significant number of managers seem to fall into the same trap, and it only takes one such manager in the chain above you for it to be painful.
> They are the dark matter of software developers.
That reminds me of an article that was linked from here, a couple of years ago, titled “IT Runs On Java 8”[0].
I worked for hardware manufacturers, for most of my career, and can report that it’s even worse.
That’s because the company does have an engineering culture, but one with drastically different priorities and processes.
Our software shops were expected to run in hardware patterns.
[0] https://vickiboykis.com/2019/05/10/it-runs-on-java-8/
That reminds me of an article that was linked from here, a couple of years ago, titled “IT Runs On Java 8”[0].
I worked for hardware manufacturers, for most of my career, and can report that it’s even worse.
That’s because the company does have an engineering culture, but one with drastically different priorities and processes.
Our software shops were expected to run in hardware patterns.
[0] https://vickiboykis.com/2019/05/10/it-runs-on-java-8/
The 'line' vs 'staff' distinction makes a ton of sense to me. I've been reading Will Larson's blog about staff engineers and trying to articulate what sets staff engineers apart, and I think you've nailed it. "Staff" more or less equals "support", but on an executive or strategic level.
A problem I deal with personally is growing into "Staff" style work. I'd love to have bigger, wider impacts on a more strategic level, but I'm so damn good at getting into line work and doing a good job of it. (I also understand myself well enough to know that I like stabbing away at a technical problem way more than I like a VP or C-level planning meeting.) I also feel like I've gotten so good at doing "line" style work that there doesn't seem to be org pressure to promote me. My perception is that I'm considered too good on the "line"; I'd be a loss to the org to move up a notch. This could also mean that I'm actually not as good as I think I am, or can't see the forest for the trees. It could also be a sign of what a brutal struggle promotion is for "line" style workers. (More competition, less routes up the ladder.)
Is there a path to grow there, or am I just doomed to be a Principal Engineer? (Not the worst fate, "doomed" is probably too strong a word there lol)
A problem I deal with personally is growing into "Staff" style work. I'd love to have bigger, wider impacts on a more strategic level, but I'm so damn good at getting into line work and doing a good job of it. (I also understand myself well enough to know that I like stabbing away at a technical problem way more than I like a VP or C-level planning meeting.) I also feel like I've gotten so good at doing "line" style work that there doesn't seem to be org pressure to promote me. My perception is that I'm considered too good on the "line"; I'd be a loss to the org to move up a notch. This could also mean that I'm actually not as good as I think I am, or can't see the forest for the trees. It could also be a sign of what a brutal struggle promotion is for "line" style workers. (More competition, less routes up the ladder.)
Is there a path to grow there, or am I just doomed to be a Principal Engineer? (Not the worst fate, "doomed" is probably too strong a word there lol)
I don’t think I’d try to mix those things together. Same word, completely different things.
In this article, a new grad who works on basic HR IT tasks for a factory is doing staff work. That’s not staff level scope in the Will Larson sense.
There are plenty of “staff software engineers” in the Will Larson sense who create strategy for new product lines and launch them - “line” level work. Also plenty who work on DevX - “staff” level work.
In this article, a new grad who works on basic HR IT tasks for a factory is doing staff work. That’s not staff level scope in the Will Larson sense.
There are plenty of “staff software engineers” in the Will Larson sense who create strategy for new product lines and launch them - “line” level work. Also plenty who work on DevX - “staff” level work.
I think we'll have to agree to disagree. My takeaway from much of Larson's writing is that staff engineers can do the line work required to launch new product lines, but generally don't, because the impacts of their strategic work is much higher than that of line style coding.
They direct and advise on technical strategy, but delegate execution to others, because having the 10k foot view is typically more valuable when deployed on strategic opportunities.
They direct and advise on technical strategy, but delegate execution to others, because having the 10k foot view is typically more valuable when deployed on strategic opportunities.
I think you're missing what the above is saying, i.e. that the featured article uses staff in a different way than Larson and most discussions around "staff".
Will and this article use "staff" in a completely different sense. The author of the post even acknowledges this difference in his HN comment at the top of this post.
Will uses "Staff Software Engineer" as the rank of Staff (I.e. one above Senior).
This article uses "staff engineer" not as the rank, but as the type of engineer (Line vs staff).
Will uses "Staff Software Engineer" as the rank of Staff (I.e. one above Senior).
This article uses "staff engineer" not as the rank, but as the type of engineer (Line vs staff).
"Line vs staff" is a fundamentally bankrupt concept, as much so as "combat vs logistics". Wars are won or lost on logistics, as Russia recently discovered.
Money wasted in a "profit center" has exactly the effect on bottom line as the same waste in a "cost center", and failure of a "cost center" can have just as large an effect on your business as in a "profit center". The only meaningful distinction is that the return on investment in a "cost center" is gated by the success of "profit centers".
But, woe betide if you find yourself in a cost center at a company run by MBAs. Get yourself to a profit center, or to a better-run, less MBA-saddled company.
Money wasted in a "profit center" has exactly the effect on bottom line as the same waste in a "cost center", and failure of a "cost center" can have just as large an effect on your business as in a "profit center". The only meaningful distinction is that the return on investment in a "cost center" is gated by the success of "profit centers".
But, woe betide if you find yourself in a cost center at a company run by MBAs. Get yourself to a profit center, or to a better-run, less MBA-saddled company.
as much so as "combat vs logistics".
First time I've ever heard these two things talked about as a matter of "this versus that" and not "combat and logistics".
I'd hate to be a CO or NCO under a General who looked at the two as somehow adversarial or mutually exclusive in terms of planning and resourcing.
Yours is quite an interesting analogy, here.
First time I've ever heard these two things talked about as a matter of "this versus that" and not "combat and logistics".
I'd hate to be a CO or NCO under a General who looked at the two as somehow adversarial or mutually exclusive in terms of planning and resourcing.
Yours is quite an interesting analogy, here.
You’re used to reading about western militaries.
Look at the Ukraine War… Russia clearly completely ignored logistics and failed in their attempt at a “modern” war and quickly degraded to a WW1 style artillery duel.
And yes, being a NCO or field officer in the Russian army is miserable.
Look at the Ukraine War… Russia clearly completely ignored logistics and failed in their attempt at a “modern” war and quickly degraded to a WW1 style artillery duel.
And yes, being a NCO or field officer in the Russian army is miserable.
> First time I've ever heard these two things talked about as a matter of "this versus that" and not "combat and logistics".
Not sure if you’re being sarcastic? Or haven’t read much about the military and are assuming?
Combat vs combat support vs combat service support (logistics) is a very common and very significant distinction to make and usually matters a lot for a great many things.
Has a logistics branch officer ever led a major Army? We had an artillery officer in the UK and even that was a talking point at the time.
Not sure if you’re being sarcastic? Or haven’t read much about the military and are assuming?
Combat vs combat support vs combat service support (logistics) is a very common and very significant distinction to make and usually matters a lot for a great many things.
Has a logistics branch officer ever led a major Army? We had an artillery officer in the UK and even that was a talking point at the time.
> A problem I deal with personally is growing into "Staff" style work.
My problem is that you seemingly get locked into it. The only people who want to talk to me are staff positions, the “line” roles do not want me at all. Technically my current role is at a tech company, but in a “staff-like” position and happens to be one of the least recognized teams invoice department because the work is among the least visible and a very tiny percentage of the companies income.
My problem is that you seemingly get locked into it. The only people who want to talk to me are staff positions, the “line” roles do not want me at all. Technically my current role is at a tech company, but in a “staff-like” position and happens to be one of the least recognized teams invoice department because the work is among the least visible and a very tiny percentage of the companies income.
"destined" may be a better word than "doomed" in this case :)
I have a similar feeling, I like doing low level work but I also mentoring junior engineers, hopefully that mentoring will multiply my overall output over time!
I have a similar feeling, I like doing low level work but I also mentoring junior engineers, hopefully that mentoring will multiply my overall output over time!
Hah, yeah, mental note to reframe as "destined".
I also really like the mentorship angle. It's really cool to watch someone grow, and how fast they do when given stuff that's just outside their current capability level.
I also really like the mentorship angle. It's really cool to watch someone grow, and how fast they do when given stuff that's just outside their current capability level.
I look for folks with this background to join my team at my Day Job. I need folks with a solid hands-on technical background who want to stop building things and start telling me which people SHOULD build and which people ARE building those things so I can give those people money.
It’s tricky because I need hands on experience but the desire to switch to a more strategic, executive-style role. Plus folks need to have the core communication and people skills to manage a complex set of stakeholders.
Hard to find good people, but the people I find tend to be very very good.
It’s tricky because I need hands on experience but the desire to switch to a more strategic, executive-style role. Plus folks need to have the core communication and people skills to manage a complex set of stakeholders.
Hard to find good people, but the people I find tend to be very very good.
> My perception is that I'm considered too good on the "line"; I'd be a loss to the org to move up a notch.
At a previous company, they moved a lot of their top performer “line” engineers to staff level and they all felt unproductive and eventually quit.
At a previous company, they moved a lot of their top performer “line” engineers to staff level and they all felt unproductive and eventually quit.
This is a fairly well known issue Peter Principle (https://en.wikipedia.org/wiki/Peter_principle)
> The Peter principle is a concept in management developed by Laurence J. Peter, which observes that people in a hierarchy tend to rise to "a level of respective incompetence": employees are promoted based on their success in previous jobs until they reach a level at which they are no longer competent, as skills in one job do not necessarily translate to another.[
> The Peter principle is a concept in management developed by Laurence J. Peter, which observes that people in a hierarchy tend to rise to "a level of respective incompetence": employees are promoted based on their success in previous jobs until they reach a level at which they are no longer competent, as skills in one job do not necessarily translate to another.[
Yeah sure but the point being these people never wanted this role and not only t company lost them as productive ICs to some other role but they lost them altogether (great engineers with deep domain expertise)
Yep. I've see this happen. People who are good at coding may actually want to code, not write "tech specs" and have review meetings all day.
Two thing. One, I always hated the cost center vs profit center distinction. These are accounting terms. It's super common in places that have embedded software (auto industry is close to me) where any manufacturing plant is considered a profit center, and engineering is often a cost center. When things are tight they tend want to reduce "costs" not realizing that engineering can also be seen as an investment in the companies future.
Second, as we move to more open source for infrastructure software (the tools used by staff) the above becomes more clear. SAP is charging for something with zero marginal cost, therefore it's perfectly valid to say they are renting software and hopefully using the money to develop the next version.
As the world moves to more open source I think you'll see fewer line software people, as the staff will do both support of the business and push some changes upstream (equivalent to what the line guys at sofware companies do). Once software is mature the rent model is really obsolete, but maintenance still has to be done by someone.
Second, as we move to more open source for infrastructure software (the tools used by staff) the above becomes more clear. SAP is charging for something with zero marginal cost, therefore it's perfectly valid to say they are renting software and hopefully using the money to develop the next version.
As the world moves to more open source I think you'll see fewer line software people, as the staff will do both support of the business and push some changes upstream (equivalent to what the line guys at sofware companies do). Once software is mature the rent model is really obsolete, but maintenance still has to be done by someone.
> engineering can also be seen as an investment in the companies future.
In fact, when things are tight is the very moment you should go all in for R&D.
Let's clear up something simple people forget: when things are tight for you, they are normally also tight for your customers. In fact, that's generally how they become tight for you.
So you can forget investing in production and sales when things are tight. Things are tight because the world is in a period where your customers aren't buying. You won't change that by trying to sell harder.
However, small research projects are an incredibly cheap way to learn things and invent new technologies. When you're not encumbered by turning things into products, you can discover at a frightening speed. So you spend on research when the times are tough, and then when things go better you have a huge backlog of technologies you can apply right away.
In fact, when things are tight is the very moment you should go all in for R&D.
Let's clear up something simple people forget: when things are tight for you, they are normally also tight for your customers. In fact, that's generally how they become tight for you.
So you can forget investing in production and sales when things are tight. Things are tight because the world is in a period where your customers aren't buying. You won't change that by trying to sell harder.
However, small research projects are an incredibly cheap way to learn things and invent new technologies. When you're not encumbered by turning things into products, you can discover at a frightening speed. So you spend on research when the times are tough, and then when things go better you have a huge backlog of technologies you can apply right away.
> However, small research projects are an incredibly cheap way to learn things and invent new technologies
And recessions are the time when this research is at its cheapest.
And recessions are the time when this research is at its cheapest.
Saw this in interview at an RV company. Their market tanked in 2008 and the invested in engineering projects. Bought competitors after the recovery by selling newer better product.
“ I always hated the cost center vs profit center distinction.” You may hate it but ignore it at your peril. It’s how the company sees you.
I think the issue with it is that finance get to dictate how a company's strategy goes, which may not work well in any industry that's hard to understand (e.g. tech).
> I always hated the cost center vs profit center distinction. These are accounting terms.
But that's how it's meant when people use it like that. They mean they want to do the work somewhere where it's (considered by the accounting department) a profit centre; not cost. That doesn't mean it could be another way for that company or that nobody should work there, much the same way as OP isn't saying nobody staff vs. line is right vs. wrong nor vice versa.
But that's how it's meant when people use it like that. They mean they want to do the work somewhere where it's (considered by the accounting department) a profit centre; not cost. That doesn't mean it could be another way for that company or that nobody should work there, much the same way as OP isn't saying nobody staff vs. line is right vs. wrong nor vice versa.
It's crossed my mind in the past that there are companies where often devs run things and companies where devs are just support for the real business. I don't think I ever want to work at a company where devs do not run things only because my spoiled experience has entirely been at companies where they do and I selfishly don't want to just be support staff for the real business.
You might disagree with these examples but:
A stock trading company, IT stuff are support for the real employees, the traders. You have a trader, you have a trading company. The programmers are just support for them.
Animated Movies (even pixar). Sure, there are important software devs but the real staff at pixar are animators. They can ship animations with off the shelf software or paper and pencil. In house software devs are super important but at the end of the day if all they had was animators they could still ship animation.
Lawyer firms, Medical Facilities: Yea, they need IT staff to help run things but they can function with just lawyers or just doctors.
VS say Apple, Google, Facebook, Microsoft. No devs, no company.
Video Game companies used to be and probably mostly still are this way. No software devs no product ships. That might be fraying as tools get better.
You might disagree with these examples but:
A stock trading company, IT stuff are support for the real employees, the traders. You have a trader, you have a trading company. The programmers are just support for them.
Animated Movies (even pixar). Sure, there are important software devs but the real staff at pixar are animators. They can ship animations with off the shelf software or paper and pencil. In house software devs are super important but at the end of the day if all they had was animators they could still ship animation.
Lawyer firms, Medical Facilities: Yea, they need IT staff to help run things but they can function with just lawyers or just doctors.
VS say Apple, Google, Facebook, Microsoft. No devs, no company.
Video Game companies used to be and probably mostly still are this way. No software devs no product ships. That might be fraying as tools get better.
Since you mention videogames. I used to work at EA and one thing I found was that the company culture was not as developer oriented as you might expect. Obviously, they invested a lot in developers, artists, and other content producers.
But the overal company culture and the upper echelons of leadership very strongly reflected EA's history as a software publishing company founded by business folks, and not a group of game makers who set out to build their own company. It was very much about producers, money, marketing, etc.
I used to joke that EA was in the business of selling disks and that the games on them were merely an annoying chore that they were obliged to do in order to get people to buy them. It often felt like they considered the entire dev team to be a cost center.
But the overal company culture and the upper echelons of leadership very strongly reflected EA's history as a software publishing company founded by business folks, and not a group of game makers who set out to build their own company. It was very much about producers, money, marketing, etc.
I used to joke that EA was in the business of selling disks and that the games on them were merely an annoying chore that they were obliged to do in order to get people to buy them. It often felt like they considered the entire dev team to be a cost center.
Ex-gamedev and this totally rings true.
We had one title I worked on where the "interviews with the dev team" was all just interviews with the external producers(aka PM who came in from the publisher to keep everything "on track").
Never happened to us but the best one I heard was that the publisher puts a clause in your contract that they get the source+IP if you go bankrupt(protect their investments, their taking huge risk, etc....). However about 2/3 through development when the studio is at peak HC burn they would start denying milestones for trivial things. One, two milestones go by and the studio burns through all cash, folds and publisher gets source+IP. Publisher then hires the dev team, who just lost their jobs, at a reduced rate(most gamedev a don't have great savings...) to finish out the game, avoids paying any royalties and picks up the IP.
Happy to be out of that industry, some really interesting technical challenges and driven people but the whole thing is similar to the recording industry in the way they exploit people and passions for their own gain.
We had one title I worked on where the "interviews with the dev team" was all just interviews with the external producers(aka PM who came in from the publisher to keep everything "on track").
Never happened to us but the best one I heard was that the publisher puts a clause in your contract that they get the source+IP if you go bankrupt(protect their investments, their taking huge risk, etc....). However about 2/3 through development when the studio is at peak HC burn they would start denying milestones for trivial things. One, two milestones go by and the studio burns through all cash, folds and publisher gets source+IP. Publisher then hires the dev team, who just lost their jobs, at a reduced rate(most gamedev a don't have great savings...) to finish out the game, avoids paying any royalties and picks up the IP.
Happy to be out of that industry, some really interesting technical challenges and driven people but the whole thing is similar to the recording industry in the way they exploit people and passions for their own gain.
Fully agreed with your overall position, but I got a small correction in regards to what you said about fintech.
While you are correct in that at a lot of finance companies, devs just act as "support for the real business" (e.g., Goldman Sachs). But there are others where devs and quants pretty much harmoniously run the show.
Look at something like Jane Street and their tech blog[0]. Their annual "what our interns have wrought" blog posts grab my attention like nothing else, and from everything I read coming from them, it seems like engineering there is not just "support for the real business". And there are quite a few companies in fintech like this, they just won't be flashed in the mass media due to their relatively small size, but everyone in the industry (and plenty of people on the outside) knows about them. Out of all things, they are known as one of the largest contributors to OCaml language and its ecosystem.
Jane Street was just a singular example, and there are other fintech firms of a similar engineering-focused culture.
0. https://blog.janestreet.com/
While you are correct in that at a lot of finance companies, devs just act as "support for the real business" (e.g., Goldman Sachs). But there are others where devs and quants pretty much harmoniously run the show.
Look at something like Jane Street and their tech blog[0]. Their annual "what our interns have wrought" blog posts grab my attention like nothing else, and from everything I read coming from them, it seems like engineering there is not just "support for the real business". And there are quite a few companies in fintech like this, they just won't be flashed in the mass media due to their relatively small size, but everyone in the industry (and plenty of people on the outside) knows about them. Out of all things, they are known as one of the largest contributors to OCaml language and its ecosystem.
Jane Street was just a singular example, and there are other fintech firms of a similar engineering-focused culture.
0. https://blog.janestreet.com/
> but I got a small correction in regards to what you said about fintech.
Market makers like Jane Street are not fintech. They are trading companies.
Jane Street in particular is still very much gut-feeling point-and-click trading, compared to Jump and Citadel Securities.
Fintech companies are more related to payments: Stripe, Gusto, Plaid, etc.
Another difference is pay/TC: trading companies pay significantly more than fintech and MAANG, even for SWEs.
Market makers like Jane Street are not fintech. They are trading companies.
Jane Street in particular is still very much gut-feeling point-and-click trading, compared to Jump and Citadel Securities.
Fintech companies are more related to payments: Stripe, Gusto, Plaid, etc.
Another difference is pay/TC: trading companies pay significantly more than fintech and MAANG, even for SWEs.
A stock trading company, IT stuff are support for the real employees, the traders. You have a trader, you have a trading company. The programmers are just support for them.
Not the norm, but I suspect it probably happens more than it should...but this is the sensation I'm feeling about "Devops engineers" in the last few years. Which, yeah, we could sit here and talk all day about whether or not "Devops engineers" should be a job title at all, because Devops is a "way of working" or whatever but that's kinda the self-fulfilling problem isn't it?
Devops was supposed to be a way of working and somehow it got turned into "Help Desk for the App Developers" in way too many environments and orgs, where too many great Developers with Operational capabilities end up being on the receiving end of "the devs are working on feature x, we need someone to do this, and we failed to really figure out our engineering resourcing needs, so uh, I dunno give it to the Devops team to deal with".
Not the norm, but I suspect it probably happens more than it should...but this is the sensation I'm feeling about "Devops engineers" in the last few years. Which, yeah, we could sit here and talk all day about whether or not "Devops engineers" should be a job title at all, because Devops is a "way of working" or whatever but that's kinda the self-fulfilling problem isn't it?
Devops was supposed to be a way of working and somehow it got turned into "Help Desk for the App Developers" in way too many environments and orgs, where too many great Developers with Operational capabilities end up being on the receiving end of "the devs are working on feature x, we need someone to do this, and we failed to really figure out our engineering resourcing needs, so uh, I dunno give it to the Devops team to deal with".
Feels like the opposite to me. A lot of ops teams got turned into ‘devops’ teams overnight without any change in mode of operations, leading to skewed expectations from developers that actually know what the ‘dev’ part is about.
At least, I was fairly surprised by how our devops team looked at what I was trying to push onto them until I learned their origin story.
At least, I was fairly surprised by how our devops team looked at what I was trying to push onto them until I learned their origin story.
Chesterton's fence is a real bitch, ain't it?
I work at a non-tech company. I mostly write/maintain unexciting components for a website's CMS, and any tertiary work around that. Easygoing, remote, great work/life balance, good pay. Often go fishing or work on projects like an ebike for a lot of the day, sporadically checking the work chat and tuning into meetings from my phone. On the rare occasion something really important comes up I'm always ready to jump in and give 100%. Established a good reputation and get great performance reviews for what I do. I'd probably never trade this for a job at Google et al with higher expectations and stress.
My partner and I both have similar roles to yours, in non-tech companies. Sometimes we both feel like we’re not being ambitious enough… but we walk into town for two-hour lunches together 2-3 times per week, finish household errands on weekdays, and never have to worry about money. The initial transition from “working hard” to “hardly working” was difficult to settle into, but imo as long as we can keep up our skills with all this extra time, it’s a very enjoyable lifestyle.
I've got the same type of deal here. I just worry about skills getting outdated since I'm only working on an in-house system and doing mostly maintenance. But perhaps that fear is overblown.
I could easily hop to a gig with more responsibility and more opportunity for increasing my skills - but also more stress.
I could easily hop to a gig with more responsibility and more opportunity for increasing my skills - but also more stress.
I feel like you'll never be out of a job long with a good work history, good references, and knowing your way around overall web development. Might not be enough for Facebook but it seems like enough for us.
What type and size company do you work for? And how did you find it?
That sounds like a pretty ideal scenario to me, but I'm not sure how to go about finding similar positions.
That sounds like a pretty ideal scenario to me, but I'm not sure how to go about finding similar positions.
I don't want to make myself too identifiable, but it's a fairly big place and I lucked into it more than anything. Can't give any specific advice how to find a similar job besides looking for remote listings at non tech places.
I had not heard the "Staff" designation before Google popularized it. I believe in early 2000s, the popular job prefixes were "Senior" and "Principal". The "Staff" prefix always confused me and gave me a feeling that if layoff ever came "Staff" will be protected while everyone else was expendable. I don't think Google adopted this prefix in the sense it was popular in militery.
It's been common in academics forever. A 'staff researcher' is someone who is typically affiliated with an 'organized research unit' which is basically a facility that a lot of 'principal investigators' utilize, and which are likely funded by overhead on the PIs individual grants, or via bulk grants. Benefits are not having to sit around writing grant proposals all day, but they're basically never first or last authors on papers, so it's not a route to becoming a department chair or famous academic etc. Can be more interesting as you get to work with multiple research projects, although if the PIs in the department are the petty tyrant types with inflated egos (more common than not) it can be ridiculously political (who gets time on the big machine etc.). Typically called 'supertechs' by PIs, i.e. 'not real scientists'. Training grad students in techniques is often part of the job, too.
the incentive structure is reversed in academia. staff are closer to adjuncts than full-time faculty positions in compensation and benefits
More confusingly, at my first (tech industry) jobs the progression was Jr -> no modifier -> Staff -> Senior -> Principal, "Staff" being the first level you could start coasting at, "Senior" being the end for most people who kept developing their skills, and "Principal" for extremely autonomous / R&D roles / "Leads" with no actual teams. In this case, "layoff protection" was exactly what the staff level was for; you were also expected to hit it in 3-5 years.
Now it seems to be Jr / n/a / Senior / sort of equal footing for Staff/Principal depending on whether you're a generalist or specialist? And Staff might also be Lead but also not? I've read Larson's stuff and I'm still not sure the moniker is useful in a way "Senior" wasn't, except to the degree other titles have inflated. (I've seen three resumes in the past week for "senior" applicants with 2y experience or less restricted to a single stack.)
Now it seems to be Jr / n/a / Senior / sort of equal footing for Staff/Principal depending on whether you're a generalist or specialist? And Staff might also be Lead but also not? I've read Larson's stuff and I'm still not sure the moniker is useful in a way "Senior" wasn't, except to the degree other titles have inflated. (I've seen three resumes in the past week for "senior" applicants with 2y experience or less restricted to a single stack.)
In my experience I think of Senior as an autonomous builder of a thing that they are told to build. Staff is the same but may work across multiple teams and help define the thing that needs building. They will usually have considerably broad experience. They get thrown at random problems nobody is sure how to fix. Principals extend that concept but may be industry leaders in a field or at least deeply specialised.
In our company the prefix Staff was adopted when the CTO team got tired of creating (mostly fake) managerial positions for good software developers who have reached the maximum salary allowed by the CFO team for a “Senior” software engineer.
Most NYC finance firms did this. You will find lot of AVPs (Assistant Vice President) who are mere software developers getting paid more than $125k base (during early 2000s). It was fun to suddenly have “Vice President” in your title.
Google got it from industry research labs, the industry research labs got it from the national labs, who got it from the military.
The term staff scientist existed before google (eg at National labs) and it probably was derived from that.
Reminds me of C Sharp developers until I joined a purely MS stack using company. Also a silent majority in my opinion.
I saw a post on r/ProgrammerHumor a while back saying something along the lines of "why does no one make jokes about C# here" and the replies were all the same - there's nothing particularly funny, and all the users are quietly plugging away at their corporate jobs. Made me chuckle.
Yeah. It's not a language you come across a lot ouside of corp work,
it largely avoided the absurdity of AbtractFactoryFactory and similarly overdesigned architecture that is a common focus of Java jokes, and it did not suffer from language stagnation for enough years to make the alternate languages for the VM feel like actually competition, as opposed to things that are mostly useful in certain specialist scenarios.
It’s popular in games now because of Unity and il2cpp. Even though it started as a Java ripoff, it’s infinitely better because it has value types.
But my impression using it in school was the standard library was even worse than Java. Where Java buries things under six namespaces of reverse domain name, C# buries them under what looks like random technical terms chosen to impress people.
ie there is no reason for System.Console.WriteLine() or System.Collections.ArrayList to be where they are. It doesn’t make your program work better.
But my impression using it in school was the standard library was even worse than Java. Where Java buries things under six namespaces of reverse domain name, C# buries them under what looks like random technical terms chosen to impress people.
ie there is no reason for System.Console.WriteLine() or System.Collections.ArrayList to be where they are. It doesn’t make your program work better.
Really nice article. Well done.
[deleted]
For me the more useful distinction has been: how close are you to the customer? If you never interact with them, not even indirectly through a team manager directly interacting with them, you're probably working more in a "staff" role under this categorization regardless of who is actually using the thing you're building. Admittedly this has problems -- you have to figure out who the customer is, for one, but it's legitimate for them to be either internal or external, paying or not. And for many companies (perhaps especially "tech companies" and tech startups) it often ends up being both via dogfeeding. I think the presence/absence of the customer in short feedback loops alongside those actually making and maintaining things dominates the distinction of whether it's staff or line. Focusing this way does help avoid the sometimes difficult distinctions of what makes a company tech or non-tech and how reasonable people can disagree over some particular example, whether what you're doing is really important to the company's overall success, or whether something is a profit center or cost center (I find it more useful to think first about whether an individual employee is an Asset/Profit or Cost, and note that being a cost isn't necessarily bad but also types can change over time).
Still, even customer proximity is not always a useful distinction, and certainly doesn't have to be a static one. I wonder if this industry resists distinctions among people or groups like these due to something at the root of the hacker culture that created it, like a realization/commitment to the idea that the only really worthwhile distinction is the bit.
I'm not sure I buy the dark matter idea. In the US there are only on the order of a few million software developers, you don't have to go very far down a list of FAANG/FAANG-like high paying tech companies to reach on the order of a few hundred thousand US-employed programmers at those firms (~10% of the market, already exceeding ordinary matter's 5% of the universe). Decide on a consistent definition of tech company in general and add in all of the programmers from them and it wouldn't surprise me at all if tech company employees actually exceeded non-tech, though I can see it being the other way too, just not being "vast majority".
As for stories from roles at non-tech places, most are probably told orally (especially to fellow employees at larger companies as cautionary tales of the crazy messes out there that make their own current insanity look pretty sane) but also remember that at any given time like half of the professional market has been in it for less than 5 years (how many of them got into tech-company vs non-tech-company roles?). And remember you may have read stories from them but not realized it because the actual work regardless of line/staff or tech/non-tech company distinction itself for programmers can be so similar, so it's not always clear whether some story on e.g. The Daily WTF is from which (though sometimes it is or you can guess).
Still, even customer proximity is not always a useful distinction, and certainly doesn't have to be a static one. I wonder if this industry resists distinctions among people or groups like these due to something at the root of the hacker culture that created it, like a realization/commitment to the idea that the only really worthwhile distinction is the bit.
I'm not sure I buy the dark matter idea. In the US there are only on the order of a few million software developers, you don't have to go very far down a list of FAANG/FAANG-like high paying tech companies to reach on the order of a few hundred thousand US-employed programmers at those firms (~10% of the market, already exceeding ordinary matter's 5% of the universe). Decide on a consistent definition of tech company in general and add in all of the programmers from them and it wouldn't surprise me at all if tech company employees actually exceeded non-tech, though I can see it being the other way too, just not being "vast majority".
As for stories from roles at non-tech places, most are probably told orally (especially to fellow employees at larger companies as cautionary tales of the crazy messes out there that make their own current insanity look pretty sane) but also remember that at any given time like half of the professional market has been in it for less than 5 years (how many of them got into tech-company vs non-tech-company roles?). And remember you may have read stories from them but not realized it because the actual work regardless of line/staff or tech/non-tech company distinction itself for programmers can be so similar, so it's not always clear whether some story on e.g. The Daily WTF is from which (though sometimes it is or you can guess).
I've been both staff and line at various companies.
The biggest downside to staff IME is that you are almost constantly reminded that you are a cost and at danger of being cut.
OTOH, the biggest upside is the domain knowledge, and in particular, how companies (ie customers of the line engineers) really deploy and run their systems, which IME is often very different from how the line engineers think they run them.
Line engineers tend to gloss over the myriad of external influences that affect how easy their systems are to deploy and integrate (eg how many FTEs doe it take to operate your systems, how long is an acceptable maintenance window for applying fixes, how long does it take to roll back if a fix fails, etc).
An experienced staff engineer introduced to a line team can be a huge asset, and will ask the right kind of questions, ie those that the customer is often most interested in.
The biggest downside to staff IME is that you are almost constantly reminded that you are a cost and at danger of being cut.
OTOH, the biggest upside is the domain knowledge, and in particular, how companies (ie customers of the line engineers) really deploy and run their systems, which IME is often very different from how the line engineers think they run them.
Line engineers tend to gloss over the myriad of external influences that affect how easy their systems are to deploy and integrate (eg how many FTEs doe it take to operate your systems, how long is an acceptable maintenance window for applying fixes, how long does it take to roll back if a fix fails, etc).
An experienced staff engineer introduced to a line team can be a huge asset, and will ask the right kind of questions, ie those that the customer is often most interested in.
>are almost constantly reminded that you are a cost
That was my life working tech support. Now I should say I was well paid, and it was a good job generally, but I worked closely with some of the engineers and you got all of those wonderful informal "hints" about your value at the company that didn't happen with the engineering team.
Our back fills would get held up on an off almost infinitely. Even if we wanted to hire someone they'd low ball the new folks absurdly (I was embarrassed I even interviewed these folks). If there were cutbacks our quarterly pizza lunch (maybe cost a couple hundred dollars in so-so quality pizza) would get canceled ... (the engineering team would quietly invite me to their lunches, nice guys). And the quality of management was pretty poor / there was no effort to improve them. We were also the department that got the usual cycle of VPs in and out as they realized nobody cared what they thought and would move on.
When the time came I moved on to a new career. It wasn't so much a bad job, but that sense of absurdity and being just a cost wore me down.
That was my life working tech support. Now I should say I was well paid, and it was a good job generally, but I worked closely with some of the engineers and you got all of those wonderful informal "hints" about your value at the company that didn't happen with the engineering team.
Our back fills would get held up on an off almost infinitely. Even if we wanted to hire someone they'd low ball the new folks absurdly (I was embarrassed I even interviewed these folks). If there were cutbacks our quarterly pizza lunch (maybe cost a couple hundred dollars in so-so quality pizza) would get canceled ... (the engineering team would quietly invite me to their lunches, nice guys). And the quality of management was pretty poor / there was no effort to improve them. We were also the department that got the usual cycle of VPs in and out as they realized nobody cared what they thought and would move on.
When the time came I moved on to a new career. It wasn't so much a bad job, but that sense of absurdity and being just a cost wore me down.
> The biggest downside to staff IME is that you are almost constantly reminded that you are a cost and at danger of being cut.
It seems like this shouldn't be an absolute that applies to all staff roles, just a sign of a company with an immature viewpoint on costs. Or even just an inconsistent one. Consider the electricity used to keep the office running, it's a cost, but no one would feel the urge to remind the utility company that it's a cost and therefore at danger of being cut. That "and therefore" isn't even true in general anyway. Pre-pandemic most would consider the risk of cutting the office electricity to be no higher than the risk of the company ceasing to exist for whatever reason, i.e. if the company goes the office also goes, and there aren't many other causes for the office to go for most companies so it's mostly vice-versa too. Similarly there are businesses basically entirely supported by staff teams/individuals doing maintenance of some old software, if they go, the business goes, and vice versa. Anyone trying to pull a "don't forget you're a cost and might get cut!" reminder on them would be an asshole. Meanwhile companies like Google have no problem killing off entire products and their teams (though I think they tend to re-purpose the programmers rather than officially lay them off) even though it's making on the order of ("only") $200m/yr in profit.
Sure, if people can get something for cheaper than they used to, or get rid of something they realize they don't need/want, there's incentive to do that and "cut costs" by that amount if they can, but this incentive applies regardless of the staff/line division. Maybe the cure is to remind line roles at such places that they too are in some vague danger.
It seems like this shouldn't be an absolute that applies to all staff roles, just a sign of a company with an immature viewpoint on costs. Or even just an inconsistent one. Consider the electricity used to keep the office running, it's a cost, but no one would feel the urge to remind the utility company that it's a cost and therefore at danger of being cut. That "and therefore" isn't even true in general anyway. Pre-pandemic most would consider the risk of cutting the office electricity to be no higher than the risk of the company ceasing to exist for whatever reason, i.e. if the company goes the office also goes, and there aren't many other causes for the office to go for most companies so it's mostly vice-versa too. Similarly there are businesses basically entirely supported by staff teams/individuals doing maintenance of some old software, if they go, the business goes, and vice versa. Anyone trying to pull a "don't forget you're a cost and might get cut!" reminder on them would be an asshole. Meanwhile companies like Google have no problem killing off entire products and their teams (though I think they tend to re-purpose the programmers rather than officially lay them off) even though it's making on the order of ("only") $200m/yr in profit.
Sure, if people can get something for cheaper than they used to, or get rid of something they realize they don't need/want, there's incentive to do that and "cut costs" by that amount if they can, but this incentive applies regardless of the staff/line division. Maybe the cure is to remind line roles at such places that they too are in some vague danger.
Related to this article: The owner of a company (non-startup, but growing and profitable) I used to work for gave me great career advice. He said to always focus on things that produce revenue. If you aren't doing things that produce revenue, try to move into those areas if possible.
His view was that revenue can soar 100%, 200%, 1,000%, 10,000% or however high. Cost savings, on the other hand, can only go down to a maximum of 100% (but obviously much lower in practice). So in his mind, a business-wide focus on growing revenue is always better than a focus on cutting costs. If you are in the second boat, it means the company is struggling and maybe it's time to get out.
Obviously, a rational CEO would see $1m cost savings the same as a $1m gain in profits, but CEO's are not rational beings (nor is any human) and understanding that they usually prefer higher revenue to lower costs is fundamental to understanding how they value different parts of the company. It's not fair, it's just truth (at least in many companies).
There's something refreshing about some hedge funds where portfolio managers are rewarded exclusively on their own performance. For example, if the fund loses money, but you continue to bring in great revenue, you can bet that any sane hedge fund will pay you a lot to stay around, regardless of how they are doing overall. Unfortunately (or maybe fortunately), profit in most companies isn't directly attributable in the way it is at hedge funds. But the same truth holds. If you are bringing in good profit, it's hard to get rid of you (or not pay you well) regardless of how the company is doing overall. Try to be in one of those profit centers, if you can.
His view was that revenue can soar 100%, 200%, 1,000%, 10,000% or however high. Cost savings, on the other hand, can only go down to a maximum of 100% (but obviously much lower in practice). So in his mind, a business-wide focus on growing revenue is always better than a focus on cutting costs. If you are in the second boat, it means the company is struggling and maybe it's time to get out.
Obviously, a rational CEO would see $1m cost savings the same as a $1m gain in profits, but CEO's are not rational beings (nor is any human) and understanding that they usually prefer higher revenue to lower costs is fundamental to understanding how they value different parts of the company. It's not fair, it's just truth (at least in many companies).
There's something refreshing about some hedge funds where portfolio managers are rewarded exclusively on their own performance. For example, if the fund loses money, but you continue to bring in great revenue, you can bet that any sane hedge fund will pay you a lot to stay around, regardless of how they are doing overall. Unfortunately (or maybe fortunately), profit in most companies isn't directly attributable in the way it is at hedge funds. But the same truth holds. If you are bringing in good profit, it's hard to get rid of you (or not pay you well) regardless of how the company is doing overall. Try to be in one of those profit centers, if you can.
That owner was absolutely correct. If you can make the company money and you can prove how, the sky's the limit. You're much more likely to get a cut of profits over a cut of savings.
I worked as Consultant for several years and instead of a daily rate, always proposed for each of my large projects, that companies would pay me 0.5% of the money my activities made the company or 0.1% of the money I saved the company.
Not one ever took up on this offer...
Not one ever took up on this offer...
Probably because it's ambiguous and opens them up to legal headaches when there's disagreement over how much was made or saved.
No. I always made it very clear.
Example: Show me your current budget for your main data center. Let me show a proposal for a Cloud move that will keep equivalent or better quality of service, including training and while defining KPI's for success.
Example: Show me your current budget for your main data center. Let me show a proposal for a Cloud move that will keep equivalent or better quality of service, including training and while defining KPI's for success.
Seems like that would quickly turn into a game of reverse engineering shitty KPIs, would it not?
I agree some play the game of working for the KPI's as defined.
The main point of the proposal was always clear up front. I was not the one deciding on KPI's it was a joint choice.
For the SAME business applications and SAME business processes:
- At the end of a quarter you either spend less OR more with your infra costs including required teams.
- At the end of a quarter you either have more uptime OR less uptime.
- At the end of a quarter you either spend more on licenses OR less.
Some KPI's are somewhat objective.
The main point of the proposal was always clear up front. I was not the one deciding on KPI's it was a joint choice.
For the SAME business applications and SAME business processes:
- At the end of a quarter you either spend less OR more with your infra costs including required teams.
- At the end of a quarter you either have more uptime OR less uptime.
- At the end of a quarter you either spend more on licenses OR less.
Some KPI's are somewhat objective.
> The main point of the proposal was always clear up front. I was not the one deciding on KPI's it was a joint choice.
Which is exactly the parent's issue with their statement "I always make it clear". Many rev share negotiations break down quickly due to the nature of these deal:
- The profit maximizing buyer of said services has little incentive to pay you your "fair" share, EVEN if they do in fact create more revenue because of said services effect. They'll find every way to pay you as little as possible within the bounds of your contract.
- A buyer of said services rarely will rarely let you into their financial systems to validate. Even if they do, financials notoriously are easy to manipulate/game (ever heard of Adj. EBITDA?). The overhead of financial clarity is rarely worth the headache. Heck, most businesses internal operations rarely can create clear ROI their projects when they used internal resources much less using external resources.
- There are so many hidden variables that it's nearly impossible to control for your impact. Let's say you help reduce a company's EC2 instances from 10 to 7. Savings...great! Now the company grows and they need 8 EC2 instances. Did you still save them money? Down the rabbit hole we go...
I get what you're saying but you're living in a vacuum if you think you can universally demand that type of contract. They're possible but require the stars to align.
Note - I'm talking specifically about professional services / consulting work.
Which is exactly the parent's issue with their statement "I always make it clear". Many rev share negotiations break down quickly due to the nature of these deal:
- The profit maximizing buyer of said services has little incentive to pay you your "fair" share, EVEN if they do in fact create more revenue because of said services effect. They'll find every way to pay you as little as possible within the bounds of your contract.
- A buyer of said services rarely will rarely let you into their financial systems to validate. Even if they do, financials notoriously are easy to manipulate/game (ever heard of Adj. EBITDA?). The overhead of financial clarity is rarely worth the headache. Heck, most businesses internal operations rarely can create clear ROI their projects when they used internal resources much less using external resources.
- There are so many hidden variables that it's nearly impossible to control for your impact. Let's say you help reduce a company's EC2 instances from 10 to 7. Savings...great! Now the company grows and they need 8 EC2 instances. Did you still save them money? Down the rabbit hole we go...
I get what you're saying but you're living in a vacuum if you think you can universally demand that type of contract. They're possible but require the stars to align.
Note - I'm talking specifically about professional services / consulting work.
Yea because people want a single invoice and to be done with you. No one wants to pay a ongoing expense, nor an expense that isn’t fixed. Math/accounting is way harder.
Except when is to reward the board ;-)
unless you work in sales, it is very hard to prove how lines of code can translate in more money for the company. maybe easier in startups but nearly impossible in big corps where everyone is just a cog in the machine
You don't need to prove it. You just need to justify the number you show.
For example: you build a feature to notify customers via email that they have a balance due. The email includes a link with UTM tracking stuff. You also have metrics as to who pays and when. So now you can say "X number of people paid their balance within Y hours of an email being sent out, and within Z minutes of the email linked being clicked" and total up the amount of balances paid. Sure, your feature isn't 100% responsible for enabling that balance to be collected, but it deserves to say it contributed to a portion of the collected balance value.
For example: you build a feature to notify customers via email that they have a balance due. The email includes a link with UTM tracking stuff. You also have metrics as to who pays and when. So now you can say "X number of people paid their balance within Y hours of an email being sent out, and within Z minutes of the email linked being clicked" and total up the amount of balances paid. Sure, your feature isn't 100% responsible for enabling that balance to be collected, but it deserves to say it contributed to a portion of the collected balance value.
I wouldn't say "nearly impossible", although big companies do tend to have a few teams in that position. Everywhere I've worked, large or small, there have been a substantial number of engineers who justify their work in terms of money for the company and rocket up the career ladder because of it. (And I've seen a lot of seemingly "cog in the machine" tasks that have large dollar amounts attached as far as management is concerned.)
It's much easier to save money than it is to make it, and that's why revenue is valued more.
You can hire any number of consulting firms or smart engineers that can tell you how to lower your AWS bill, or get rid of unproductive employees. It's much harder to figure out how to grow your business by 2x.
You can hire any number of consulting firms or smart engineers that can tell you how to lower your AWS bill, or get rid of unproductive employees. It's much harder to figure out how to grow your business by 2x.
It's not linear. Cutting 1% of costs while maintaining the same revenue might be trivial. Cutting 10% of costs might be very doable. Cutting 50% of costs might be incredibly hard.
And I assure you that growing revenue by 100% is far easier than cutting costs by 100% (while maintaining current revenue).
Also, there's a human element to it. I'd venture that most CEOs would much rather the company make more money than have to lower bonuses and benefits, cut down of office space and fire employees.
And I assure you that growing revenue by 100% is far easier than cutting costs by 100% (while maintaining current revenue).
Also, there's a human element to it. I'd venture that most CEOs would much rather the company make more money than have to lower bonuses and benefits, cut down of office space and fire employees.
Cloud companies do present unique opportunities for easy saving, though.
Cutting cost can often bring in revenue.
If you can provide the same product or service but with a smaller margin, you can out price your competitors and win the customers over.
I think Jeff Bezos is famous for saying: Your margin is my opportunity.
If you can provide the same product or service but with a smaller margin, you can out price your competitors and win the customers over.
I think Jeff Bezos is famous for saying: Your margin is my opportunity.
That’s essentially just a race to the bottom in most cases. There aren’t too many cases where you can realistically lower your price below your competitor’s cost AND have your competitor be unable to make the necessary changes to match you.
This happens all the time. Your objection around competitors could equally apply to revenue growing areas of work.
Your distinction of revenue vs cost-saving doesn't translate neatly, in my opinion, into reality.
In reality, you have a lot of different functions that translate into revenue: product tries to determine what you ought to build that will increase revenue; marketing will bring potential revenue to your doors; sales turns potential revenue into real revenue; application/service engineers do the monkey-wrenching to turn the additional-revenue-producing feature into reality. Is any one person in any of these functions fully responsible for the revenue increase? Clearly no. So how can you, in one of those roles, claim full credit for the additional revenue? It sounds like hubris to me. Companies are a team effort.
Cost reduction is a culture, though. It's when startups, when contemplating a new feature, ask the people involved, "how much will this cost us?" instead of ignoring that question entirely. It's when someone makes sure that billing alerts are set up correctly so that people are aware of the costs of what they're running. It's when the CTO asks questions like "can you run that on spot instances?" because he knows it will bring huge average savings. Revenue increases aren't a "culture" in the same way; desiring additional revenue is the default state of things and can rest as an unspoken assumption.
In reality, you have a lot of different functions that translate into revenue: product tries to determine what you ought to build that will increase revenue; marketing will bring potential revenue to your doors; sales turns potential revenue into real revenue; application/service engineers do the monkey-wrenching to turn the additional-revenue-producing feature into reality. Is any one person in any of these functions fully responsible for the revenue increase? Clearly no. So how can you, in one of those roles, claim full credit for the additional revenue? It sounds like hubris to me. Companies are a team effort.
Cost reduction is a culture, though. It's when startups, when contemplating a new feature, ask the people involved, "how much will this cost us?" instead of ignoring that question entirely. It's when someone makes sure that billing alerts are set up correctly so that people are aware of the costs of what they're running. It's when the CTO asks questions like "can you run that on spot instances?" because he knows it will bring huge average savings. Revenue increases aren't a "culture" in the same way; desiring additional revenue is the default state of things and can rest as an unspoken assumption.
What’s sad is I’m pretty sure the team I work I’m collectively paid more money than we bring in yearly.
Is your team an investment? I know we (not me, someone else I work with) asked our CEO about a team not making money, and he responded yeah, they started the team knowing it was a ten year investment, now it is looking like a 20 year investment and they are fine with it. My opinion is the team in question will never pay off the investment, but it will eventually come close enough to break even and the goodwill they generate for the company more than makes up the monitory loss. (How do you count someone who decides to buy our most profitable product vs a competitors because we have an unrelated product they use)
We’re more like a necessary expense, what we do is moderately important and pull in some income, but not a lot.
When we win, it’s rarely acknowledged, as the output from other more core teams just seems more impressive, but when we fuck up, it looks really bad.
When we win, it’s rarely acknowledged, as the output from other more core teams just seems more impressive, but when we fuck up, it looks really bad.
That's not necessarily (and probably isn't) sad, I can think of two general reasons for that to happen and it not be a problem:
- Growth, e.g. trivially everyone at a company that's yet to turn a profit
- Critical but not revenue-generating function
I mean basically that's 'line' and 'staff' from OP (but for line the subset of companies/teams that isn't profitable yet). The latter being a 'cost centre'.
If you don't like it ('what's sad is') then the article might be a useful approach/line of thought when looking for your next role - i.e. a 'line' job (at a profitable company on a team working on the profitable thing).
- Growth, e.g. trivially everyone at a company that's yet to turn a profit
- Critical but not revenue-generating function
I mean basically that's 'line' and 'staff' from OP (but for line the subset of companies/teams that isn't profitable yet). The latter being a 'cost centre'.
If you don't like it ('what's sad is') then the article might be a useful approach/line of thought when looking for your next role - i.e. a 'line' job (at a profitable company on a team working on the profitable thing).
I've never had a job where this wasn't the case.
Another thing to consider for tech folk here: if you convince the company of cost savings always consider the possible equity value increase. Software led companies can generally command high EBITDA multiples. If you cost $100k and save the company $100k in annual costs, then you potentially have created $2,000,000 in equity value (20x is a safe EBITDA multiple to assume). A business owner would take that deal any day of the year, especially one that might sell to a PE.
Note - Companies can be valued at top line ARR/Revenue and/or EBITDA, so YMMV, even in the PE world.
Note - Companies can be valued at top line ARR/Revenue and/or EBITDA, so YMMV, even in the PE world.
Lowering the costs means you get higher margins, which in turn means you can grow the company larger then other similar companies before reaching the marginal return (the point where growing wont increase profits). So a company with low expenses can grow really big - making the founders very rich.
Working in an area that produce revenue - what does that even mean? Should you work in marketing in order to increase demand ? Rather then in production ?
Working in an area that produce revenue - what does that even mean? Should you work in marketing in order to increase demand ? Rather then in production ?
[deleted]
> Obviously, a rational CEO would see $1m cost savings the same as a $1m gain in profits
This is generally incorrect, especially at SaaS companies where revenue is recurring. It's very likely that you'll see much of that $1m gain again in future years, possibly even growing, while cost savings are hard to repeat consistently without impacting future growth.
This is generally incorrect, especially at SaaS companies where revenue is recurring. It's very likely that you'll see much of that $1m gain again in future years, possibly even growing, while cost savings are hard to repeat consistently without impacting future growth.
If you save $500k this year by optimizing some pattern or behavior (eg infrastructure) then why wouldn't that $500k also be saved the next year? You're right if it's a one-time cut (eg no free snacks this year) but most savings are going to be on things that happen more than once.
Agree on things like infrastructure optimization. Most significant savings happen on people costs though, and layoffs/hiring freezes tend to not last forever, and also have impacts on future growth as well.
Compared to the same amount of revenue offering, most top SaaS companies have >100% net dollar retention, which means that their existing contracts tend to grow year-over-year from usage/upsells, so the long-term value of that $1m in revenue increases over time.
Compared to the same amount of revenue offering, most top SaaS companies have >100% net dollar retention, which means that their existing contracts tend to grow year-over-year from usage/upsells, so the long-term value of that $1m in revenue increases over time.
Cost savings we count are usually recurring in the same way.
that makes no sense at all
Your comment reminds me that I've only seen this distinction in terms of profit center VS cost center. Profit centers do business and get perks, cost centers support business and get the early layoffs.
The article's staff vs line distinction cuts it a little differently, and definitely gives a rosier picture of working in a staff role.
The article's staff vs line distinction cuts it a little differently, and definitely gives a rosier picture of working in a staff role.
I don't disagree with the article. Within a tech company, it's obvious why they value engineers. In a "staff" you might also be highly valued or you might not be. As an example, I've recently noticed that home depot has a superb website. Looking at the quality of it, they've obviously put a lot of thought and resources into it. It's something they value. The people working on it might be in the "staff" bucket, but I'd bet the C-Suite is well aware of the impact they are having. On the other hand, I've seen companies where the "staff" engineers are completely disregarded.
This view is slightly wrong when it comes to software. Software is a force multiplier, not a cost reducer.
Sometimes they're the same. Sometimes they aren't. A well placed, smart team of "staff" engineers can increase revenue as much or more than a team of line employees.
Sometimes they're the same. Sometimes they aren't. A well placed, smart team of "staff" engineers can increase revenue as much or more than a team of line employees.
> Obviously, a rational CEO would see $1m cost savings the same as a $1m gain in profits, but CEO's are not rational beings (nor is any human) and understanding that they usually prefer higher revenue to lower costs is fundamental to understanding how they value different parts of the company. It's not fair, it's just truth (at least in many companies).
A rational CEO prefers revenue growth as companies are valued based on revenue, and the CEO's purpose is to maximize per share value.
A rational CEO prefers revenue growth as companies are valued based on revenue, and the CEO's purpose is to maximize per share value.
A CEO's purpose is to organize and direct a company to meet its corporate charter.
Good read on the shortcomings of the "agency theory" based view that you're assuming, and which thankfully is finally becoming less of the de facto view: https://hbr.org/2017/05/the-error-at-the-heart-of-corporate-...
Good read on the shortcomings of the "agency theory" based view that you're assuming, and which thankfully is finally becoming less of the de facto view: https://hbr.org/2017/05/the-error-at-the-heart-of-corporate-...
You're redefining what the goals are for the rational CEO, not the rational nature of the CEO though. But suppose I believed your goals were proper. I fail to see how 'cutting costs' is going to help a company better meet its corporate charter than maximizing revenue. It seems again the latter would win out, because more revenue, means more cash coming through you which means (a) more potential for cost savings (whereas cost savings don't typically create potential for revenue) and (b) more ability to exploit that cash once you have (a).
If you can save 99% on cost, but sell at the same price, you've got a 10,000% profit, isn't it?
Percentages are interesting metrics, but real dollar values are more important when you're talking finances. If profit is revenue is $100 and costs are $1, you've got a huge profit margin, but it is unlikely that you can grow that revenue to $10m. If you have $5m in revenue and $2.5m in costs, your profit margin in percentages is lower, but you have the basis for a company that can reinvest profits to increase revenue growth.
That's called COGS, or Cost Of Goods and Services. It's separate the kind of costs he's talking about. If you're working on COGS you're working in a profit center generating revenue, not in a cost center performing necessary but expensive functions.
Tech doesn't usually measure COGS, because the cost of another user on a website is near zero.
Tech doesn't usually measure COGS, because the cost of another user on a website is near zero.
I'm not sure if you're talking about at the executive level or at the engineer level, but here's some anecdata:
At the big tech (household name) I work we definitely spend a lot of energy talking about COGS a engineers. We have a LOT of data, and we spend a lot of money on cloud services to keep our product running - you want to add a new piece of data to this database to support some new feature? Go calculate how much it'll cost in storage and compute and if it's above some threshold, request special approval. You want to improve performance by caching our indexing? Let's talk about how much that'll be in COGS. This stuff ain't free, all those users add up.
The interesting bit is that all this COGS isn't actually money that transfers hands, the cloud we use is our own. But it isn't free and internal accounting is taken seriously.
At the big tech (household name) I work we definitely spend a lot of energy talking about COGS a engineers. We have a LOT of data, and we spend a lot of money on cloud services to keep our product running - you want to add a new piece of data to this database to support some new feature? Go calculate how much it'll cost in storage and compute and if it's above some threshold, request special approval. You want to improve performance by caching our indexing? Let's talk about how much that'll be in COGS. This stuff ain't free, all those users add up.
The interesting bit is that all this COGS isn't actually money that transfers hands, the cloud we use is our own. But it isn't free and internal accounting is taken seriously.
I've seen the distinction drawn, usefully I think, between "Cost of Revenue" as more or less fixed operating costs eg AWS spend, and "Customer Acquisition Cost" as specifically the average spend to gain "another user on a website", usually in a way that can be either considered in the aggregate or broken out per channel such as for specific ad vendors or similar.
I think "COGS" as discussed here would probably be a rollup of both? Not sure; while I've been in orgs where the cost center/profit center distinction was made, I haven't run into a situation where COGS was a metric I saw used.
I think "COGS" as discussed here would probably be a rollup of both? Not sure; while I've been in orgs where the cost center/profit center distinction was made, I haven't run into a situation where COGS was a metric I saw used.
Cost of Revenue and Customer Acquisition Cost are both different metrics. COGS is used in manufacturing in order to peg inputs to a per widget basis. Cost of Revenue gets used in tech because per customer costs are both a bad way to measure it and likely to be fractions of cents.
Customer Acquisition Cost gets used in subscription businesses to measure sales and marketing performance. It can be relevant alongside COGS if you're manufacturing the thing you're selling subscriptions to, but that's kinda rare.
Customer Acquisition Cost gets used in subscription businesses to measure sales and marketing performance. It can be relevant alongside COGS if you're manufacturing the thing you're selling subscriptions to, but that's kinda rare.
Got it. Thanks for the clarification!
A great point on how profit margins are not always the best metric! A panhandler has almost no costs, so their profit margins are huge. But it's not a very scalable business :)
[deleted]
The claim that "You are line if your role makes up the largest fraction of the org chart" has a counter example: the number of pilots in the Air Force is relatively small compared to the number of non-pilot positions, yet the pilot is the only line role in the Air Force.
This is true also of other branches of military. Generally support staff outnumber actual fighters.
When reading this I was thinking that this distinction sounds more like what I know as profit center/cost center. I was glad to see a sidebar mentioning that he thinks its related. Maybe its more common to use that terminology in finance, which is really the only industry i've worked in. I've not heard line/staff used in this way but profit center/cost center is well known.
I will say that I don't really agree that profit center/cost center is less clear terminolgy or doesnt have the right boundries. I'd argue the opposite. It's a pretty direct description of why any distinction exists at all. It's also pretty inuitive that its preferable to be in a role tied to how the company generates money. Line/Staff terminology requires nice blog posts to explain what those things are. Maybe in a military context it makes sense because there is no profit center per se, but for industry, using line/profit terminology is just a whitewash of profit center/cost center, which is imo the real distinction.
Of course the classification of profit/cost is not perfect as there are jobs kind of in the the middle, like say if you are an internal recruiter (you recruit profit center people too so...) but I don't think those roles are easier to classify as line/staff either.
I will say that I don't really agree that profit center/cost center is less clear terminolgy or doesnt have the right boundries. I'd argue the opposite. It's a pretty direct description of why any distinction exists at all. It's also pretty inuitive that its preferable to be in a role tied to how the company generates money. Line/Staff terminology requires nice blog posts to explain what those things are. Maybe in a military context it makes sense because there is no profit center per se, but for industry, using line/profit terminology is just a whitewash of profit center/cost center, which is imo the real distinction.
Of course the classification of profit/cost is not perfect as there are jobs kind of in the the middle, like say if you are an internal recruiter (you recruit profit center people too so...) but I don't think those roles are easier to classify as line/staff either.
Another thing about IT dept software dev vs. the tech company dev: Often in the IT dept you have smaller projects where you have greater responsibility and ownership. For all the talk about "t-shaped people" a lot of mature tech companies prefer a stay-in-your-lane person who doesn't dare venture beyond their assigned role or challenge the pecking order. You might expect it to be more bureaucratic in the IT dept because "tech companies are too cool to be bureaucratic" but I wouldn't assume that. Definitely true that the average expertise levels are lower, pay scale is a little more "average" and promotability is high. I'd say the less competitive atmosphere keeps the dog-eat-dog behavior to a minimum. But of course your mileage may vary...
This articles sort of right, sort of wrong.
Staff in the modern military means you're a careerist. It's the last rank that you can't be forced out without advancing, and might not be expected to advance at all.
Staff has different kinds of connotations depend on officer and enlisted. Staff officers would never lead from the front. That's O1-O3s job, those people are actually trained by enlisted careerists before they ever get to lead. In the enlisted ranks, Staff starts with E6 (Staff Sgt) and they are typically platoon commander's. By contrast with officer ranks, Staff Sgts will still go on patrol.
The officers metaphor is a bit relevant to software. It's rare for Major+ to actually work in the field (unless they're highly specialized like an Air Officer). These are basically executives. On the enlisted side Corporal through Staff are your immediate leaders that the company recognizes. Corporal is the first working leader as a team lead, Sgt lead multiple corporals, and Staff Sgt can lead multiple Sgts. This can vary by +-1 rank.
I do think software does need to shift more the direction of the military where working leaders hold the majority of team direction and influence from a systemic level. Ultimately, Staff Enlisted are entrusted with direct responsibility for how and when things get done; they also (generally) have the most direction over the platoon. The biggest component I'd like to see is managers being trained by software careerists before they're ever allowed to lead a team.
Edit: my experience is colored by the Marines, which focus on small team leadership and cross training. YMMV.
Staff in the modern military means you're a careerist. It's the last rank that you can't be forced out without advancing, and might not be expected to advance at all.
Staff has different kinds of connotations depend on officer and enlisted. Staff officers would never lead from the front. That's O1-O3s job, those people are actually trained by enlisted careerists before they ever get to lead. In the enlisted ranks, Staff starts with E6 (Staff Sgt) and they are typically platoon commander's. By contrast with officer ranks, Staff Sgts will still go on patrol.
The officers metaphor is a bit relevant to software. It's rare for Major+ to actually work in the field (unless they're highly specialized like an Air Officer). These are basically executives. On the enlisted side Corporal through Staff are your immediate leaders that the company recognizes. Corporal is the first working leader as a team lead, Sgt lead multiple corporals, and Staff Sgt can lead multiple Sgts. This can vary by +-1 rank.
I do think software does need to shift more the direction of the military where working leaders hold the majority of team direction and influence from a systemic level. Ultimately, Staff Enlisted are entrusted with direct responsibility for how and when things get done; they also (generally) have the most direction over the platoon. The biggest component I'd like to see is managers being trained by software careerists before they're ever allowed to lead a team.
Edit: my experience is colored by the Marines, which focus on small team leadership and cross training. YMMV.
[deleted]
I work for a Fortune 500 company, but my entire career there (more than 20 years) has been focused on creating software used by 3rd part companies who sell our products (which range in size from a single booth in a Chinese marketplace to a mom and pop store in South America to a large multi store company in Europe). I suppose it is a staff position, but the primary people who drive where our product goes are outside the company I work for, which seems more like a line position. We are helping all these other companies with their core business of selling products. Products that my company makes.
However, my job is much more relaxed than that of a real line worker. We don’t charge any of these 3rd party companies for the software we build. So we never need to worry about things like billable hours. We are fairly free to decide what we want to work on. We have all the resources and benefits of a giant behemoth of a company to rely on. The job is almost never stressful and has great work-life balance. On the other hand, while I do have fantastic benefits and make a six figure salary, I am not making these $500k/year salaries I hear about. And we don’t have free food ;-)
However, my job is much more relaxed than that of a real line worker. We don’t charge any of these 3rd party companies for the software we build. So we never need to worry about things like billable hours. We are fairly free to decide what we want to work on. We have all the resources and benefits of a giant behemoth of a company to rely on. The job is almost never stressful and has great work-life balance. On the other hand, while I do have fantastic benefits and make a six figure salary, I am not making these $500k/year salaries I hear about. And we don’t have free food ;-)
At one place I worked full-time, the time-tracking software explicitly had a checkbox, "billable", which meant this time can be directly billed to clients, and you were expected to be able to check that for some specific percentage of your working day. A marketing company. It was annoying and onerous, quite like the company itself, come to think about it.
These days, as a freelancer, everything I do is "line", in these terms, by definition. It's glorious.
These days, as a freelancer, everything I do is "line", in these terms, by definition. It's glorious.
At one place I worked full-time, the time-tracking software explicitly had a checkbox, "billable", which meant this time can be directly billed to clients, and you were expected to be able to check that for some specific percentage of your working day.
The percentage I'm expected to bill to clients is 100%, 8hrs a day. We are even expected to make up time spent on non-billable things like company or department meetings. Definitely wears on you for sure.
The percentage I'm expected to bill to clients is 100%, 8hrs a day. We are even expected to make up time spent on non-billable things like company or department meetings. Definitely wears on you for sure.
I contracted at a place where this was expected, but any 'meetings' you were just supposed to bill to the client/project as well. Some folks were on longterm/large projects - like... 15 people on one client project. 1hr meeting? It's just... billable time.
I was stuck on support dealing with 6-8 different clients. I was supposed to split up time between the clients. 1 hr 'all hands' meeting for the company? Just charge each of those 6 clients 10 minutes each - even if you've not done anything on their project for the last 2 weeks (for example).
So... I started getting push back from higher-ups asking why I was billing projects I wasn't working on.
"I don't get paid unless I put billable hours in your system, and this is what your email said to do".
"That's not what we meant..."
"Well... what did you mean? Which of the 7 client projects I'm supporting should get billed for the 2 hr 'state of the company' meeting you made us attend last week?"
"I'll get back to you..."
Which they never did. I'm not there any longer. This was right before covid, and everything got turned upside down after that. I left soon after.
I was stuck on support dealing with 6-8 different clients. I was supposed to split up time between the clients. 1 hr 'all hands' meeting for the company? Just charge each of those 6 clients 10 minutes each - even if you've not done anything on their project for the last 2 weeks (for example).
So... I started getting push back from higher-ups asking why I was billing projects I wasn't working on.
"I don't get paid unless I put billable hours in your system, and this is what your email said to do".
"That's not what we meant..."
"Well... what did you mean? Which of the 7 client projects I'm supporting should get billed for the 2 hr 'state of the company' meeting you made us attend last week?"
"I'll get back to you..."
Which they never did. I'm not there any longer. This was right before covid, and everything got turned upside down after that. I left soon after.
> "Well... what did you mean? Which of the 7 client projects I'm supporting should get billed for the 2 hr 'state of the company' meeting you made us attend last week?"
> "I'll get back to you..."
Heh, I've met people who when asked to attend a meeting ask what charge number to use and if they don't get one they don't attend.
> "I'll get back to you..."
Heh, I've met people who when asked to attend a meeting ask what charge number to use and if they don't get one they don't attend.
I used to scroll through my github history, parseling out which precise minutes went where. No. Life is too short, and the bean counters don't really give a shit, they just want a number. 7.5 hours a day regardless, unless I worked 5 hours or 10 hours, then I put that.
That's unusual, in consulting days of yore it was about 80%* billable hours
* may vary of course, but nobody expects 100%, even the big 5/4.
* may vary of course, but nobody expects 100%, even the big 5/4.
Yeah, it crept up over the years. Start at 6hrs a day, then 6.5, then 7 and then 8 about 4 years ago.
8 is just unrealistic, and invites fraud.
BigLaw have expectations like this, but the overt toxicity of that is so famous I'd hope tech would avoid it. In some firms, with rounding allowed, it used to be common to schedule 3 20-minute calls in an hour, because it would yield 1.5h of billable time.
BigLaw have expectations like this, but the overt toxicity of that is so famous I'd hope tech would avoid it. In some firms, with rounding allowed, it used to be common to schedule 3 20-minute calls in an hour, because it would yield 1.5h of billable time.
I've worked as a consultant at various jobs, with billable expectations ranging from 55% to 85%. The largest company I worked for, which was a Big Four consultancy, had the highest billable expectation. But they also had entire departments of non-billable support staff. The smallest company I worked for also had the smallest billable expectation, but also expected certain non-billable work of us (which I generally liked).
The Big Four company also calculated their billable expectation on a nine-hour workday. So working eight billable hours per day every day meant your billable rate was only 89%. It was fine with them if you only put 40 hours a week into the time-tracker, but the denominator was 45.
The Big Four company also calculated their billable expectation on a nine-hour workday. So working eight billable hours per day every day meant your billable rate was only 89%. It was fine with them if you only put 40 hours a week into the time-tracker, but the denominator was 45.
In that case, just don't sweat it. It's all billable. Lunch, too, apparently. That's just what the sales contract stipulates, so, it's not your problem.
The stress comes from deciding which hour you bill and which you don't. Bill all the things!
The stress comes from deciding which hour you bill and which you don't. Bill all the things!
In that case, just don't sweat it. It's all billable.
The budget for these projects won't support that. Billing an hour of lunch everyday just for myself would exceed the retainer allotted for some of these projects.
And it wouldn't work anyways. Hours are billed to specific tasks, individual to the person down to 15 minute increments.
The budget for these projects won't support that. Billing an hour of lunch everyday just for myself would exceed the retainer allotted for some of these projects.
And it wouldn't work anyways. Hours are billed to specific tasks, individual to the person down to 15 minute increments.
Ok. So. You are expected to bill 8 hours, and not lunch, so you are tacitly required to work more than 8 hours per day.
What company is this? Are you in the US?
What company is this? Are you in the US?
[deleted]
I have always found this to be a useful distinction, but software is blurring the lines in many cases
For example, when I worked in Wall Street as a dev/SW architect, you could call that staff. But in fact software was so vital to how Wall Street operates that we were treated as effectively line resources. We were a core to the business.
Where as, writing internal billing software as in the example clearly comes in as a staff position. Working IT in industries where IT is not highly valued was…not fun in my experience.
For example, when I worked in Wall Street as a dev/SW architect, you could call that staff. But in fact software was so vital to how Wall Street operates that we were treated as effectively line resources. We were a core to the business.
Where as, writing internal billing software as in the example clearly comes in as a staff position. Working IT in industries where IT is not highly valued was…not fun in my experience.
> Someone at Thoughtworks sold Dominion Energy on the idea that Thoughtworks... if things go well, they will get follow-on business and maybe even a whitepaper.
...
> Market pressures don’t apply to internal teams
Market forces are constantly applied against internal IT teams, particularly in non-tech companies. The market force is replacing them with consultants. Sometimes they will make those employees train their own replacements[1][2].
Or that there are consultants that can't be fired. The project is over schedule, but too much sunk cost to replace them and no internal devs. A $6M project becomes a $1.25 billion project and fails in slow motion over a decade.[3]
Anyway, my point is that it's not as simple as "internal is always safe, consulting is always tougher".
[1] - https://www.nytimes.com/2015/06/04/us/last-task-after-layoff...
[2] - https://www.mercurynews.com/2016/11/03/after-pink-slips-ucsf...
[3] - https://www.henricodolfing.com/2019/12/project-failure-case-...
...
> Market pressures don’t apply to internal teams
Market forces are constantly applied against internal IT teams, particularly in non-tech companies. The market force is replacing them with consultants. Sometimes they will make those employees train their own replacements[1][2].
Or that there are consultants that can't be fired. The project is over schedule, but too much sunk cost to replace them and no internal devs. A $6M project becomes a $1.25 billion project and fails in slow motion over a decade.[3]
Anyway, my point is that it's not as simple as "internal is always safe, consulting is always tougher".
[1] - https://www.nytimes.com/2015/06/04/us/last-task-after-layoff...
[2] - https://www.mercurynews.com/2016/11/03/after-pink-slips-ucsf...
[3] - https://www.henricodolfing.com/2019/12/project-failure-case-...
Also 10 years ago you'd have employed IT staff to run an Exchange server and AD; now it's all in an Office 365 subscription (for better or worse). 2 years ago same for VPN; now Tailscale/Cloudflare are picking that up.
Calling a software engineer (swe) 'Staff' because
"working on non-core product"
is indeed different from the standard corpororate 'Staff' prefix as a step/level of the ladder (within an org working on either core or non-core product)
"swe, senior swe, staff swe, senior staff swe, principal swe, distinguished swe, fellow swe, senior fellow swe"
I would have like to see mentions of both kinds of 'Staff swe' in the article.
"working on non-core product"
is indeed different from the standard corpororate 'Staff' prefix as a step/level of the ladder (within an org working on either core or non-core product)
"swe, senior swe, staff swe, senior staff swe, principal swe, distinguished swe, fellow swe, senior fellow swe"
I would have like to see mentions of both kinds of 'Staff swe' in the article.
The article is titled The “Other Kind” of Staff SWE. Presumably the “first kind” is the definition to which you are referring
Sure, I just wished the author/article would have spelled out/confirm the standard definition of 'staff swe' as step/level in the ladder before going into the 'other' meaning of 'staff swe' as being part of non-core product.
Like this, from article footnotes:
When talking about “staff” in this article, I do not mean the Staff software engineer role that is found at tech companies after senior. That is a different usage of the termIndeed, like that but then in the main text instead of in a footnote, so it doesn't get overlooked. Anyway, I enjoyed your nice writing and congrats with the HN exposure!
Thanks!
Everything is, of course, blurry at the edges.
If your job is doing something that basically all companies of that size do, you might be staff. If your job is something that contributes to a product or service that your company sells, you might be line.
If you work on the deployment, monitoring and debugging of the CI that builds your SaaS, are you staff or line?
If you work on the deployment, monitoring and debugging of your CI system that QA uses, are you staff or line?
If you work on the deployment, monitoring and debugging of the point of sale systems that your brick-and-mortar stores need, are you staff or line?
If you work on the security of your company which includes the SaaS that you sell, and sometimes you talk to prospective customers about those security issues, are you staff or line?
The biggest question around all these is: does your company management think much about the staff/line distinction, and how will that affect what they do?
If your job is doing something that basically all companies of that size do, you might be staff. If your job is something that contributes to a product or service that your company sells, you might be line.
If you work on the deployment, monitoring and debugging of the CI that builds your SaaS, are you staff or line?
If you work on the deployment, monitoring and debugging of your CI system that QA uses, are you staff or line?
If you work on the deployment, monitoring and debugging of the point of sale systems that your brick-and-mortar stores need, are you staff or line?
If you work on the security of your company which includes the SaaS that you sell, and sometimes you talk to prospective customers about those security issues, are you staff or line?
The biggest question around all these is: does your company management think much about the staff/line distinction, and how will that affect what they do?
The promotion issue doesn’t sound super plausible to me. If you’re part of an internal software development team at an energy company, you’re likely considered part of a cost center not top of mind to the company’s business. Promotions to higher levels are more likely to come from people part of the core sector.
Sometimes the core sector makes a boatload of money, and the people supporting that work in turn get promotions. Companies tend to try to minimize churn in "staff" roles as there are fewer people ready to step in and replace the person who left. Similarly, recruiting for staff positions is often harder than line positions as folks often want to work on the core product mission of a company.
As an analogy, consider the lone sysadmin maintaining the lone linux server hosting a multi-billion dollar companies ERP, Billing Software, and website. The company probably cares enough to ensure this person has a backup, and is paid well enough not to leave. If the everything works the company probably doesn't care enough to do a migration to a SaaS provider, replacing this admin is likely very expensive.
As an analogy, consider the lone sysadmin maintaining the lone linux server hosting a multi-billion dollar companies ERP, Billing Software, and website. The company probably cares enough to ensure this person has a backup, and is paid well enough not to leave. If the everything works the company probably doesn't care enough to do a migration to a SaaS provider, replacing this admin is likely very expensive.
> As an analogy, consider the lone sysadmin maintaining the lone linux server hosting a multi-billion dollar companies ERP, Billing Software, and website. The company probably cares enough to ensure this person has a backup, and is paid well enough not to leave. If the everything works the company probably doesn't care enough to do a migration to a SaaS provider, replacing this admin is likely very expensive.
Eh, I've seen people like this and maybe they get paid well, but the company also can't afford to promote them or move them around. One person I know was an expert in Fortran and worked at a large Wall Street bank doing processing of very large transactions (systems that process trillions of dollars yearly). Technically, there were "backups" who could do parts of his role, but realistically he was the only person who really understood the whole system. He would threaten to leave every so often and they'd bump his pay to an absurd level that made it hard to leave. But there was also no path the promotion for him and he got bored. At a certain point, he ended up leaving anyway.
Eh, I've seen people like this and maybe they get paid well, but the company also can't afford to promote them or move them around. One person I know was an expert in Fortran and worked at a large Wall Street bank doing processing of very large transactions (systems that process trillions of dollars yearly). Technically, there were "backups" who could do parts of his role, but realistically he was the only person who really understood the whole system. He would threaten to leave every so often and they'd bump his pay to an absurd level that made it hard to leave. But there was also no path the promotion for him and he got bored. At a certain point, he ended up leaving anyway.
Yes. Most of the generals in the Air Force are former pilots and many of the executives at Big Oil are chemical or petroleum engineers.
Jokingly you could probably split this into engineers that use xml vs those that use json. I've worked in both types of companies.
I feel like nowadays that joke has evolved to devs that use JSON vs devs that use binary serialisation (like capnproto or whatever else)…
Not that much of a joke, a lot of companies are using binary protocols for internal services e.g. gRPC, and REST for external. So, best/worst of both worlds (depending on whether you are a glass half full/half empty person)
Why not both? There's a binary serialization format for XML... (https://www.w3.org/TR/exi/)
The examples given in the article assume for the sake of argument that the only software is enterprise software. So xml all around.
And Java vs just about anything else (!)
Plenty of front line software at big tech companies like Google is written in Java.
Yeah there's a lot of Java hate but faang companies definitely use it more than ocaml, lisp or what have you.
Larger interactive media tech companies use these delineations too: an animation/game company may have "line producers" whose duties are in-house active productions, while a "producer" is a former "line producer" operating as a mentor, production supervisor for multiple ongoing productions and intermediary between productions vying for the same production resources. Then the "executive producer" is the external role, creating new production pitches, presenting them to publishers/distributors/financers/IP-owners as they work to land new jobs.
While I kinda get that you can advance within a company as "staff", in practice it can take a long time, a long time working on the same software, the same technology stack, and a long time before there is room for advancement - if it even is a company where that kind of thing is possible. And even then there will be competition to advance on the ladder.
And of course, it has to depend on whether you aspire to climb the ladder and effectively change your job and responsibilities, or if you prefer to stick with (in the case of software development) the technology and advance in that direction.
And of course, it has to depend on whether you aspire to climb the ladder and effectively change your job and responsibilities, or if you prefer to stick with (in the case of software development) the technology and advance in that direction.
As per the article, line jobs are where the top talent congregate, and my experience is that the distinction between working in tech (line), and working with tech (staff), is quite a big cultural, and recruitment gap.
It's easy to get a staff job, from a good line background, but much more difficult the other way around.
It's similar, though maybe less extreme, to journalism and PR. Journalists sometimes jump to PR (often much better pay and conditions, at lower ranks anyway), but it's almost (perhaps actually) never the other way around.
It's easy to get a staff job, from a good line background, but much more difficult the other way around.
It's similar, though maybe less extreme, to journalism and PR. Journalists sometimes jump to PR (often much better pay and conditions, at lower ranks anyway), but it's almost (perhaps actually) never the other way around.
The customer's problems are different in the different roles, and the work and the rewards differ because of that. What that looks like here is that the customer of the Line engineer is external and the customer of the Staff engineer is internal. Relationships to internal or external customers are different - based on trust, confidentiality, shared culture, and the overriding fact that you work for the same or different organizations.
Impact at the Staff level frequently requires a step back from coding. External customers generate revenue. Internal customers operate as cost. That's the Profit center / Cost center division. Line engineers create value through new capabilities in market and in maintaining customer relationships - through code. Staff engineers create value through improving efficiency inside the organization - so Line engineers can deliver more. If customer revenue is recurring, returns from customer relationships compound. In comparison, Staff engineers need to demonstrate their impact as compounding returns on efficiency. That can be creating tools or creating policy -- whatever it is your work has to align with greatest impact. That may not be code.
Impact at the Staff level frequently requires a step back from coding. External customers generate revenue. Internal customers operate as cost. That's the Profit center / Cost center division. Line engineers create value through new capabilities in market and in maintaining customer relationships - through code. Staff engineers create value through improving efficiency inside the organization - so Line engineers can deliver more. If customer revenue is recurring, returns from customer relationships compound. In comparison, Staff engineers need to demonstrate their impact as compounding returns on efficiency. That can be creating tools or creating policy -- whatever it is your work has to align with greatest impact. That may not be code.
I couldnt agree with this more. I think its more common to call this a generalist vs a specialist. A lot of engineers are true generalists. At larger companies it's a lot more common to be a specialist or to have ones work touch a very small portion of the companies products.
Curiously, the term "line manager" denotes the person that is in charge of promotion, development, review and vacation request approval + expenses approval of a report (rather than the development of new product lines, which is nowadays done by distributed team in matrix settings led by a "project lead" or "technical lead"), so one would classify them as support, perhaps.
To confuse things further, the "project manager" isn't the most senior manager of the project, but its _administrator_(the "project owner" is responsible for the project).
To confuse things further, the "project manager" isn't the most senior manager of the project, but its _administrator_(the "project owner" is responsible for the project).
Although these divisions may exist, I'm not sure why we have to call them out and normalize them. Essentially what you've described is a two-class system of engineers.
Staff engineers can save the company money. Without them the "line" engineers cannot be as efficient in their mission. Why create any sort of hierarchy?
This type of thinking is antithetical to the startup mentality, but seems very amenable to the way big tech companies think. Which is exactly why I don't work for them.
Staff engineers can save the company money. Without them the "line" engineers cannot be as efficient in their mission. Why create any sort of hierarchy?
This type of thinking is antithetical to the startup mentality, but seems very amenable to the way big tech companies think. Which is exactly why I don't work for them.
It's not a two-class system, it's a reality of the business incentives, and local monopoly vs competition.
I don't think discussing something that exists is "calling it out" or "normalizing" it. It's just discussing it and personally I think it is an interesting take that I hadn't seen phrased in this way before. Now I can think about how it impacts me personally in a new light. Definitely a net win.
Some companies have both, One of the back doors into getting a fang job without being elite at leetcoding is to find staff style position at a fang and then transfer into a line
I guarantee you at Duke Energy the contractors are second-class citizens, are laid off first and each and every one of them will take FTE at Duke the first chance they get.
The primary distinction is whether they're hired directly by Duke as a contractor, versus whether they are employed by a consulting company that is contracted by Duke.
If they are hired as an individual, definitely second-class citizen, and there have been legislative pushes to make a lot of these people classified as employees.
If they are employed by a company that is contracted, chances are their situation is much more comfortable.
If they are hired as an individual, definitely second-class citizen, and there have been legislative pushes to make a lot of these people classified as employees.
If they are employed by a company that is contracted, chances are their situation is much more comfortable.
I think it depends. I suspect working at ThoughtWorks is hard, going from client to client, and losing contracts when the market doesn't look good, but also there is no Martin Fowler of Duke Energy.
> I guarantee you at Duke Energy the contractors are second-class citizens
In fairness, I’d bet the full time devs are too.
In fairness, I’d bet the full time devs are too.
That happens sometimes. But other times, HR has a lot of control over FTE salaries, and little over contractors, and they compare their salary structure to other energy companies, and therefore every FTE is drastically underpaid, and gets little to no stock compensation. So in practice, a senior contractor will earn far more. This means they have a lot of trouble converting FTEs.
I've worked in places where the contractors make about double, and those where it's the FTEs that make double. You really want to get a good idea of how the organization looks before you join there, because really, both kinds exist, and you don't want to be in the wrong group.
I've worked in places where the contractors make about double, and those where it's the FTEs that make double. You really want to get a good idea of how the organization looks before you join there, because really, both kinds exist, and you don't want to be in the wrong group.
How about the third position (which I find myself in in): Staff->Line engineer.
I work primarily on an internal support product which the company decided to license to other entities... at a ridiculously low price. We support dozens of instances and thousands of users, yet bring in less than half of one developers net salary.
And, of course, my departments performance is judged on the Line work, not the Staff work.
I work primarily on an internal support product which the company decided to license to other entities... at a ridiculously low price. We support dozens of instances and thousands of users, yet bring in less than half of one developers net salary.
And, of course, my departments performance is judged on the Line work, not the Staff work.
I work for a tech company (healthcare related, but everything is tech), and we have staff positions. They're mostly meant as someone who has a decent understanding of the entire system they're working on... even have Staff Architects who understand the global system being worked on.
It's almost as if each of our underlying teams are their own firms within the parent organization.
It's almost as if each of our underlying teams are their own firms within the parent organization.
>> If you are a dev team within a bigger, non-tech company, you are basically an in-house agency with one client.
Imma argue with this, as a developer for a bigger non-tech company (and a few small ones)
I've worked for in-house agencies and the pattern is completely different. In-house, every dictat in the software comes from the top down as a fully-formed thought. Whereas being an independent contractor gives you way more creative control over how software turns out. Instead of having to accept some wireframe drawn up by another arm of the company, you get to interrogate the people who will actually be using the software and find out what they need. You have to understand the business logic more than you would if you just accepted it as a programming job alone, and therefore you become more of a design branch than just a coding branch. And I say branch because you are still an integral part of the company, but instead of telling you what to do, they come to you for advice on how to accomplish their aims.
Imma argue with this, as a developer for a bigger non-tech company (and a few small ones)
I've worked for in-house agencies and the pattern is completely different. In-house, every dictat in the software comes from the top down as a fully-formed thought. Whereas being an independent contractor gives you way more creative control over how software turns out. Instead of having to accept some wireframe drawn up by another arm of the company, you get to interrogate the people who will actually be using the software and find out what they need. You have to understand the business logic more than you would if you just accepted it as a programming job alone, and therefore you become more of a design branch than just a coding branch. And I say branch because you are still an integral part of the company, but instead of telling you what to do, they come to you for advice on how to accomplish their aims.
> If you are a dev team within a bigger, non-tech company, you are basically an in-house agency with one client.
I only wish I had that level of autonomy when working for the most horrifically bureaucratic corps I’ve seen.
I only wish I had that level of autonomy when working for the most horrifically bureaucratic corps I’ve seen.
Maybe line should be "the last non-management role the company would outsource".
E.g. the air force wouldn't outsource pilots; Thoughtworks wouldn't outsource consultants.
E.g. the air force wouldn't outsource pilots; Thoughtworks wouldn't outsource consultants.
> In most cases, the easiest way to tell if you are line or staff is to look at the org chart of your business. You are line if your role makes up the largest fraction of the org chart.
If anything, the opposite is true. You are "line" when you are fewer in number having a more direct line to the power structure. In business, it is this, not your contribution that changes your negotiating leverage. In the original military example, mechanics, doctors, IT staff and dozens of other roles vastly outnumber actual soldiers.
If anything, the opposite is true. You are "line" when you are fewer in number having a more direct line to the power structure. In business, it is this, not your contribution that changes your negotiating leverage. In the original military example, mechanics, doctors, IT staff and dozens of other roles vastly outnumber actual soldiers.
Are product managers replacing the engineers as the core line role these days?
Product managers talk to the CEOs more than software engineers do.
Product managers talk to the CEOs more than software engineers do.
[deleted]
Where staff optimizes for staff and line for line they become opposing forces.
I didn’t like that the article opened with an insult to all the other articles about salary or interviews.
Fascinating insight.
OP admits that the distinction is mostly fictional. "Line" can means (a) whatever role the vast majority of of people do, if such exists, (b) whoever your customers see ("talent" in the entertainment/sports world), (c) the expendable interchangable cogs and cannon fodder (military, factory, and Enterprise Consulting), or other.
Not fictional. Contextual.
Pointless piece imo, doesn't really matter.
I dunno man. I think that the dirty little secret is that we're all in line roles whether we like it or not. Some of us discover that sooner than others. This distinction is made plain when a company or organization isn't doing as well and tough decisions need to be made about who stays and who goes.
These two types of roles were called line vs staff when I took a business school class and I think the differences between these two types of roles have a big impact on what the job is like, even if doing the same type of work. It's a bit confusing because it overlaps with 'staff software engineer' term.
I recall hearing stats before that the vast majority of developers work at non-tech companies, but I almost never hear their stories. They are the dark matter of software developers.