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.
I think of YAGNI as a very important principle, and encourage young developers to practice it rigorously, but as you grow in your arts you should eventually be able to reliably predict some elements of the future, and as you approach the middle of your career you should be able to start successfully heading such things off at the pass.
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.
This is something that I struggled with at first. I kept gravitating towards abstract solutions, and returning to that code was always annoying. Too many layers for so little payoff.
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.
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 promoted will be able to do their job properly once there. I think the point should be, that you would want to ensure that those you import will be able to help promote from within as things progress.
Except that the usual thing is to pay the new guy more and believe his story that the tech he used at the last gig, that he is now an expert in, is better than how you did it. Now management makes the new expert the boss. Next thing the old guy discovers the new guy was just in the right place at the right time in the last place and is useless, but, because he is the new boss you have to do everything again.
Fair point. That would definitely be a bad scenario as well, but would imho be a different issue from hiring someone from outside all together. A bad hire is a bad hire, and someone who comes in wanting to change everything to fit their way (especially if their way is wrong) is not a good thing. I still don't know if the original point is accurate as a common mistake, and perhaps the bigger issue would be that non-technical people make bad choices when trying to find technical leadership that are the wrong fit?
I agree, both reasons. The funny thing about this, in a dark funny way, is, management often offers a veto right to the team. They say "if you don't rate the new manager you can deny". Then, they hire anyway, in my experience, more often than not if they like the guy. I think the excuse is "You people doing the work (often with 'in the trenches') don't understand the big picture, this new guy does, so your veto is annulled".
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).
At review time, when you're asked what your goals are, mention the promotion. Ask what you need to do to get there. 90% of the time, the manager is more than happy to help you.
I've actually been approached by recruiters in a few companies who want me to come in and "upgrade" the whole tech stack. I ask them what's wrong with it? It turns out management was not happy with it being built in a homegrown framework by a junior, even though it was functioning fine.
Situation for the last point: I was asked to come in for a years old team. The team didn't know source control or agile. But because a large number of them were used to operating without these tools, it was extremely difficult to get them to adopt proper techniques, and we only got the juniors and testers to use Git.
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.
>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.
Related: Focusing on a single product when your customers rely on you for a suite. As I like to put it 'Being able to talk to the whole story'. Particularly relevant for MSPs - I once worked for one that went HARD on 'cloud first' to the point they stopped talking to clients about anything else.
Great, except all those clients lost interest real quick and switched to other providers who would talk to them 'about their whole story'.
The short sightedness of this is astounding - For many of those ex clients today, cloud is no longer 5 or 10% of their story, and we would have been able to continue selling to them all the way to their current adoption rates (50%+), IF we had taken them on the journey instead of refusing to talk to them about anything else.
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.
I think the folks discussing whether or not 10x developers exist are missing the more basic point here. In most companies, a manager's status is determined almost entirely by how many people he or she manages. It's absolutely in their best interest to hire more mediocre people than fewer exceptional people because the correct incentives haven't been put in place for managers in the company.
At many places, the best thing that can happen to a manager is for their team to become "too big". Oops, now they have to split it into two teams, and suddenly they're a Director instead of a Team Lead (or whatever titles are used).
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 sprints for ridiculous hours, and then stayed home or might as well have.
I'm sure there are incredible people out there who can 10x and also be great team members, and I'm sure management are idiots if they don't pay them 10x.
But in my experience, the people who claim to be 10x are usually just insufferable egotists who have no idea of the pain they cause for everyone else.
The 10x thing. Here's what I usually say about that:
A 2nd edition of Peopleware summarises it; the 10x programmer is not a myth, but it's comparing the best to the worst; NOT best to median. It's also not about programming specifically; it's simply a common distribution in many metrics of performance.
The rule of thumb Peopleware states is that you can rely on the best outperforming the worst by a factor of 10, and you can rely on the best outperforming the median by a factor of 2.5. This of course indicates that a median developer, middle of the pack, is a 4x developer. Obviously, this is a statistical rule, and if you've got a tiny sample size or some kind of singular outlier or other such; well, we're all adults and we understand how statistics and distributions work.
Peopleware uses Boehn (1981), Sackman (1968), Augustine (1979) and Lawrence (1981) as its sources. [ "Peopleware", DeMarco and Lister, 1987, p45 ]
There are plenty of 10x or more effects. Anything with a binary outcome can be considered as such. If you measure a person's productivity along those lines, you will get 10x or more output. Also, this characteristic isn't restricted to programming. Furthermore, it is probable that someone can be -10X.
Probable examples of 10x, Steve Wozniak for Apple, John Carmack back in the day, Dennis Ritchie, Tim Berners-Lee, Jeff Dean.
If you aren't getting 10X output, it's possible that the problem or situation you have placed the person limits them to less than 10X.
I do agree that there are far more people who claim to be 10X than that there actually are and that many come with costs.
Also it is simplistic to claim a person is 10x. A more accurate measure is seeing a 10x effect. Writing key software that saves a company or gets a company bought is a 10x effect. I've seen that happen several times.
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.
I've been 100x or 1000x in certain situations. Two examples: a solution required a recursive descent parser which no one recognized or knew how to implement, and another time a team fought a bug in some Java code for weeks, but none of them understood thread safety. So in these two instances, I've done things other simply couldn't. Not because I'm special in anyway, just because I had some experience these others lacked.
Otherwise, I am a thoroughly mediocre performer. I'm a minimum effort Loser[1] all the way.
I think the -1x programmer is even more common, the ones that have negative productivity and actually create more work for other programmers. I've encountered many of these types over the years.
They are usually the very hard working type too. The kind who when encountering a problem always solves it by piling on more code, never refactoring, never taking a step back and thinking about the problem. You don't want to be seen idling at your desk, better keep typing.
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.
> 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
In my experience, the '10x' programmer is not necessarily more productive (as in amount of work done in a certain timeframe), it's that the 10x programmer does better work, resulting in time savings down the line. Fewer bugs, a more flexible architecture, etc. It can be the difference between being able to easily add a new feature in version 2 and having to rewrite half the application.
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. They weren't involved in the design decisions, they didn't pair-program or brainstorm any of the code. It's pretty impenetrable. And the "10x" who wrote it is now unavailable after that "heroic" sprint so they can't even ask questions.
Teams work together. Heroic sprints of productivity followed by absence is not working together. It's leaving other people to clean up your mess while you claim the credit.
You know that famous inverse square root code? Apple basic?
Some things just cannot be pair programmed. They are simply impenetrable to average minds at the time.
Your argument sounds like one for a Handicapper General, to be honest. (If missing the reference Google it). You want to handicap everyone actually competent with a slower partner. And before you claim the usual: it is ok to write suboptimal but simple to understand code, consider that in some cases we actually DO care for performance and size of code..
99.9% of modern software does not require that level of cleverness. Also, the fast inverse square root code is a poor example as it's:
1) A very small amount of code
2) Isolated from everything else
3) Conceptually easy to understand what it's accomplishing (even if the implementation itself is interesting and non-obvious)
Most people would kill for a colleague who wrote code like that.
No, instead what you most often get out of people like the OP is mentioning (because I too have worked with and been burned by them) is some weird pseudo-ORM they wrote from scratch because they don't like how Hibernate handles joins.
Naturally, there's no documentation or even comments because it should be obvious why paxos was poorly implemented in this weird pseudo-ORM framework. And of course, the entire codebase was rewritten overnight to use this new framework as well.
Metaphorically speaking, some mountain routes require a very, very good climber to scale. If it is a team that you are trying to get to the top, that amazing lead climber still needs to throw a rope down to the rest of the team.
I do agree that sometimes managers want to fit "chefs" into a McDonald's like cooking process.
"team-oriented behavior"? So the talented individual gets to write all the code and explain it to other people at the same time?
This is a well known major impediment for creative persons in any field. You can explain things after they are done, not while you are doing them.
This is why average developers create such a drag on productivity. They always want meetings, explanations -- in short, anything that slows down the work horse and make them look productive in the process.
The parent post seems to assume that a "heroic sprint of productivity" would not include communication and documentation, i.e. that productivity only means coding. I don't see that assumption reflected in the grandparent post, and moreover if you don't consider communication productive in its own right, you're going to have much bigger problems than people taking a day off.
> In my experience, the 10x programmer is a bit of a myth
It's at least a unicorn, so companies shouldn't worry about hiring any 10x developers because they are THAT rare.
What they should do is avoid the developers that actually cost productivity. I'm a 10x developer compared to someone else not because I'm 10x average but because there is a 1/10th average dev there.
I'd say try to find the people who are just way over average (2x devs) and pay them twice the money if necessary. The problem is finding these people and making sure you aren't paying someone average twice the pay.
I rely on your experience for the non-existence of the 10x dev, but I've seen a x2 dev first hand, at young age. One of my interns did the same work in 3 months as the other in 6 months, plus various bonuses: Refactoring of old code into readable one, introduction of Kotlin, more unit tests, interesting discussions at lunch with other startups... Some people are amazingly smart.
yeah, I completely agree. There are people who are amazing at this out there. But they tend to be pretty humble about it, too, in my experience. And the best of them are really, really, good at bringing the rest of the team up with them.
"In my experience, the 10x programmer is a bit of a myth. "
I think it depends on Industry / Role. A creative person in Advertisment or a good chip design engineer or someone great with Algorithm are often worthy of 10 or 20X compensation. Whats wrong is that many people think 10X guys can exist on Application layer / Front end. I think its very hard to do that
Let me guess - you don't work on app layer or front end? :)
Of course it's hard to be 10x there. The same way it's hard to be 10x on the algorithm side. It's also a matter of scope - if you have a giant backend, and your frontend is a single text box, it's hard to tell if somebody is 10x. As the FE scope grows, you start seeing the differences.
Maybe I haven't met a true 10x programmer but met plenty who pretend that they are 10x. I would say those 10X programmers that I had "pleasure" of working with, are net negative to overall productivity.
In my experience, 10x programmers are hard to manage, they complain all the time, no one wants to work with them, their ego gets bruised easily.
But you keep them around because they seem really smart until you look at overall work produced. They might produce 10x work over a weekend but over longterm, they hardly produce any more work than average programmer.
In my interview process, if anyone even slightly hints that they are smarter than average, I end interview immediately. My team is composed of average programmers who get along and have fun working together.
My experience is that the long term effects are more than 10x.
I heard a joke once : Complicated problems requires complicated solutions. Unfortunately, all problems are a bit complicated if you are a bit thick.
The gist is that complexity grows faster than it needs.
Ignoring people that can't make things over a certain threshold, there is a large group of programmers that can make things work, but are not able to build things clean enough or put in the effort required to build testable and maintainable code, simplify support and reduce runtime costs.
Knowing when to stop and what to spend some extra time on is also important.
I'll hesitate to add reducing future development costs, because I've seen too much overly complex code written in a misguided attempt to handle unknown future requirements.
All these costs can easily build up to 10x over time.
A factor is that a team probably smoothes over the effects of one or two bad coders in a way that it's not noticeable at short term - the code is delivered and the worst bits are plastered over, but the long term performance is reduced.
Another thing often happening, is features coming down to developers, who by slight alteration can be trivial to implement. This usually happens due to missing domain knowledge of the management and sales (and a lack of insight regarding this lack).
The 10x effect is not on the immediate output of a particular development task. It's the lifetime value/cost of the choices made. In this respect there are many 10x developers, the ones who can factor complexity into a composition of conceptually and realized simple components. This works if they're presence is early in development, otherwise you may need a 20x to turn a 1x codebase into a 5x one.
It consistently astounds me how many companies would rather hire 2-3 average developers (for average or below-average salaries) rather than one great developer for 1.5x the price.
Here in New York, this is especially acute. Many finance companies have thousands and thousands of developers. They'll have a team of developers (costing maybe $500k/yr total) working on a problem which a single excellent developer could easily accomplish (and be happy with $250k/yr).
Tons of companies are penny-wise and pound-foolish, mostly because programming is still considered a low-status profession.
> 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.
There are companies which do this, but they're almost exclusively pure tech companies (ex. Netflix).
In many companies you get paid for status, not for productivity or value.
Management doesn't want super-performers, because they can upset the power dynamic.
Developers must have lower status than management, and super-performers can challenge that.
Companies are actually social networks. Instead of gaining status by posting selfies of yourself in exotic locations with cool people, you gain status by making high status noises in emails, talking in a high status way, having many people reporting to you, and having equity.
Sometimes getting things done is relevant too, but not as often as it should be.
Exactly, that's why I think this is one of the biggest examples of mismanagement out there.
For me, it's actually not about the compensation for its own sake. It's that compensation is a strong signal of how the company thinks about the status of developers.
This is also part of redundancy. If you hire 1 10x programmer and they get sick, no work gets done. If they leave, you will have hard time finding their replacement.
3 average programmers who understand your code adds a lot of redundancy.
And as an interviewer, it is really hard to identify who is 10x and who is not. But very easy to tell who has enough knowledge and pleasant personality. Programming in most companies is team sports, not a marathon.
Sure, you don't want to rely on a lone genius. But I'd argue it's much better to have a team of 10 excellent engineers than 30 mediocre ones.
There are tons of companies with thousands and thousands of engineers who could easily make do with 100-1000 engineers if they were willing to attract and retain top talent.
> And as an interviewer, it is really hard to identify who is 10x and who is not.
That's definitely true, but top companies manage to do it. And when they make a mistake, they rectify it.
Team sports still pay to attract top performers. The best players can be a force multiplier for everyone.
> That's definitely true, but top companies manage to do it. And when they make a mistake, they rectify it.
I know many programmers from FB, Google, Amazon, Apple. There is no way they are 10 or even 2x. Some of them I worked with too, so I know their work. Others are just friends, we discuss technology all the time.
> Team sports still pay to attract top performers. The best players can be a force multiplier for everyone.
You are right team sports do pay a lot of money for top talent. Unfortunately, my experience with 10x programmers, as a teammate and as a manager, has always been negative.
Most of them barely produce more than average programmer on long run but demotivate entire team or department by their arrogance, talking down, complaining, rudeness.
Seems like management is damned if they do and damned if they don't. If they reward high performers in proportion to the value they generate, they kill the culture of the company. If they reward everyone fairly & equally, then all the high performers quit.
Full employment theorem for entrepreneurs, I guess. If management is rational, they'll never put the whims of one high-performing employee over the culture of the company as a whole. If that employee is rational, he'll quit and take his work directly to the market. This creates a fresh stream of new startups, each of which either has to be bought back for their true market value, or else becomes the new hot company that hires the masses and hemorrhages its high performers.
I don't see how that 4th and 5th bulletpoint in any way contradicts OP. Popular != productive, although it can be hard to tell this apart in real life situations.
Will management be able to explain to the rest of the employees why this person gets 10x their compensation?
If not, it doesn't matter what the facts are from management's POV, it will lead to the same effect on trust & morale. Most people believe they are high performers and the work that they do for the company is valuable; if they didn't, they probably wouldn't do that work. If you have a workforce who believes they are all solid performers and then they have to confront the fact that management believes one of them is 10x better, you've got a recipe for a toxic culture.
One thing that I've learned over the years is that evaluating your own performance and the performance of others is in itself a skill that needs to be developed. Being able to reward high performers requires them to first be identified! In absence of the specific knowledge needed to assess perf, people fall back to likeability and other biases.
> Will management be able to explain to the rest of the employees why this person gets 10x their compensation?
That's a major part of why I consider open salaries to be a terrible idea for top performers. Performance and popularity are frequently uncorrelated, and I'm not talking about the asshole genius trope. You don't want to force your best performers into allocating lots of time schmoozing to ensure everyone loves them and isn't offended by their higher pay.
Almost nobody thinks they're below average in performance, but mathematically some people have to make less than average.
That's harder to prove, what I definitely see is roles staying unfilled open because the extra $10k a year to snag somebody faster is an obvious cost but six months of lost productivity isn't.
> I sometimes wonder what would happen if some company simply offered to pay 3X the market rate and mercilessly filter the results.
I've always heard this is the Netflix model.
> difference between developer salaries at any company varies by maybe 50%, whereas the productivity varies by at least a full order of magnitude.
I like your thought process but do you really believe this is possible? There are few fields where you can observe order of magnitude differences in salary. As you said, human nature seems to reject this, likely because it does not really occur in the wild. Even in sports it is rare for a particular position to have pay disparity to that degree.
What do you mean even in sports? What metric are you using to compare on athlete to another? Obviously one golfer won't be able to hit the ball 10x as far or sink the ball in 10x fewer strokes than another. Obviously a gold medal sprinter won't run 10x as fast as the an amateur. But they very well may be better than 10x as many others and that small difference in speed is what makes the difference between winning and losing. The claim the parent poster is making is different, because programming is much different than sports in that he really is claiming that one programmer can create 10x as much valuable work than another. Very different from saying that one programming contest competitor is 10x better than the average programming contest contestant.
> Obviously one golfer won't be able to hit the ball 10x as far or sink the ball in 10x fewer strokes than another. Obviously a gold medal sprinter won't run 10x as fast as the an amateur.
What's obvious about that? I can pretty well guarantee the existence of golfers who need 10x the strokes of professional golfers. I can definitely guarantee the existence of people who can't manage 10% of the running speed of a gold medal sprinter.
Usain Bolt's average speed was about 23 miles per hour[0] when he set the world record (9.58 sec/100m). Nearly everyone can "run" 2.3 mph for a quarter-lap; that's not even a brisk walking pace.
The 10x programmer idea also applies to adults working as programmers. If you were to limit the runners to an analogous population (runners, I guess, or even healthy adults), I'd definitely take that bet.
[0] His peak speed was a bit faster (~27 mph), but the point stands...
>> I sometimes wonder what would happen if some company simply offered to pay 3X the market rate and mercilessly filter the results.
> I've always heard this is the Netflix model.
Also, Valve. By some accounts, this creates terrible working environment, where people are competing instead of cooperating. Not to mention it distorts the incentives, as devs are heavily incentivised to project an image of being impactful high-achiever (as oposed to actually just being one, and not having to manage one's image). Of course, it also happens in regular companies, but here higher stakes make the game more vicious.
>> 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.
In many organizations, quadrupling the number of people that report to you is worth doubling the delivery time, hands down. Number of reports is an easy measure of influence.
Maybe but that makes sense when this "smart person" leaves then no-one knows how to keep their stuff going and the system is likely to crash and burn taking the manager with it. If you have a 4 person team you can handle people coming in and out over time, using best ideas from the team.
We already do that all over. It's called consulting.
The outcome isn't higher quality or better work, just capture of perceived value. The super productive developer has a risk/reward ratio. When you get a little older, stability has a value of its own.
This is a fair objection, and probably a rational basis for at least some pay overegalitarianism. If management can't figure out who the star performers are, there's not much point in differentiating the reward.
On the other hand, this seems like a fundamental management failure. The identity of the star performers has not been a mystery to the actual engineers working on every team I've ever been a part of. The information is not unknowable. Also, we already have a pay grade of "10 bucks": Some people get fired.
"Management" will never realize this because to some extent the reasoning is driven by ego. It feels better to be in charge of 20 mediocre producers than 5 amazing ones. Of course there will be exceptions but the general rule follows.
I ran into this problem.. I felt like I was worth more than the best offers I was getting. I continued to get job offers, but I couldn't get one for more than 100k remotely or in my area(Burlington, VT).
I've got many many years experience, can solve any challenge, and work at twice the rate of most of the developers I have worked w/ in the tech stacks I focus on(ruby, elixir, reactjs/javascript/ember/angular etc)..
So I decided to go at it on my own and charge a rate I felt I was worth. Best career decision I've made so far. I think every developer reaches a point where the only way they can make more is to move into management and stop being a developer, or branch out on their own. I myself hate being a manager and love being a developer.
Managers generally seem to think that a developer is a developer is a developer. When there is a clear difference between a $50/hr developer and someone who can charge $250/hr in the time it takes to solve the same problem. What takes a $250/hr dev 1hr to solve correctly, might take a jr dev 5hrs to just "get it working."
>So I decided to go at it on my own and charge a rate I felt I was worth. Best career decision I've made so far.
I think this, above all else, is the key to the frustration and ever decreasing salaries we're seeing. The market has spoken: employees just aren't worth that much. If you want to capture more of the value you create you'll need to go into business for yourself. It's risky, but sitting a desk in a huge office watching rates go down and down will probably turn out to be more risky in the end if you can't retire before it gets too bad.
Having said all that, would you mind expanding on exactly what you did?
I started by talking to my friends and networking with people who needed developers, using online sites to find people hiring or seeking developers I could pitch on my services(this works amazingly well), and doing content marketing to get some SEO and exposure for myself and services. I started with a rate that was a little more than my salary when I left to cover things like savings, retirements, insurance, taxes etc that my job paid and raised my rates any time I had to much work to do. See my other response in the thread for more details.
I started w/ word of mouth and networking through people I already knew. I also started with a lower rate. I raised my rates anytime I had to much work to do. I discovered this technique from another friend.
I was complaining one day about having WAY to many clients. He said and I'll never forget it, "if you have to much work to do, you're not charging enough."
I started 2.5 years ago at $70/hr and am now at $135/hr after several rounds of raising rates. Sometimes I would lose a client when raising my rates, but that was ok and really was the goal. They were usually the most painful to deal w/ anyway. My best clients usually never even balked at it. Just said ok and kept on paying.
I then got to the point where I needed to give myself a brand and bring on another developer because I started taking on very large green field projects(this was something my lawyer and accountants suggested for insurance/legal/protection reasons).
At that point I got more advanced and started doing some content marketing, facebook ads, and google ads to keep the pipeline running. The hardest part was keeping clients lined up in the beginning. Because I would get a client, work the client and during that time stop looking for new clients. Which lead to a lot of down cycles with no work to be done while I looked for the next client. This is still an ongoing thing we're working on at this time to improve our client acquisition techniques.
My partner and I now do about 20-30hrs a week for clients pretty steady and spend the rest of the time working on projects we own fully that we hope can generate recurring revenue. It has been a really fantastic journey that I hope never ends.
Every day get really inspired by the stories on indiehackers.com and just find this way of work extremely fascinating. Very rewarding both personally and financially so far and I don't think I'll ever stop doing what I'm doing if I have anything to say about it.
There is an inherent safety in having four average employee write something rather than using your unicorn. It's safe because three of them will still be around to manage it when one of them gets a new job, cancer or retires.
On top of that, your unicorns are only really worth their wages if they are solving problems no one else can or if they are mentoring others.
Or, the group of four writes something an order of magnitude more complex. It becomes difficult to make changes, estimates grow, and execution is consistently buggy.
With the right unicorn, one can act swiftly, groom a lean architecture, and make instinctive calls that move the needle of the entire roadmap. Real unicorns present sound technical strategies and inspire new opportunities that help push the company to the next level.
> I sometimes wonder what would happen if some company simply offered to pay 3X the market rate and mercilessly filter the results.
As a developer, what I want is kind of the opposite. I don't want to be paid more than others if I'm more productive, I want to work fewer hours. Pay me for the value of my work, not how long it took to do it.
Personally, as a product design manager, I like to find the middle ground. Having a set of "4x" employees is useful when you also have a number of "1x"and "2x" employees that can learn and grow from the influence of the highest skill and/or productive employees.
Attempting to build a "quantity over quality" organization is bad for the reasons you list, but "all quality, no quantity" is a close second in being detrimental.
Each critical "4x" employee that you have is only beneficial if they stay at your company. Burning them out because a company is ruthlessly focused on keeping their staffing lean by only hiring "4x unicorn-ninja-guru-rockstar" developers is a quick way to trigger management to swing the pendulum too far in the opposite direction.
You're still not guaranteed that by spending $400 per hour on one person with excellent credentials you will have a better outcome than with 4 x $100. There is also a balance of risk especially on longer term projects, with the 1 x $400 person there will probably be less technical oversight and also if they get ill or leave then the project is is serious trouble.
I'm not advocating employing talentless monkeys, they still need to be good at what they do but from a business perspective it's a more complex and wider ranging decision.
If you spend a lot of money you're not guaranteed to get the best. But if you go cheap you are nearly guaranteed to get a bad developer/product/whatever.
Btw. your example is missing the bus factor. But I understand your point and actually I do not think that salaries are meant to depend 100% on performance.
I think it is more like 90% of time the person invests and 10% performance bonus. That way the one with to 50% higher salary would probably be 5 times as performant as the average dev. If that is fair, is a different (and very difficult) question.
This is simple risk management. The risks are too big that you're paying someone $400/hr without the expected benefits. There's just a too wide margin of error. Pay four people, things even out if and the whole thing just becomes more predictable (and thus easier to manage). Managers are often eager to pay the cost of predictability.
How do you propose filtering the candidates? The only way to know for sure how they perform is to actually hire them and see how they perform after some amount of time. Since you will be firing a majority of people this causes a culture of fear. Interviews are far too unreliable for filtering candidates like you are proposing.
Exactly. If you hire 4 it is likely that 1 will be very good and 2 average and 1 bad. If you hire 1 you probably hired the one who knows how sell himself/herself.
Netflix is known for a policy of paying well for talent and being generous when dropping people who don't work out, for whatever reason. Their culture document is a great read.
I agree with hiring the four people over the one star. If that one person leaves or is on vacation you have a hole in your team.
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.
These 4x (or 10x or whatever outlandish multiple) developers are rare, if they even exist, unless one constrains the scope of their work to a tiny sliver of their particular expertise.
Hiring for such micro optimization is inefficient at best, ineffective usually, and counterproductive at worst.
This is often an information problem. To find an expert or specialist takes a lot of time. While it would be nice to always have an expert solution, sometimes we don't have the luxury of time.
whereas the productivity varies by at least a full order of magnitude
I think we need to put the myth of the 10x developer to bed. 99% of the time, the 10x guy is just someone who solved the same or similar problem at his or her last job and are simply exercising their experience. Sure there are outliers, but that's the same in every field - whereas in programming 50% of people believe that they're the 10x guy and that all their cow-orkers are slothful idiots.
I'd suggest virtually the opposite: a good way to be an outlier is to have reasonably broad knowledge plus being good at learning new stuff, such that when faced with a new problem you can quickly bring the right set of skills/technologies/whatever at it.
If you want to talk about it from a financial perspective, talk about the rate of return.
Can one developer do ten times the work any other developer does during a week? Probably not.
Can one developer have a rate of return such that they get ten times more valuable work done? Almost certainly.
So developer A delivers 3% improvement per year and developer B delivers 6% improvement per year. Across a career, if you start with 100 units, developer A delivers 245 units at the end, and developer B delivers 2008 units.
I have met and worked with a few people that fall under the 10x banner. Incredibly clever people who kept their intelligence in check with pragmatic solutions.
Some tough problems that took other skilled developers months they could solve in a couple of days and they could consistently do it across the tech and domain sphere.
I think the issue is people claim to be 10x, if you're claiming to be 10x then most likely you are not, the 10xers I've met have all been very humble.
the reason they'll rather hide 4x people that are half as slow, is that they have bums in seats that are available for whatever hairbrained idea they come up with. the x10 (sic) coder will get bored of the mundane stuff surrounding the complex stuff s/he loves
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.
My metric for projects is that if I'm not returning near-term value at least double my billing rate, it's probably not worth doing.
If you are, the difference between 2.2x, double, and 1.8x is pretty negligible - non zero, for sure, but not worth the additional 20% effort to minimize variance.
If you aren't, as he says, no amount of diligence will fix it, because it's simply the wrong project.
It's the classic penny-wise pound-foolish.
So by my conclusion, many of the 'project management' activities that people do are at best wasteful or indeed actively harmful.
I agree with your general point. It's difficult/impossible to get accurate numbers. I would contend that we have a general idea. Management nearly always imposes more control when it's nervous the costs are approaching the rewards. The flip side is Silicon Valley VC investing. Tonnes of money is thrown and very little control is exercised by investors, at least at first, because the rewards devour almost all costs. The programming equivalent might be Big-O notation. We don't know _precisely_ the costs of an algorithm, but we can do general comparisons.
DeMarco also seems to agree.
The book’s most quoted line is its first sentence:
"You can’t control what you can’t measure." This line
contains a real truth, but I’ve become increasingly
uncomfortable with my use of it. Implicit in the quote
(and indeed in the book’s title) is that control is an
important aspect, maybe the most important, of any
software project. But it isn’t. Many projects have
proceeded without much control but managed to produce
wonderful products such as GoogleEarth or Wikipedia.
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.
Once a sales junior came to me and said "this year I will make our product be the center of the Big Data hype" like it was some meaningful concept, besides having much data...
Misguided cost savings is the worst when it comes from engineers. Software developers love to optimize, so if they can save $500 - $1,000 a month buy rolling their own service instead of paying for an existing one, they'll do it, completely ignoring the fact that their time costs money.
Eh, most developers I know are lazy and won't even measure the performance of the thing they're building if it's "good enough". I can't remember the last time any of us fired up a profiler. Optimization is generally hard and un-fun.
On the other hand, developers love to build shiny new stuff more than they like using things that are already there. The "Optimize" part you're talking about is more "reinvent the wheel" in my experience.
Figuring out how to use X new library isn't fun. Building this cool thing that does the same thing but better is a lot of fun! That's why things get overengineered and built for "scale", which is probably mostly what you'r referring to. Instead of taking something off the shelf that would work fine some developers are compelled to build something that can handle the entire traffic of the internet. They don't achieve this by optimizing what's there, they do it by building an enormously complex system for no reason :)
> They don't achieve this by optimizing what's there, they do it by building an enormously complex system for no reason :)
This aspect of the industry drives me absolutely insane. I've seen this at every single company I've worked at. I feel like I'm taking crazy pills. Am I the only developer that sees tech as merely a tool? I don't want to build a massively complex system that scales to infinity and does everything for everyone. I don't want to build everything from scratch. I want to build dead simple, boring software that accomplishes a goal and is easy to maintain, so that I can go home and not worry about it.
> Reorganizing seemingly for the sake of reorganizing
This definitely happens every time a manager or executive is replaced or hired. And it's easy to see why it happens despite the damage it causes. Executive turnover might not be the cause in your case, but if it is, the good news is you can see it coming.
Speaking of seeing it coming, since my employer became part of $MultiNationalEngineeringCo, one of the most popular acronyms around the watering hole has been BOHICA. (Bend Over, Here It Comes Again for those lucky enough to work for a smaller company...)
-Definitely a person; however, the gender balance in my immediate surroundings is -ahem- slightly skewed and I all too easily fall into the trap of calling any person a man.
(Judging from the time clock (whose logs are openly available on the intranet, presumably through oversight rather than by design), there are currently 217 people working in the hall I currently sit in. Of those, one appear to be female.)
* 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 :-)
> 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 outside work. We are human and human relations are variable, not absolute.
In my experience only (all disclaimers apply) I have never seen an employee whose productivity outweighed the damage they did to the rest of the team if their misbehavior was tolerated by management. I understand how scary it can be to have to let someone like that go, but the dozen or so cases that I had good visibility into over my career the ones where the employee was accommodated all had worse outcomes than those where the employee was let go.
Way late on this, but this thread has been referenced in things like Oren Ellenbogen's Software Lead Weekly, so maybe the reference will help someone...
Bob Sutton's "The No Asshole Rule" calls this TCA - total cost of assholes. TCA incorporates the cost to replace people who leave because of the asshole, time spent by manager calming people down and cleanup, customer relastionship issues, etc.
Before leaping to firing that person, you'd want to talk to them and explain that the misbehaviour has to stop. There may be personal reasons, and the person may need support to change. But if the behaviour doesn't shift then yes, dismissal is absolutely appropriate. The demoralisation stemming from a misbehaver who is protected from on high can be huge.
Great performance does not require being an asshat. It's (nearly?) always possible to find an equivalent performer who's pleasant to be around and a constructive team member.
> What if said employee pulls in 10x, 100x more revenue/value than average worker for the company?
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.
Unless you're giving everyone that benefit of the doubt, then you're just reinforcing the idea that the rules don't apply to everyone. But even then, there's only so much that a personal/family problem can excuse.
One of the biggest constraints in a business is employee focus. Theoretically, you want to maximize future free cash flow. Unfortunately, there are many inputs: rev growth, solid roi on capex, lowering non-essential costs, employee retention, unit costs, brand etc.
Management teams have to distill the message about what they want in a way that many employees can get behind. Nestle was too focused on unit costs, and should have likely added one more constraint like rev growth, but if they added too many, employees as a group would lose focus.
Most businesses have 2-3 essential business drivers. 1 is never enough, 4+ is likely too many to focus on.
That looks on the face of it nice and worthy but it's rather be meaningless because those are not actual goals. Those words are way too loose for that. The other thing about it is it smells like a marketing phrase rather than anything truthful
You can use this list in any way. For example when you want to increase your product price. This is fine when it is good for the customer (because they will get a better product). But it is not fine when you do it for the shareholders alone.
They are also goals because the ultimate goal is to please the customer, then the employee and than the shareholder.
Does that also mean it is always a great idea to decrease your product price?
In the consulting company where I work at employees come before customers. Employees are the single most important asset and much harder to replace than customers.
Google uses a hierarchical system for quarterly and annual goals called OKRs (Objectives and Key Results) that tries to align goals for the company, orgs, teams, and individuals.
Interesting. How did you like it? Does every person at Intel have their own quarterly OKR list, or do they stop propagating down at some level? Were they always on time? How did lower levels give input with regard to what they thought were important goals? Or did really everything come top-down?
If you're selling non-commodity goods your brand is an important reason why consumers purchase from you. If they realize product quality is going down they'll churn. You might have a short run of good profits, but eventually consumers will start purchasing something better, thus hurting your your total numbers.
In this example, it states that because of this enployees were rewarded for reducing the unit cost of the product, which meant cutting in to quality. This led to sales declining because custoners were less interested in ab inferior product.
If management had looked less at the "how much profit can we squeeze out of 1 gallon" angle, and more "how much profit can we make overall", they might have made different decisions, such as preserving the quality of the product, they may have done better overall.
Unit profit is one factor in overall profit / revenue, but # of units solds is equally as important...it's a balancing act.
Yes, as you can tell by the fact that your overall profit in the first scenario is $10M while in the second it is $2M. How is that an argument against overall profit?
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 :)
In our current job-hopping world, where you are lucky to even get 4 years from an employee, you can take someone from good to great, acceptable to good, or bad to acceptable in the time you work with them. Your investment should almost always be on the first two, especially because the last one is a much bigger investment of time and energy. Keep in mind many times what you're fighting is not just lack of experience or some other easily fixable thing, you're fighting personality traits the person has had for years, and will continue to have (to a lesser degree) even if you _do_ "fix" things.
It is one of my signals of inexperienced management that they believe they can/should take on this sort of challenge.
Yeah, ~10 years as a manager (and 30 in the industry) is not a lot of experience. But it's enough to know that "focus on the stars" mostly aims at making the managers life easier - anybody can manage a team of great performers.
Of course it's a judgment call. Some things, you cannot fix. But some things, you can, and the cost of doing so is much less than rehiring. Good management means making those judgment calls, not just saying "meh, I don't care about low performers, too much work".
Maybe, just maybe, that's a tiny part of the reason people on my team seem to stay longer than 4 years. Because we don't just treat them as disposable cogs.
I'd be happy to discuss over a beer. I don't believe there are any hard and fast rules in life, and I've tried to help people more than once in my career (currently I do it in a non-management capacity which is arguably harder). But I think we can agree some situations aren't going to be saved. Good management is knowing how hard to try and when to stop.
Always happy to discuss things over a beer. (Well, I'll have white wine, if you don't mind ;)
And yes, not every situation is salvageable. Alas. Knowing when to stop is why I'm in favor of having a defined process well before you come to the "change, or else" part. That prevents the sad effect that your bar shifts as you collect reports, just because you've got more things to do.
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?
Maybe data modeling is something that's officially a "manager-level task" at your company, so it's something you have to be involved in. But I would try to err on the side of delegating too much, rather than too little. If you have knowledge in a certain area that gives you special insight into how to improve implementation of code, I would challenge you to try to disseminate that amongst your team and hold them accountable for following it themselves, rather than setting yourself up as a gatekeeper.
All this assumes you trust your team to be thoughtful and do good work. If not then that's a whole 'nother issue.
> How would you like your manager to handle being involved in data modeling?
When it comes to business-domain concepts, like "what is a project" or "what subtypes of customers do we have", that's stuff where I feel a manager should be helping to involve more people.
I'm speaking from the perspective of working on a business' proprietary ERP system, and it feels like nobody really knows how the business "ought" to work, they just follow the traditions enshrined in the code and then ask for their itches to be scratched.
I think that is true in a lot of cases, especially in business process engineering. It's a blessing when you work with a really good business process engineer!
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.
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.
Yes, this. Convincing managers to focus on the minimal viable implementation that users can start productively using sooner rather than later and building from there is a real art of senior developers in my experience.
A variation on this theme: years ago I had a manager who was a pretty solid developer who had written a lot of the mission critical code we were supporting. He moved up a couple rungs, got an MBA, brought in scrum (to replace a sclerotic waterfall process), and served as product owner on a lot of our products.
So he was involved in planning meetings and did a pretty good job of steering things there in his product owner role. But once planning was complete and development started, he couldn't resist getting in the ear of individual devs and project managers on the team to alter specs or dictate how he thought things should be implemented. This was after we had met, agreed on a design or strategy (with him present), and started (or even sometimes completed) implementation. It got to the point that we would joke about the stated requirements of a project and the on-the-way-to-the-bathroom requirements.
It really gnawed at both developers and the project managers who worked under him and were responsible for the day-to-day management of the projects. He developed a reputation among the team for being arrogant, aloof, and disrespectful even though that wasn't really his character at all and he was actually a pretty friendly easy-going guy who tried to do things right.
- 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
Jira has a lot of bad use cases around it, but I don't think it's a bad tool. I rather be looking at the board to get status updates than interrupting someone to see where things are at, and basically resorting to micromanagement. It should however not be used as a replacement to talking to the team or reading the code - but it should be one of the tools in the shed.
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.)
Yes, this. I'd add that you end up losing a probably (as he/she's been promoted) skilled engineer as well. Promotion via management is what forces people who might not have the "people-skills" to accept management jobs because they want to be valued.
This reminds me of an article from Rands in Repose:
As I wrote about in Being Geek, the Curse of the Silicon Valley is that great engineers are often promoted to leadership for their hard work. While many succeed in this role, an equal part fails because the skills required to lead are vastly different than the ones required to be an engineer. The Curse is that we’re often placing our most valuable engineers in a role where they’re predisposed to fail.
Think of it like this: there’s a large population of immensely talented engineers that should not be leaders. There is no amount of training that would make up for the talent we’d extinguish by teaching them how to write annual reviews.
But everyone wants to grow.
Unfortunately, in many companies the only perceived growth path is via management.
I read lots of books about management, I tried to emulate what managers who I thought were competent were doing, and I made lots of mistakes and tried to learn from them.
There were some mistakes that I was never able to recover from, like being too friendly with the people who reported to me - that makes you really dread the prospect of having to lay someone off, makes it hard to give difficult feedback, etc.
Eventually, after being a manager for several years, I decided to go back to being a developer, and now I'm much happier.
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.
Best case, good people leave and the company spends more than it needed to on onboarding new people.
Worst case, good people leave and your team never fully recovers, the product is technical garbage and you end up spending on a rebuild, or the product fails. Considering the product is the foundation of the project, ignoring warnings from the people building it would be like ignoring someone yelling "Fire" inside a wood mill. They know the product, wood, doesn't come out very well given the current circumstance, fire. We should probably listen.
Ultimately, more money and happier people could have been had if things were done pragmatically but correctly. There is of course such a thing as an overengineered product, so there is certainly a balance between pragmatism, speed and quality. But the mindset being brought up here is that you can forsake quality and happiness for more profit without consequence, and I suspect that's not truly the case.
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.
The corollary to that is that many technical types will make things work despite management ignoring the fundamentals. Sometimes its better to let something fail sooner than to make it work, when it's clear the fundamentals will eventually overtake the effort.
Ya, great point, though at big companies it can be very hard to just let things fail. Though that reminds me of another answer to the parent question which is managers who reward people who fix broken stuff, but don't reward people who didn't build fragile things to begin with.
Makes you think. Maybe you need a "villain" in your team that brings the crisis NOW, when only seeing it approaching on the horizon. Making future problems real
> Punishing people, often indirectly, for taking risks, conducting experiments, doing quick prototypes, etc
You hit the nail on the head with this one. People seem to forget that so many important parts of our daily life were once upon a time passion projects and 20% time projects (Gmail, Adsense etc)
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.
just because "nerds" are experts in everything tech does NOT equate to good decision making / good management for the company as a whole.
You think a programmer's job and abilities stops where they don't. Programmers do understand what the customer want. They ship to customers. I'm not saying programmers don't need help though.
False. I was directly reacting to what the OP said (below), which said nothing of a relationship w/ customers. Personally, I'm a proponent of having devs closely involved in every step of the product, including messaging and marketing. But that's not what this post was about.
> We are the technology, we did it in the first place.
> By default, we know better than them (because we are the one who do the tech)
I agree with the argument but not the evidence - I have seen a lot of good tech managed directly into the ground by management teams that have clear track records of non-success. Bad products being sold and kept alive through clever / kleptocratic / crony business practices is what the market for enterprise anything has become because all the purchasers and sellers are one and the same - people that are never the users of said products or even the services and that can skillfully resolve themselves of blame while taking credit for "success" and somehow justifying it all as "positive thinking."
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.
This was back when I was a junior dev, but I had to demo how an unprivileged user could delete every user in our system before I could work fix that section of code without getting fussed at for trying to discuss something unimportant. Even then the immediate response was, well we have a nightly backup so we're fine.
1) Trying to solve lack of skill with More Rules For Everyone.
One of your teams write messy code? Don't try to educate them. Instead enforce strict coding standards that forbid all but the most basic complexity. Everyone else now have to make their code more verbose and objectively worse, while the problem team still writes bad code but now they make even more of it in a neater formatting.
2) Raise wages only for people who threaten to leave.
3) Run a high tech software development shop but have an IT department that assumes everyone only ever need Excel and Outlook.
Ports are blocked. Local computer admin is locked. Updates are forced, delayed and centralized. Hardware is underpowered. Network blocks ping.
4) Demand to be in full control.
Make sure nobody does anything you don't understand. Shoot down experiments you can't see the point of, even if they're small. Hire skilled and experienced people, but demand that you can understand everything they do.
5) Let random people deal with hiring and interviews.
Hiring is both a hard and sensitive process. On one hand you are giving people an impression of your workplace, and on the other hand you are trying to evaluate the skill of someone who has a different skill set than yourself.
Giving this job to some burnt out elitist asshole who throws resumes in the garbage because they did or didn't include a cover letter, or a wannabe drill sergeant who tries to be "tough" and "test them under pressure" during interviews, gives you a bad rep in tech circles and doesn't help you hire skilled people. Giving it to someone who can't be bothered to reply to applicants or update them on rejections is also shitty.
There is one cardinal mistake that management makes (and development blithely accepts):
* Management is always right.
This truism is built into the entire fabric of software development: whether your process is an agile one where the product manager has ultimate knowledge of what is needed and on what timescales; the project that is delayed not because of bad planning or poor company organisation but because the developers are not working hard enough; that the only variable that affects the business is how productive / expensive the developers are - all the factors that describe how effective the management is are completely ignored or irrelevant. The list goes on and on and described in better detail in all the comments here.
Of course the solution to all of this is better data. You can be sure that the volume of data is inversely proportional to the strength of belief of the above statement. This leads to the second fundamental mistake that management makes:
* Not reading High Output Management by Andy Grove.
Task mastering. Ie a Focus on pumping through the JIRA tickets or equivalent as fast as possible. Meaning no time for respite or learning. Meaning lots of shitty metrics and pressure / humiliation if you don't meet them. I get a weekly report of tasks that took more than 25% over estimate within the team and names, for example. It doesn't help that anyone else can log time against my JIRA either. A three person meeting could burn up all the time.
At my company we had a good manager. Whenever we saw a problem in the systems, even a minor, low priority one, we opened a JIRA ticket for it. After all, JIRA was there for the convenience of the workers in the IT department.
Then a new manager came in. When he discovered we had JIRA, he told us he was going to use JIRA to evaluate us on how fast we fixed tickets and how many tickets we fixed.
We in the IT department maintained JIRA. That night I completely purged virtually all tickets of tasks that could not be done quickly. I put those tasks in a directory on my laptop only visible to me. From that time on, we only opened tickets for simple tasks we could do quickly. As volume counted as well, we would open multiple tickets for a multi-step task, whereas before we would have opened only one.
Eventually there were some office politics between divisions at the company and I and others were laid off (which I knew was coming, but decided to stay for the severance). When I left, the files containing all the the system flaws I had noted were erased.
Honestly, poor management aside....I cannot believe you are bragging about this. Rather than confront and address the problem, your solution was to actually delete shared knowledge?
Confront and address? You ain't gonna get your boss fired without a scratch. He's just bragging that he achieved a local maxima, and I think he's correct.
Maybe during the exit interview he could have said, "oh by the way, there's a file on my computer..."
But then he might suddenly find the severance offer is retracted.
> Someone who finds the forks, crashes, etc. a personal offense, and will repeatedly risk annoying management by fighting to stop these things. Especially someone who spends their own political capital, hard earned doing things management truly values, on doing work they don't truly value – such a person can keep fighting for a long time. Some people manage to make a career out of it by persisting until management truly changes their mind and rewards them. Whatever the odds of that, the average person cannot comprehend the motivation of someone attempting such a feat.
In answer to your question: yes, I do. Just like the rest of your link states, it pays off.
I got burned on this once. I was the most senior engineer on a team and spent a lot of time coaching and reviewing the work of college hires, which meant I didn't output as many raw task points as everyone else. I was called out on it so I stopped helping as much. My task completion shot up, but team productivity and quality went down. Overall a negative.
Giving junior devs all the greenfield applications as "learning experiences". Because groundwork should always be laid by those with the least experience.
Haphazard task assignment - I build a feature, then when they need an enhancement, it often gets given to someone else with no understanding of how it works, even though I am free.
Cargo culting in general. We do "Kanban" just to say we do, despite it having zero relevance to how we actually work. It's buzzwordy. Insistence on daily standup despite having very good communication and everyone knowing what everyone else is doing, were a small team in an open office.
Pushing for faster code review and generally treating it as a negative thing that just slows us down.
Previously we actually hired more devs to "help" get a project out the door - I think we all know what the mythical man month has to say about that.
Having to argue about basic security practices. I got in a heated argument about how we needed to encrypt temporary passwords even though they were system generated. I'm still angry. They wanted to be able to look them up for users. Sigh.
- Bouncing a developer from task to task without ever finishing a task
- Letting whatever customer screams the loudest dictate product behavior, and then effectively alternating product behavior based on which customer is angry this month
- Deferring technical debt until a customer screams
- Hiring unreasonable product managers who have unreasonable expectations. (This just leads to a lot of time being burnt in haggling and a much worse product delivered.)
- Treating software as an art project, getting obsessed with pixels and fonts instead of functionality
- Not paying enough
(edits)
- Interrupting programmers constantly for trivial matters
- Allowing the entire organization to interrupt a developer at any time because he's unofficially become a "go-to" person
- Not backing up critical processes when departments interact. (This is the information needed when there is a bug, support escalation, ect.)
- Expecting developers to handhold people in other departments
(more edits)
- Micromanaging task priority, assuming that a developer jumped on a specific task and completed it instantly
Reinventing the wheel when new management come in, i.e. don't check their ego at the door. The new management think they have to make their mark/impact/whatever in the products/processes by throwing out the old's. I've seen new VP/CTO came in, canceled a release pending product, and promised to rebuild the product quickly with his oversight. As with any rewrite, the project dragged on and on. The product ended up delayed for a year and half. The company bellied up shortly after.
There is people/resource management and there is also technical management, and most companies really struggle with the latter.
What I mean by technical management is the following:
* onboarding new developers: showing them how to get the dev environment going, how to debug, how to use testing infrastructure, configuration management
* propagating information about design rules: documenting and evangelization of contracts between different different pieces of code, and all the various rules -- what must be authenticated, what must be logged, how to consistently check for access rights, which common module/library to use for what, etc.
* enforcing software development lifecycle: making sure there are design reviews/sign off/etc
It seems that managers offload a lot of the above to senior roles who rely on force of personality and personal effort to get this done, which creates a lot of randomness and also stress. Devs often don't learn these things except by creating breakage and then relying on experience or institutional knowledge.
It's very strange that on the one hand when it comes to corporate policies such as vacation time and provisioning
productivity software, or even using the bug tracking system, there are handbooks, mandatory trainings, lots of online resources, etc. But when it comes to the technical rules such as which library to use, we pass to a medieval guild system of ad hoc 1 on 1 mentoring over Slack.
But perhaps I've just been working in the wrong companies.
Assuming that because someone shipped software that looks good , that they're good.
Everywhere I worked, there's always one "super star" who keeps getting promoted for shipping something quick that looks good on the surface, but did so either by introducing massive amounts of tech debt (beyond what would be acceptable for an MVP), or by shitting on everyone else (working in a corner, ignoring any request for help, ignoring their direct reports, or generally at the cost of all of their other duties).
Makes everyone else look bad and them look good, and generally creates a pretty toxic atmosphere until management gets it (at which point its usually too late).
From the trenches in large corporate (aka 'enterprise') tech departments:
* Technology decisions in large organizations will often not be made based on technical evaluations or merit. Some other arbitrary thing will influence a decision. You will get stuck with technically inferior product and have to deal, some call this job security.
* If you propose something and it gets floated up the management chain, chances are good that management will not "buy in". Not until they hire consultants to come in at $300-500/hr to spend 6 months or more and come back with the same decision. Possibly using a technology the consultants are pimping out, see point above.
* Buying COTS (customizable off the shelf software) with a 20% yearly maintenance/support fee to do basic IT functions is viewed as being cheaper than hiring software developers to build and maintain it. Even when there are open source solutions.
* Maintaining a list of "approved" vendors. This really narrows your possible solution set. When the vendors know this they will keep increasing fees.
* Offshoring work to save money. Many times this is not really done to save a department money. They will use accounting loop holes to track the offshore work as a 'service' and not labor. It will cost your department more in terms of delivery time but they don't care.
* Decision making by committee. Your job is to make decisions and the dysfunction is so bad that people will not work together. Not in a dramatic way, just passive aggressive, ignorance, etc. Every decision takes forever because they have to confer with multiple peers, go through management hierarchy for some, etc.
- Not knowing what is important and what is not (micromanaging at the expense of team happiness and autonomy).
- Negativity.
- Not changing their minds often enough.
- Generalising past negative experiences and applying them to new situations without properly acknowledging key differences.
- Not recognising the strengths and weaknesses of individual employees - They prefer to just throw more engineers at the problem as though they were rocket fuel.
- Not letting engineers feel a sense of ownership over a part of the product that they're building out of fear that they might leave.
- Not giving raises until it's too late; seriously undervaluing the long-term acquired knowledge of their engineers.
Not knowing the difference between "high performer" and social biases. Eg. Is your top person your top person because they are really doing good work on their merits, or do you just like them personally and therefore give them important projects, attention, recognition? Are your lesser favorites the ones doing real work? If they had equal opportunity, would they outperform the "top" people? Maybe they are outperforming them already?
There are several mistakes that I keep seeing over and over again.
Short term-ism. It seems to stem from the need to report financially on an annual basis, which means everything gets tied to that - bonuses, sales discounts, hiring, project deadlines. The reality is that many extremely worthwhile things take longer to do than whatever time is left in this financial period and are harmed by trying to shortcut, sometimes irreparably. Tying everything to an arbitrary accounting period often encourages behaviour from management that is counter productive in the longer term. Yes a company has to report, but it doesn't have to treat those end of year numbers like they are the basis for everything.
Distrust. Often management simply do not trust their employees to know better than them. I've seen senior management who haven't got their hands dirty for two decades overruling far more qualified and experienced people on technical and operational decisions inappropriately with disastrous consequences (e.g. a new product suite developed over five years for a 9 figure sum arrives on the market on a legacy platform with far less functionality than what it is attempting to replace). Usually this stems a senior manager assessing risks poorly where they are in unfamiliar territory.
Lack of empathy. I've lost count of the number of initiatives and re-organisations and changes introduced top down style which fail miserably because there is zero engagement from employees. Usually the management have simply forgotten to think about what a change means to them and how it will affect their work. The assumption seems to be if a change makes a business easier for a manager to manage, it must be the right thing - even if that makes the people that do the work less effective. Often there's a drive to make revolutionary changes for the wrong (career enhancing) reasons. Usually it's better to encourage change to happen organically at all levels of the organisation and often it's better to evolve. People are people, if you don't take that into account and empathise you will have a bad time.
Analytics Team of Captive Organisation (X shared functions) :
* Management (Manager) hardly aligns their goals with the client/partner (X) for whom we support instead they're primarily interested in filling up their Kpis in their ppt for their own organisation (XSF) even when we're fully funded by X.
* New Projects and tasks are kicked off just to make more number of slides in the weekly meeting rather than delivering valuable insight on time that could just go on in an email.
* Employees are just another data point in their Kpi sheet, empathy for wasting employees time and career doesn't seem to exist.
* Fresh grads out of college has been taken into the organisation with no clear idea about how to help them with a successful career and nor this responsibility exists.
Stressing and emphasizing employees to give trust to a company but not giving any in return.
Loyalty and "Do it for the team" sentiments are commonly paraded, but if you hide company performance and important developments, you not only have employees making decisions without context, but also sow seeds of distrust and signal you don't see your workers as capable minded adults.
For example, I used to work in a support department where the key metric agents were graded on was "replies per hour". Naturally favoring this above everything else led to a couple issues:
1. Little time spent on reply quality
2. No care given to handling a ticket after the first reply, because sending a stock first reply to a ticket is much faster and easier than working through the individual challenges of each ticket.
Management identified these as problems, but never changed how they graded staff in performance reviews, so the problems persist. From what I've read of other companies, this seems the rule rather than the exception.
Everything else I can think of's already been mentioned.
Not wanting to take the time to evaluate if the decisions made at the start of the project are still the right ones. It somehow feels safer to say "we aren't going to change anything" and keep accelerating toward the cliff.
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.
* Accept that the Internal IT sabotages External IT (using politics/compliance/HR).
Background:
Interesting projects are often handed to external IT, while the internal IT is perfectly capable to implement most or parts of it, they're held back from the project by the management. However internal IT is very often the only rep the external IT can talk to. Management never allows true of co-operation of internal and external IT to restrict costs and to 'benchmark' the internal IT.
Real Story:
1) I'm the "external IT" and the internal IT together with their project-manager (senior enterprise architect) block all my communication to the client and want to be aware of everything beforehand.
2) They're unhappy with my progress, but blocked my selection of a cloud-computing instance via HR.
3) Just got access to their lowest tier EC2-instance via a ridiculously complicated connection processs.
4) I'm not error free, but my consultant manager is on the customer's side, by principle.
5) The data I received is a very small and useless fraction that can barely be used for machine learning (at least with my limited skills).
6) I'm so frustrated and work remotely, away from both offices I've to report to.
7) I see me failing in this settings and I'm afraid of that. I don't know what to do.
Internal IT here.
Points 1-3 are all very understandable from a customers point of view and do not strike me as sabotaging.
Your other points are not relevant.
I believe that nearly all mistakes that management make are largely due to empathy. I think this is effectively why we've seen so many large, uber successful, companies being started by people with comp sci/software backgrounds. Worth noting - conversely, it doesn't mean that all comp sci/software people have the ability/capability to lead technology teams.
Would just like to add one in addition to the points already made in the comments:
Offering you a significant raise, a different and more interesting project/location, when you have put in your papers. Asking you to rethink your decision of quitting.
Seems like I didn't exist for the manager until I put my resignation.
Putting their own compensation and bonuses way above what decent people would do for employees. Their short-sightedness and selfish thinking does a lot of harm to thousands of people in every organization. Why am I calling these as mistakes and not just brushing these off as "it's a capitalistic system, just live with it"? I do so because good management that doesn't do all this keeps many more people happier than bad management. But this is the norm, and management that doesn't do this is a rare animal.
What's the point of making profits and more money if we can't increase happiness levels among more people, especially the ones who work on building the stuff that makes the money in the first place?
P.S.: My point is concise and can be counter argued in many ways. This is what I wanted to say without writing a whole book.
Sticking around and believing that they're essential.
When organisations are formed of people with perfectly aligned incentives, they don't need to be managed. Such people know what needs to be done and have the expertise and autonomy to make it happen.
Of course, such an organisation is hopelessly unlikely to retain this utopian state as the number of employees rises above 2. And it becomes vanishingly improbable if outside funding is involved.
So management is the act of taking care of something which can't take care of itself. A symptom: like an antibody, it arises when a system gets of out whack and its continued presence indicates a chronic condition.
The best thing management can do is to put systems in place to make itself redundant. So, by this definition, anything it does which promotes the opposite goal is a mistake.
The same ones. For many years. I don't dwell on them because people generally don't learn from other peoples mistakes, they have to make those mistakes themselves. There have been businesses and business management for many thousands of years. If people learned from other peoples mistakes we would have business perfected by now. Instead we are constantly starting over making those same mistakes. I left the rat race many years ago to run my own business which has been successful; for variety I am looking at returning to the corporate world, I know exactly what to expect because it doesn't change.
You may be a "zebra" = Belonging to 1% top IQ but not succeeding to communicate with people who don't notice patterns and second degree concepts that are obvious to you. There are help groups, although they won't help you with the groupthink.
Treating different departments differently in a company. In my experience the sales and marketing teams get the new toys, shiny offices, and budget for fun. Tech teams (this includes eng, ops, it, etc) get whatever's left.
1) Re-orgs upon re-orgs believing they'll fix underlying problems
2) Related to 1), lack of accountability when it comes to decision making, like when no one is accountable for the previous, failed re-org when deciding to re-org again.
3) Spending way too much time trying to make perfect decisions, especially around product vision. Much better to decide quickly, be flexible going forward and iterate.
4) Providing perverse incentives. As an example, one place I managed didn't give lower-level managers a budget, only a headcount. So, of course, everyone hired only senior and above developers. This created logjams during promotion time and forced a lot of turnover which could have been avoided with a more balanced hiring plan that included more junior devs.
5) Seagull management, especially from the C-level. For those not familiar, it's swoop in, shit all over everything and then leave others to deal with the mess. Either provide minor course corrections or devote a significant portion of your attention to that area until it's stable.
6) Being too good of a motivator. This doesn't sound like it should be a problem, but I had one manager who was so good at selling shitty ideas to the team that we kept working on the wrong vision. A good vision should largely sell itself.
7) Not caring enough about their employees as people. When the difficult conversations need to be had, it's a lot easier to deal with it if there's an underlying relationship where the employees feel appreciated and considered. It doesn't mean you have to be their friend, just that they believe you care about them. The easiest way to make them believe that is to actually care about them.
8) Not devoting enough time and energy to hiring. This was my secret as a manager. I put a lot of time into recruiting (lots of after-hours meet-ups and mixers) and was picky with who I hired, built a great team, worked to keep them happy and focused and then spent 3 years getting awesome reviews for doing basically nothing but shielding them from unnecessary distractions.
9) Rewarding busy over good. Who deserves most organizational praise, the employee who valiantly wrestled with a production issue until 4am or the employee who pushed a non-event release to production and went home at 4pm? I'm amazed at how often managers recognize and reward the former when the latter is giving customers a better experience.
I could probably come up with another 20 or so, but these are the ones that have cropped up the most in my experience.
Hiring non technical people for roles that are becoming increasingly more technical.
Many fields such as hr, payroll, etc have become far more technical in the implementation and use of system.
Management isn't realizing how much how quickly their business is changing and the impacts to their business.
Sometimes I wonder if perceived non-tech roles need to introduce an excel competency test not to measure excel talent, but the ability to work with data and details at a baseline level for the organization, or become the weak link.
If you can't work with the details of a business in a basic sense....
* 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.
One of my favourite books on management is Extreme Ownership. The classic mistakes I've seen made are: bypassing the chain of command and forgetting the mission.
There's a process by which my team accepts change requests, error reports, and feature requests from stakeholders. We plan our development in cycles and I co-ordinate efforts between teams so that people aren't getting blocked or stuck. The mistake here is when stakeholders bypass the chain of command and directly assign tasks to people on my team without telling me.
They don't realize the impact this has on productivity, momentum, and due dates. Not to mention morale! My developers don't like it when they have the next couple of days planned out for themselves and someone comes over and interrupts them to work on some non-related, trivial issue. They feel like they have no ownership or autonomy.
This all segues into _forgetting the mission_. A group of people need a clear mission in order to prioritize and co-ordinate work. Often times management will forget what the mission is and prioritize a customer's change request and delay important projects in order to meet their goals of keeping the customers happy. Sometimes you have to remember to say _no_ when doing the opposite harms the mission.
I work for an agency. The one I see most often is promising a specific deadline and/or budget at the beginning of the project, before we even know what the MVP is.
I have worked as an Android developer for 2 years at a startup and the worst thing is the micro-managing part. Companies take so many tests for developers and hire project managers or product managers who don't know shit about tech or how anything works. All they know is to ask "When will it be done?" and don't care about the complexity of the implementation or the time taken to do something the right way , an optimised solution. Another issue is releasing app/software without thorough testing and then blaming the developers for any bugs and crashes. Third and very important aspect is the "Why?". Nobody cares to explain why we are doing things certain way, why are we changing the designs, why are we moving the button, etc. Developers are not robots whom you can give any task and expect them to complete it in a ziffy. Developers want to understand the reason behind the changes, the results of these changes so that they know they are doing something worth the time and effort.
Everything I can't stand about management revolves around agile methodologies for profit. Agile itself is a good thing, but once you throw in companies trying to profit off of its processes you end up with this weird dogmatic dumpster fire that inhibits people from really doing anything besides keeping track of the current sprint or planning for the next sprint.
There is no such thing as "done" software. Everything program that is written must be maintained but PHB's never even consider maintenance costs.
Consequently, there is no such thing as a "build" and "maintain" phase of software. Something that takes 10 developers to build will take 10 developers to maintain.
The manager of my current team came up with some complex way of solving a problem that we're facing as a business. He implemented a proof of concept and showed the business without involving anyone else in the dev team at all. Now the business wants to roll with this "solution" to a key part of our software we've been desperate to refactor with foresight of incoming requirements. Instead we're ploughing forward, saving refactoring for later to implement this proof of concept. No design work is to be done - only implementation because we're on a tight fictional deadline. He's throwing more developers on it to "help" and even micromanaging the implementation.
The same manager expressed displeasure that he wasn't involved in discussions with the business about a new project that rose whilst he was away on holiday.
* Moving developers on and off of projects in the middle of development.
* Not listening to the lead developers' time estimates
* Focusing on the quickest possible development time instead of quality (and then complaining about going over-budget when bug fixing takes way too long).
* Worrying more about for how long you're sat in your seat rather than the quality of your work.
* Doesn't reward exceptional work.
* Gives developers work that they're not skilled in without adjusting the time estimates
* All 7 hours of the day must be billable time spent coding.
* Constantly wants to change what technologies are used for projects
* Over complicates tasks and/or tries to add their own 'good ideas' which are actually a nightmare to do.
This is my current boss. My stress levels are off the charts. Fortunately I've found work elsewhere and will be leaving soon.
Not enough one-on-one time with the coders. As a coder, it's very easy in a stand-up for any coder to say "yeah yeah yeah, I've got this covered". Then a week before release everyone realizes that person has a month's worth of work ahead of them. I've been all three: the "yeah yeah" guy, the manager, and one of the other coders that has to take the slack. It's a situation that seems easily avoidable just by a little better teamwork. Oftentimes "yeah yeah" can just mean "I have no idea what I'm doing", but dev2 (or mgr) could do and teach that task in half an hour, but dev1 just doesn't know who to ask.
I honestly think that being a manager 1st layer is the least enjoyable job in a tech company. So I wouldn't blame them too much since they're already dealing with a bunch of problems:
* Managers are easily replaceable because they don't have any expertise but people skills. My grandma has those skills, could she take on a manager role? Of course.
* You often get promoted internally to manager. So it's hard for you to move horizontally between different companies since they don't know you. You need to prove yourself again. Plus there is 1 manager job out there versus 10000 dev jobs.
* You get away from coding, far away from product then have to deal with expenses, HR issues, infinite meetings, etc.
One simple and subtle thing: not being empathetic.
There are a lot of process problems, a lot of productivity issues and lack of strategy, but the cold relationship kills the team's vibrancy and drains the energy, preventing people to do more in a better way.
My number one pick is always finding the next new thing in management from a New York Times bestseller. Then sending an email on the greatness of the process to the whole team and lo-behold expecting everyone to embrace it.
2nd for me is getting stuck on project names. It seems finding a cool sounding name is somehow more necessary than how it works.
To quote an example, we were using the waterfall model for our development. Then somewhere management read about "Rapid Application Development or RAD" and we embrace it ASAP. But not before dissing that RAD was not the word they wanted because rad the word had negative connotation to it so we needed a new name.
Management who incorrectly see IT as a cost center cause a lot of problems.
Every business is becoming or is a software business in that software of one kind or another is increasingly tracking the details, data and processes of the business.
Failing to realize this shift, technology is not utilized as an enhancement and leverage tool for competitive advantage, instead their competitors do.
Business technologists who both understand business and can solve problems with tech will likely become a new class of business professionals like accountants.
That, or technologists will inherit the jobs of hr, accountants because the existing folks are not able to keep up and innovate constantly.
Assuming that saying 'Do X' is really 'Do X'. Truth is I have to fix 10 bugs before I can even set up a test case for 'X'...
Also just the general cluelessness of the state of the software.
Managers need to convince the higher-ups that the software is in good shape (because their job is on the line), meanwhile the devs know its got 1000 bugs in the ticket list plus 3000 bugs that didn't make it to the list.
Failure to explain management objectives. 'We promised company X feature Y in Z days'
They don't make decisions based on data, despite believing themselves to be a data driven company. All decisions flow from the top, and are ego-based, not data driven.
not sharing company goals with engineering - engineers have to second guess whether it's the moment for building or polishing, for adding new features or for consolidating before a big push etc.
this cause a wealth of secondary problems like deadline that seem arbitrary, focus on random features that need to be rushed every stint without logic or order, developer burnout and the need for ever-increasing micromanaging.
Becoming managers to sooth their self-esteem issues.
I don't mean this as a cynical joke at all. In my experience too few managers see the job as a job, and instead they see it as a power and status boost --- a way to be "winning" in the game of life.
It should be a calling. It should be the thing you were put on this earth to do.
Of dozens of managers I've encountered, I've only met 1 or 2 where it seemed to be their calling.
Management have the misguided notion that if you adopt the Agile methodology (TM) you will deliver successful software projects.
Loads of people uninterested in software engineering and technology follow agile training and the end result is loads of pictures of walls covered in Post-it notes, disgruntled developers and no working software or product to show for it.
Failure to focus on the logistics surrounding the team, while relentlessly pushing out carrots and sticks for more productivity.
If you have the right skills, training, tools, and processes; things get done well. When there are gaps in these areas, no amount of discipline or incentives will make up for it. Don't make the cheese bigger, make the maze smaller.
When devs are promoted into management or team lead positions they are not given adequate training on what it means to manage / lead. Thus devs don't learn what good management is, and the stereotype of the bad manager perpetuates.
- Acting like 1:1s and performance reviews aren't the most important aspect of your job by putting them off, ignoring them or saying you dislike them to your reports
- I'll repeat: "misusing agile in order to micromanage"
Massive problem in tech: Valuing easily-quantifiable metrics for productivity over "softer" forms of productivity. Current tech culture reminds me of a random idiot who makes claims like "Xavi wasn't much of a midfielder because he rarely scored goals".
On one small project I was on (6 person team), we had a guy -- we'll call him Carl -- who was right at the bottom of the pile of commits. I mean, maybe 20-30 over the course of a 6 month project. From an earlier collaboration, I happened to know that he was a very good programmer, but he wrote practically zero code for this project. And Carl wasn't that popular with our bull-in-a-china-shop director, who claimed that Carl was dead weight slowing our fast-paced team down. He constantly asked the rest of us what Carl was "contributing".
So, after months of pressure, Carl "left" for a separate team as the project wound down, in spite of our vociferous appeals to management to keep him on. He quit a few months later.
Why were we so desperate to keep him?
Because Carl was the glue that kept the group working so productively. He managed the egos, kept focus on the goal, and fostered respect for everybody on the team. He intervened during technical and interpersonal disputes. He was calm and quiet and rational. During design discussions, when the more outspoken members of the team were trying to ram through their visions of the world (guilty!), he would bring brilliantly insightful and cogent questions about the long-term and medium-term ramifications of said designs. He was an unofficial liaison to our internal customers. He volunteered to break bad news to management when there was a delay, but deferred to other members of the team when it came time to claim credit for our progress.
Carl was, in short, our unofficial PM, and a damn good one. He realized that his social skills were more valuable to the team than his technical skills. But his contributions weren't valued by management because they weren't as visible as our commits. Our team fell apart in a matter of months after he left, as we quickly became overwhelmed by all the stupid shit -- and toxic politics -- he had deftly absorbed and deflected. We wasted two of those last months working on a feature that he had opposed, only for none of our clients to use that feature upon release. Just as he had predicted.
In general, all the things he brought to the table -- humility, empathy, patience, foresight, listening, respect, selflessness -- are the sorts of pro-social traits that tech companies (and especially SV tech companies) aggressively select against, in spite of the fact that they are precisely the kinds of traits that lead, in my experience, to far greater productivity.
The current culture is borderline toxic. In all the talk of "10x" programmers, people seem eager to overlook that a 1x programmer might have a 10x positive impact on their team in other ways.
Continuing to use methods and behavior that has never worked efficiently before and expecting changes in details to have large improvements in efficiency.
I think there is inverse proportionality of development speed vs code quality + maintainance cost which management does not take into a count, ever, no matter what.
Not thinking about team morale until it becomes a issue. Negative mindsets can spread through a team quickly, and once they take hold they can be hard to root out.
i don't think they make too many mistakes. from their perspective its about minimizing cost and maximising earnings and i think they do this reasonably well. some managers can get a bit fanatical about this, which can shoot them in the foot sometimes but that is not the case at any company i worked for.
#1: Management cutting corners in the budget in areas that need the money, but keeping the money flowing in areas that don't. For example, I was a one-man-miracle show brought in to do an infrastructure upgrade for a company drowning in technical debt. I managed to impliment what would have been a $45-70k$ system for ~$19k, at the core node level, but when requesting a ~$8k horizontal cabling job to be done by a contractor, all I got was "no, it's not gonna happen". Which brings me to...
#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.
* 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 and trying to defy gravity in ignoring skills rot etc. through lack of investment in training
* Expectation that devs can be swapped between technologies without problems
* Swapping people in and out of projects as if this will not affect progress
* Deliberate hoarding of information as a means of disempowering devs
All of this inevitably leads to a bunch of pissed off devs. The ones that are happy to eat it become the golden boys and get promotions. Those that point out the bullshit leave once they can and are replaced with the desperate at the bottom who sooner or later arrive at the same position of wanting to leave once they realise what's going on. I think tech can be pretty miserable if you are not in the upper echelon of lucky types that can score a position at a Google, Facebook etc.
Oh and a couple more:
* Give no feedback unless things go wrong
* Treat your highly educated, intelligent and motivated devs like children by misusing agile in order to micromanage them
> * Treat your highly educated, intelligent and motivated devs like children by misusing agile in order to micromanage them
These two points made me cry. I suffered my very first burn-out due to that and although having a higher degree in computer science and love towards programming this really made me feel like a piece of shit. I have the feeling that it's really hopeless and it wants me to make the change to IT-Consulting instead of software-engineering.
Also hits a nerve for me. Our mgmt just shuffles devs around from fire to fire without really just sticking the same devs to a single project until it's done.
Then we get questioned why projects are not done.
And don't get my started on our new Agile process. We have scrum meetings for our scrum meetings. We have mgmt. popping in the project level scrum meetings to tell us what is and isn't scrummy enough to talk about during the meetings.
And I moved to this company after thinking my last company didn't have it together. Man, I was wrong. No one writes comments here, or any tests. We just "make it work". Pay is awesome though...
LPT: Don't complain, but suggest improvements. Stop looking at "management" as some evil superpower that can't be reasoned with. They're just people with different responsibilities. Align.
Oh dear, I'm really sorry for touching a nerve! I think management often have zero insight into how much many devs care about their work. Not all - I'm sure there are plenty with a thick skin and/or that care little beyond getting paid - but some of us are only capable of delivering our best given the right conditions. Lack of feedback is one of the most serious red flags I would say, and shows either the company is seriously dysfunctional, or that they absolutely do not give a shit about your progress. At that point the job should become just a paycheck until something better comes along. The funny thing is when they expect you to do your best work despite not keeping up their side of the bargain!
That is very true for me. A lot of managers don't understand my motivation at work, they don't understand that what actually keeps me going is the love for technology and for software engineering. That is being able to learn and develop interesting things, to research, to create, that motivates me. I can't bother on corporate politics. I don't care on going up the corporate ladder (I'm already in a top engineering position, I don't want to stop doing coding to become some sort of manager/architect/VP/etc).
> I have the feeling that it's really hopeless and it wants me to make the change to IT-Consulting instead of software-engineering.
Doesn't IT Consulting involve a fair amount of software engineering? Or by IT Consulting you mean like design high level architecture in a way that is abstracted from the app(s) it runs (e.g. setup a docker swarm)?
That one can hit all areas of ICT real bad when the company is a managed service provider, leading to a 'Chefs kitchen/Plumber's bathroom' where the company provides great outsource ICT services offering to its clients, but runs an absolute shitshow for it's own systems because they're chronically under resourced (you can't bill it, so don't spend time on it).
That has extra interesting results when such a company tries to spin up and sell services which it's built/hosting/maintaining/developing itself.
I think I get what you mean by 'Chefs kitchen/Plumber's bathroom', but I've never heard either colloquialism before and can't find anything on Google, either. What's the origin of these terms?
Based on the context, something like "the cobbler's children have no shoes" meaning they are too busy doing paid work for others to the same work for themselves.
I don't think it's related to too many chef's in the kitchen. More a reference to chefs having a spotless kitchen at their day job, but a messy kitchen at home. Likewise for plumbers.
A lot of non-tech companies treat IT as a cost center and that can lead to short sighted decisions that cost them a lot in the long run (or more accurately, they fail to realize benefits that were available to them with appropriate investment).
But it seems counter intuitive that this effect can be worse for some tech companies, where a major part of their business involves convincing clients to treat their tech as more than just a cost center.
Like, you have an entire staff compliment of developers, architects, PMs, engineers and customer service staff, and your own entire ICT practice is a disaster? HOW?
I ended up having to draw people's attention to it by pointing out 'this is your single biggest client, and receives the least attention of them all'.
Loops into the old 'eat your own dog food' wisdom, but from an angle that seems to often get missed.
Because of this mindset, companies who decided to outsource IT as an obvious cost optimization realized how their company actually runs.
Specifically that there are huge off-the-record operations (outside of the ticket system). The more VIP the problem is, the less tickets.
And suddenly, the people supporting them (particularly if they were outsourced but stayed in the company as contractors, and were pissed off) had one sentence "open a ticket". Doesn't matter if this is the CEO asking, or something "urgent", ticket it is.
And the gates to hell opened.
Source : me not being IT anymore (huge company) but strongly advocating against the outsourcing (pointing to the above), and then taking a backseat and watching the world burn with popcorn in hand.
> * 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.
1. Building a product for a specific client takes less time than building a configurable generalized product that you can sell to others. The business may be willing to take a $30k haircut as in your example, but are they also willing to have development take 50-60% longer (and the additional financial costs of that)?
2. Once it's a generalized product, how will that first client feel about being told that a new feature they want won't be built?
3. As a corollary to #2, the first client will also look at it as something they purchased, not a service that you now offer to them. They'll demand things and the business will need to have the fortitude to tell them no, and most businesses can't (or won't) do this.
It's very hard to get a scenario like this to work out where people are still happy with the arrangement 2-3 years in the future.
In my experience, often the product ends up being molded to fit the particular client (it's custom software, after all) and then the cost of altering it for other clients is perceived as too steep. Or you end up with a bunch of similar, incompatible projects.
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).
I agree that sounds like a reasonable approach - but in my working life it's always been seen as this fantastic wheeze of 'let's charge one customer to build something and then go off and sell it to everyone else!'. It seems like a great idea, but the usual story is that either making it generic burns up days that would otherwise be spent meeting the specific customer's requirements, thereby ensuring a worse product, or you stay on track with the customer's requirements and ditch the idea of making it generic as soon as days get tight.
This is one of the things that always makes me groan, along with 'and you can learn x technology along the way!' >:|
Out of the blue, I was once expected to set up a recording studio and learn the electrical engineering side of things 'along the way! You've got the afternoon, in addition to your normal duties.' My background is in CS, not physics or engineering, so you can imagine how that went - and of course, the manager wasn't to blame.
Sometimes it can work. More often it starts innocently and mutually as you describe, but it very quickly becomes a game of firefighting and drains innovation within the product line. Next thing you know, you're selling based on roadmap features and don't have control over your own product anymore.
Unfortunately I've just thought of another - moaning about time estimations - even after these have been pared down to the absolute minimum with the expectation of putting in extra hours on the side to meet the deadline!
"This will take 40 hours" (I hate estimating in hours for individual tasks as there's no way to average the overrages with the ones that went under estimate).
"Thats too much, can you do it in 20?"
"No, 40 is already underestimating imo"
"Well, it won't fit in the project plan at 40"
"Sorry, that's really as fast as it can"
"Well, lets put 20 and either make up the time or just go over" (wtf?)
> All of this inevitably leads to a bunch of pissed off devs. The ones that are happy to eat it become the golden boys and get promotions.
The question asks about behavior that management repeatedly makes. If management repeatedly makes these mistakes, then the mistakes should become expectations, so one should simply accept them and understand that they are part of the game being played. If they are expected behaviors, being "pissed" about them simply is foolish.
Of course, by "accept them" I don't mean one should never try to influence or change the situation, but reacting emotionally rather than rationally is silly. Even if there are no upward-feedback or 360 review procedures in place at the workplace, one can articulate these concerns more diplomatically (less offensively) and send out an email requesting that they be considered. One can even illustrate and trace through how such mistakes have impacted recent projects.
It seems to me that the ones "happy to eat it" simply understand that others have limitations and make mistakes and will try to make the best of the situation. It sounds to me like such people indeed deserve the promotions more than people who bring anger to bear on their work.
> one should simply accept them and understand that they are part of the game being played. If they are expected behaviors, being "pissed" about them simply is foolish.
Does this apply to athletes who are upset when referees seem to be consistently favoring their competitors? Does it apply to people living under an oppressive government? Does it apply to a person who is being verbally abused by a spouse?
Sure it'd be great if these people could seek to improve their situation through rational means, or perhaps just accept it if they can't change it, but humans and emotions don't work that way.
> reacting emotionally rather than rationally is silly
Humans are emotional creatures. Expecting humans, even yourself, to act rationally shows a misunderstanding of human psychology and behavior.
That sounds a bit like you are suggesting excusing bad behaviour, or blaming the victim. If someone warns you they are going to hit you before they hit you, does it make it hurt any less?
Also when eating it means 60 hour weeks to make up for terrible managers (all the while collecting their substantial pay packets) I'm quite happy to walk out the door and let then find someone else to be abused.
Passed a telephone interview today, got a f2f next week, hopefully onwards and upwards soon.
Ah, the realities of supporting IT infrastructure. When things go right, management wonders why they even pay you. When things go wrong, management wonders why they even pay you.
> * Inadequate training and expectation devs can just piggy back learning technology x from scratch whilst writing production software using it
Yeah that's funny, believe it or not - I prefer the exact opposite. At my last jobs I had a hard time diving into new technologies unless I knew them completely. Thus I think synchronization is an important thing...
To be fair, these managing behaviors happen in other areas like civil engineering consultancies. In fact, it happens so frequently, I really don't know what a "correct" managing behavior looks like.
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.)