Hacker News Reader

Comment by jedberg | Hacker News Reader

The best way to tell if a company values engineers is to ask which cost center they are in.

Is it IT? Then they will treat you like a cog and consider you just a cost to the company. Is it Product? Then they will consider you valuable and critical to the company's success.

View on HN

That's a good theory, but it doesn't always work that way. I was working on the most profitable product the company had, but was laid off anyway. The new 6 month CTO had a new idea for how software development should be done and I wasn't part of it. Meanwhile at my prior job in IT my boss begged me to stay, I think because I made him look good.

Can relate to the latter. I've left about half a dozen jobs before striking out on my own, and the places where my boss actively pleaded with me to stay were places where I was definitely an operations cost centre and a galaxy away from anything resembling a profit centre or a revenue driver.

Politics. I was competent, precocious, energetic, participated in many meetings and liaised with lots of teams with which people in my position don't usually liaise, bailed out some people in other parts of the business with unexpected skill sets and initiative, and made the manager look good.

Meanwhile, the one job I was actually fired - not laid off - from, I was sitting very close to the money train.

The money train is usually the part of the company that attracts the wrong kinds of people. They know it’s the easiest way to succeed: by being part of the team that brings in a lot of revenue. It becomes easier to show your “contributions” in monetary terms even if you may have not been directly responsible for that. As a result, these competitive types will also try to remove anyone who isn’t an “ally” regardless of whether these people provide value to the business.

> The money train is usually the part of the company that attracts the wrong kinds of people.

Waiting for it...

> As a result, these competitive types will also try to remove anyone who isn’t an “ally” regardless of whether these people provide value to the business.

Ah, there it is. I had to learn this lesson the hard way, and let me tell you, the kool-aid is no longer so sweet. The money train is often just a mobile coliseum. There's no escaping the gladiator aspects role. It's disappointing.

I've found if you are good at your position being part of the cost centre operation side means you will be left alone and ignored. Because of that you are less likely to be promoted. The profit side often gets random kudos, awards and probably bigger salaries.

For me being unimportant enough that money spent on a scrum master doesn't make sense is the right work-life balance.

A question I like for non-tech businesses is: "do you see this as a software business or transitioning to become one?"

Because these days every business has to be investing into software products, and the ones that don't recognize that the software is key to all their products are the ones that are dead folks walking. They're also great targets for SaaS consultant vultures.

I dearly hope my cast iron skillet will never require a firmware upgrade.

A company that makes cast iron skillets can still have software as a core part of their business. Logistics, monitoring the manufacturing process, forecasting demand. All of these things can be software that is core to business. Or even more important, having a useful website for selling their products.

Sure, but Le Creuset will never describe themselves as "a software business"...

(And if they did, I'd immediately be looking for a different cookware supplier.)

Ah yeah I don't think asking if they are a "software business" is actually a good question.

But I'd still be wary of working for them if their software engineers were in IT.

On the other hand, would you _ever_ have even _considered_ working for Juicero? <smirk>

Haha I would not, but that has nothing to do with where their software engineers were classified in their org. ;)

This kind of companies don't have software engineers per se, they outsource everything and just keep management around, even IT.

But it's sold by a company with a website, and if it's in-house, (probably quite a big 'if') its developers probably don't want to be lumped in with its phone line, office PC etc. sysadmins (and I'm sure it's mutual).

I think that's the point. Cookware's just a further-from-tech example of it.

I'd be perfectly happy being lumped in with the Sys Admins. They are, in most companies, the most misunderstood role. There's an expression that basically says "When things are going great, everyone wonders what sysadmin does. When things are going poorly, everyone wonders what sysdamin does". A good sysadmin team is amazing and, in many cases, vital to a successful business.

I think the only other role that gets ignored as much is the Executive Assistant(s). Much like sysadmin, good ones make sure everything runs smoothly, and should be prized like gold.

Being viewed as a value multiplier (like good instances of the above should be) is a fine goal in life.

I wasn't saying their useless at all, I said the feeling's probably mutual, is just a different role, so if they're lumped together then as you say, at least one has been misunderstood.

I think a better question is: do you consider your software systems a competitive advantage?

This can be carried too far. Every business now has a director or consultant whose job is to chart the company's progress towards becoming a software business. This can have any number of effects:

1. It's not a slam dunk that software development is an asset to a business. Entire books have been written on how to keep software projects from eating your business alive. Many software businesses fail.

2. The hardware people notice that they're being treated as second class citizens, and wander away. Remember, the best leave first, including the people who fully understand how your product works.

If development is in product, how long has development been in product? Is this a recent change where development was transitioned from IT to product during a recent transformation?

Not directed at you, just some general comments.

As someone hinted at in another comment, it seems a better (less dichotomous) framing is:

- tech first (developer lead, selling software or hardware),

- tech enabled (developers are a key collaborator with the business, e.g., logistics, manufacturing, ecomm, marketing, really every company should be), or

- tech as a cost center (the “traditional” company in the article).

What about the trifecta of product, engineering, and design advocated for by Marty Cagan?

I think the same argument that’s being made for giving developers more weight in the development process could be argued equally as well from the side of design.

Edit for formatting.

Has anyone made the switch between these two types of companies? I’m 2 years into my career but I’m one of those cog engineers working in IT and it’s really draining my soul. I don’t know how to talk about my job in interviews without giving off red flags.

I haven't done it myself, but I've hired people who were stuck in IT.

Just don't talk negatively about your old job. "I'm looking to move because I want to have more impact". "The work I'm doing now is not core to company's success and I want to have more impact". Etc.

I never looked down on someone who was doing boring work if that is what they were supposed to be doing. I'm looking for people who can communicate well and have strong core fundamentals. If you can demonstrate those things then you're doing well.

What kind of red flags are you worried about?

I guess I’m worried about talking about how we have really poor development practices. It’s hard to describe what I do, they try to block people from learning about what their kanban card is for. I just write proprietary scripting language functions then fill out a Word document “unit test” about them. I guess I can editorialize and try to steer the conversation towards what I can bring to the company. Thanks for the advice!

If I was interviewing you and you told me "my current company has very bad development practices" and then gave me a list of all the things you think they are doing wrong and all the ways it could improve, I'd probably be really impressed. Then I'd ask you why you don't change those things, and I would hope you'd tell me a story about how you tried to change it but got blocked, or maybe small changes you are making to make things better.

This would tell me that you're really engaged, up to date on the latest methods, and motivated to make things around you better.

Good advice. Also: don't blame the people around you for why you couldn't fix something. Even if it's because your manager was a short-sighted idiot, or the senior engineer on your team was jealously guarding his territory, you don't have to say that in the interview. See if you can reframe it in a more blame-neutral way.

For example, if you couldn't remove a bad pattern because it was too deeply entrenched for you to handle it yourself, and you couldn't get anyone more senior interested: that's expected for a junior developer and probably wouldn't be held against you.

I've actually asked this question in an interview before to a candidate. "Is there anything about the process you work in now that you would change, and how would you do it differently?"

That sounds not great. Two years into your career you need a better experience and great mentors. Get any job that is writing code. What's great is that you're only two years in, I see people like this 10 years into their career. They get laid off and can't find a job because they don't have any skills others value;

I am sure this will just get buried, but you could consider searching for a company that appreciates honesty.

You can talk about wanting more ownership. That can include talking about working closely with end users and making long term design decisions.

I made the switch you are talking about. I did talk about my job in the interviews, and in retrospect that would have been a pretty clear signal than I didn't know how that type of company works. I think I got the job because my employer is primarily looking for competent problem solvers, and they are willing to teach the rest on the job. Not all companies may be like this, but the big ones probably will.

That’s good to know, thanks. Congrats on the move!

I guess the question to ask is, what do you talk about? When I talk about working in those types of companies I mention that I like to work in cross functional teams, interact with product and design, being part of the ideation process, wanting to understand the business and deliver value quicker.

What types of things do you say and why do you feel they may be red flags?

And the geography too. If a european company outsources its development to India, even if they hire the top of the basket there, and they often can’t, the devs are so remote from the business that I hardly see how it could emulate the sort of dynamism you have in the SV.

I'm lucky enough to make products for our company while being in IT, so it is a hybrid. With data driven decisions becoming more important to businesses these days, I see IT's transitional role as the cost side (vs. profit side) starting to change.

> The best way to tell if a company values engineers is to ask which cost center they are in.

Duh! Companies don't put all the engineers in one cost center. It's either by teams/product/business unit/function

Reply on news.ycombinator.com