The other kind of staff software engineer
earthly.dev
earthly.dev
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.
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.
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.)
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)
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.
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.
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.
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).
I have a similar feeling, I like doing low level work but I also mentoring junior engineers, hopefully that mentoring will multiply my overall output over time!
I 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.
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.
> 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.[
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.
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.
Look at the Ukraine War… Russia clearly completely ignored logistics and failed in their attempt at a “modern” war and quickly degraded to a WW1 style artillery duel.
And yes, being a NCO or field officer in the Russian army is miserable.
Not sure if you’re being sarcastic? Or haven’t read much about the military and are assuming?
Combat vs combat support vs combat service support (logistics) is a very common and very significant distinction to make and usually matters a lot for a great many things.
Has a logistics branch officer ever led a major Army? We had an artillery officer in the UK and even that was a talking point at the time.
It’s tricky because I need hands on experience but the desire to switch to a more strategic, executive-style role. Plus folks need to have the core communication and people skills to manage a complex set of stakeholders.
Hard to find good people, but the people I find tend to be very very good.
The thing is that every non-tech company is now in some sense in the tech industry, whether they mean to be or not; a large part of their business is done online. As opposed to companies that specialize in building tech for other companies, many of them have nickel-and-dimed their way into their own hardware/software infrastructure and the maintenance of that has become crucial to their normal operations, to the point where instead of business logic dictating changes to it, it frequently dictates changes to their business logic. That puts independent devs for those companies in a kind of catbird seat to determine which stacks and which infrastructure are going to drive the next round of growth. Some people (like my friend who's a salesman for Salesforce) call this "technical debt", but really it's bootstrapping and the better and cheaper you can do it through indy devs, the better your bottom line.
So it's quite different than the normal software world, but it's neither what you're calling a staff position nor is it actually a line position.
There are plenty of staff positions where incompetence could be very damaging or deadly to the business. E.g. in-house lawyers or accountants, even HR in some circumstances (failing to act in the presence of a hostile work environment). That doesn't mean it's not a staff position.
By the definitions of the article, the head of engineering at a tech company, or even the CEO, are considered support staff. Their success and failures will 100% map to the success and failures of the company.
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.
Why equate them as the same here?
Some wise exec had the vision to outsource it to an external company and then Motorola (that was already on the path to its death) realized how much was done outside of the process (which is typical for such companies, fortunately or not).
Suddenly your threat of whatever happening if your thing is not fine had exactly zero value against "raise a ticket". Everything crawled to a stop because of that and "golden tickets" were used.
This is one true example of why you should think 20 times before outsourcing something you do not understand.
Second, as we move to more open source for infrastructure software (the tools used by staff) the above becomes more clear. SAP is charging for something with zero marginal cost, therefore it's perfectly valid to say they are renting software and hopefully using the money to develop the next version.
As the world moves to more open source I think you'll see fewer line software people, as the staff will do both support of the business and push some changes upstream (equivalent to what the line guys at sofware companies do). Once software is mature the rent model is really obsolete, but maintenance still has to be done by someone.
In fact, when things are tight is the very moment you should go all in for R&D.
Let's clear up something simple people forget: when things are tight for you, they are normally also tight for your customers. In fact, that's generally how they become tight for you.
So you can forget investing in production and sales when things are tight. Things are tight because the world is in a period where your customers aren't buying. You won't change that by trying to sell harder.
However, small research projects are an incredibly cheap way to learn things and invent new technologies. When you're not encumbered by turning things into products, you can discover at a frightening speed. So you spend on research when the times are tough, and then when things go better you have a huge backlog of technologies you can apply right away.
And recessions are the time when this research is at its cheapest.
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.
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.
I could easily hop to a gig with more responsibility and more opportunity for increasing my skills - but also more stress.
That sounds like a pretty ideal scenario to me, but I'm not sure how to go about finding similar positions.
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).
You might disagree with these examples but:
A stock trading company, IT stuff are support for the real employees, the traders. You have a trader, you have a trading company. The programmers are just support for them.
Animated Movies (even pixar). Sure, there are important software devs but the real staff at pixar are animators. They can ship animations with off the shelf software or paper and pencil. In house software devs are super important but at the end of the day if all they had was animators they could still ship animation.
Lawyer firms, Medical Facilities: Yea, they need IT staff to help run things but they can function with just lawyers or just doctors.
VS say Apple, Google, Facebook, Microsoft. No devs, no company.
Video Game companies used to be and probably mostly still are this way. No software devs no product ships. That might be fraying as tools get better.
While you are correct in that at a lot of finance companies, devs just act as "support for the real business" (e.g., Goldman Sachs). But there are others where devs and quants pretty much harmoniously run the show.
Look at something like Jane Street and their tech blog[0]. Their annual "what our interns have wrought" blog posts grab my attention like nothing else, and from everything I read coming from them, it seems like engineering there is not just "support for the real business". And there are quite a few companies in fintech like this, they just won't be flashed in the mass media due to their relatively small size, but everyone in the industry (and plenty of people on the outside) knows about them. Out of all things, they are known as one of the largest contributors to OCaml language and its ecosystem.
Jane Street was just a singular example, and there are other fintech firms of a similar engineering-focused culture.
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.
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".
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.
But the overal company culture and the upper echelons of leadership very strongly reflected EA's history as a software publishing company founded by business folks, and not a group of game makers who set out to build their own company. It was very much about producers, money, marketing, etc.
I used to joke that EA was in the business of selling disks and that the games on them were merely an annoying chore that they were obliged to do in order to get people to buy them. It often felt like they considered the entire dev team to be a cost center.
We had one title I worked on where the "interviews with the dev team" was all just interviews with the external producers(aka PM who came in from the publisher to keep everything "on track").
Never happened to us but the best one I heard was that the publisher puts a clause in your contract that they get the source+IP if you go bankrupt(protect their investments, their taking huge risk, etc....). However about 2/3 through development when the studio is at peak HC burn they would start denying milestones for trivial things. One, two milestones go by and the studio burns through all cash, folds and publisher gets source+IP. Publisher then hires the dev team, who just lost their jobs, at a reduced rate(most gamedev a don't have great savings...) to finish out the game, avoids paying any royalties and picks up the IP.
Happy to be out of that industry, some really interesting technical challenges and driven people but the whole thing is similar to the recording industry in the way they exploit people and passions for their own gain.
The biggest downside to staff IME is that you are almost constantly reminded that you are a cost and at danger of being cut.
OTOH, the biggest upside is the domain knowledge, and in particular, how companies (ie customers of the line engineers) really deploy and run their systems, which IME is often very different from how the line engineers think they run them.
Line engineers tend to gloss over the myriad of external influences that affect how easy their systems are to deploy and integrate (eg how many FTEs doe it take to operate your systems, how long is an acceptable maintenance window for applying fixes, how long does it take to roll back if a fix fails, etc).
An experienced staff engineer introduced to a line team can be a huge asset, and will ask the right kind of questions, ie those that the customer is often most interested in.
That was my life working tech support. Now I should say I was well paid, and it was a good job generally, but I worked closely with some of the engineers and you got all of those wonderful informal "hints" about your value at the company that didn't happen with the engineering team.
Our back fills would get held up on an off almost infinitely. Even if we wanted to hire someone they'd low ball the new folks absurdly (I was embarrassed I even interviewed these folks). If there were cutbacks our quarterly pizza lunch (maybe cost a couple hundred dollars in so-so quality pizza) would get canceled ... (the engineering team would quietly invite me to their lunches, nice guys). And the quality of management was pretty poor / there was no effort to improve them. We were also the department that got the usual cycle of VPs in and out as they realized nobody cared what they thought and would move on.
When the time came I moved on to a new career. It wasn't so much a bad job, but that sense of absurdity and being just a cost wore me down.
It seems like this shouldn't be an absolute that applies to all staff roles, just a sign of a company with an immature viewpoint on costs. Or even just an inconsistent one. Consider the electricity used to keep the office running, it's a cost, but no one would feel the urge to remind the utility company that it's a cost and therefore at danger of being cut. That "and therefore" isn't even true in general anyway. Pre-pandemic most would consider the risk of cutting the office electricity to be no higher than the risk of the company ceasing to exist for whatever reason, i.e. if the company goes the office also goes, and there aren't many other causes for the office to go for most companies so it's mostly vice-versa too. Similarly there are businesses basically entirely supported by staff teams/individuals doing maintenance of some old software, if they go, the business goes, and vice versa. Anyone trying to pull a "don't forget you're a cost and might get cut!" reminder on them would be an asshole. Meanwhile companies like Google have no problem killing off entire products and their teams (though I think they tend to re-purpose the programmers rather than officially lay them off) even though it's making on the order of ("only") $200m/yr in profit.
Sure, if people can get something for cheaper than they used to, or get rid of something they realize they don't need/want, there's incentive to do that and "cut costs" by that amount if they can, but this incentive applies regardless of the staff/line division. Maybe the cure is to remind line roles at such places that they too are in some vague danger.
His view was that revenue can soar 100%, 200%, 1,000%, 10,000% or however high. Cost savings, on the other hand, can only go down to a maximum of 100% (but obviously much lower in practice). So in his mind, a business-wide focus on growing revenue is always better than a focus on cutting costs. If you are in the second boat, it means the company is struggling and maybe it's time to get out.
Obviously, a rational CEO would see $1m cost savings the same as a $1m gain in profits, but CEO's are not rational beings (nor is any human) and understanding that they usually prefer higher revenue to lower costs is fundamental to understanding how they value different parts of the company. It's not fair, it's just truth (at least in many companies).
There's something refreshing about some hedge funds where portfolio managers are rewarded exclusively on their own performance. For example, if the fund loses money, but you continue to bring in great revenue, you can bet that any sane hedge fund will pay you a lot to stay around, regardless of how they are doing overall. Unfortunately (or maybe fortunately), profit in most companies isn't directly attributable in the way it is at hedge funds. But the same truth holds. If you are bringing in good profit, it's hard to get rid of you (or not pay you well) regardless of how the company is doing overall. Try to be in one of those profit centers, if you can.
Tech doesn't usually measure COGS, because the cost of another user on a website is near zero.
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.
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.
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.
You can hire any number of consulting firms or smart engineers that can tell you how to lower your AWS bill, or get rid of unproductive employees. It's much harder to figure out how to grow your business by 2x.
And I assure you that growing revenue by 100% is far easier than cutting costs by 100% (while maintaining current revenue).
Also, there's a human element to it. I'd venture that most CEOs would much rather the company make more money than have to lower bonuses and benefits, cut down of office space and fire employees.
The article's staff vs line distinction cuts it a little differently, and definitely gives a rosier picture of working in a staff role.
When we win, it’s rarely acknowledged, as the output from other more core teams just seems more impressive, but when we fuck up, it looks really bad.
- 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).
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.
Not one ever took up on this offer...
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.
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.
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.
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.
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.
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.
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 ?
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.
Note - Companies can be valued at top line ARR/Revenue and/or EBITDA, so YMMV, even in the PE world.
Sometimes they're the same. Sometimes they aren't. A well placed, smart team of "staff" engineers can increase revenue as much or more than a team of line employees.
A rational CEO prefers revenue growth as companies are valued based on revenue, and the CEO's purpose is to maximize per share value.
Good read on the shortcomings of the "agency theory" based view that you're assuming, and which thankfully is finally becoming less of the de facto view: https://hbr.org/2017/05/the-error-at-the-heart-of-corporate-...
I will say that I don't really agree that profit center/cost center is less clear terminolgy or doesnt have the right boundries. I'd argue the opposite. It's a pretty direct description of why any distinction exists at all. It's also pretty inuitive that its preferable to be in a role tied to how the company generates money. Line/Staff terminology requires nice blog posts to explain what those things are. Maybe in a military context it makes sense because there is no profit center per se, but for industry, using line/profit terminology is just a whitewash of profit center/cost center, which is imo the real distinction.
Of course the classification of profit/cost is not perfect as there are jobs kind of in the the middle, like say if you are an internal recruiter (you recruit profit center people too so...) but I don't think those roles are easier to classify as line/staff either.
Staff in the modern military means you're a careerist. It's the last rank that you can't be forced out without advancing, and might not be expected to advance at all.
Staff has different kinds of connotations depend on officer and enlisted. Staff officers would never lead from the front. That's O1-O3s job, those people are actually trained by enlisted careerists before they ever get to lead. In the enlisted ranks, Staff starts with E6 (Staff Sgt) and they are typically platoon commander's. By contrast with officer ranks, Staff Sgts will still go on patrol.
The officers metaphor is a bit relevant to software. It's rare for Major+ to actually work in the field (unless they're highly specialized like an Air Officer). These are basically executives. On the enlisted side Corporal through Staff are your immediate leaders that the company recognizes. Corporal is the first working leader as a team lead, Sgt lead multiple corporals, and Staff Sgt can lead multiple Sgts. This can vary by +-1 rank.
I do think software does need to shift more the direction of the military where working leaders hold the majority of team direction and influence from a systemic level. Ultimately, Staff Enlisted are entrusted with direct responsibility for how and when things get done; they also (generally) have the most direction over the platoon. The biggest component I'd like to see is managers being trained by software careerists before they're ever allowed to lead a team.
Edit: my experience is colored by the Marines, which focus on small team leadership and cross training. YMMV.
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 ;-)
These days, as a freelancer, everything I do is "line", in these terms, by definition. It's glorious.
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.
* may vary of course, but nobody expects 100%, even the big 5/4.
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.
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.
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.
> "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.
The stress comes from deciding which hour you bill and which you don't. Bill all the things!
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.
What company is this? Are you in the US?
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.
...
> 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-...
"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.
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 termIf 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?
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.
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.
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.
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.
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).
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.
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.
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.
In fairness, I’d bet the full time devs are too.
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.
It's almost as if each of our underlying teams are their own firms within the parent organization.
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.
I only wish I had that level of autonomy when working for the most horrifically bureaucratic corps I’ve seen.
E.g. the air force wouldn't outsource pilots; Thoughtworks wouldn't outsource consultants.
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.
Product managers talk to the CEOs more than software engineers do.
Lines help you walk by you looking at them. Staff help you walk by you holding them.