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

151–160 of 201 posts

Re: The other kind of staff software engineer

#151

Post by rendall »

Goronmon wrote: post #138
rendall wrote: post #110

Earlier quoted context omitted.

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!

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.

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?

Re: The other kind of staff software engineer

#152

Post by throwanem »

awkward wrote: post #142
throwanem wrote: post #84

Earlier quoted context omitted.

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

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

Got it. Thanks for the clarification!

Re: The other kind of staff software engineer

#153

Post by z3t4 »

chadash wrote: post #65

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…

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 ?

Re: The other kind of staff software engineer

#154

Post by solatic »

chadash wrote: post #65

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…

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.

Re: The other kind of staff software engineer

#155

Post by mbesto »

belter wrote: post #137
krisrm wrote: post #135

Earlier quoted context omitted.

Seems like that would quickly turn into a game of reverse engineering shitty KPIs, would it not?

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

> 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.

Re: The other kind of staff software engineer

#156

Post by mbesto »

chadash wrote: post #65

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…

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.

Re: The other kind of staff software engineer

#157

Post by dvtrn »

gernb wrote: post #147
adamgordonbell wrote: post #3

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

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…

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".

Re: The other kind of staff software engineer

#158

Post by frellus »

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.

Re: The other kind of staff software engineer

#159

Post by gowld »

frellus wrote: post #158

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…

It's not a two-class system, it's a reality of the business incentives, and local monopoly vs competition.

Re: The other kind of staff software engineer

#160

Post by lesuorac »

mgkimsal wrote: post #25
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…

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

> "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.

Post reply on HN