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.
Author here. Working at a tech company as a developer vs working at a non-tech company are very different.
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.
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.
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.
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.
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.)
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.
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.
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.
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.
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.
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).
"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 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.
> 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)
"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.
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.
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.
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.
> 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.
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.
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.
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.
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.
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.
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).
> 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.
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. 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.
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.
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 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.
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.
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.
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).
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
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.
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.
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".
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.
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.
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.
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)
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.
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.
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.
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.
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 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.
> "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.
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!
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 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.
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'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.
>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.
> 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.
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.
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...
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)
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.
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 term
Indeed, 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!
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.
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.
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.
200 comments
[ 6.1 ms ] story [ 487 ms ] threadThese 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.
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.
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.)
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)
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.
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.
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.
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).
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 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.
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.
> 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.[
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.
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.
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.
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.
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.
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.
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.
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 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.
Why equate them as the same here?
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.
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.
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.
And recessions are the time when this research is at its cheapest.
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.
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/
I could easily hop to a gig with more responsibility and more opportunity for increasing my skills - but also more stress.
That sounds like a pretty ideal scenario to me, but I'm not sure how to go about finding similar positions.
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).
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.
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/
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.
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".
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.
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.
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.
Lines help you walk by you looking at them. Staff help you walk by you holding them.
These days, as a freelancer, everything I do is "line", in these terms, by definition. It's glorious.
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.
* may vary of course, but nobody expects 100%, even the big 5/4.
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.
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.
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'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.
The stress comes from deciding which hour you bill and which you don't. Bill all the things!
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.
What company is this? Are you in the US?
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.
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.
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.
In fairness, I’d bet the full time devs are too.
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 almost as if each of our underlying teams are their own firms within the parent organization.
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.
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?
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.
I only wish I had that level of autonomy when working for the most horrifically bureaucratic corps I’ve seen.
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.
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.
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.
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.
"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.
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.
Product managers talk to the CEOs more than software engineers do.