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.
> 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 '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)
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.
"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.
> 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.
"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 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.
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.
> 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.
> 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.
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.
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.
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".
I work at a non-tech company. I mostly write/maintain unexciting components for a website's CMS, and any tertiary work around that. Easygoing, remote, great work/life balance, good pay. Often go fishing or work on projects like an ebike for a lot of the day, sporadically checking the work chat and tuning into meetings from my phone. On the rare occasion something really important comes up I'm always ready to jump in and give 100%. Established a good reputation and get great performance reviews for what I do. I'd probably never trade this for a job at Google et al with higher expectations and stress.
My partner and I both have similar roles to yours, in non-tech companies. Sometimes we both feel like we’re not being ambitious enough… but we walk into town for two-hour lunches together 2-3 times per week, finish household errands on weekdays, and never have to worry about money. The initial transition from “working hard” to “hardly working” was difficult to settle into, but imo as long as we can keep up our skills with all this extra time, it’s a very enjoyable lifestyle.
I've got the same type of deal here. I just worry about skills getting outdated since I'm only working on an in-house system and doing mostly maintenance. But perhaps that fear is overblown.
I could easily hop to a gig with more responsibility and more opportunity for increasing my skills - but also more stress.
I 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.
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 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.
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.
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.
I worked as Consultant for several years and instead of a daily rate, always proposed for each of my large projects, that companies would pay me 0.5% of the money my activities made the company or 0.1% of the money I saved the company.
unless you work in sales, it is very hard to prove how lines of code can translate in more money for the company. maybe easier in startups but nearly impossible in big corps where everyone is just a cog in the machine
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.
It's not linear. Cutting 1% of costs while maintaining the same revenue might be trivial. Cutting 10% of costs might be very doable. Cutting 50% of costs might be incredibly hard.
And I assure you that growing revenue by 100% is far easier than cutting costs by 100% (while maintaining current revenue).
Also, there's a human element to it. I'd venture that most CEOs would much rather the company make more money than have to lower bonuses and benefits, cut down of office space and fire employees.
That’s essentially just a race to the bottom in most cases. There aren’t too many cases where you can realistically lower your price below your competitor’s cost AND have your competitor be unable to make the necessary changes to match you.
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.
Is your team an investment? I know we (not me, someone else I work with) asked our CEO about a team not making money, and he responded yeah, they started the team knowing it was a ten year investment, now it is looking like a 20 year investment and they are fine with it. My opinion is the team in question will never pay off the investment, but it will eventually come close enough to break even and the goodwill they generate for the company more than makes up the monitory loss. (How do you count someone who decides to buy our most profitable product vs a competitors because we have an unrelated product they use)
That's not necessarily (and probably isn't) sad, I can think of two general reasons for that to happen and it not be a problem:
- Growth, e.g. trivially everyone at a company that's yet to turn a profit
- Critical but not revenue-generating function
I mean basically that's 'line' and 'staff' from OP (but for line the subset of companies/teams that isn't profitable yet). The latter being a 'cost centre'.
If you don't like it ('what's sad is') then the article might be a useful approach/line of thought when looking for your next role - i.e. a 'line' job (at a profitable company on a team working on the profitable thing).
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.
If you save $500k this year by optimizing some pattern or behavior (eg infrastructure) then why wouldn't that $500k also be saved the next year? You're right if it's a one-time cut (eg no free snacks this year) but most savings are going to be on things that happen more than once.
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.
I don't disagree with the article. Within a tech company, it's obvious why they value engineers. In a "staff" you might also be highly valued or you might not be. As an example, I've recently noticed that home depot has a superb website. Looking at the quality of it, they've obviously put a lot of thought and resources into it. It's something they value. The people working on it might be in the "staff" bucket, but I'd bet the C-Suite is well aware of the impact they are having. On the other hand, I've seen companies where the "staff" engineers are completely disregarded.
This view is slightly wrong when it comes to software. Software is a force multiplier, not a cost reducer.
Sometimes they're the same. Sometimes they aren't. A well placed, smart team of "staff" engineers can increase revenue as much or more than a team of line employees.
> Obviously, a rational CEO would see $1m cost savings the same as a $1m gain in profits, but CEO's are not rational beings (nor is any human) and understanding that they usually prefer higher revenue to lower costs is fundamental to understanding how they value different parts of the company. It's not fair, it's just truth (at least in many companies).
A rational CEO prefers revenue growth as companies are valued based on revenue, and the CEO's purpose is to maximize per share value.
Percentages are interesting metrics, but real dollar values are more important when you're talking finances. If profit is revenue is $100 and costs are $1, you've got a huge profit margin, but it is unlikely that you can grow that revenue to $10m. If you have $5m in revenue and $2.5m in costs, your profit margin in percentages is lower, but you have the basis for a company that can reinvest profits to increase revenue growth.
That's called COGS, or Cost Of Goods and Services. It's separate the kind of costs he's talking about. If you're working on COGS you're working in a profit center generating revenue, not in a cost center performing necessary but expensive functions.
Tech doesn't usually measure COGS, because the cost of another user on a website is near zero.
A great point on how profit margins are not always the best metric! A panhandler has almost no costs, so their profit margins are huge. But it's not a very scalable business :)
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 ;-)
Readit News
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.
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.
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/
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)
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.
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.
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 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!
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.
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.
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.
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.
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/
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.
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".
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.
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.)
Deleted Comment
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).
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.
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.
Not one ever took up on this offer...
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.
And I assure you that growing revenue by 100% is far easier than cutting costs by 100% (while maintaining current revenue).
Also, there's a human element to it. I'd venture that most CEOs would much rather the company make more money than have to lower bonuses and benefits, cut down of office space and fire employees.
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.
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.
- Growth, e.g. trivially everyone at a company that's yet to turn a profit
- Critical but not revenue-generating function
I mean basically that's 'line' and 'staff' from OP (but for line the subset of companies/teams that isn't profitable yet). The latter being a 'cost centre'.
If you don't like it ('what's sad is') then the article might be a useful approach/line of thought when looking for your next role - i.e. a 'line' job (at a profitable company on a team working on the profitable thing).
Note - Companies can be valued at top line ARR/Revenue and/or EBITDA, so YMMV, even in the PE world.
Working in an area that produce revenue - what does that even mean? Should you work in marketing in order to increase demand ? Rather then in production ?
Deleted Comment
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.
The article's staff vs line distinction cuts it a little differently, and definitely gives a rosier picture of working in a staff role.
Sometimes they're the same. Sometimes they aren't. A well placed, smart team of "staff" engineers can increase revenue as much or more than a team of line employees.
A rational CEO prefers revenue growth as companies are valued based on revenue, and the CEO's purpose is to maximize per share value.
Good read on the shortcomings of the "agency theory" based view that you're assuming, and which thankfully is finally becoming less of the de facto view: https://hbr.org/2017/05/the-error-at-the-heart-of-corporate-...
Tech doesn't usually measure COGS, because the cost of another user on a website is near zero.
Deleted Comment
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.
Staff in the modern military means you're a careerist. It's the last rank that you can't be forced out without advancing, and might not be expected to advance at all.
Staff has different kinds of connotations depend on officer and enlisted. Staff officers would never lead from the front. That's O1-O3s job, those people are actually trained by enlisted careerists before they ever get to lead. In the enlisted ranks, Staff starts with E6 (Staff Sgt) and they are typically platoon commander's. By contrast with officer ranks, Staff Sgts will still go on patrol.
The officers metaphor is a bit relevant to software. It's rare for Major+ to actually work in the field (unless they're highly specialized like an Air Officer). These are basically executives. On the enlisted side Corporal through Staff are your immediate leaders that the company recognizes. Corporal is the first working leader as a team lead, Sgt lead multiple corporals, and Staff Sgt can lead multiple Sgts. This can vary by +-1 rank.
I do think software does need to shift more the direction of the military where working leaders hold the majority of team direction and influence from a systemic level. Ultimately, Staff Enlisted are entrusted with direct responsibility for how and when things get done; they also (generally) have the most direction over the platoon. The biggest component I'd like to see is managers being trained by software careerists before they're ever allowed to lead a team.
Edit: my experience is colored by the Marines, which focus on small team leadership and cross training. YMMV.
Deleted Comment
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 ;-)