Ask HN: What mistakes in your experience does management keep making?
271–280 of 396 posts
Re: Ask HN: What mistakes in your experience does management keep making?
#272Re: Ask HN: What mistakes in your experience does management keep making?
#273I'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 unfores…
I think it is important while young to be very aggressive with the YAGNI because otherwise you will have a much harder time developing that prediction skill, as the data set will be much noisier.
Re: Ask HN: What mistakes in your experience does management keep making?
#274I've never met a manager that wouldn't rather pay four average people $100/hr to solve a problem that one smart person could solve in half the time for $400/hr. There seems to be some sort of quasi-religious belief in the fundamental averageness of humans; consequently the difference between developer salaries at any company varies by maybe 50%, whereas the productivity varies by at least a full order of magnitude. U…
There is a chance of the four who are not as capable today, 1-2 might become a stars in the future. He/she will be more loyal because of the opportunity the manager gave them.
Re: Ask HN: What mistakes in your experience does management keep making?
#275#2: Not putting more effort into communication and discovering needs of departments they have been unable to communicate properly to get approved. I'm a senior sysadmin (taking a break and transitioning to data science), but for a long time all I wanted to do was be in the datacenter with my head in a terminal and doing good work. In retrospect since my break, I have realized that as a senior that's not my role anymore except in case of escalation no one else can solve. I was not playing the board-room politics game to get what my department needed, and that was a failure on my part. Generally, I am now calling for high investment in the CTO/CIO position because they should be the people who can talk to the technical people who don't need to spend all day in a meeting room, and spend all day in the meeting room advocating for them and the things they and the department need. Execs like to stay on their pedestal and force others to rise to their level, but they need to spend at least some effort on actually listening to the middle-men and "going down to their level" so to speak.
I don't care what industry you are in, those two things alone would vastly improve the workplace for workers of all types (not just IT) and business in general. Those two misteps, particularly combined with lackluster reward systems (once spent a year working overtime-exempt salary hoping for a raise, and instead, after having spent the overtime while salary fixing up a place, got shifted to hourly once I was no longer working late and on weekends,) are recipes for hemoragging good talent. Good talent might temporarily forget how good they are, are be stuck for some other reason, but it's only a matter of time before they drop your company like hotcakes and move on. Pay them fairly, and as far as retention goes, real, substantial bonuses can make all the difference.
Never forget, that regardless of industry, your internal IT team is much more critical and important than you can imagine, and ignoring IT as your bastard-child will come back and bite you in the ass. Removing technical debt should be a #1 priority.
It's one reason I am so thankful for being a senior sysadmin for so long. As a senior, since we touch so much of a company, I got to see the internal non-it mechanisms of so many companies I think I have gained a level of macro-business insight not many have.
Re: Ask HN: What mistakes in your experience does management keep making?
#276There are some very common ones; * Building a one more generation of product than the market supports (so you build a new version when the market has moved on to something new). * Rewarding productivity over quality. * Managing to a second order effect. For example when Nestle' bought Dryers they managed to 'most profit per gallon' which rewarded people who substituted inferior (and cheaper) components, that lead to…
> Tolerating misbehavior out of fear of losing an employee. What if said employee pulls in 10x, 100x more revenue/value than average worker for the company? Would you fire him because the rule book say so? That said I trust in effective communication as soon as possible to manage difficult situations or misbehaviour. Often the reasons can be deeply personal or family related and people are preoccupied with stuff outs…
Unless you're pulling in that revenue directly, because you're in sales or negotiating deals with other companies, it's impossible to make the claim that someone is 10x more valuable to the company.
Of the most highly productive devs I've ever known, most of them are not 10x more valuable, they are just more productive. The very few real super-programmers I've ever seen (maybe 3 of them in 20 years) have skyrocketed into the stratosphere, make lots of money and lead large teams. So, I don't think anyone super valuable would get fired, but my experience is that they get moved (up).
Most highly productive devs I've known are productive people that are prolific and also do a proportional amount of damage. I've known several people in different companies that were smart, prolific and very opinionated, and they would inflict their ideas on everyone and get support from management and not enough pushback from other devs. They implemented processes that were needlessly complex and caused measurable drain on the productivity of everyone else. You can lose your 10x productivity benefit really fast if you suck 10% from everyone else.
One guy I knew was a 10x performer and lead a team, but had a nasty attitude and took down the morale of everyone he talked to regularly. Even though he performed, he was causing everyone around him to go slower and work less. To the parent comment's point, this guy's productivity kept him from getting fired despite his misbehavior.
Re: Ask HN: What mistakes in your experience does management keep making?
#277* 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…
This, so much. No matter how many first-years physics students you have, you're not going to invent general relativity.
Re: Ask HN: What mistakes in your experience does management keep making?
#278* Micromanaging, always the micromanaging.
Re: Ask HN: What mistakes in your experience does management keep making?
#279Earlier 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.