[daguar]

The spectrum of (product engineer) <---> ($NEEDS_A_NAME) has been one I've encountered a lot and which I find is underappreciated in hiring and team-building.

The way I think about it is that you're giving weights to one of two different goals:

1. Building the right thing

2. Building the thing right

I've found that in early-stage work, you really really need to have engineers who are more interested in (1) than (2). I'd probably say a product engineer who's a good fit for early stage work probably has an 70%/30% mix of what motivates them between these two goals.

The strongest product engineers also have a keen sense of the power of MANUALLY handling some cases as a way to learn. At small scale, the cost of manually handling something can be way lower than building for that case. So another attribute I've seen is that strong product engineers are either okay with or even actively enjoy supporting users in those edge cases, talking with them as a way to learn.

I'd be curious to know how companies most effectively hire for and/or cultivate these kinds of behaviors in eng teams.

[ebiester]

I'd say the word you're looking for is Software Crafts[man,woman] but I don't necessarily believe the two are exclusive, but rather horizontal and vertical axes.

There is a difference between someone actively making compromises between time to market and features, and someone who doesn't understand how to write software in a maintainable fashion but can get something quickly out to market. There are even people who are good at neither.

[rileymat2]

This is an understated point, there is a difference between intended technical debt and incompetence.

At a very micro level, yesterday I was looking at a simple JS object with 6 entries, and 3 different naming conventions. Doing even simple changes without code-completion in the code base is mentally taxing.

[Vinnl]

Very much agreed. In fact, I'd say that "building the right thing" often enables "building the thing right": by not spending time building things that are unimportant, you can spend time making the things that are work better.

Needing to get to market faster doesn't mean skimping on, say, a proper CI setup; it means not trying to do everything, and focusing on delivering and iterating on only those features that are relevant to the market.

[avip]

The "hire for" part is pretty straightforward - when you interview, you'll have candidates with zero idea what your company is building. They won't care either.

Come Q time they'll ask about tech stack, code review, 4k screen, could they use their esoteric linux distro (yes).

OTOH you'll have candidates who already know your competitors, and know the tech stack because they registered for invite-only beta the day before the interview.

[therealdrag0]

Eh. I lean towards the former; in an interview I ask tech/process related questions and don't care about product (unless the interviewer mentions something that piques my interest). But when I start the job I give above-average energy to product-engineering. I'm looking for a tech fit, and I can apply my product-engineering energy anywhere.

[chiefalchemist]

In my experience, #1 is relatively the (very) hard part. #2 is relatively easy as it's finite in scope and push come to shove you pay a bounty (to a one-off consultant) to architect the direction of a solution.

Put another way, you can get #1 wrong and even if #2 hits that target, you're still wrong. But get #1 right and over a couple iterations you can get the means to support the desired ends.

[lwb]

One possible value for $NEEDS_A_NAME is Infrastructure Engineer ... not to say that infra isn't always productized, because it sometimes is, but the instincts required just aren't the same when your customer is the team that works down the hall. Maybe Systems Engineer if you consider the type of engineer that optimizes for speed and other factors. Idk, names are hard.

[nitrogen]

SRE sort of fits that box, though I have to point out w.r.t. the OP's post that there is being scrappy (not building for edge cases that don't have confirmed ROI) and being reckless (ignoring any engineering concern whatsoever).

I've seen projects sink for having PMs too far on the reckless side. Frontend engineers who appear to be developing the day's hot feature end up building a massive platform on platform on (...ad nauseam) on Reactive React just to show a few forms, while the backend engineers get pushback every time they ask a question. The product sinks because it takes three weeks just to move a field from one form to a different form, you have to refactor the whole redux store, ...

These are the teams that go so far in the "manual" direction that they refuse to build support tools of any kind whatsoever, and then when the inevitable fires come nobody knows what's going on.

So product<->reliability might be often mutually exclusive just because that is what people are used to, but really engineers should be able to do both and know when to adjust, and so should the managers.