Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The other kind of staff software engineer

earthly.dev

Post reply on HN
Print view View original

21–30 of 201 posts

Re: The other kind of staff software engineer

#21

Post by jacknews »

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.

Re: The other kind of staff software engineer

#22

Post by dpcx »

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.

Re: The other kind of staff software engineer

#23

Post by xarope »

Goronmon wrote: post #18
rendall wrote: post #9

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 th…

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 meetin…

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.

Re: The other kind of staff software engineer

#24

Post by jawns »

mynameishere wrote: post #13

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.

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.

Re: The other kind of staff software engineer

#25

Post by mgkimsal »

Goronmon wrote: post #18
rendall wrote: post #9

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 th…

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 meetin…

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.

Re: The other kind of staff software engineer

#27

Post by Goronmon »

xarope wrote: post #23
Goronmon wrote: post #18

Earlier quoted context omitted.

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 meetin…

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.

Re: The other kind of staff software engineer

#28

Post by xarope »

caffeine wrote: post #8
geogra4 wrote: post #4

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

I feel like nowadays that joke has evolved to devs that use JSON vs devs that use binary serialisation (like capnproto or whatever else)…

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)

Re: The other kind of staff software engineer

#29

Post by troelsSteegin »

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.

Re: The other kind of staff software engineer

#30

Post by dsr_ »

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?

Post reply on HN