Lessons from Mythical man-month aside, what mistakes does management keep making and what do they never seem to learn? And of course the effects on those on you and your peers?
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, maybe "suits", maybe not. They come out of the meeting and the next day your priorities are rewritten. Cool beans, that's a thing that can happen and that's not my issue. My issue is, why? What are the goals we are trying to hit now? What's the plan? Why is that better than the old plan?
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, and all sorts of other things that are very hard to determine if you just come to me with "And actually, our customers need a new widget to frozzle the frobazz now more than they need to dopple the dipple now."
Not necessarily the biggest issue, there's a lot of other suggestions here that are probably bigger in most places, but this is one that has frustrated me.
(I'll also say this is one you may be able to help fix yourself, simply by asking. If you are in that senior role I think you pretty much have a professional obligation to ask, and I would not be shy about working that into the conversation one way or another.)
> 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.
Both managers and co-workers come to me asking me to perform a task. If I don't know why they're asking, then I immediately ask:
What is the problem you're trying to solve?
This is just a different way of asking "Why?" More often than not, this changes the entire conversation. Often this leads to us determining that the task is unnecessary. Sometimes it's that a different approach would be better. Sometimes I do the task with a small modification. Rarely, I perform the task exactly as described.
>You might think startups are small enough that this couldn't happen but that was actually where my worst experience was.
Start ups are merely new businesses. New businesses can be poorly run just like any other business can. If anything, start ups are probably more likely to be poorly run merely because the genuinely awful ones haven't gone out of business yet.
If people (even if they have a special position in the company) can just come to your developers with a list of tasks, without going through a process, that is a much bigger problem.
Agreed. Sometimes though I suspect this falls into the deliberate siloing of information category - though God knows how anyone thinks that keeping people uninformed is a good way to write software.
* 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 proposition.
* Trying to negotiate deadlines for product development. "We don't have two months to finish this. Let's do this in one." In software estimation, there's the estimate, the target, and the commitment. If the commitment and estimate are far off, it should be questioned why, not negotiated.
* Hiring two mediocre developers at half the salary of one good developer. They usually can't solve problems past a certain treshhold.
* Importing tech talent, rather than promoting. Usually the people who have built the product have a better understanding of the tech stack than someone else they import.
* Startups that rely on low quality people to skimp on the budget. These people later form the DNA of the company and make it difficult to improve, if they're not the type who improve themselves.
I'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.
Until "management" realizes this, the only way that a developer on the upper end of the productivity scale can capture their value is to found their own company. I sometimes wonder what would happen if some company simply offered to pay 3X the market rate and mercilessly filter the results.
Want to jump ahead a few years from Mythical Man-Month? Let me recommend Peopleware by Tom DeMarco and Tim Lister.[2] It's painful that we haven't crawled far out of the 80s practices.
The first chapter says: "The major problems of our work are not so much technological as sociological in nature." Sorry Google Memo Dude. DeMarco and Lister called it in the 80s.
Speaking of DeMarco, he also wrote a book about controlling software projects before Peopleware. Then in 2009 he denounced it. [1]
To understand control’s real role, you need to
distinguish between two drastically different kinds
of projects:
* Project A will eventually cost about a million
dollars and produce value of around $1.1 million.
* Project B will eventually cost about a million
dollars and produce value of more than $50 million.
What’s immediately apparent is that control is really
important for Project A but almost not at all important
for Project B. This leads us to the odd conclusion that
strict control is something that matters a lot on
relatively useless projects and much less on useful
projects. It suggests that the more you focus on control,
the more likely you’re working on a project that’s
striving to deliver something of relatively minor value.
I always think about that when I'm doing a Sprint Review.
Is the A/B situation DeMarco describes about knowing ahead of time that A will turn minimal profit while B will turn maximal profit?
If so, the conclusion reached seems right: tighter profit margins require tighter control. And control requires resource, which is a cost that further diminishes returns.
But if the described scenario is about not knowing ahead of time whether A or B will turn a large profit, how should this be handled? Regular review, and a scaling-down of control as confidence in profit increases?
Of course, profit is only one metric. There may be others that are more critical.
Working for a company building heavy hardware, I see the following happen time and time again:
* Reorganizing seemingly for the sake of reorganizing. Result: Every time the new organization has settled somewhat and people know who to interact with to make things flow smoothly, everything is upended and back to square one.
* Trying to make our products buzzword compliant without understanding the consequences - we've on occasion been instructed to incorporate technologies which are hardly fit for purpose simply because 'everyone else is doing it' (Where 'everyone' is the companies featured in whatever magazine the CEO leafed through on his latest flight. Yes, I exaggerate a bit for effect.)
* Misguided cost savings; most of what hardware we use, we buy in small quantities - say, a few hundred items a year, maximum. Yet purchasing are constantly measured on whether they are able to source an 'equivalent' product at a lower price. Hence, we may find ourselves with a $20,000 unit being replaced by a $19,995 one - order quantity, 5/year - and spend $10,000 on engineering hours to update templates, redo interfaces &c.
* Assuming a man is a man is a man and that anyone is easily and quickly replaceable (except management, of course) - and not taking the time and productivity loss associated with training new colleagues into account.
Edit: An E-mail just landed in my inbox reminding me of another:
* Trying to quantify anything and everything, one focuses on the metrics which are easy to measure, rather than the ones which matter. As a result, the organization adapts and focuses on the metrics being measured, not the ones which matter - with foreseeable consequences for productivity.
"Reorganizing seemingly for the sake of reorganizing"
These things often to be the observable consequence of political battles between executives. From what I've observed there are always clear winners and losers in these battles (although it may take a while to work out who lost and who won). From the perspective of the execs who were for the re-orgs and who come out on top these reorganizations are positive things even if they are bad for the company as a whole - typically they don't care about the company as a whole only for what they can get out if it.
Edit: A colleague once said that the behaviour of executives became far easier to understand and predict once you found out their individual bonus calculations were done (which, of course, we weren't supposed to know).
* Software is not an assembly line. It is part science part art. We are not interchangeable. You can't take an embedded engineer and hope for good luck on a Node.js project.
* Constant reorganization. I worked at a major internet company in the late 90s, early 00s and they literally reorganized every two years. It was usually under the guise of helping communication and fostering growth but it simply just toggled from a vertical project based organization to a flat and wide matrix organization. Such a waste of time, energy, and resources.
* 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 lower overall sales and that leads to lower overall revenue. Had they managed to overall revenue they might have caught the decline sooner.
* Creating environments where nobody trusts anyone else and so no one is honest. Leads to people not understanding the reality of a situation until the situation forces the disconnect into the mainstream.
* Rewarding popular popular employees differently than rank and file. Or generally unevenly enforcing or applying standards.
* Tolerating misbehavior out of fear of losing an employee. If I could fire anyone in management who said, "Yeah but if we call them on it they will quit! See what a bind that puts us in?" I believe the world would be a better place.
There are lots of things, that is why there are so many management books :-)
I have held management and non-management careers in roughly equal proportion over my career. My list would look like this:
1) believing you can dramatically change the performance of an employee -- it's very rare to save someone and less experienced managers always believe they can.
1.5) corollary to the above: not realizing the team is aware and waiting for you to fix the problem and won't thank you for taking longer to do what's necessary.
2) believing that people don't know what you're thinking -- people see you coming a mile off.
3) thinking you can wait to fix a compensation problem until the next comp review -- everyone waits too long on these.
4) believing HR when they tell you that you can't do something that's right for your team -- what they're really saying is that you have to go up the ladder until you find someone who can force them to make an exception.
5) not properly prioritizing the personal/social stuff -- at least this is my personal failing, and why ultimately management has not stuck for me.
6) believing your technical opinion matters -- I've seen way too many VP's making technical decisions that they are too far from the work to make, trust your team!
It'd be fun to see a list of these from the non-management point of view. I'd start off with the inverse of #6 above:
1) believing your technical opinion matters -- the business is what ultimately matters.
6) believing your technical opinion matters -- I've seen way too many VP's making technical decisions that they are too far from the work to make, trust your team!
This! It needs management people who understand their role as being "facilitators", rather than being "decision makers". And they are kind of rare.
In response to 1 and 1.5 the company should expend reasonable resources to support those who are struggling, and these rules are laid down in Human Resources policies (as I'm sure you know).
Management are just as bound by the rules as non-management, or should be.
Of course, "reasonable" here has a strong subjective component.
I have seen dramatic change in an individual, but it's the exception. More likely is a slow progression to dismissal. This can be handled well by management with appropriate skills, but is hard and is a often suboptimal. However it's possible that this process is a necessity in any organisation that supports its staff. Wishing it to not happen is unrealistic, and indicates naivety. Perhaps these naive, disgruntled employees are part of a larger problem?
You can't change it dramatically overnight, but you can certainly change it enough that it's worth it.
It's a boatload of work. Expect to spend as much time per week as you usually spend on 3-5 people. Then make the call if you can afford to do that. It's buying you a lot in terms of employee goodwill and team morale. (The second one only if you don't neglect the team over it, obviously :)
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.
I couldn't agree more here. As a manager you need to do all the shit work. The work the team hates. Ad integration, 3rd party phone calls, aws cost cutting, etc. All the grunt work too. Going through every god damn qa ticket. If you do this your team will perform at a higher level. Pushing crap work to the team will demotivate them and force multitasking.
Interesting, as a manager, I try very hard to do as much of the grunt work as possible and the devs do more feature coding. Out of curiosity, where do you rank data modeling?
I tend to want to either design or review all data design, either relational or other, partly because of my background in data engineering and partly because I have business awareness that the devs don't have. It's just not possible to convey every nuance of a constantly evolving business to each dev on the team without it being distracting.
How would you like your manager to handle being involved in data modeling? Develop a spec and then review? pair modeling?
For a manager that was a developer, this is one of the hardest things to learn. Knowing how and when to delegate properly.
When I first took on a manager role, I for sure made this mistake. Anything hard had to have me fully involved. Grunt work was definitely given out, and yeah, I ended up being stressed out far too often.
I think it's important to have manager training for new managers. Somebody to whisper over their shoulder and say, "give them a shot, trust them on this"
As a manager, what's the best way to respond when your VP or CEO asks you why you don't code a lot? I've been pressured to both code and manage. It takes two totally different mindsets to do that. It is really hard, and it usually means I end up not doing a good job at either.
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 complexity to defined business rules or adding obscure use cases to the system. Too many managers can't help but dominate meetings because their dominant personalities is how they became managers in the first place.
The worst is when you get two or more managers attending the same meeting. Then nothing will get done as they eat up all of the meeting time arguing about business rules, magnifying the complexity of the system until you end up with some Rube Goldberg chain of logic that they will completely forget minutes after they've left the meeting. A good manager knows to trust their employees and only intervenes to make sure those employees have the resources they need to do their jobs. The most effective managers are humble and respect the expertise of the experts they hire.
- Trying to "create a buzz" around the office, asking for a "sense of urgency," and other things that result in an illusion of productivity.
- Focusing on fixing problems, rather than preventing problems
- Acting as yes-men to bad upper-management strategy, thereby creating a layer of indirection between the people who think it's a good plan vs the engineers who can explain why it's not quite that easy
- Trying to use software tools (e.g. Jira's burndown charts) to quantitatively/"objectively" measure engineers
Promoting technical people with no management experience into management jobs, without providing them with any training or guidance. (Happened to me.) Writing code and managing people require very different sets of skills, and just because you're good at the former doesn't necessarily mean you'll be any good at the latter (or that you'll enjoy doing it).
(Similar problems can happen when a bunch of people with no management skills decide to found a company and start hiring people.)
The worst mistake I've seen management make over 20 years of software development is not listening to the technical people.
Estimates get shortened. Technical decisions are overruled for business or political reason. Warnings about undesirable outcomes are ignored. Sheer impossibility deemed surmountable.
I feel this is the worst mistake by management because the technical people are the ones who suffer for it. Overtime, inferior software, frustration, technical debt, lack of quality, are all things management doesn't really care about because they can always just push people harder to get what they want.
Overly optimistic schedules. Even with a known gelled team, being constantly overscheduled is a nightmare. You cut corners, and are always stressed and tired. Other teams that believe the optimistic schedules may become angry or blocked on you. Over time this just leads to burnout, but since nobody seems to stay anywhere for very long, nobody seems to care.
This! In the same vein, believing that "this time" the team will work faster because of lessons learned. Refusing to accept that historical performance really is the true performance of the team. Failing to account for the previous project completing almost on schedule only because of major overtime. Etc etc.
On my first project I learned that every time a PM said the word "hope" (as in "I hope we can meet this deadline") that we were screwed. It was said a lot.
When I had a corporate job, they were overly controlling about schedules and how much you could earn in a way that was completely unnecessary and that I felt came back to bite them. People who wanted more money would take on part time jobs for evenings and weekends. Then, when management tried to put a gun to our head and insist we work overtime, these people had prior commitments and couldn't be there. Bonus points for the whole atmosphere of fear with the entire approach of trying to pressure people to work overtime on demand, at the convenience of the company.
None of this was really necessary. Every single year, they watched the backlog of work gradually climb over the course of the summer. Then, around September, they began insisting on overtime at psychological gun point to try to clear the backlog. It would have been entirely possible to allow people who met certain quality standards to work some overtime during the summer and cap how much could be worked. People could have competed for overtime slots instead of feeling forced into it. It would have worked vastly better for everyone.
Of course, an elegant solution like that takes a bit more planning on the end of management. Simply demanding extra hours at a certain point is a simpler, brute force method. But, I felt it had a lot of downside to it and was mostly avoidable for the company in question.
It makes me wonder how many companies basically create drama of this sort. Because this crisis was entirely created by management, IMO. There was zero reason they had to wait until it hit a certain volume and then force overtime on us.
Everywhere I've worked, the folks running the show have too much ego and political capital invested in products or projects that are turds. The result is massive financial losses for the business.
My experience has been similar in the past. In more recent times I've seen numerous products rewritten from scratch by completely new teams on different continents - the mindset being that they would do things "properly" - only to encounter all the problems that the original teams had to deal with, and re-implement the same mistakes, but in a different language. In one case, the new team quit to a man ( and obviously, the old team were nolonger around either ), resulting in the loss of two complete product implementations, and all the domain and implementation knowledge.
Something I see a ton is management by crisis - 20 people from an organization could tell certain managers that there will be performance issues in 3 months if we don't pay down tech debt, but nothing actually sinks in until there is a performance crisis in 3 months.
1. Arrogance (only do what I say, don't think for yourself)
2. Fear (you're getting a lot of attention and praise, this somehow makes me look bad)
3. Short sightedness (that's a good idea, we can't use it here, now go do something productive)
A good manager loves his team and opens doors, prevents road blocks, and facilitates approvals for them. He is a steward of their success. He removes fear of failure. He is not self absorbed but finds joy in the team. So, without these attributes, the negative effects are too sad to write about.
I think management fails when they don't understand that the nerds hired them and not the opposite. We are the technology, we did it in the first place. We hired managers to help us. By default, we know better than them (because we are the one who do the tech), they should listen to us and not the opposite. Now, when everybody knows his place, we can collaborate and do great work.
I got the luck to work with great managers at amazon. From what I've seen, programmers are driving the company there - or at least, they have their word to say, often, and power that comes with it. On my team, decisions relative to product development were clearly strongly driven by us. Seems to work pretty well for amazon.
The tone you use here helps make my point: just because "nerds" are experts in everything tech does NOT equate to good decision making / good management for the company as a whole. Sometimes it does. Often times it does not. Things aren't usually that black and white; "I built it, so I should run it." Just had this convo with a coworker the other day. He was telling me about all the complaints from the dev team and how we should let them drive the bus. I had to remind him of all the good-tech-but-bad-business ideas several of them have offered in the past. In my experience, the rare "nerd" who also intimately understands the nuances of every day business (relationships, the board, profit margins, brand experiences, etc.) is hard to beat.
It might be the case with companies like Amazon, but in other areas, or in government contracting, the contractors were present long before current technology was born. And they are still the ones running the show, IT is just a current commodity they sell.
[+] [-] jerf|8 years ago|reply
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, maybe "suits", maybe not. They come out of the meeting and the next day your priorities are rewritten. Cool beans, that's a thing that can happen and that's not my issue. My issue is, why? What are the goals we are trying to hit now? What's the plan? Why is that better than the old plan?
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, and all sorts of other things that are very hard to determine if you just come to me with "And actually, our customers need a new widget to frozzle the frobazz now more than they need to dopple the dipple now."
Not necessarily the biggest issue, there's a lot of other suggestions here that are probably bigger in most places, but this is one that has frustrated me.
(I'll also say this is one you may be able to help fix yourself, simply by asking. If you are in that senior role I think you pretty much have a professional obligation to ask, and I would not be shy about working that into the conversation one way or another.)
[+] [-] noxToken|8 years ago|reply
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.
[+] [-] justin_oaks|8 years ago|reply
What is the problem you're trying to solve?
This is just a different way of asking "Why?" More often than not, this changes the entire conversation. Often this leads to us determining that the task is unnecessary. Sometimes it's that a different approach would be better. Sometimes I do the task with a small modification. Rarely, I perform the task exactly as described.
[+] [-] thehardsphere|8 years ago|reply
Start ups are merely new businesses. New businesses can be poorly run just like any other business can. If anything, start ups are probably more likely to be poorly run merely because the genuinely awful ones haven't gone out of business yet.
[+] [-] hobofan|8 years ago|reply
[+] [-] Boothroid|8 years ago|reply
[+] [-] nashashmi|8 years ago|reply
[+] [-] muzani|8 years ago|reply
* 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 proposition.
* Trying to negotiate deadlines for product development. "We don't have two months to finish this. Let's do this in one." In software estimation, there's the estimate, the target, and the commitment. If the commitment and estimate are far off, it should be questioned why, not negotiated.
* Hiring two mediocre developers at half the salary of one good developer. They usually can't solve problems past a certain treshhold.
* Importing tech talent, rather than promoting. Usually the people who have built the product have a better understanding of the tech stack than someone else they import.
* Startups that rely on low quality people to skimp on the budget. These people later form the DNA of the company and make it difficult to improve, if they're not the type who improve themselves.
[+] [-] stickfigure|8 years ago|reply
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.
Until "management" realizes this, the only way that a developer on the upper end of the productivity scale can capture their value is to found their own company. I sometimes wonder what would happen if some company simply offered to pay 3X the market rate and mercilessly filter the results.
[+] [-] JamesLeonis|8 years ago|reply
The first chapter says: "The major problems of our work are not so much technological as sociological in nature." Sorry Google Memo Dude. DeMarco and Lister called it in the 80s.
Speaking of DeMarco, he also wrote a book about controlling software projects before Peopleware. Then in 2009 he denounced it. [1]
I always think about that when I'm doing a Sprint Review.[1]: https://www.computer.org/cms/Computer.org/ComputingNow/homep... [2]: https://en.wikipedia.org/wiki/Peopleware:_Productive_Project...
[+] [-] austinjp|8 years ago|reply
Is the A/B situation DeMarco describes about knowing ahead of time that A will turn minimal profit while B will turn maximal profit?
If so, the conclusion reached seems right: tighter profit margins require tighter control. And control requires resource, which is a cost that further diminishes returns.
But if the described scenario is about not knowing ahead of time whether A or B will turn a large profit, how should this be handled? Regular review, and a scaling-down of control as confidence in profit increases?
Of course, profit is only one metric. There may be others that are more critical.
[+] [-] j_s|8 years ago|reply
Programming Beyond Practices https://amzn.com/dp/B01LYRCGA8 $14.99
detailed examples of the many problems developers encounter, including the thought process it takes to solve them
[+] [-] tnolet|8 years ago|reply
[+] [-] tnolet|8 years ago|reply
[deleted]
[+] [-] lb1lf|8 years ago|reply
* Reorganizing seemingly for the sake of reorganizing. Result: Every time the new organization has settled somewhat and people know who to interact with to make things flow smoothly, everything is upended and back to square one.
* Trying to make our products buzzword compliant without understanding the consequences - we've on occasion been instructed to incorporate technologies which are hardly fit for purpose simply because 'everyone else is doing it' (Where 'everyone' is the companies featured in whatever magazine the CEO leafed through on his latest flight. Yes, I exaggerate a bit for effect.)
* Misguided cost savings; most of what hardware we use, we buy in small quantities - say, a few hundred items a year, maximum. Yet purchasing are constantly measured on whether they are able to source an 'equivalent' product at a lower price. Hence, we may find ourselves with a $20,000 unit being replaced by a $19,995 one - order quantity, 5/year - and spend $10,000 on engineering hours to update templates, redo interfaces &c.
* Assuming a man is a man is a man and that anyone is easily and quickly replaceable (except management, of course) - and not taking the time and productivity loss associated with training new colleagues into account.
Edit: An E-mail just landed in my inbox reminding me of another:
* Trying to quantify anything and everything, one focuses on the metrics which are easy to measure, rather than the ones which matter. As a result, the organization adapts and focuses on the metrics being measured, not the ones which matter - with foreseeable consequences for productivity.
[+] [-] arethuza|8 years ago|reply
These things often to be the observable consequence of political battles between executives. From what I've observed there are always clear winners and losers in these battles (although it may take a while to work out who lost and who won). From the perspective of the execs who were for the re-orgs and who come out on top these reorganizations are positive things even if they are bad for the company as a whole - typically they don't care about the company as a whole only for what they can get out if it.
Edit: A colleague once said that the behaviour of executives became far easier to understand and predict once you found out their individual bonus calculations were done (which, of course, we weren't supposed to know).
[+] [-] snarf21|8 years ago|reply
* Software is not an assembly line. It is part science part art. We are not interchangeable. You can't take an embedded engineer and hope for good luck on a Node.js project.
* Constant reorganization. I worked at a major internet company in the late 90s, early 00s and they literally reorganized every two years. It was usually under the guise of helping communication and fostering growth but it simply just toggled from a vertical project based organization to a flat and wide matrix organization. Such a waste of time, energy, and resources.
[+] [-] ChuckMcM|8 years ago|reply
* 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 lower overall sales and that leads to lower overall revenue. Had they managed to overall revenue they might have caught the decline sooner.
* Creating environments where nobody trusts anyone else and so no one is honest. Leads to people not understanding the reality of a situation until the situation forces the disconnect into the mainstream.
* Rewarding popular popular employees differently than rank and file. Or generally unevenly enforcing or applying standards.
* Tolerating misbehavior out of fear of losing an employee. If I could fire anyone in management who said, "Yeah but if we call them on it they will quit! See what a bind that puts us in?" I believe the world would be a better place.
There are lots of things, that is why there are so many management books :-)
[+] [-] sulam|8 years ago|reply
1) believing you can dramatically change the performance of an employee -- it's very rare to save someone and less experienced managers always believe they can.
1.5) corollary to the above: not realizing the team is aware and waiting for you to fix the problem and won't thank you for taking longer to do what's necessary.
2) believing that people don't know what you're thinking -- people see you coming a mile off.
3) thinking you can wait to fix a compensation problem until the next comp review -- everyone waits too long on these.
4) believing HR when they tell you that you can't do something that's right for your team -- what they're really saying is that you have to go up the ladder until you find someone who can force them to make an exception.
5) not properly prioritizing the personal/social stuff -- at least this is my personal failing, and why ultimately management has not stuck for me.
6) believing your technical opinion matters -- I've seen way too many VP's making technical decisions that they are too far from the work to make, trust your team!
It'd be fun to see a list of these from the non-management point of view. I'd start off with the inverse of #6 above:
1) believing your technical opinion matters -- the business is what ultimately matters.
[+] [-] rooundio|8 years ago|reply
This! It needs management people who understand their role as being "facilitators", rather than being "decision makers". And they are kind of rare.
[+] [-] austinjp|8 years ago|reply
Management are just as bound by the rules as non-management, or should be.
Of course, "reasonable" here has a strong subjective component.
I have seen dramatic change in an individual, but it's the exception. More likely is a slow progression to dismissal. This can be handled well by management with appropriate skills, but is hard and is a often suboptimal. However it's possible that this process is a necessity in any organisation that supports its staff. Wishing it to not happen is unrealistic, and indicates naivety. Perhaps these naive, disgruntled employees are part of a larger problem?
[+] [-] groby_b|8 years ago|reply
It's a boatload of work. Expect to spend as much time per week as you usually spend on 3-5 people. Then make the call if you can afford to do that. It's buying you a lot in terms of employee goodwill and team morale. (The second one only if you don't neglect the team over it, obviously :)
[+] [-] tboyd47|8 years ago|reply
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.
[+] [-] ransom1538|8 years ago|reply
[+] [-] kaspm|8 years ago|reply
I tend to want to either design or review all data design, either relational or other, partly because of my background in data engineering and partly because I have business awareness that the devs don't have. It's just not possible to convey every nuance of a constantly evolving business to each dev on the team without it being distracting.
How would you like your manager to handle being involved in data modeling? Develop a spec and then review? pair modeling?
[+] [-] Cshelton|8 years ago|reply
When I first took on a manager role, I for sure made this mistake. Anything hard had to have me fully involved. Grunt work was definitely given out, and yeah, I ended up being stressed out far too often.
I think it's important to have manager training for new managers. Somebody to whisper over their shoulder and say, "give them a shot, trust them on this"
[+] [-] drpentode|8 years ago|reply
[+] [-] adamb_|8 years ago|reply
[+] [-] ideonexus|8 years ago|reply
The worst is when you get two or more managers attending the same meeting. Then nothing will get done as they eat up all of the meeting time arguing about business rules, magnifying the complexity of the system until you end up with some Rube Goldberg chain of logic that they will completely forget minutes after they've left the meeting. A good manager knows to trust their employees and only intervenes to make sure those employees have the resources they need to do their jobs. The most effective managers are humble and respect the expertise of the experts they hire.
[+] [-] alexandercrohde|8 years ago|reply
- Focusing on fixing problems, rather than preventing problems
- Acting as yes-men to bad upper-management strategy, thereby creating a layer of indirection between the people who think it's a good plan vs the engineers who can explain why it's not quite that easy
- Trying to use software tools (e.g. Jira's burndown charts) to quantitatively/"objectively" measure engineers
[+] [-] greenyoda|8 years ago|reply
(Similar problems can happen when a bunch of people with no management skills decide to found a company and start hiring people.)
[+] [-] mychael|8 years ago|reply
* Preaching about the virtues of a flat organizational structure, but making unilateral decisions.
* Hiring people for a particular challenging job, but have them work on menial unchallenging tasks.
* Creating multiple layers of management for a tiny team.
* Facilitating post mortems that would be better facilitated by a neutral third party.
* Using vague management speak as a deliberate strategy to never be held responsible for anything.
* Rewarding politics with promotions.
* Marginalizing experienced employees.
* Talking too much about culture.
* Trying to be the company “thought leader” instead of helping people do their best work.
* Assuming that everyone underneath you views you as a career mentor.
* Negging employees.
* New hire managers: Firing incumbent employees after you’ve only been on the job for a few weeks.
* New hire managers: Not doing 1:1s with everyone who reports to you.
* New hire managers: Create sweeping changes like re-orgs after a few weeks on the job.
* New hire managers: Doing things a certain way because it worked well at a previous company.
* New hire managers: Changing office work hours to suit your personal life.
[+] [-] redleggedfrog|8 years ago|reply
Estimates get shortened. Technical decisions are overruled for business or political reason. Warnings about undesirable outcomes are ignored. Sheer impossibility deemed surmountable.
I feel this is the worst mistake by management because the technical people are the ones who suffer for it. Overtime, inferior software, frustration, technical debt, lack of quality, are all things management doesn't really care about because they can always just push people harder to get what they want.
[+] [-] cbanek|8 years ago|reply
[+] [-] cpitman|8 years ago|reply
On my first project I learned that every time a PM said the word "hope" (as in "I hope we can meet this deadline") that we were screwed. It was said a lot.
[+] [-] quickthrower2|8 years ago|reply
[+] [-] unknown|8 years ago|reply
[deleted]
[+] [-] Mz|8 years ago|reply
None of this was really necessary. Every single year, they watched the backlog of work gradually climb over the course of the summer. Then, around September, they began insisting on overtime at psychological gun point to try to clear the backlog. It would have been entirely possible to allow people who met certain quality standards to work some overtime during the summer and cap how much could be worked. People could have competed for overtime slots instead of feeling forced into it. It would have worked vastly better for everyone.
Of course, an elegant solution like that takes a bit more planning on the end of management. Simply demanding extra hours at a certain point is a simpler, brute force method. But, I felt it had a lot of downside to it and was mostly avoidable for the company in question.
It makes me wonder how many companies basically create drama of this sort. Because this crisis was entirely created by management, IMO. There was zero reason they had to wait until it hit a certain volume and then force overtime on us.
[+] [-] Spooky23|8 years ago|reply
Everywhere I've worked, the folks running the show have too much ego and political capital invested in products or projects that are turds. The result is massive financial losses for the business.
[+] [-] probablybroken|8 years ago|reply
[+] [-] alimoeeny|8 years ago|reply
[+] [-] zilchers|8 years ago|reply
[+] [-] pbourke|8 years ago|reply
* Short-term thinking ("we don't have time to fix the tech debt, we have to get something on the board this quarter")
* Over-resourcing projects from the start, rather than letting a small number of employees germinate it and set it on the right path
* Punishing people, often indirectly, for taking risks, conducting experiments, doing quick prototypes, etc
* Frequent shifts in direction, priority or emphasis. If "everything" is important at one time or another, then nothing truly is
[+] [-] pcunite|8 years ago|reply
2. Fear (you're getting a lot of attention and praise, this somehow makes me look bad)
3. Short sightedness (that's a good idea, we can't use it here, now go do something productive)
A good manager loves his team and opens doors, prevents road blocks, and facilitates approvals for them. He is a steward of their success. He removes fear of failure. He is not self absorbed but finds joy in the team. So, without these attributes, the negative effects are too sad to write about.
[+] [-] quadcore|8 years ago|reply
I got the luck to work with great managers at amazon. From what I've seen, programmers are driving the company there - or at least, they have their word to say, often, and power that comes with it. On my team, decisions relative to product development were clearly strongly driven by us. Seems to work pretty well for amazon.
[+] [-] forthelove|8 years ago|reply
[+] [-] k__|8 years ago|reply
I met many founders over the years and those with technical background were the best.
The non-technical founders had often bad ideas to start with or were piggy backing on the techies, while putting them down with their big words etc.
[+] [-] Arwill|8 years ago|reply