Comment by RubberbandSoul

21 days ago

It's easy to get bitter about these things. "Experience" seems to be code for: "we've spent fifteen years painting ourself into a corner and now we need a guy who will get us out of it in three months or less". You are however not allowed to give any feedback whatsoever about their processes, priorities, organization, promotion strategies, retention policies, etc.

Having experience usually means that you've acquired a holistic view of software development. Usually the hard way. But they want solutions, not advice or opinions.

I've met a few devs that makes a living like that. Get in, solve problems. Keep quiet. Get out. Wait for them to call back in a couple of years.

> You are however not allowed to give any feedback whatsoever about their processes, priorities, organization, promotion strategies, retention policies, etc.

Ironically, the only people who have social permission to do that are extremely expensive Big Name outside consultants. Who will then do one of two things: either speak to the staff, collate what they have to say, and launder it back to the boss; or produce a thinly veiled adaptation of whatever business book the CEO last read in an airport.

  • > speak to the staff, collate what they have to say, and launder it back to the boss

    My wife is a management consultant and this is _exactly_ what she does in half of her projects. But it is a bit more sinister than that, the management consultant feed the info back to the _top_ bosses bypassing the middle-management hellscape.

    For example, she did a project for a big bank where she interviewed 70 or so people her main output was a streamlined virtual machine requisition flow (which included merging a couple of teams together and configuring the ticketing system they already had). It used to take devs 6 months to get a VM. I bet the devs where yelling at their middle managers to sort it out, but their managers didn't have or want to actually bring it up with upper management with a plan on how to do it.

    I joke that companies could just do that internally, have some people interviewing the leaf nodes in the org to find out top-down initiatives to help work get done, but companies simply don't do this.

This is a reason why when life pushed me away from product development into consulting/agency work, I hated it at first and eventually I learnt to appreciate the positive side of it.

Usually those kind of companies won't hire old employees, while at the same time will gladly pay for consulting knowledge to solve their problems.

Also while product companies tend to hire folks that the very last thing they worked on checks all bullet points on the HR job ad, agencies will gladly throw people at a problem regardless of the skills list, as long as the team learns to swimm fast enough.

  • > agencies will gladly throw people at a problem regardless of the skills list, as long as the team learns to swim fast enough.

    I did a few years at a company which was "product development consultancy", and this aspect of it was really enjoyable. We got a set of diverse challenges through the door, often "virtual startups" (CEO hiring consultants rather than staff in order to do v1 of a product). The company was basically a single room, and we had two senior guys (the founders) to review work and support us. Plus one "smartest guy in the room" who served as mathematician fire-support for things like signal processing or the rare actual DS&A problem.

  • Most often product development involves a lot of legacy. In consultancy you get to start from scratch at least every once in a while.