[HN Gopher] The other kind of staff software engineer
___________________________________________________________________
The other kind of staff software engineer
Author : adamgordonbell
Score : 349 points
Date : 2022-05-13 10:17 UTC (12 hours ago)
(HTM) web link (earthly.dev)
(TXT) w3m dump (earthly.dev)
| Scubabear68 wrote:
| 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.
| troelsSteegin wrote:
| 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.
| kerblang wrote:
| 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...
| dsr_ wrote:
| 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?
| rel2thr wrote:
| 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
| geogra4 wrote:
| 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 wrote:
| I feel like nowadays that joke has evolved to devs that use
| JSON vs devs that use binary serialisation (like capnproto or
| whatever else)...
| xarope wrote:
| 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)
| Cthulhu_ wrote:
| Why not both? There's a binary serialization format for
| XML... (https://www.w3.org/TR/exi/)
| loudmax wrote:
| The examples given in the article assume for the sake of
| argument that the only software is enterprise software. So xml
| all around.
| xarope wrote:
| And Java vs just about anything else (!)
| chrisseaton wrote:
| Plenty of front line software at big tech companies like
| Google is written in Java.
| geogra4 wrote:
| Yeah there's a lot of Java hate but faang companies
| definitely use it more than ocaml, lisp or what have you.
| lupire wrote:
| 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 wrote:
| Not fictional. Contextual.
| frellus wrote:
| 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 wrote:
| It's not a two-class system, it's a reality of the business
| incentives, and local monopoly vs competition.
| rockemsockem wrote:
| 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.
| kitd wrote:
| 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.
| Jach wrote:
| > 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.
| duxup wrote:
| >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.
| trimbo wrote:
| > 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...
|
| [2] - https://www.mercurynews.com/2016/11/03/after-pink-slips-
| ucsf...
|
| [3] - https://www.henricodolfing.com/2019/12/project-failure-
| case-...
| robertlagrant wrote:
| 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.
| erwincoumans wrote:
| 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 wrote:
| I think that's why the title reads "the other kind"
| [deleted]
| mepiethree wrote:
| The article is titled The "Other Kind" of Staff SWE. Presumably
| the "first kind" is the definition to which you are referring
| erwincoumans wrote:
| 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 wrote:
| 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 wrote:
| Indeed, like that but then in the main text instead of in
| a footnote, so it doesn't get overlooked. Anyway, I
| enjoyed your nice writing and congrats with the HN
| exposure!
| danesparza wrote:
| 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.
| lupire wrote:
| 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 wrote:
| Is this a Jack Ma quote?
| jll29 wrote:
| 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).
| Random_Person wrote:
| 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.
| darkwater wrote:
| While we are talking about staff, then what's the meaning of
| "staff engineer" as in "high level engineer"?
| mcntsh wrote:
| Engineer that works across functions and on high level
| engineering initiatives/domains.
| [deleted]
| rendall wrote:
| 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 wrote:
| _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.
| rendall wrote:
| In that case, just don't sweat it. It's all billable. Lunch,
| too, apparently. That's just what the sales contract
| stipulates, so, it's not your problem.
|
| The stress comes from deciding which hour you bill and which
| you don't. Bill all the things!
| Goronmon wrote:
| _In that case, just don 't sweat it. It's all billable._
|
| The budget for these projects won't support that. Billing
| an hour of lunch everyday just for myself would exceed the
| retainer allotted for some of these projects.
|
| And it wouldn't work anyways. Hours are billed to specific
| tasks, individual to the person down to 15 minute
| increments.
| rendall wrote:
| Ok. So. You are expected to bill 8 hours, and not lunch,
| so you are tacitly required to work more than 8 hours per
| day.
|
| What company is this? Are you in the US?
| [deleted]
| xarope wrote:
| 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 wrote:
| Yeah, it crept up over the years. Start at 6hrs a day, then
| 6.5, then 7 and then 8 about 4 years ago.
| lmkg wrote:
| I've worked as a consultant at various jobs, with
| billable expectations ranging from 55% to 85%. The
| largest company I worked for, which was a Big Four
| consultancy, had the highest billable expectation. But
| they also had entire departments of non-billable support
| staff. The smallest company I worked for also had the
| smallest billable expectation, but also expected certain
| non-billable work of us (which I generally liked).
|
| The Big Four company also calculated their billable
| expectation on a _nine_ -hour workday. So working eight
| billable hours per day every day meant your billable rate
| was only 89%. It was fine with them if you only put 40
| hours a week into the time-tracker, but the denominator
| was 45.
| ubermonkey wrote:
| 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.
| mgkimsal wrote:
| I contracted at a place where this was expected, but any
| 'meetings' you were just supposed to bill to the
| client/project as well. Some folks were on longterm/large
| projects - like... 15 people on one client project. 1hr
| meeting? It's just... billable time.
|
| I was stuck on support dealing with 6-8 different clients. I
| was _supposed_ to split up time between the clients. 1 hr
| 'all hands' meeting for the company? Just charge each of
| those 6 clients 10 minutes each - even if you've not done
| anything on their project for the last 2 weeks (for example).
|
| So... I started getting push back from higher-ups asking why
| I was billing projects I wasn't working on.
|
| "I don't get paid unless I put billable hours in your system,
| and this is what your email said to do".
|
| "That's not what we meant..."
|
| "Well... what did you mean? Which of the 7 client projects
| I'm supporting should get billed for the 2 hr 'state of the
| company' meeting you made us attend last week?"
|
| "I'll get back to you..."
|
| Which they never did. I'm not there any longer. This was
| right before covid, and everything got turned upside down
| after that. I left soon after.
| lesuorac wrote:
| > "Well... what did you mean? Which of the 7 client
| projects I'm supporting should get billed for the 2 hr
| 'state of the company' meeting you made us attend last
| week?"
|
| > "I'll get back to you..."
|
| Heh, I've met people who when asked to attend a meeting ask
| what charge number to use and if they don't get one they
| don't attend.
| rendall wrote:
| I used to scroll through my github history, parseling out
| which precise minutes went where. No. Life is too short,
| and the bean counters don't really give a shit, they just
| want a number. 7.5 hours a day regardless, unless I worked
| 5 hours or 10 hours, then I put that.
| tl wrote:
| > 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.
| noduerme wrote:
| >> 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 wrote:
| > 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.
| Cthulhu_ wrote:
| 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.
| irrational wrote:
| 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 ;-)
| bsenftner wrote:
| 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.
| gumby wrote:
| 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.
| jnwatson wrote:
| Yes. Most of the generals in the Air Force are former pilots
| and many of the executives at Big Oil are chemical or petroleum
| engineers.
| lumost wrote:
| 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 wrote:
| _> 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.
| draw_down wrote:
| physicsgraph wrote:
| 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 wrote:
| This is true also of other branches of military. Generally
| support staff outnumber actual fighters.
| 6510 wrote:
| Where staff optimizes for staff and line for line they become
| opposing forces.
| Taylor_OD wrote:
| 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.
| jwmoz wrote:
| Pointless piece imo, doesn't really matter.
| frankc wrote:
| 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.
| chadash wrote:
| 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.
| mbesto wrote:
| 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.
| [deleted]
| drchopchop wrote:
| 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.
| fdasfsdfgasdfds wrote:
| 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.
| robertlagrant wrote:
| Cloud companies do present unique opportunities for easy
| saving, though.
| pgodzin wrote:
| > 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.
| whimsicalism wrote:
| that makes no sense at all
| ncmncm wrote:
| Cost savings we count are usually recurring in the same way.
| Brystephor wrote:
| 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.
| pgodzin wrote:
| Agree on things like infrastructure optimization. Most
| significant savings happen on people costs though, and
| layoffs/hiring freezes tend to not last forever, and also
| have impacts on future growth as well.
|
| Compared to the same amount of revenue offering, most top
| SaaS companies have >100% net dollar retention, which means
| that their existing contracts tend to grow year-over-year
| from usage/upsells, so the long-term value of that $1m in
| revenue increases over time.
| solatic wrote:
| 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.
| nunez wrote:
| 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.
| hathym wrote:
| 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
| Brystephor wrote:
| You don't need to prove it. You just need to justify the
| number you show.
|
| For example: you build a feature to notify customers via
| email that they have a balance due. The email includes a
| link with UTM tracking stuff. You also have metrics as to
| who pays and when. So now you can say "X number of people
| paid their balance within Y hours of an email being sent
| out, and within Z minutes of the email linked being
| clicked" and total up the amount of balances paid. Sure,
| your feature isn't 100% responsible for enabling that
| balance to be collected, but it deserves to say it
| contributed to a portion of the collected balance value.
| SpicyLemonZest wrote:
| I wouldn't say "nearly impossible", although big companies
| do tend to have a few teams in that position. Everywhere
| I've worked, large or small, there have been a substantial
| number of engineers who justify their work in terms of
| money for the company and rocket up the career ladder
| because of it. (And I've seen a lot of seemingly "cog in
| the machine" tasks that have large dollar amounts attached
| as far as management is concerned.)
| belter wrote:
| 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.
|
| Not one ever took up on this offer...
| chadash wrote:
| Probably because it's ambiguous and opens them up to legal
| headaches when there's disagreement over how much was made
| or saved.
| belter wrote:
| No. I always made it very clear.
|
| Example: Show me your current budget for your main data
| center. Let me show a proposal for a Cloud move that will
| keep equivalent or better quality of service, including
| training and while defining KPI's for success.
| krisrm wrote:
| Seems like that would quickly turn into a game of reverse
| engineering shitty KPIs, would it not?
| belter wrote:
| I agree some play the game of working for the KPI's as
| defined.
|
| The main point of the proposal was always clear up front.
| I was not the one deciding on KPI's it was a joint
| choice.
|
| For the SAME business applications and SAME business
| processes:
|
| - At the end of a quarter you either spend less OR more
| with your infra costs including required teams.
|
| - At the end of a quarter you either have more uptime OR
| less uptime.
|
| - At the end of a quarter you either spend more on
| licenses OR less.
|
| Some KPI's are somewhat objective.
| mbesto wrote:
| > The main point of the proposal was always clear up
| front. I was not the one deciding on KPI's it was a joint
| choice.
|
| Which is exactly the parent's issue with their statement
| "I always make it clear". Many rev share negotiations
| break down quickly due to the nature of these deal:
|
| - The profit maximizing buyer of said services has little
| incentive to pay you your "fair" share, EVEN if they do
| in fact create more revenue because of said services
| effect. They'll find every way to pay you as little as
| possible within the bounds of your contract.
|
| - A buyer of said services rarely will rarely let you
| into their financial systems to validate. Even if they
| do, financials notoriously are easy to manipulate/game
| (ever heard of Adj. EBITDA?). The overhead of financial
| clarity is rarely worth the headache. Heck, most
| businesses internal operations rarely can create clear
| ROI their projects when they used internal resources much
| less using external resources.
|
| - There are so many hidden variables that it's nearly
| impossible to control for your impact. Let's say you help
| reduce a company's EC2 instances from 10 to 7.
| Savings...great! Now the company grows and they need 8
| EC2 instances. Did you still save them money? Down the
| rabbit hole we go...
|
| I get what you're saying but you're living in a vacuum if
| you think you can universally demand that type of
| contract. They're possible but require the stars to
| align.
|
| Note - I'm talking specifically about professional
| services / consulting work.
| vineyardmike wrote:
| Yea because people want a single invoice and to be done
| with you. No one wants to pay a ongoing expense, nor an
| expense that isn't fixed. Math/accounting is way harder.
| didibus wrote:
| Cutting cost can often bring in revenue.
|
| 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.
| devoutsalsa wrote:
| 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.
| whimsicalism wrote:
| This happens all the time. Your objection around
| competitors could equally apply to revenue growing areas of
| work.
| the_only_law wrote:
| What's sad is I'm pretty sure the team I work I'm collectively
| paid more money than we bring in yearly.
| bluGill wrote:
| 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)
| OJFord wrote:
| 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).
| jstx1 wrote:
| I've never had a job where this wasn't the case.
| z3t4 wrote:
| 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 ?
| awkward wrote:
| 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.
| chadash wrote:
| 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.
| tgv wrote:
| If you can save 99% on cost, but sell at the same price, you've
| got a 10,000% profit, isn't it?
| zdragnar wrote:
| 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 wrote:
| It may not even be that remarkable. A decent fraction of
| things I can accomplish for $1 I could also do for free.
| emaginniss wrote:
| 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.
| chadash wrote:
| 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 :)
| awkward wrote:
| 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.
| throwanem wrote:
| I've seen the distinction drawn, usefully I think, between
| "Cost of Revenue" as more or less fixed operating costs eg
| AWS spend, and "Customer Acquisition Cost" as specifically
| the average spend to gain "another user on a website",
| usually in a way that can be either considered in the
| aggregate or broken out per channel such as for specific ad
| vendors or similar.
|
| I think "COGS" as discussed here would probably be a rollup
| of both? Not sure; while I've been in orgs where the cost
| center/profit center distinction was made, I haven't run
| into a situation where COGS was a metric I saw used.
| awkward wrote:
| Cost of Revenue and Customer Acquisition Cost are both
| different metrics. COGS is used in manufacturing in order
| to peg inputs to a per widget basis. Cost of Revenue gets
| used in tech because per customer costs are both a bad
| way to measure it and likely to be fractions of cents.
|
| Customer Acquisition Cost gets used in subscription
| businesses to measure sales and marketing performance. It
| can be relevant alongside COGS if you're manufacturing
| the thing you're selling subscriptions to, but that's
| kinda rare.
| throwanem wrote:
| Got it. Thanks for the clarification!
| names_are_hard wrote:
| I'm not sure if you're talking about at the executive level
| or at the engineer level, but here's some anecdata:
|
| At the big tech (household name) I work we definitely spend
| a lot of energy talking about COGS a engineers. We have a
| LOT of data, and we spend a lot of money on cloud services
| to keep our product running - you want to add a new piece
| of data to this database to support some new feature? Go
| calculate how much it'll cost in storage and compute and if
| it's above some threshold, request special approval. You
| want to improve performance by caching our indexing? Let's
| talk about how much that'll be in COGS. This stuff ain't
| free, all those users add up.
|
| The interesting bit is that all this COGS isn't actually
| money that transfers hands, the cloud we use is our own.
| But it isn't free and internal accounting is taken
| seriously.
| jacknews wrote:
| 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.
| kodah wrote:
| 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]
| mynameishere wrote:
| 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.
| hibikir wrote:
| That happens sometimes. But other times, HR has a lot of
| control over FTE salaries, and little over contractors, and
| they compare their salary structure to other energy companies,
| and therefore every FTE is drastically underpaid, and gets
| little to no stock compensation. So in practice, a senior
| contractor will earn far more. This means they have a lot of
| trouble converting FTEs.
|
| I've worked in places where the contractors make about double,
| and those where it's the FTEs that make double. You really want
| to get a good idea of how the organization looks before you
| join there, because really, both kinds exist, and you don't
| want to be in the wrong group.
| the_only_law wrote:
| > I guarantee you at Duke Energy the contractors are second-
| class citizens
|
| In fairness, I'd bet the full time devs are too.
| jawns wrote:
| 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.
| adamgordonbell wrote:
| 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.
| dpcx wrote:
| 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.
| adamgordonbell wrote:
| 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.
| [deleted]
| _the_inflator wrote:
| Reminds me of C Sharp developers until I joined a purely MS
| stack using company. Also a silent majority in my opinion.
| sciuromorpha_ wrote:
| 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 wrote:
| 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.
| gernb wrote:
| 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.
| dvtrn wrote:
| _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".
| Aeolun wrote:
| Feels like the opposite to me. A lot of ops teams got
| turned into 'devops' teams overnight without any change in
| mode of operations, leading to skewed expectations from
| developers that actually know what the 'dev' part is about.
|
| At least, I was fairly surprised by how our devops team
| looked at what I was trying to push onto them until I
| learned their origin story.
| dvtrn wrote:
| Chesterton's fence is a real bitch, ain't it?
| filoleg wrote:
| 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/
| bcj7393nsk wrote:
| > but I got a small correction in regards to what you said
| about fintech.
|
| Market makers like Jane Street are not fintech. They are
| trading companies.
|
| Jane Street in particular is still very much gut-feeling
| point-and-click trading, compared to Jump and Citadel
| Securities.
|
| Fintech companies are more related to payments: Stripe,
| Gusto, Plaid, etc.
|
| Another difference is pay/TC: trading companies pay
| significantly more than fintech and MAANG, even for SWEs.
| phkahler wrote:
| 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.
| kqr wrote:
| > 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.
| phkahler wrote:
| Saw this in interview at an RV company. Their market tanked
| in 2008 and the invested in engineering projects. Bought
| competitors after the recovery by selling newer better
| product.
| jonny_eh wrote:
| > However, small research projects are an incredibly cheap
| way to learn things and invent new technologies
|
| And recessions are the time when this research is at its
| cheapest.
| OJFord wrote:
| > 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.
| rubidium wrote:
| " 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 wrote:
| 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).
| ChrisMarshallNY wrote:
| _> 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/
| sytelus wrote:
| 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.
| MikePlacid wrote:
| 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.
| photochemsyn wrote:
| 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 wrote:
| the incentive structure is reversed in academia. staff are
| closer to adjuncts than full-time faculty positions in
| compensation and benefits
| j7ake wrote:
| The term staff scientist existed before google (eg at
| National labs) and it probably was derived from that.
| chrisseaton wrote:
| Google got it from industry research labs, the industry
| research labs got it from the national labs, who got it from
| the military.
| morelisp wrote:
| 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.)
| justinhj wrote:
| In my experience I think of Senior as an autonomous builder
| of a thing that they are told to build. Staff is the same
| but may work across multiple teams and help define the
| thing that needs building. They will usually have
| considerably broad experience. They get thrown at random
| problems nobody is sure how to fix. Principals extend that
| concept but may be industry leaders in a field or at least
| deeply specialised.
| rendall wrote:
| Really nice article. Well done.
| cushychicken wrote:
| 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 wrote:
| > 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 wrote:
| 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.
| cushychicken wrote:
| I think we'll have to agree to disagree. My takeaway from
| much of Larson's writing is that staff engineers _can_ do
| the line work required to launch new product lines, but
| generally don 't, because the impacts of their strategic
| work is much higher than that of line style coding.
|
| They direct and advise on technical strategy, but delegate
| execution to others, because having the 10k foot view is
| typically more valuable when deployed on strategic
| opportunities.
| ZephyrBlu wrote:
| Will and this article use "staff" in a completely
| different sense. The author of the post even acknowledges
| this difference in his HN comment at the top of this
| post.
|
| Will uses "Staff Software Engineer" as the rank of Staff
| (I.e. one above Senior).
|
| This article uses "staff engineer" not as the rank, but
| as the type of engineer (Line vs staff).
| triyambakam wrote:
| I think you're missing what the above is saying, i.e.
| that the featured article uses staff in a different way
| than Larson and most discussions around "staff".
| roland35 wrote:
| "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!
| cushychicken wrote:
| Hah, yeah, mental note to reframe as "destined".
|
| I also really like the mentorship angle. It's really cool
| to watch someone grow, and how fast they do when given
| stuff that's just outside their current capability level.
| wreath wrote:
| > 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.
|
| 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.
| RHSeeger wrote:
| This is a fairly well known issue Peter Principle
| (https://en.wikipedia.org/wiki/Peter_principle)
|
| > The Peter principle is a concept in management developed
| by Laurence J. Peter, which observes that people in a
| hierarchy tend to rise to "a level of respective
| incompetence": employees are promoted based on their
| success in previous jobs until they reach a level at which
| they are no longer competent, as skills in one job do not
| necessarily translate to another.[
| icedchai wrote:
| Yep. I've see this happen. People who are good at coding
| may actually want to code, not write "tech specs" and have
| review meetings all day.
| ncmncm wrote:
| "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.
| dvtrn wrote:
| _as much so as "combat vs logistics"._
|
| First time I've ever heard these two things talked about as
| a matter of "this _versus_ that " and not "combat _and_
| logistics ".
|
| I'd hate to be a CO or NCO under a General who looked at
| the two as somehow adversarial or mutually exclusive in
| terms of planning and resourcing.
|
| Yours is quite an interesting analogy, here.
| anoy8888 wrote:
| 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
| Jach wrote:
| 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).
| jimmaswell wrote:
| 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.
| sdsaga12 wrote:
| 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 wrote:
| 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.
| escapedmoose wrote:
| 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.
| iguanayou wrote:
| 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 wrote:
| 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.
| noduerme wrote:
| 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.
| tobyjsullivan wrote:
| 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.
| ncmncm wrote:
| The author isn't saying it, but business schools are.
|
| The business school mantra is _invest in profit centers,
| nickel-and-dime cost centers_. If you are so unfortunate as
| to be at a company run by an MBA and are in a cost center,
| woe to you.
| waych wrote:
| The author called out that profit centers and cost
| centers are similar, but different, to the staff vs line
| distinction being made.
|
| Why equate them as the same here?
| drdec wrote:
| > 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.
| alpha5 wrote:
| Fascinating insight.
| sreeramb93 wrote:
| Are product managers replacing the engineers as the core line
| role these days?
|
| Product managers talk to the CEOs more than software engineers
| do.
| nuclearnice1 wrote:
| I didn't like that the article opened with an insult to all the
| other articles about salary or interviews.
| robertlagrant wrote:
| 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.
___________________________________________________________________
(page generated 2022-05-13 23:00 UTC)