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 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 '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)
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.
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.
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 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.
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'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.
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.
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.
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.
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.
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.
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 ?
> 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.
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 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.
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.
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...
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.
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 ;-)
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.
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.
> 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".
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.
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)
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.
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.
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.
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.
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.
[+] [-] adamgordonbell|3 years ago|reply
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.
[+] [-] anoy8888|3 years ago|reply
[+] [-] noduerme|3 years ago|reply
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.
[+] [-] ChrisMarshallNY|3 years ago|reply
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/
[+] [-] cushychicken|3 years ago|reply
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)
[+] [-] phkahler|3 years ago|reply
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.
[+] [-] gernb|3 years ago|reply
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.
[+] [-] jimmaswell|3 years ago|reply
[+] [-] sytelus|3 years ago|reply
[+] [-] _the_inflator|3 years ago|reply
[+] [-] rendall|3 years ago|reply
[+] [-] unknown|3 years ago|reply
[deleted]
[+] [-] Jach|3 years ago|reply
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).
[+] [-] kitd|3 years ago|reply
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.
[+] [-] duxup|3 years ago|reply
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.
[+] [-] Jach|3 years ago|reply
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.
[+] [-] chadash|3 years ago|reply
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.
[+] [-] nunez|3 years ago|reply
[+] [-] drchopchop|3 years ago|reply
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.
[+] [-] didibus|3 years ago|reply
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.
[+] [-] solatic|3 years ago|reply
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.
[+] [-] the_only_law|3 years ago|reply
[+] [-] mbesto|3 years ago|reply
Note - Companies can be valued at top line ARR/Revenue and/or EBITDA, so YMMV, even in the PE world.
[+] [-] z3t4|3 years ago|reply
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 ?
[+] [-] unknown|3 years ago|reply
[deleted]
[+] [-] pgodzin|3 years ago|reply
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.
[+] [-] awkward|3 years ago|reply
The article's staff vs line distinction cuts it a little differently, and definitely gives a rosier picture of working in a staff role.
[+] [-] physicsgraph|3 years ago|reply
[+] [-] dwohnitmok|3 years ago|reply
[+] [-] frankc|3 years ago|reply
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.
[+] [-] kerblang|3 years ago|reply
[+] [-] kodah|3 years ago|reply
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.
[+] [-] unknown|3 years ago|reply
[deleted]
[+] [-] irrational|3 years ago|reply
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 ;-)
[+] [-] rendall|3 years ago|reply
These days, as a freelancer, everything I do is "line", in these terms, by definition. It's glorious.
[+] [-] Goronmon|3 years ago|reply
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.
[+] [-] Scubabear68|3 years ago|reply
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.
[+] [-] trimbo|3 years ago|reply
...
> 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-...
[+] [-] robertlagrant|3 years ago|reply
[+] [-] erwincoumans|3 years ago|reply
"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.
[+] [-] mepiethree|3 years ago|reply
[+] [-] np_tedious|3 years ago|reply
[+] [-] dsr_|3 years ago|reply
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?
[+] [-] gumby|3 years ago|reply
[+] [-] geogra4|3 years ago|reply
[+] [-] bsenftner|3 years ago|reply
[+] [-] Cthulhu_|3 years ago|reply
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.
[+] [-] jacknews|3 years ago|reply
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.
[+] [-] troelsSteegin|3 years ago|reply
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.
[+] [-] AlwaysRock|3 years ago|reply