Hacker News Reader

> youre not here to decide what problems to solve, youre here to solve the problems the product team wants solved they get all upset and moody

Please be very up front that you hold this view when recruiting, it will be better for everyone. This may need to be an "agree to disagree" situation, but my experience goes completely the opposite direction of what you're suggesting here.

One of the biggest dysfunctions in tech over the last decade has been the rise of the product role and re-subjugation of engineers. We've recreated all the dysfunctions of the "pointy haired boss" just now with a PM title instead.

The 90s had the trope of incompetent business/managerial class folks being in charge and engineers being expected to do as they were told. Then in the 00s/10s there was a renaissance as engineer-founder companies (Google, Facebook, etc) elevated the status of developers and gave them increased autonomy and influence. This period saw technical innovation, business growth and increased wellness for employees.

In the past few years, the people who couldn't thrive as developers realized they could rebrand themselves as product managers and do all the fun parts of making things while leaving the difficult implementation work to developers. Unsurprisingly, the outcome is worse business behavior, worse customer experience, and burnt out developers who don't want to just be a cog in a machine building someone else's idea.

This is exactly correct. We have seen “market maturity” which basically means “tech companies are now run on modern management theory” and that theory, frankly, is wrong.

Open doors, frank discussions, flat hierarchy, hacking culture, planning at the edge, and personal relationships all took a dive. Performance plans, recruiters, mid-level managers, central planning and product management overuse exploded.

Somewhere around 2014-2017 working in a tech company started to be indistinguishable from working in any other Enterprise.

Now a lot of that seems to be the result of all the pioneers leaving the industry and the settlers arriving. There was a point around 2012-13 where Ivy League grads stopped going to McKinsey and started going to the valley, and they brought all their management theory with them.

> Somewhere around 2014-2017 working in a tech company started to be indistinguishable from working in any other Enterprise.

That's because the definition changed. Silicon Valley used to be tech companies, that meant companies whose product was tech.

That's no longer the case. The so-called tech companies do not sell technology anymore. Sure they use tech internally, but that's every enterprise ever. So working at them is indeed just a boring non-tech enterprise job.

I have said similar things to a few replies but i really think it’s less simple and there being one way that works.

I’m sure the agree to disagree works sometimes but my experience is we need to trust people to do their job, and if we cannot, we need to move on without them.

This isn’t to say we will disagree and not find a way to live with it. I more mean, the ideal outcome is that the mind of developers and product staff are tightly aligned. If they’re not, that’s going to be a constant source of friction that’ll slow down everything about product development.

I personally believe (and maybe bias is showing now) that a lot of the best ideas come out of the people closest to the code. It’s often easy to spot opportunity as a developer, but we need to not discount the work good product people out into user research and market research.

Neither alone is sufficient, but the teams have to work together to get the idealized outcomes.

> One of the biggest dysfunctions in tech over the last decade has been the rise of the product role and re-subjugation of engineers.

This is absolutely correct. Although your timeline is a bit off.

In the 80s and 90s there was no such thing as a product manager. At least, I never met or heard of one. If any existed, they were rare as hens teeth.

Engineering was driven by engineering. Thus craftsmanship mattered and it was a very fulfilling job. Engineers were expected to define the product and had the authority and responsibility to do it.

The PMs started to appear in the 00s and spread like wildfire in the 2010s. Now they almost outnumber engineering. Engineers own nothing and are expected to like it.

>> youre not here to decide what problems to solve, youre here to solve the problems the product team wants solved they get all upset and moody

> Please be very up front that you hold this view when recruiting, it will be better for everyone. This may need to be an "agree to disagree" situation, but my experience goes completely the opposite direction of what you're suggesting here.

Also, there are both types of companies out there! There are places where "engineering" means "implement what the Product Manager dreams up" and other places where it means "you define the product and implementation." Find the company that works best for your expectations. Some people like having a PM do all the ideation and just sit back and program what's in the requirements doc. Others feel put in a box in that environment. Both types of companies exist.

I beg to differ, well, at least i beg to add a 3rd option. I like to subscribe to the thinking that the PM owns the decision but the best outcomes are made when they work closely with, and often take a lot of input from, the developers.

At the end of the day the reason i say i like this model is because i want ownership from a product group, and likewise no development team wants PMs prescribing to them how to structured the database or what language to choose. So ultimately, this division of responsibility is kind of a logical divide, to ensure we see where each other operates and let the developers have input but also their own area of ownership without taking away the ownership the product people bring to the table.

I understand what you mean, and after several tours of duty across FAANGs and startups I think the bouncing-around tends to me less of an individual characteristic and more of a symptom of organizational dysfunction.

For startups, the landscape within a given role tends to vary drastically year over year. Some folks like being employee #10 but don't want to hang around past employee #20. Other folks like being employee #1000 but out of 2000 or 3000 feel overwhelmed. Organizations these days hire, especially where employment is at-will, with the expectation that their staff are fungible (they're not) and can be rearranged at the drop of a hat (which happens often).

One project can be a blast, and if the next one isn't then the grass is indeed often greener on the other side -- at least in our industry.

Some of my best hires have been folks who have never stuck around at previous places for more than 6-9 months over the course of several years. On the whole, it's all a total crapshoot.

Your last sentence for me is it: total crapshoot.

Agreed, it’s so hard to tell. I try hire more for personality and general intelligence and assume we can teach process and new tools.

Historically I’ve attempted to tell developers what you said upfront, that some projects will suck but I’ll do my best to make sure you’re not always on the sucky work. I think managers often forget that cycling people in and out of fun roles is important for retention, just as is pay etc.

There is some value in expectation setting around “I’m not going to abandon you in the shit forever, but at times you’ll be in the shit and so will i, and i appreciate you sticking with me and will do everything i can to reward that”

Ted Lasso kinda stuff…but it’s not all worthless even if it doesn’t work 100% of the time.

I have definitely noticed that fewer and fewer managers are fostering that type of relationship with their team. Seems like managers are doing the same, and hopping from ship to ship.

I've recently seen some managers totally throw folks under the bus -- otherwise very good folks too.

But otherwise I agree. The market has been quick to hire and fire which makes building and retaining talent difficult. The instability of the last several years has really left things in a seemingly universal bad state.

That’s a good point. I guess this is just how it goes right now. I’ve found that retaining members on a team is the best hack for high performance. You need management bought into paying them well and giving you some autonomy around HR processes and what you work on, but if you can do it i believe the returns are real.

If I can be blunt, you sound like the kind of person who manages purely top-down and makes what could be an interesting and engaging workplace into corporate drudgery.

And that’s kind of the point right? I mean, it’s very hard to be that honest and reflective with one’s self but everyone has their preferences of style, engagement tactics etc, and it’s very hard to get right.

I truly hope your impression isn’t reality but all i can say is in certain settings it’s worked great, in others it’s been meh. I’m subject to the same issues we all experience here.

I appreciate your candor and self-reflection. I want to encourage more of it.

I'm curious what you mean -- worked great for what aspect? Short-term bottom-line targets for the company at the expense of workers, or long-term culture-supported productivity ones that benefit both company and worker?

I suppose if you have a team of people who treat work as "doing homework for the rest of your life" (and quite a few SWEs never grow out of this mindset) then you can help them stunt their growth and extract whatever you want out of them for the company's sake. It's been my experience that typically the real movers and shakers need more than that to thrive, and they need to feel like they're thriving to stick around. I worked too long in a dessicated environment because the people who were insightful and good at their jobs were told to shut up and grind. They left for places where they could have more agency and feel like part of a team that values their input.

All good, i try not take things too seriously. Appreciate your bluntness and curiosity.

Most of my career has been with early stage tech but I’ve also been in companies of thousands. I think I’m best cast in teams of 5-20 and I’ve found I’ve done well building good culture around working within the limits of what the business needs (realistic costing, time estimates, alignment to product vision) while finding ways to intertwine the quality developers want to see in their own work with the objectives of product and the leadership team.

I think to try put it in simpler terms, the best people want an environment where they can do their best work. The question i encourage people to ask themselves is if they actually know what that environment looks like? Often they have an idea of what’s worked best so far, but not what is optimal. I like having discussions around that as you can go from there to a) learn from their perspective and see if you can include part of that in the environment you’re presently operating under and b) determine if that’s a good near team goal or long term goal for the current environment and set realistic expectations with that individual as to not “bait and switch” them. I really see little point wasting someone’s time with promises of utopia when you’ve got a team that just isn’t working…that’ll end predictably.

I’ve said before my best skill has been building small teams of very bright people, retaining them and out performing larger teams. It’s pretty trivial to out perform larger teams if you can retain people, but to retain them they need to like what they’re doing and how they’re doing it.

I understand better, thanks. Initially I was reacting pretty strongly based on past traumatic managers but your approach centers the people you manage which sounds like a decent compromise between what the company needs and what the worker wants.

Thanks for asking! Honestly I’m sure I’ve been that bad manager plenty of times, no one improves without making plenty of mistakes, unfortunately.

I've found more and more recently that a lot of things I've thought to be a universally incorrect option often can work with the right person behind it. I don't think it's entirely hard to believe someone can executed a top-down management style well

Love this. So relatable. Keep this attitude please, and use it beyond your work life.

I've worked in both, top-down and bottom-up + as a manager. I think both have their merits, and different people want/need different styles. For me, it was fun to be able to drive my own backlog, do my own discoveries, talk with stakeholders and feel like I really owned the product as well.

Now I work as an IC again at a more top-down place where I work fully remote and only 4 days a week. It's honestly quite nice to not have to talk to anyone and just wake up at 6am, have my task assigned, get it done and then go focus on my hobby projects/go hiking/exercise/spend time with my girlfriend. I don't have to be online 24/7 and I have maybe 2-3 meetings a week. The org sets the direction and we decide how to implement it. It works for me because in many ways I drive the requirements by telling the org what I need to execute properly. I can also still drive infrastructure improvements, and the org. is mature enough to prioritize them. I still grow, just in a different direction than I did as a manager. I get the chance to really focus on the technical parts of a solution.

> The org sets the direction and we decide how to implement it.

This is key.

"Good" managers can manage the expectations of the org to enforce this kind of relationship if the org wants to be pushy or micromanage-y. They insulate their team to create a real sense of agency and ownership. It's nice that your org makes your manager's job easy in this regard.

"Bad" managers are the opposite, they just dump the poorly-defined, poorly-justified demands onto their ICs. When they can't figure out why things aren't going well, they call for many hours of meetings with their ICs to hash out in detail how the implementation should proceed, which typically ends up being nothing more than the manager trying different ways of convincing their ICs to do it the way they already imagine it should go.

That is some deeply targeted recruiting my friend. ;)

Lol, yeah honestly wasn’t the plan but adding the plug felt like an opportune moment.