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.
The other kind of staff software engineer
51–60 of 201 posts
Re: The other kind of staff software engineer
#52Earlier quoted context omitted.
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.
Yeah, it crept up over the years. Start at 6hrs a day, then 6.5, then 7 and then 8 about 4 years ago.
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.
Re: The other kind of staff software engineer
#53Author 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 recal…
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.
Re: The other kind of staff software engineer
#54Author 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 recal…
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.
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.
Re: The other kind of staff software engineer
#55Author 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 recal…
> 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.
Re: The other kind of staff software engineer
#56Calling 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 arti…
I think that's why the title reads "the other kind"
Re: The other kind of staff software engineer
#57The 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.
Re: The other kind of staff software engineer
#58Calling 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 arti…
The article is titled The “Other Kind” of Staff SWE. Presumably the “first kind” is the definition to which you are referring
Re: The other kind of staff software engineer
#59I'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. Lin…
>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.
Re: The other kind of staff software engineer
#60Author 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 recal…
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 leve…
"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!