16 ms·

The other kind of staff software engineer

419 points by adamgordonbell 4y ago

alpha5 4y ago
Fascinating insight.
physicsgraph 4y ago
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.
- dwohnitmok 4y ago
  This is true also of other branches of military. Generally support staff outnumber actual fighters.
bsenftner 4y ago
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.
adamgordonbell 4y ago
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.
- rendall 4y ago
  Really nice article. Well done.
- _the_inflator 4y ago
  Reminds me of C Sharp developers until I joined a purely MS stack using company. Also a silent majority in my opinion.
  - sciuromorpha_ 4y ago
    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.
    - jsmith45 4y ago
      Yeah. It's not a language you come across a lot ouside of corp work, it largely avoided the absurdity of AbtractFactoryFactory and similarly overdesigned architecture that is a common focus of Java jokes, and it did not suffer from language stagnation for enough years to make the alternate languages for the VM feel like actually competition, as opposed to things that are mostly useful in certain specialist scenarios.
      - astrange 4y ago
        It’s popular in games now because of Unity and il2cpp. Even though it started as a Java ripoff, it’s infinitely better because it has value types. But my impression using it in school was the standard library was even worse than Java. Where Java buries things under six namespaces of reverse domain name, C# buries them under what looks like random technical terms chosen to impress people. ie there is no reason for System.Console.WriteLine() or System.Collections.ArrayList to be where they are. It doesn’t make your program work better.
- sytelus 4y ago
geogra4 4y ago
Jokingly you could probably split this into engineers that use xml vs those that use json. I've worked in both types of companies.
- caffeine 4y ago
  I feel like nowadays that joke has evolved to devs that use JSON vs devs that use binary serialisation (like capnproto or whatever else)…
  - Cthulhu_ 4y ago
    Why not both? There's a binary serialization format for XML... (https://www.w3.org/TR/exi/ https://www.w3.org/TR/exi/)
  - xarope 4y ago
    Not that much of a joke, a lot of companies are using binary protocols for internal services e.g. gRPC, and REST for external. So, best/worst of both worlds (depending on whether you are a glass half full/half empty person)
- loudmax 4y ago
  The examples given in the article assume for the sake of argument that the only software is enterprise software. So xml all around.
- xarope 4y ago
  And Java vs just about anything else (!)
  - chrisseaton 4y ago
    Plenty of front line software at big tech companies like Google is written in Java.
    - geogra4 4y ago
      Yeah there's a lot of Java hate but faang companies definitely use it more than ocaml, lisp or what have you.
lupire 4y ago
OP admits that the distinction is mostly fictional. "Line" can means (a) whatever role the vast majority of of people do, if such exists, (b) whoever your customers see ("talent" in the entertainment/sports world), (c) the expendable interchangable cogs and cannon fodder (military, factory, and Enterprise Consulting), or other.
- tonyg 4y ago
  Not fictional. Contextual.
lupire 4y ago
Lines are straight. Staffs are are uneven. Lines help you walk by you looking at them. Staff help you walk by you holding them.
- dqpb 4y ago
  Is this a Jack Ma quote?
rendall 4y ago
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.
- Goronmon 4y ago
  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.
  - xarope 4y ago
    That's unusual, in consulting days of yore it was about 80%* billable hours * may vary of course, but nobody expects 100%, even the big 5/4.
    - Goronmon 4y ago
      Yeah, it crept up over the years. Start at 6hrs a day, then 6.5, then 7 and then 8 about 4 years ago.
      - ubermonkey 4y ago
        8 is just unrealistic, and invites fraud. BigLaw have expectations like this, but the overt toxicity of that is so famous I'd hope tech would avoid it. In some firms, with rounding allowed, it used to be common to schedule 3 20-minute calls in an hour, because it would yield 1.5h of billable time.
      - 4y ago
Cthulhu_ 4y ago
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.
mynameishere 4y ago
I guarantee you at Duke Energy the contractors are second-class citizens, are laid off first and each and every one of them will take FTE at Duke the first chance they get.
- adamgordonbell 4y ago
  I think it depends. I suspect working at ThoughtWorks is hard, going from client to client, and losing contracts when the market doesn't look good, but also there is no Martin Fowler of Duke Energy.
- hibikir 4y ago
  That happens sometimes. But other times, HR has a lot of control over FTE salaries, and little over contractors, and they compare their salary structure to other energy companies, and therefore every FTE is drastically underpaid, and gets little to no stock compensation. So in practice, a senior contractor will earn far more. This means they have a lot of trouble converting FTEs. I've worked in places where the contractors make about double, and those where it's the FTEs that make double. You really want to get a good idea of how the organization looks before you join there, because really, both kinds exist, and you don't want to be in the wrong group.
- jawns 4y ago
  The primary distinction is whether they're hired directly by Duke as a contractor, versus whether they are employed by a consulting company that is contracted by Duke. If they are hired as an individual, definitely second-class citizen, and there have been legislative pushes to make a lot of these people classified as employees. If they are employed by a company that is contracted, chances are their situation is much more comfortable.
- the_only_law 4y ago
  > I guarantee you at Duke Energy the contractors are second-class citizens In fairness, I’d bet the full time devs are too.
jacknews 4y ago
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.
dpcx 4y ago
I work for a tech company (healthcare related, but everything is tech), and we have staff positions. They're mostly meant as someone who has a decent understanding of the entire system they're working on... even have Staff Architects who understand the global system being worked on. It's almost as if each of our underlying teams are their own firms within the parent organization.
troelsSteegin 4y ago
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.
dsr_ 4y ago
Everything is, of course, blurry at the edges. If your job is doing something that basically all companies of that size do, you might be staff. If your job is something that contributes to a product or service that your company sells, you might be line. If you work on the deployment, monitoring and debugging of the CI that builds your SaaS, are you staff or line? If you work on the deployment, monitoring and debugging of your CI system that QA uses, are you staff or line? If you work on the deployment, monitoring and debugging of the point of sale systems that your brick-and-mortar stores need, are you staff or line? If you work on the security of your company which includes the SaaS that you sell, and sometimes you talk to prospective customers about those security issues, are you staff or line? The biggest question around all these is: does your company management think much about the staff/line distinction, and how will that affect what they do?
noduerme 4y ago
>> If you are a dev team within a bigger, non-tech company, you are basically an in-house agency with one client. Imma argue with this, as a developer for a bigger non-tech company (and a few small ones) I've worked for in-house agencies and the pattern is completely different. In-house, every dictat in the software comes from the top down as a fully-formed thought. Whereas being an independent contractor gives you way more creative control over how software turns out. Instead of having to accept some wireframe drawn up by another arm of the company, you get to interrogate the people who will actually be using the software and find out what they need. You have to understand the business logic more than you would if you just accepted it as a programming job alone, and therefore you become more of a design branch than just a coding branch. And I say branch because you are still an integral part of the company, but instead of telling you what to do, they come to you for advice on how to accomplish their aims.
- the_only_law 4y ago
  > If you are a dev team within a bigger, non-tech company, you are basically an in-house agency with one client. I only wish I had that level of autonomy when working for the most horrifically bureaucratic corps I’ve seen.
6510 4y ago
Where staff optimizes for staff and line for line they become opposing forces.
nuclearnice1 4y ago
I didn’t like that the article opened with an insult to all the other articles about salary or interviews.
rel2thr 4y ago
Some companies have both, One of the back doors into getting a fang job without being elite at leetcoding is to find staff style position at a fang and then transfer into a line
kitd 4y ago
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.
- duxup 4y ago
  >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.
- Jach 4y ago
  > 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.
deleted 4y ago
[deleted]
jwmoz 4y ago
Pointless piece imo, doesn't really matter.
kerblang 4y ago
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...
erwincoumans 4y ago
Calling a software engineer (swe) 'Staff' because "working on non-core product" is indeed different from the standard corpororate 'Staff' prefix as a step/level of the ladder (within an org working on either core or non-core product) "swe, senior swe, staff swe, senior staff swe, principal swe, distinguished swe, fellow swe, senior fellow swe" I would have like to see mentions of both kinds of 'Staff swe' in the article.
- np_tedious 4y ago
  I think that's why the title reads "the other kind"
  - deleted 4y ago
    [deleted]
- mepiethree 4y ago
  The article is titled The “Other Kind” of Staff SWE. Presumably the “first kind” is the definition to which you are referring
  - erwincoumans 4y ago
    Sure, I just wished the author/article would have spelled out/confirm the standard definition of 'staff swe' as step/level in the ladder before going into the 'other' meaning of 'staff swe' as being part of non-core product.
    - adamgordonbell 4y ago
      Like this, from article footnotes: When talking about “staff” in this article, I do not mean the Staff software engineer role that is found at tech companies after senior. That is a different usage of the term
      - erwincoumans 4y ago
danesparza 4y ago
I dunno man. I think that the dirty little secret is that we're all in line roles whether we like it or not. Some of us discover that sooner than others. This distinction is made plain when a company or organization isn't doing as well and tough decisions need to be made about who stays and who goes.
Scubabear68 4y ago
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.
gumby 4y ago
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.
- lumost 4y ago
  Sometimes the core sector makes a boatload of money, and the people supporting that work in turn get promotions. Companies tend to try to minimize churn in "staff" roles as there are fewer people ready to step in and replace the person who left. Similarly, recruiting for staff positions is often harder than line positions as folks often want to work on the core product mission of a company. As an analogy, consider the lone sysadmin maintaining the lone linux server hosting a multi-billion dollar companies ERP, Billing Software, and website. The company probably cares enough to ensure this person has a backup, and is paid well enough not to leave. If the everything works the company probably doesn't care enough to do a migration to a SaaS provider, replacing this admin is likely very expensive.
  - chadash 4y ago
    > As an analogy, consider the lone sysadmin maintaining the lone linux server hosting a multi-billion dollar companies ERP, Billing Software, and website. The company probably cares enough to ensure this person has a backup, and is paid well enough not to leave. If the everything works the company probably doesn't care enough to do a migration to a SaaS provider, replacing this admin is likely very expensive. Eh, I've seen people like this and maybe they get paid well, but the company also can't afford to promote them or move them around. One person I know was an expert in Fortran and worked at a large Wall Street bank doing processing of very large transactions (systems that process trillions of dollars yearly). Technically, there were "backups" who could do parts of his role, but realistically he was the only person who really understood the whole system. He would threaten to leave every so often and they'd bump his pay to an absurd level that made it hard to leave. But there was also no path the promotion for him and he got bored. At a certain point, he ended up leaving anyway.
- 4y ago
_9rq6 4y ago
Are product managers replacing the engineers as the core line role these days? Product managers talk to the CEOs more than software engineers do.
jll29 4y ago
Curiously, the term "line manager" denotes the person that is in charge of promotion, development, review and vacation request approval + expenses approval of a report (rather than the development of new product lines, which is nowadays done by distributed team in matrix settings led by a "project lead" or "technical lead"), so one would classify them as support, perhaps. To confuse things further, the "project manager" isn't the most senior manager of the project, but its _administrator_(the "project owner" is responsible for the project).
chadash 4y ago
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.
- tgv 4y ago
  If you can save 99% on cost, but sell at the same price, you've got a 10,000% profit, isn't it?
  - zdragnar 4y ago
    If the revenue is 101, cost is a dollar and the profit is a hundred, saving 99% on cost is remarkable but hardly a 10k improvement of profit.
    - joebob42 4y ago
      It may not even be that remarkable. A decent fraction of things I can accomplish for $1 I could also do for free.
frankc 4y ago
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.
kodah 4y ago
This articles sort of right, sort of wrong. Staff in the modern military means you're a careerist. It's the last rank that you can't be forced out without advancing, and might not be expected to advance at all. Staff has different kinds of connotations depend on officer and enlisted. Staff officers would never lead from the front. That's O1-O3s job, those people are actually trained by enlisted careerists before they ever get to lead. In the enlisted ranks, Staff starts with E6 (Staff Sgt) and they are typically platoon commander's. By contrast with officer ranks, Staff Sgts will still go on patrol. The officers metaphor is a bit relevant to software. It's rare for Major+ to actually work in the field (unless they're highly specialized like an Air Officer). These are basically executives. On the enlisted side Corporal through Staff are your immediate leaders that the company recognizes. Corporal is the first working leader as a team lead, Sgt lead multiple corporals, and Staff Sgt can lead multiple Sgts. This can vary by +-1 rank. I do think software does need to shift more the direction of the military where working leaders hold the majority of team direction and influence from a systemic level. Ultimately, Staff Enlisted are entrusted with direct responsibility for how and when things get done; they also (generally) have the most direction over the platoon. The biggest component I'd like to see is managers being trained by software careerists before they're ever allowed to lead a team. Edit: my experience is colored by the Marines, which focus on small team leadership and cross training. YMMV.
- deleted 4y ago
  [deleted]
AlwaysRock 4y ago
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.
trimbo 4y ago
> Someone at Thoughtworks sold Dominion Energy on the idea that Thoughtworks... if things go well, they will get follow-on business and maybe even a whitepaper. ... > Market pressures don’t apply to internal teams Market forces are constantly applied against internal IT teams, particularly in non-tech companies. The market force is replacing them with consultants. Sometimes they will make those employees train their own replacements[1][2]. Or that there are consultants that can't be fired. The project is over schedule, but too much sunk cost to replace them and no internal devs. A $6M project becomes a $1.25 billion project and fails in slow motion over a decade.[3] Anyway, my point is that it's not as simple as "internal is always safe, consulting is always tougher". [1] - https://www.nytimes.com/2015/06/04/us/last-task-after-layoff-at-disney-train-foreign-replacements.html https://www.nytimes.com/2015/06/04/us/last-task-after-layoff... [2] - https://www.mercurynews.com/2016/11/03/after-pink-slips-ucsf-tech-workers-train-their-foreign-replacements/ https://www.mercurynews.com/2016/11/03/after-pink-slips-ucsf... [3] - https://www.henricodolfing.com/2019/12/project-failure-case-study-queensland-health.html https://www.henricodolfing.com/2019/12/project-failure-case-...
- robertlagrant 4y ago
  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.
darkwater 4y ago
While we are talking about staff, then what's the meaning of "staff engineer" as in "high level engineer"?
- mcntsh 4y ago
  Engineer that works across functions and on high level engineering initiatives/domains.
tl 4y ago
> In most cases, the easiest way to tell if you are line or staff is to look at the org chart of your business. You are line if your role makes up the largest fraction of the org chart. If anything, the opposite is true. You are "line" when you are fewer in number having a more direct line to the power structure. In business, it is this, not your contribution that changes your negotiating leverage. In the original military example, mechanics, doctors, IT staff and dozens of other roles vastly outnumber actual soldiers.
irrational 4y ago
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 ;-)
Random_Person 4y ago
How about the third position (which I find myself in in): Staff->Line engineer. I work primarily on an internal support product which the company decided to license to other entities... at a ridiculously low price. We support dozens of instances and thousands of users, yet bring in less than half of one developers net salary. And, of course, my departments performance is judged on the Line work, not the Staff work.
robertlagrant 4y ago
Maybe line should be "the last non-management role the company would outsource". E.g. the air force wouldn't outsource pilots; Thoughtworks wouldn't outsource consultants.
draw_down 4y ago
frellus 4y ago
Although these divisions may exist, I'm not sure why we have to call them out and normalize them. Essentially what you've described is a two-class system of engineers. Staff engineers can save the company money. Without them the "line" engineers cannot be as efficient in their mission. Why create any sort of hierarchy? This type of thinking is antithetical to the startup mentality, but seems very amenable to the way big tech companies think. Which is exactly why I don't work for them.
- gowld 4y ago
  It's not a two-class system, it's a reality of the business incentives, and local monopoly vs competition.
- rockemsockem 4y ago
  I don't think discussing something that exists is "calling it out" or "normalizing" it. It's just discussing it and personally I think it is an interesting take that I hadn't seen phrased in this way before. Now I can think about how it impacts me personally in a new light. Definitely a net win.

Fascinating insight.

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.

dwohnitmok 4y ago
This is true also of other branches of military. Generally support staff outnumber actual fighters.

bsenftner 4y ago

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.

adamgordonbell 4y ago

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.

rendall 4y ago
Really nice article. Well done.
_the_inflator 4y ago
Reminds me of C Sharp developers until I joined a purely MS stack using company. Also a silent majority in my opinion.
- sciuromorpha_ 4y ago
  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.
  - jsmith45 4y ago
    Yeah. It's not a language you come across a lot ouside of corp work, it largely avoided the absurdity of AbtractFactoryFactory and similarly overdesigned architecture that is a common focus of Java jokes, and it did not suffer from language stagnation for enough years to make the alternate languages for the VM feel like actually competition, as opposed to things that are mostly useful in certain specialist scenarios.
    - astrange 4y ago
      It’s popular in games now because of Unity and il2cpp. Even though it started as a Java ripoff, it’s infinitely better because it has value types. But my impression using it in school was the standard library was even worse than Java. Where Java buries things under six namespaces of reverse domain name, C# buries them under what looks like random technical terms chosen to impress people. ie there is no reason for System.Console.WriteLine() or System.Collections.ArrayList to be where they are. It doesn’t make your program work better.
sytelus 4y ago

geogra4 4y ago

Jokingly you could probably split this into engineers that use xml vs those that use json. I've worked in both types of companies.

caffeine 4y ago
I feel like nowadays that joke has evolved to devs that use JSON vs devs that use binary serialisation (like capnproto or whatever else)…
- Cthulhu_ 4y ago
  Why not both? There's a binary serialization format for XML... (https://www.w3.org/TR/exi/ https://www.w3.org/TR/exi/)
- xarope 4y ago
  Not that much of a joke, a lot of companies are using binary protocols for internal services e.g. gRPC, and REST for external. So, best/worst of both worlds (depending on whether you are a glass half full/half empty person)
loudmax 4y ago
The examples given in the article assume for the sake of argument that the only software is enterprise software. So xml all around.
xarope 4y ago
And Java vs just about anything else (!)
- chrisseaton 4y ago
  Plenty of front line software at big tech companies like Google is written in Java.
  - geogra4 4y ago
    Yeah there's a lot of Java hate but faang companies definitely use it more than ocaml, lisp or what have you.

lupire 4y ago

OP admits that the distinction is mostly fictional. "Line" can means (a) whatever role the vast majority of of people do, if such exists, (b) whoever your customers see ("talent" in the entertainment/sports world), (c) the expendable interchangable cogs and cannon fodder (military, factory, and Enterprise Consulting), or other.

tonyg 4y ago
Not fictional. Contextual.

lupire 4y ago

Lines are straight. Staffs are are uneven. Lines help you walk by you looking at them. Staff help you walk by you holding them.

dqpb 4y ago
Is this a Jack Ma quote?

rendall 4y ago

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.

Goronmon 4y ago
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.
- xarope 4y ago
  That's unusual, in consulting days of yore it was about 80%* billable hours * may vary of course, but nobody expects 100%, even the big 5/4.
  - Goronmon 4y ago
    Yeah, it crept up over the years. Start at 6hrs a day, then 6.5, then 7 and then 8 about 4 years ago.
    - ubermonkey 4y ago
      8 is just unrealistic, and invites fraud. BigLaw have expectations like this, but the overt toxicity of that is so famous I'd hope tech would avoid it. In some firms, with rounding allowed, it used to be common to schedule 3 20-minute calls in an hour, because it would yield 1.5h of billable time.
    - 4y ago

Cthulhu_ 4y ago

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.

mynameishere 4y ago

I guarantee you at Duke Energy the contractors are second-class citizens, are laid off first and each and every one of them will take FTE at Duke the first chance they get.

adamgordonbell 4y ago
I think it depends. I suspect working at ThoughtWorks is hard, going from client to client, and losing contracts when the market doesn't look good, but also there is no Martin Fowler of Duke Energy.
hibikir 4y ago
That happens sometimes. But other times, HR has a lot of control over FTE salaries, and little over contractors, and they compare their salary structure to other energy companies, and therefore every FTE is drastically underpaid, and gets little to no stock compensation. So in practice, a senior contractor will earn far more. This means they have a lot of trouble converting FTEs. I've worked in places where the contractors make about double, and those where it's the FTEs that make double. You really want to get a good idea of how the organization looks before you join there, because really, both kinds exist, and you don't want to be in the wrong group.
jawns 4y ago
The primary distinction is whether they're hired directly by Duke as a contractor, versus whether they are employed by a consulting company that is contracted by Duke. If they are hired as an individual, definitely second-class citizen, and there have been legislative pushes to make a lot of these people classified as employees. If they are employed by a company that is contracted, chances are their situation is much more comfortable.
the_only_law 4y ago
> I guarantee you at Duke Energy the contractors are second-class citizens In fairness, I’d bet the full time devs are too.

jacknews 4y ago

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.

dpcx 4y ago

I work for a tech company (healthcare related, but everything is tech), and we have staff positions. They're mostly meant as someone who has a decent understanding of the entire system they're working on... even have Staff Architects who understand the global system being worked on. It's almost as if each of our underlying teams are their own firms within the parent organization.

troelsSteegin 4y ago

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.

dsr_ 4y ago

Everything is, of course, blurry at the edges. If your job is doing something that basically all companies of that size do, you might be staff. If your job is something that contributes to a product or service that your company sells, you might be line. If you work on the deployment, monitoring and debugging of the CI that builds your SaaS, are you staff or line? If you work on the deployment, monitoring and debugging of your CI system that QA uses, are you staff or line? If you work on the deployment, monitoring and debugging of the point of sale systems that your brick-and-mortar stores need, are you staff or line? If you work on the security of your company which includes the SaaS that you sell, and sometimes you talk to prospective customers about those security issues, are you staff or line? The biggest question around all these is: does your company management think much about the staff/line distinction, and how will that affect what they do?

noduerme 4y ago

>> If you are a dev team within a bigger, non-tech company, you are basically an in-house agency with one client. Imma argue with this, as a developer for a bigger non-tech company (and a few small ones) I've worked for in-house agencies and the pattern is completely different. In-house, every dictat in the software comes from the top down as a fully-formed thought. Whereas being an independent contractor gives you way more creative control over how software turns out. Instead of having to accept some wireframe drawn up by another arm of the company, you get to interrogate the people who will actually be using the software and find out what they need. You have to understand the business logic more than you would if you just accepted it as a programming job alone, and therefore you become more of a design branch than just a coding branch. And I say branch because you are still an integral part of the company, but instead of telling you what to do, they come to you for advice on how to accomplish their aims.

the_only_law 4y ago
> If you are a dev team within a bigger, non-tech company, you are basically an in-house agency with one client. I only wish I had that level of autonomy when working for the most horrifically bureaucratic corps I’ve seen.

6510 4y ago

Where staff optimizes for staff and line for line they become opposing forces.

nuclearnice1 4y ago

I didn’t like that the article opened with an insult to all the other articles about salary or interviews.

rel2thr 4y ago

Some companies have both, One of the back doors into getting a fang job without being elite at leetcoding is to find staff style position at a fang and then transfer into a line

kitd 4y ago

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.

duxup 4y ago
>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.
Jach 4y ago
> 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.

deleted 4y ago

[deleted]

jwmoz 4y ago

Pointless piece imo, doesn't really matter.

kerblang 4y ago

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...

erwincoumans 4y ago

Calling a software engineer (swe) 'Staff' because "working on non-core product" is indeed different from the standard corpororate 'Staff' prefix as a step/level of the ladder (within an org working on either core or non-core product) "swe, senior swe, staff swe, senior staff swe, principal swe, distinguished swe, fellow swe, senior fellow swe" I would have like to see mentions of both kinds of 'Staff swe' in the article.

np_tedious 4y ago
I think that's why the title reads "the other kind"
- deleted 4y ago
  [deleted]
mepiethree 4y ago
The article is titled The “Other Kind” of Staff SWE. Presumably the “first kind” is the definition to which you are referring
- erwincoumans 4y ago
  Sure, I just wished the author/article would have spelled out/confirm the standard definition of 'staff swe' as step/level in the ladder before going into the 'other' meaning of 'staff swe' as being part of non-core product.
  - adamgordonbell 4y ago
    Like this, from article footnotes: When talking about “staff” in this article, I do not mean the Staff software engineer role that is found at tech companies after senior. That is a different usage of the term
    - erwincoumans 4y ago

danesparza 4y ago

I dunno man. I think that the dirty little secret is that we're all in line roles whether we like it or not. Some of us discover that sooner than others. This distinction is made plain when a company or organization isn't doing as well and tough decisions need to be made about who stays and who goes.

Scubabear68 4y ago

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.

gumby 4y ago

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.

lumost 4y ago
Sometimes the core sector makes a boatload of money, and the people supporting that work in turn get promotions. Companies tend to try to minimize churn in "staff" roles as there are fewer people ready to step in and replace the person who left. Similarly, recruiting for staff positions is often harder than line positions as folks often want to work on the core product mission of a company. As an analogy, consider the lone sysadmin maintaining the lone linux server hosting a multi-billion dollar companies ERP, Billing Software, and website. The company probably cares enough to ensure this person has a backup, and is paid well enough not to leave. If the everything works the company probably doesn't care enough to do a migration to a SaaS provider, replacing this admin is likely very expensive.
- chadash 4y ago
  > As an analogy, consider the lone sysadmin maintaining the lone linux server hosting a multi-billion dollar companies ERP, Billing Software, and website. The company probably cares enough to ensure this person has a backup, and is paid well enough not to leave. If the everything works the company probably doesn't care enough to do a migration to a SaaS provider, replacing this admin is likely very expensive. Eh, I've seen people like this and maybe they get paid well, but the company also can't afford to promote them or move them around. One person I know was an expert in Fortran and worked at a large Wall Street bank doing processing of very large transactions (systems that process trillions of dollars yearly). Technically, there were "backups" who could do parts of his role, but realistically he was the only person who really understood the whole system. He would threaten to leave every so often and they'd bump his pay to an absurd level that made it hard to leave. But there was also no path the promotion for him and he got bored. At a certain point, he ended up leaving anyway.
4y ago

_9rq6 4y ago

Are product managers replacing the engineers as the core line role these days? Product managers talk to the CEOs more than software engineers do.

jll29 4y ago

Curiously, the term "line manager" denotes the person that is in charge of promotion, development, review and vacation request approval + expenses approval of a report (rather than the development of new product lines, which is nowadays done by distributed team in matrix settings led by a "project lead" or "technical lead"), so one would classify them as support, perhaps. To confuse things further, the "project manager" isn't the most senior manager of the project, but its _administrator_(the "project owner" is responsible for the project).

chadash 4y ago

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.

tgv 4y ago
If you can save 99% on cost, but sell at the same price, you've got a 10,000% profit, isn't it?
- zdragnar 4y ago
  If the revenue is 101, cost is a dollar and the profit is a hundred, saving 99% on cost is remarkable but hardly a 10k improvement of profit.
  - joebob42 4y ago
    It may not even be that remarkable. A decent fraction of things I can accomplish for $1 I could also do for free.

frankc 4y ago

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.

kodah 4y ago

This articles sort of right, sort of wrong. Staff in the modern military means you're a careerist. It's the last rank that you can't be forced out without advancing, and might not be expected to advance at all. Staff has different kinds of connotations depend on officer and enlisted. Staff officers would never lead from the front. That's O1-O3s job, those people are actually trained by enlisted careerists before they ever get to lead. In the enlisted ranks, Staff starts with E6 (Staff Sgt) and they are typically platoon commander's. By contrast with officer ranks, Staff Sgts will still go on patrol. The officers metaphor is a bit relevant to software. It's rare for Major+ to actually work in the field (unless they're highly specialized like an Air Officer). These are basically executives. On the enlisted side Corporal through Staff are your immediate leaders that the company recognizes. Corporal is the first working leader as a team lead, Sgt lead multiple corporals, and Staff Sgt can lead multiple Sgts. This can vary by +-1 rank. I do think software does need to shift more the direction of the military where working leaders hold the majority of team direction and influence from a systemic level. Ultimately, Staff Enlisted are entrusted with direct responsibility for how and when things get done; they also (generally) have the most direction over the platoon. The biggest component I'd like to see is managers being trained by software careerists before they're ever allowed to lead a team. Edit: my experience is colored by the Marines, which focus on small team leadership and cross training. YMMV.

deleted 4y ago
[deleted]

AlwaysRock 4y ago

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.

trimbo 4y ago

> Someone at Thoughtworks sold Dominion Energy on the idea that Thoughtworks... if things go well, they will get follow-on business and maybe even a whitepaper. ... > Market pressures don’t apply to internal teams Market forces are constantly applied against internal IT teams, particularly in non-tech companies. The market force is replacing them with consultants. Sometimes they will make those employees train their own replacements[1][2]. Or that there are consultants that can't be fired. The project is over schedule, but too much sunk cost to replace them and no internal devs. A $6M project becomes a $1.25 billion project and fails in slow motion over a decade.[3] Anyway, my point is that it's not as simple as "internal is always safe, consulting is always tougher". [1] - https://www.nytimes.com/2015/06/04/us/last-task-after-layoff-at-disney-train-foreign-replacements.html https://www.nytimes.com/2015/06/04/us/last-task-after-layoff... [2] - https://www.mercurynews.com/2016/11/03/after-pink-slips-ucsf-tech-workers-train-their-foreign-replacements/ https://www.mercurynews.com/2016/11/03/after-pink-slips-ucsf... [3] - https://www.henricodolfing.com/2019/12/project-failure-case-study-queensland-health.html https://www.henricodolfing.com/2019/12/project-failure-case-...

robertlagrant 4y ago
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.

darkwater 4y ago

While we are talking about staff, then what's the meaning of "staff engineer" as in "high level engineer"?

mcntsh 4y ago
Engineer that works across functions and on high level engineering initiatives/domains.

tl 4y ago

> In most cases, the easiest way to tell if you are line or staff is to look at the org chart of your business. You are line if your role makes up the largest fraction of the org chart. If anything, the opposite is true. You are "line" when you are fewer in number having a more direct line to the power structure. In business, it is this, not your contribution that changes your negotiating leverage. In the original military example, mechanics, doctors, IT staff and dozens of other roles vastly outnumber actual soldiers.

irrational 4y ago

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 ;-)

Random_Person 4y ago

How about the third position (which I find myself in in): Staff->Line engineer. I work primarily on an internal support product which the company decided to license to other entities... at a ridiculously low price. We support dozens of instances and thousands of users, yet bring in less than half of one developers net salary. And, of course, my departments performance is judged on the Line work, not the Staff work.

robertlagrant 4y ago

Maybe line should be "the last non-management role the company would outsource". E.g. the air force wouldn't outsource pilots; Thoughtworks wouldn't outsource consultants.

draw_down 4y ago

frellus 4y ago

Although these divisions may exist, I'm not sure why we have to call them out and normalize them. Essentially what you've described is a two-class system of engineers. Staff engineers can save the company money. Without them the "line" engineers cannot be as efficient in their mission. Why create any sort of hierarchy? This type of thinking is antithetical to the startup mentality, but seems very amenable to the way big tech companies think. Which is exactly why I don't work for them.

gowld 4y ago
It's not a two-class system, it's a reality of the business incentives, and local monopoly vs competition.
rockemsockem 4y ago
I don't think discussing something that exists is "calling it out" or "normalizing" it. It's just discussing it and personally I think it is an interesting take that I hadn't seen phrased in this way before. Now I can think about how it impacts me personally in a new light. Definitely a net win.