Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: What mistakes in your experience does management keep making?

news.ycombinator.com

Post reply on HN
Print view View original

231–240 of 396 posts

Re: Ask HN: What mistakes in your experience does management keep making?

#231

Post by Boothroid »

elliottcarlson wrote: post #158
muzani wrote: post #69

* Killing things that are low profit margins, under some misguided Pareto Principle approach. Sometimes these things are loss leaders designed to pull customers for other products. * Spending too much on marketing/sales before people want the product. They usually just end up burning their brand if the product is too low quality. * Too much focus on building multiple small features rather than focusing on the value p…

> Importing tech talent, rather than promoting. is often at odds with both the point above and below it. When a company is in rapid growth, there may be a point where the talent they relied on is not quite ready for the promotion they are hiring in for. Without expanding that search outside, you may become stale in the organization, and not provide the right mentorship to ensure that those interested in getting promo…

Here's another one - promoting without advertising the role first. Come annual review time: 'I am pleased to announce that x, y and z are now Senior Consultants and will be managing a, b, c, d, e and f' (who were never given any chance to apply for the role).

Re: Ask HN: What mistakes in your experience does management keep making?

#232

Post by le-mark »

ideonexus wrote: post #199

The biggest recurring issue I have with my managers over the last twenty years is their need to add unnecessary complexity to projects. I think a good manager stays out of the way and just monitors employees for any obstructions that are preventing them from meeting their goals. Yet, my experience is that when a manager sits in on a project meeting, they can't help but start giving input on the project itself, adding…

The best manager I every had was famous for telling his guys to give him the easy 80%, and worry about the hard stuff when someone will pay for it. That person was pure gold, highly effective.

The worst, there have been many. These guys just complicate simple task so no one knows what they're supposed to be doing anymore. Managers should ruthlessly limit scope wherever possible.

Re: Ask HN: What mistakes in your experience does management keep making?

#233

Post by le-mark »

marcus_holmes wrote: post #118
dasmoth wrote: post #92

Earlier quoted context omitted.

they worked in 2-3 day sprints for ridiculous hours, and then stayed home or might as well have. The other points you make might be big problems depending on the situation, but this? What's wrong with someone taking a day off after a burst of productivity? This seems like classic valuing of face-time over results.

it's not team-oriented behaviour. I'm not talking about face-time, but about having the attitude that you're part of a team. The "10x" works 16 hours a day for 3 days and produces a chunk of code that works, does what it's supposed to, ahead of schedule. So far, so awesome. But the rest of the team is working away on the rest of the project. Suddenly they're lumped with a huge chunk of code that they don't understand…

This is not 10x, this -10x. If a developer churns out tech debt in a vacuum, they're a liability, not an asset.

Re: Ask HN: What mistakes in your experience does management keep making?

#234

Post by noxToken »

jerf wrote: post #217

I'll add one that even after 200 comments I don't see: Failure to explain the reason why . Coming down to their developer with a list of tasks without explaining why those tasks are the most important and will lead to company success. You might think startups are small enough that this couldn't happen but that was actually where my worst experience was. The founders are visibly in a meeting with a couple people, mayb…

> This is especially important IMHO for more senior engineers responsible for architecture and stuff, because those matters can greatly affect the architecture. Telling me why lets me start getting a grasp on what parts of the code are long term and what can be considered a short term hack, what the scaling levels I need to shoot for...

This right here has been the biggest problem in my experience. We'll have unforeseen issues arise in production, and the business side will come up with methods to fix the issue. Without context, all of these fixes to our products have been fine, but they never take the future into consideration. It makes me paranoid.

I used to adhere pretty well to the adage "Write code for what you have now and not some mystical thing that may arise in the future" while still maintaining enough abstractness to extend things. New requirements would come in, we would implement them, and everyone is happy. 3 months later, a new set of requirements that destroys how we wrote something else. If we knew a road map before we started designing and implementing, we could have saved everyone time and money by designing for X + Y instead of X alone.

I get that you can't know everything that is going to happen. I get that there will be times where you must refactor the code. That's fine. However, tell me where the product is going. It may seem like a trivial change to you as a business person, and the only way we devs can keep the change trivial is by proper design.

Re: Ask HN: What mistakes in your experience does management keep making?

#235

Post by lhnz » 

  * Micromanagement of skilled people.
  * Over-investing when things have gone badly
    wrong, and being sluggish to invest in a team
    which is having success.
  * Hiring unskilled engineers to develop features
    which are meant to be reused by other teams.
    Bad or complex architecture leads to lots of
    workarounds and bugs, which destroy efficiency
    in other teams.
  * Not investing in fixing inefficiencies, instead
    just asking people to work longer hours.

Re: Ask HN: What mistakes in your experience does management keep making?

#236

Post by Deestan »

MatthewWilkes wrote: post #136
marcus_holmes wrote: post #70

Earlier quoted context omitted.

In my experience, the 10x programmer is a bit of a myth. Where I have seen people do some incredible feats of productivity, it usually came with a clutch of bad stuff, too. Like: - they didn't work well with others and soaked up a lot of management time dealing with their shit. - they had really limited areas of expertise where they were amazing, but couldn't fill in for a sick colleague. - they worked in 2-3 day spr…

I think it depends on perspective. I don't think there's a 10x programmer, but I've worked with plenty of 0.1x programmers. If your organisation is not doing a good job of managing your developer team you may have a very skewed view of what 1x really looks like.

That's my impression too. It's not that good programmers are immensely more productive than decent programmers, it's that bad programmers are very bad. Not only can they just not do certain things, but they leave messes that others have to spend time fixing.

I've had days where I've ended up doing literally nothing, but still objectively outperform some colleagues because they rammed some shitty unstable undocumented race-condition hack into the codebase.

Re: Ask HN: What mistakes in your experience does management keep making?

#237

Post by Angostura »

pestkranker wrote: post #200
Boothroid wrote: post #131

* Zero career direction and zero technical speciality for devs * Underestimation of difficulty whether through cynicism (burn the devs) or cluelessness * Inadequate training and expectation devs can just piggy back learning technology x from scratch whilst writing production software using it * Trying to use one off contracts as a way of building resellable products * Insistence that all devs time must be billable an…

> * Trying to use one off contracts as a way of building resellable products Can you tell me why? Sometimes, asking a client for 50k instead of 80k with a "spin-off" agreement can pay to both parties. The client can get long-term support with new features without the need to pay for it.

This was the one that really struck a chord with me. You start of trying to take the product you created for one specific client and then generalising it.

You end up, in practice creating a individual bloody application for each client.

(Not a coder, more a manager who created specs and tried to shield the coders from the worst of the shit-storm).

Re: Ask HN: What mistakes in your experience does management keep making?

#238

Post by groby_b »

elliottcarlson wrote: post #158
muzani wrote: post #69

* Killing things that are low profit margins, under some misguided Pareto Principle approach. Sometimes these things are loss leaders designed to pull customers for other products. * Spending too much on marketing/sales before people want the product. They usually just end up burning their brand if the product is too low quality. * Too much focus on building multiple small features rather than focusing on the value p…

> Importing tech talent, rather than promoting. is often at odds with both the point above and below it. When a company is in rapid growth, there may be a point where the talent they relied on is not quite ready for the promotion they are hiring in for. Without expanding that search outside, you may become stale in the organization, and not provide the right mentorship to ensure that those interested in getting promo…

It's not just a rapid growth thing. It's pretty well known that if you want your career to progress at a non-glacial pace, you'll need to hop jobs. Pretty much all companies are more willing to take a risk on new hires than on their own people.

Re: Ask HN: What mistakes in your experience does management keep making?

#239

Post by tboyd47 »

Trying to write code alongside their devs.

Here's what happens when a manager tries to fill tickets himself: his sense of control of the project is derived not from relationships of trust and cooperation with his reports, but from direct involvement in the code. So naturally, any challenging or critical piece of code ends up getting written by him (because otherwise, how could he be confident about it?)

The manager is essentially holding two jobs at once so they end up working late or being overly stressed at work.

The devs will feel intimidated to make architecture decisions, because they know if they do something their manager doesn't like, it will get refactored.

They will also feel as if they are only given the "grunt work" as all the challenging work is taken on by their manager.

The code itself is in a constant state of instability because there is a tension between the manager needing the other employees' help to get the code written on time, while also needing to have that complete control and mastery over the code that can only come from writing it yourself. So people's work gets overwritten continually.

This is very bad and it's very common - managers should learn to delegate as that is an essential part of their job. If they can't delegate they should remain as an individual contributor and not move into management.

Re: Ask HN: What mistakes in your experience does management keep making?

#240

Post by Karunamon »

Managers making tech decisions without the input of the people who work with systems every day who are in the best position to determine whether that's a good decision or not.

True story:

A deployment of a distributed application at $dayjob a long while ago had "must have RAID6 or equivalent fault tolerance" added to its project requirements by clueless managers. The engineer who specced out the system, who was responsible for its POC, and had spent many, many hours setting up the environment and tweaking it for performance protested, since the application had fault tolerance built in. The idea being that if a node loses a hard drive, we don't care. We just throw a spare drive (that's kept in stock) in, rebuild the node (a literal 10 minute process), and no data is lost.

Protests, backed up with data, that long RAID6 rebuild times on TB+ drives increased the likelihood of data loss (a restripe takes longer than our average rebuild-the-damn-machine-from-scratch time and leaves the cluster degraded longer) went ignored.

The RAID6 requirement added about 50% to the cost of the project, and ended up having to be thrown out around ~6 month mark since the cluster write performance was unable to keep up with the RAID0 that the engineer had originally specced out. We now use the engineer's original idea, even though he long since moved somewhere where presumably, his experience is trusted rather than insulted. This incident was a contributor to his decision to leave.

To this day, RAID6 is an inside reference to management cluelessly screwing up a project against the wishes of people who know better.

Post reply on HN