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 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 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.
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.
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.
* 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.
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.
This, so much. No matter how many first-years physics students you have, you're not going to invent general relativity.
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.
All hiring managers want the best of the best, but they won't simply come and knock at your door if you're a no-name.
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.
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).
That's interesting. Not the total compensation of the people she manages?
And so, off we go to empire-build. It's a pretty hard impulse to resist. Especially since many places consider "growth" the ultimate goal.
- 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.
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 ]
I think too much faith is put in the abilities of most management; otherwise this Ask-HN article might not have been asked.
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.
Otherwise, I am a thoroughly mediocre performer. I'm a minimum effort Loser 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.
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 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.
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.
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.
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..
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.
I do agree that sometimes managers want to fit "chefs" into a McDonald's like cooking process.
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.
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 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
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.
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.
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.
Preferably the requirements are explored by the team with the stake holders.
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.
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).
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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'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.
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.
 His peak speed was a bit faster (~27 mph), but the point stands...
Most people could beat a par 3 in less than 30 strokes given 1 week of exposure to golf.
> 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.
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.
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.
In a team environment that is not so easy.
Is it the code, the communication, the business sense, building a good team? Who made that million? And who only made 10 bucks?
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.
Your idea works in teams where everyone at all levels is switched on and tuned in.
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."
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 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.
I also use a pretty unique billing structure that my clients seem to really love. You can read all about how and why we chose to do it this way here https://blog.grillwork.io/why-we-no-longer-use-fixed-price-c...
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.
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.
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.
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.
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.
Edit: fixed a typo
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.
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.
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.
Hiring for such micro optimization is inefficient at best, ineffective usually, and counterproductive at worst.
The existence of a 10x developer is a question of what you use as a reference point for your scale.
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. 
To understand control’s real role, you need to
distinguish between two drastically different kinds
* 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.
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.
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.
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.
Programming Beyond Practices https://amzn.com/dp/B01LYRCGA8 $14.99
detailed examples of the many problems developers encounter, including the thought process it takes to solve them
* 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.
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.
I always try to explain this. Yes there are best practices, but there is also a ton of creativity that goes into good software dev.
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...
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 :)
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.
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.
> "a person"?
-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 :-)
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.
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.
10x, 100x revenue is only one piece of the story.
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.
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.
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.
Customers, employees, shareholders.
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.
I think they are great guidelines.
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.
Most succinct expression of the basic problem yet - nice one
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.
> Why is overall revenue a better metric than unit profit? Wouldn't overall profit be the first-order effect?
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.
This! It needs management people who understand their role as being "facilitators", rather than being "decision makers". And they are kind of rare.
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?
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 :)
It is one of my signals of inexperienced management that they believe they can/should take on this sort of challenge.
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.
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 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?
All this assumes you trust your team to be thoughtful and do good work. If not then that's a whole 'nother issue.
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.
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"
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 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.
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.
- 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
I've seen so many "managers" spend all their time staring at Jira instead of talking to their actual team or reading the code.
I'm convinced Jira is an anti-pattern for management
Makes me think of "There are two types of managers: shit umbrellas and shit funnels".
(Similar problems can happen when a bunch of people with no management skills decide to found a company and start hiring people.)
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 also believe that management should be about facilitating your team's work, rather than endorsing your team's responsibility.
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.
* Preaching about the virtues of a flat organizational structure, but making unilateral decisions.
* Hiring people for a particular challenging job, but have them work on menial unchallenging tasks.
* Creating multiple layers of management for a tiny team.
* Facilitating post mortems that would be better facilitated by a neutral third party.
* Using vague management speak as a deliberate strategy to never be held responsible for anything.
* Rewarding politics with promotions.
* Marginalizing experienced employees.
* Talking too much about culture.
* Trying to be the company “thought leader” instead of helping people do their best work.
* Assuming that everyone underneath you views you as a career mentor.
* Negging employees.
* New hire managers: Firing incumbent employees after you’ve only been on the job for a few weeks.
* New hire managers: Not doing 1:1s with everyone who reports to you.
* New hire managers: Create sweeping changes like re-orgs after a few weeks on the job.
* New hire managers: Doing things a certain way because it worked well at a previous company.
* New hire managers: Changing office work hours to suit your personal life.
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.
How is this a mistake then? It seems As Planned. It'd be a mistake if the management suffered for it.
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.
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.
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.
* Short-term thinking ("we don't have time to fix the tech debt, we have to get something on the board this quarter")
* Over-resourcing projects from the start, rather than letting a small number of employees germinate it and set it on the right path
* Punishing people, often indirectly, for taking risks, conducting experiments, doing quick prototypes, etc
* Frequent shifts in direction, priority or emphasis. If "everything" is important at one time or another, then nothing truly is
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)
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 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.
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.
> 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 often feel evidence is used selectively.
Statement - Programmers are bad business decisions Evidence - Often use single example point that out.
Statement Managers are good at business decisions - Tons of bad decisions over the years - Apparently still good at business decisions?
I met many founders over the years and those with technical background were the best.
The non-technical founders had often bad ideas to start with or were piggy backing on the techies, while putting them down with their big words etc.
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.
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.
6) Open fucking landscape workplaces.
* 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.
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.
The new manager was laid off shortly after I was.
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.
> Corollary 1. Who can, and sometimes does, un-rot the fish from the bottom? An insane employee.
> 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.
* the employee isn’t good and everyone knows it. Manager lacks discipline or has a low talent bar.
* the person is very talented, but a jerk. Manager is worried it will hurt productivity to get rid of them.
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.
- 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
- 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
- Micromanaging task priority, assuming that a developer jumped on a specific task and completed it instantly
This strikes way too close to home.