7 ms·

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 w

• 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
  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.
  • j7ake 4y ago
    The term staff scientist existed before google (eg at National labs) and it probably was derived from that.
  • chrisseaton 4y ago
    Google got it from industry research labs, the industry research labs got it from the national labs, who got it from the military.
  • photochemsyn 4y ago
    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.
    • nunez 4y ago
      the incentive structure is reversed in academia. staff are closer to adjuncts than full-time faculty positions in compensation and benefits
  • 4y ago
• cushychicken 4y ago
  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)
  • the_only_law 4y ago
    > 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.
  • kleinsch 4y ago
    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.
    • 4y ago
• noduerme 4y ago
  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.
  • drdec 4y ago
    > 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.
  • tobyjsullivan 4y ago
    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.
• phkahler 4y ago
  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.
  • rubidium 4y ago
    “ I always hated the cost center vs profit center distinction.” You may hate it but ignore it at your peril. It’s how the company sees you.
    • robertlagrant 4y ago
      I think the issue with it is that finance get to dictate how a company's strategy goes, which may not work well in any industry that's hard to understand (e.g. tech).
  • kqr 4y ago
    > 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.
• ChrisMarshallNY 4y ago
  > They are the dark matter of software developers. That reminds me of an article that was linked from here, a couple of years ago, titled “IT Runs On Java 8”[0]. I worked for hardware manufacturers, for most of my career, and can report that it’s even worse. That’s because the company does have an engineering culture, but one with drastically different priorities and processes. Our software shops were expected to run in hardware patterns. [0] https://vickiboykis.com/2019/05/10/it-runs-on-java-8/ https://vickiboykis.com/2019/05/10/it-runs-on-java-8/
• deleted 4y ago
  [deleted]
• jimmaswell 4y ago
  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.
  • iguanayou 4y ago
    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.
    • jimmaswell 4y ago
      I feel like you'll never be out of a job long with a good work history, good references, and knowing your way around overall web development. Might not be enough for Facebook but it seems like enough for us.
  • sdsaga12 4y ago
    What type and size company do you work for? And how did you find it? That sounds like a pretty ideal scenario to me, but I'm not sure how to go about finding similar positions.
    • jimmaswell 4y ago
      I don't want to make myself too identifiable, but it's a fairly big place and I lucked into it more than anything. Can't give any specific advice how to find a similar job besides looking for remote listings at non tech places.
  • 4y ago
• Jach 4y ago
  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).
• anoy8888 4y ago
  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
  • oblio 4y ago
    That's nice, I think the question on everyone's mind is: is your pay comparable to FAANG?
    • anoy8888 4y ago
      Nope. Much lower . Fanng salaries are crazy. And I live in a developing country. But the salary is comfortable
• gernb 4y ago
  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.
  • filoleg 4y ago
    Fully agreed with your overall position, but I got a small correction in regards to what you said about fintech. While you are correct in that at a lot of finance companies, devs just act as "support for the real business" (e.g., Goldman Sachs). But there are others where devs and quants pretty much harmoniously run the show. Look at something like Jane Street and their tech blog[0]. Their annual "what our interns have wrought" blog posts grab my attention like nothing else, and from everything I read coming from them, it seems like engineering there is not just "support for the real business". And there are quite a few companies in fintech like this, they just won't be flashed in the mass media due to their relatively small size, but everyone in the industry (and plenty of people on the outside) knows about them. Out of all things, they are known as one of the largest contributors to OCaml language and its ecosystem. Jane Street was just a singular example, and there are other fintech firms of a similar engineering-focused culture. 0. https://blog.janestreet.com/ https://blog.janestreet.com/
    • bcj7393nsk 4y ago