Things I have learnt as the software engineering lead of a multinational(minnenratta.wordpress.com)
minnenratta.wordpress.com
Things I have learnt as the software engineering lead of a multinational
https://minnenratta.wordpress.com/2017/01/25/things-i-have-learnt-as-the-software-engineering-lead-of-a-multinational/
225 comments
This really is an exceptionally good article, written by a pragmatic and insightful student of working life.
I have often experienced the following but could never have described it as elegantly:
> Incompetence is fiercely gregarious while knowledge is often fractious; the reason for this is that raw ideas transfer more easily through untrained minds than refined ideas transfer through trained minds. There’s a reason why large organisations focus so much on simple messages, pity that difficult problems often have simple solutions that don’t work.
I have often experienced the following but could never have described it as elegantly:
> Incompetence is fiercely gregarious while knowledge is often fractious; the reason for this is that raw ideas transfer more easily through untrained minds than refined ideas transfer through trained minds. There’s a reason why large organisations focus so much on simple messages, pity that difficult problems often have simple solutions that don’t work.
[deleted]
> Being overworked is not a good reason to hire. Instead, hire to be ready to catch opportunities, not to survive the current battles.
I disagree - if you have overworked people, that is usually a red flag that you need more personnel and planning failed. It doesn’t necessarily mean you should be hiring right at the moment, but it is a significant alarm bell that you should seriously consider starting to hire or you’re going to chase away engineers.
I disagree - if you have overworked people, that is usually a red flag that you need more personnel and planning failed. It doesn’t necessarily mean you should be hiring right at the moment, but it is a significant alarm bell that you should seriously consider starting to hire or you’re going to chase away engineers.
>> Being overworked is not a good reason to hire. Instead, hire to be ready to catch opportunities, not to survive the current battles.
> I disagree - if you have overworked people, that is usually a red flag.
Overworked people is a red flag indeed, but it is usually a symptom of a deeper problem that is unlikely to be solved with more hires. I think the author hits the nail on the head here -- first and foremost hire for future opportunities.
> I disagree - if you have overworked people, that is usually a red flag.
Overworked people is a red flag indeed, but it is usually a symptom of a deeper problem that is unlikely to be solved with more hires. I think the author hits the nail on the head here -- first and foremost hire for future opportunities.
Agreed. At a previous (small) job the IT department was VERY overworked. They tried to hire to fix it and it didn’t work. Because it wasn’t the problem.
The problem was unsustainable methods of doing everything. Every job was unique for no good reason. It was all managed by hand, monitoring monitored the wrong things.
Each existing thing generated a ton of work due to how it was setup and required constant tweaking. Any new thing just piled additional work on, often causing issues with what already existed.
Because of the lack of any kind of system or useful documentation new employees only made things worse as they tried to understand what existed, had to ask constant questions, or failed to take into account hidden gotchas that they had no way to watch out for.
Until they started standardizing and stabalizing the base things couldn’t be improved.
Yes there are times you have 10 developers worth of work and 5 developers. But there are times you have 4 developers worth of work and 6 developers worth of mess they have to tip-toe around, but only 5 people.
The problem was unsustainable methods of doing everything. Every job was unique for no good reason. It was all managed by hand, monitoring monitored the wrong things.
Each existing thing generated a ton of work due to how it was setup and required constant tweaking. Any new thing just piled additional work on, often causing issues with what already existed.
Because of the lack of any kind of system or useful documentation new employees only made things worse as they tried to understand what existed, had to ask constant questions, or failed to take into account hidden gotchas that they had no way to watch out for.
Until they started standardizing and stabalizing the base things couldn’t be improved.
Yes there are times you have 10 developers worth of work and 5 developers. But there are times you have 4 developers worth of work and 6 developers worth of mess they have to tip-toe around, but only 5 people.
"Overworked" does not need to mean your engineers are pulling 14 hour days. Even just having a massive backlog that never gets knocked down is, to me, a form of "overwork".
Even if the work life balance is fine, it's very difficult to stay motivated when you are constantly chasing bugs and never getting to actually build anything, or your manager is having to defend your team against second guessing from the outside. Having too many things to do and not enough people to do it can really kill morale.
Even if the work life balance is fine, it's very difficult to stay motivated when you are constantly chasing bugs and never getting to actually build anything, or your manager is having to defend your team against second guessing from the outside. Having too many things to do and not enough people to do it can really kill morale.
> Overworked people is a red flag indeed, but it is usually a symptom of a deeper problem that is unlikely to be solved with more hires.
Not necessarily. Accepting a new project or extra responsibilities in exchange for a generous sum may increase your company's workload unexpectedly, which leads to overworked people while the company struggles with the hiring process. Another example is losing a team member right before crunch time.
Not necessarily. Accepting a new project or extra responsibilities in exchange for a generous sum may increase your company's workload unexpectedly, which leads to overworked people while the company struggles with the hiring process. Another example is losing a team member right before crunch time.
Sure, there are exceptions. For example, I do not see a team flying out for a 2 60+ hour week test campaign as a red flag as long as the participation is mostly voluntary and the team gets an ample opportunity to detox after the fact.
The exceptions, for me, have three key properties: (1) they are temporary, (2) overworked people know that it is temporary and have a clear (maybe not 100% realistic) date for return to normalcy and (3) this state of affairs is seen by most of the team as acceptable at the moment: not pleasant, but bearable and probably least bad of all options.
If (1) and (2) hold, (3) is usually easy to achieve with sweeteners: $x bonus, T extra vacation, etc. But break either of the three and you have a clear red flag. Just my 2c.
The exceptions, for me, have three key properties: (1) they are temporary, (2) overworked people know that it is temporary and have a clear (maybe not 100% realistic) date for return to normalcy and (3) this state of affairs is seen by most of the team as acceptable at the moment: not pleasant, but bearable and probably least bad of all options.
If (1) and (2) hold, (3) is usually easy to achieve with sweeteners: $x bonus, T extra vacation, etc. But break either of the three and you have a clear red flag. Just my 2c.
Perhaps the deeper problem is the lead who committed to the deliverables isn't doing a good job and should be removed.
I think what he was going for was that you shouldn't solve the overworked problem with hiring. It indicates you need more manpower, yes, but it's also indicative of planning and resource allocation problems that need to be solved first. Adding more people before you solve those problems will probably make things worse. Things need to be properly divided and conquered, some things may need to be put on the back burner. It often indicates that you haven't split up the workload into manageable pieces, and are instead trying to get it all done at one time.
Someone might now jump and say 'sometimes crunch time is necessary!', and I would reply that if you're in crunch time you've just demonstrated the exact issue I'm describing.
I think he's essentially restating 'the mythical man month' for a modern environment.
Someone might now jump and say 'sometimes crunch time is necessary!', and I would reply that if you're in crunch time you've just demonstrated the exact issue I'm describing.
I think he's essentially restating 'the mythical man month' for a modern environment.
But similarly, quickly coming to the conclusion to not hire is just as fallacious.
If someone burns out as a result of the bungled planning, then the project can potentially be doomed without hiring (or even doomed anyway) - one should almost immediately reevaluate when one comes into this situation unless there was some sort of agreement beforehand.
If someone burns out as a result of the bungled planning, then the project can potentially be doomed without hiring (or even doomed anyway) - one should almost immediately reevaluate when one comes into this situation unless there was some sort of agreement beforehand.
Alternatively, feeling pressure to hire because of workload means that you failed to hire quickly enough upfront, and now you are manpower strapped because you were trying to make your burn rate look better for this month.
You either need more people or less work. And having too much work may be because the organization has lost focus on what really matters, and is trying to do everything. You cannot hire enough people to solve that problem, because as you add people, management says "great, now we can do even more..."
Almost every military metaphor in this piece fell flat for me, but this one might have been the worst of the bunch. Not only is it a forced metaphor that barely fits the point being made, it's not even a particularly good point.
That's about where I stopped reading.
"18. Don’t shy away from leading without doing, it is unavoidable, so just do it. Then do some work to stay pertinent.
19. If you are not able to hire and fire people, leave. Or stay for the retirement fund if you can stomach it."
the way the author discusses people and pretty much everything in the "Yourself" category makes me think this unnamed multinational is a sweatshop overseas. I've worked (temporarily) with people who try to bring this thinking to Silicon Valley
19. If you are not able to hire and fire people, leave. Or stay for the retirement fund if you can stomach it."
the way the author discusses people and pretty much everything in the "Yourself" category makes me think this unnamed multinational is a sweatshop overseas. I've worked (temporarily) with people who try to bring this thinking to Silicon Valley
I got the same sense as you, but without the "overseas" bit. We have sweatshop software shops in the US (look in just about any AAA game company, for example).
I took #18 as ‘don’t be afraid to delegate, you don’t have to have your finger in everything.
#19 makes sense me to too. If you can’t hire/fire then you’re not really in charge. How can you manage your team if other people have the ultimate veto on your strongest management options?
#19 makes sense me to too. If you can’t hire/fire then you’re not really in charge. How can you manage your team if other people have the ultimate veto on your strongest management options?
The article is too abstract for me. I don't have enough leadership experience to relate to what is being said. I'd be grateful if someone could rewrite this article with some concrete examples. I am sure there are many others in the same boat as I am. They will find this useful too.
Getting lots of people together to work on a large problem is an engineering problem in itself. It has its own language and constructs. Doing it wrong means millions or billions are wasted, and enterprises lose ground on the world stage.
Some of these ideals don’t translate well to smaller scale. A 5 person team doesn’t have to work out much except the work. How do you get 1000 people to agree on a plan, an IDE, a language, and to row in the same direction? Not magic. Study and practice.
Some of these ideals don’t translate well to smaller scale. A 5 person team doesn’t have to work out much except the work. How do you get 1000 people to agree on a plan, an IDE, a language, and to row in the same direction? Not magic. Study and practice.
I'm an architect at a huge multinational, and I also found it to be too abstract, even vague. I'm sure it works for some people, but I'm really not a fan of this writing style.
Sadly, you are correct. You need some experience. "Experience is the great teacher, and some will learn from no other."
In my career, I've seen shocking, astounding, career, organization, and company threatening examples of nearly everything he mentions, and to me his reactions are terrific and make a lot of sense.
But, likely as you mentioned, need lots of real world examples from which he has extracted general, "abstract" lessons.
He has terrific stuff. He is an excellent observer and, then, analyst of what the heck he saw.
I put the text in my collection of management essays and regard it as by a wide margin the best management advice I've found for my startup: Currently I'm a sole, solo founder, so far have done it all, including all the important work and a lot of grunt work, but if my startup is successful then I'll have to hire and manage, all of it. Sure, eventually I'll get a COO and delegate a lot to them, but, still I'll have to know what's going on. And there will have to be more software development; I'll have to manage that either directly or through, say, a CTO or CIO, and that essay is the best advice I've seen so far.
Other good advice is in Brooks, The Mythical Man-Month. Brooks is deeper in technical issues; the OP is better in the human and management issues which, IMHO, is where the real problems really are.
Oh, by the way, I still believe that nearly all the best ideas in software management I've heard about are old (although I do have along list of questions where the old stuff doesn't give good answers and where I haven't seen good answers either old or new). So, e.g., I have essentially no faith in "agile" or "object-oriented". And I believe that (A) code without good documentation is essentially worthless, (B) the documentation is more work than the code, and (C) between the code and the documentation, if I had to save just one, it would be the documentation. So, in particular, for the work, the most important part of it is writing documentation; writing the code is the lesser part. And (D) my view of writing code is that it's simple: Start with a good description of (i) the programming language to be used and (ii) good descriptions of the functions, classes, APIs, etc. to be used, and between these two by far the more difficult is (ii). [No, right, usually it's not automatically simple, not at all; instead, in the end it should look and be simple, and that can take a lot of hard work.] Then from the documentation get the really crucial stuff -- what the heck the code is to do. It is the documentation that makes clear the issues of threading, locking, roll back, exceptional condition handling from small scale to large, the UI/UX, etc. Those issues are to be clear in appropriate parts of the documentation and not to be worked out only during the coding. So, e.g., try to get most of the coding down to (a) allocate storage, (b) the usual control structures if-then-else, do-while, select-when, (c) call-return, (d) clear architecture on exceptional condition handling, logging, etc., and (e) the functions, classes, APIs, etc.
From what I learned from before the OP, although the OP has it better but maybe not as explicit, here are two lessons:
First Lesson.
"Why should I"? If you see a person in an organization and some work they might do, ideas they might have, etc. you have to ask the question, how will that person answer the question "Why should I". What's important here for a manager is not how YOU would answer this question but how you would anticipate that subordinate, other person, would answer the question. To be cynical, just because some area A is in the person's area of work, for some work X, will they actually do X and do it well? First way to know is, how would that person answer "Why should I do X"? To be cynical and likely often realistic, without a good answer, the person may simply neglect to do X.
E.g., there is the old Ross Perot joke: Most organizations, when they see a snake, form a committee on snakes. In a good organization, when someone sees a snake, they kill it. Well, then, the answer to "Why should I kill the snake" is that Perot had a good organization.
Second Lesson.
There is a field, with courses, in public administration, business schools, and parts of sociology called organizational behavior. There one of the better ideas is goal subordination. Well, the OP is awash in cases of goal subordination. The idea of goal subordination, and common for middle managers, is to "subordinate" the "goals" of the organization to the "goals" of that middle manager. So, the manager does what he believes is good for his career even if it is bad for the organization. So, an exercise is to read the OP essay and list and explain the places where the author is suggesting goal subordination.
There's much more to say, but, trust me, the OP is talking about stuff that is darned real.
For me, I want my startup to work. A big, huge advantage of being founder and 100% owner is that I don't have to explain stuff to some BoD that, as in the OP, has no chance of understanding reality. So, I'd constantly have to create "company theater" for the BoD, and that would be so wasteful it could kill my company.
My point here generalizes and is generalized in the OP: The crucial details of a serious real problem and its best solution are typically too difficult for communicating up a management chain or even just from a CEO to a BoD. The OP is correct. So, as sole founder and 100% owner, I don't have to try to communicate to a BoD that has no hope of understanding or waste effort on company theater. Instead, I just concentrate on making my company successful. If I am successful, then the main evidence visible externally will be just the financial, brand, etc. success, a lot of which the news media will likely heavily distort; the real reason the company was successful will be known just to me and maybe a COO or CTO if I get really good ones.
In my career, I've seen shocking, astounding, career, organization, and company threatening examples of nearly everything he mentions, and to me his reactions are terrific and make a lot of sense.
But, likely as you mentioned, need lots of real world examples from which he has extracted general, "abstract" lessons.
He has terrific stuff. He is an excellent observer and, then, analyst of what the heck he saw.
I put the text in my collection of management essays and regard it as by a wide margin the best management advice I've found for my startup: Currently I'm a sole, solo founder, so far have done it all, including all the important work and a lot of grunt work, but if my startup is successful then I'll have to hire and manage, all of it. Sure, eventually I'll get a COO and delegate a lot to them, but, still I'll have to know what's going on. And there will have to be more software development; I'll have to manage that either directly or through, say, a CTO or CIO, and that essay is the best advice I've seen so far.
Other good advice is in Brooks, The Mythical Man-Month. Brooks is deeper in technical issues; the OP is better in the human and management issues which, IMHO, is where the real problems really are.
Oh, by the way, I still believe that nearly all the best ideas in software management I've heard about are old (although I do have along list of questions where the old stuff doesn't give good answers and where I haven't seen good answers either old or new). So, e.g., I have essentially no faith in "agile" or "object-oriented". And I believe that (A) code without good documentation is essentially worthless, (B) the documentation is more work than the code, and (C) between the code and the documentation, if I had to save just one, it would be the documentation. So, in particular, for the work, the most important part of it is writing documentation; writing the code is the lesser part. And (D) my view of writing code is that it's simple: Start with a good description of (i) the programming language to be used and (ii) good descriptions of the functions, classes, APIs, etc. to be used, and between these two by far the more difficult is (ii). [No, right, usually it's not automatically simple, not at all; instead, in the end it should look and be simple, and that can take a lot of hard work.] Then from the documentation get the really crucial stuff -- what the heck the code is to do. It is the documentation that makes clear the issues of threading, locking, roll back, exceptional condition handling from small scale to large, the UI/UX, etc. Those issues are to be clear in appropriate parts of the documentation and not to be worked out only during the coding. So, e.g., try to get most of the coding down to (a) allocate storage, (b) the usual control structures if-then-else, do-while, select-when, (c) call-return, (d) clear architecture on exceptional condition handling, logging, etc., and (e) the functions, classes, APIs, etc.
From what I learned from before the OP, although the OP has it better but maybe not as explicit, here are two lessons:
First Lesson.
"Why should I"? If you see a person in an organization and some work they might do, ideas they might have, etc. you have to ask the question, how will that person answer the question "Why should I". What's important here for a manager is not how YOU would answer this question but how you would anticipate that subordinate, other person, would answer the question. To be cynical, just because some area A is in the person's area of work, for some work X, will they actually do X and do it well? First way to know is, how would that person answer "Why should I do X"? To be cynical and likely often realistic, without a good answer, the person may simply neglect to do X.
E.g., there is the old Ross Perot joke: Most organizations, when they see a snake, form a committee on snakes. In a good organization, when someone sees a snake, they kill it. Well, then, the answer to "Why should I kill the snake" is that Perot had a good organization.
Second Lesson.
There is a field, with courses, in public administration, business schools, and parts of sociology called organizational behavior. There one of the better ideas is goal subordination. Well, the OP is awash in cases of goal subordination. The idea of goal subordination, and common for middle managers, is to "subordinate" the "goals" of the organization to the "goals" of that middle manager. So, the manager does what he believes is good for his career even if it is bad for the organization. So, an exercise is to read the OP essay and list and explain the places where the author is suggesting goal subordination.
There's much more to say, but, trust me, the OP is talking about stuff that is darned real.
For me, I want my startup to work. A big, huge advantage of being founder and 100% owner is that I don't have to explain stuff to some BoD that, as in the OP, has no chance of understanding reality. So, I'd constantly have to create "company theater" for the BoD, and that would be so wasteful it could kill my company.
My point here generalizes and is generalized in the OP: The crucial details of a serious real problem and its best solution are typically too difficult for communicating up a management chain or even just from a CEO to a BoD. The OP is correct. So, as sole founder and 100% owner, I don't have to try to communicate to a BoD that has no hope of understanding or waste effort on company theater. Instead, I just concentrate on making my company successful. If I am successful, then the main evidence visible externally will be just the financial, brand, etc. success, a lot of which the news media will likely heavily distort; the real reason the company was successful will be known just to me and maybe a COO or CTO if I get really good ones.
I'm a bit confused by the authors use of the words entropy and entropic, starting specifically with this point:
> Don’t let entropy get at your daily routine. Avoid entropy-driven work
In a physical sense, my understanding of entropy is that it's a degenerative phenomenon, a lowest common denominator - it doesn't create anything. This point means avoiding distracting or sporadic work, which is a test of discipline. But the rest of this point and others further down using words like 'entropy-driven' work are meaningless.
I'm sure there's a good point to be made here about valuable work in large corporations, but the (over)use of the word entropy has lost me.
> Don’t let entropy get at your daily routine. Avoid entropy-driven work
In a physical sense, my understanding of entropy is that it's a degenerative phenomenon, a lowest common denominator - it doesn't create anything. This point means avoiding distracting or sporadic work, which is a test of discipline. But the rest of this point and others further down using words like 'entropy-driven' work are meaningless.
I'm sure there's a good point to be made here about valuable work in large corporations, but the (over)use of the word entropy has lost me.
Entropy is the measure of disorder in a system, so my interpretation here was that you shouldn't take on work that was generated by organizational disorder. An example I have in mind is when someone on the product side asks for a new feature that you know wouldn't take much time at all. Even though you could knock it out quickly, the correct action is to have them go through proper feature request channels.
I get a lot of fulfillment out of knocking out quick features/bugs. Usually I just consider it my "10% time". Is that really a problem as long as I'm not chasing geese all the time?
Your example is right on the money. I used to be consumed by organizational disorder, and even worse, wasn't aware that it was happening. Agile is no magic solution but it can be a vehicle to creating organizational order if you need it, especially if it's a hot buzz word in your company.
Scrum, if you do it right, is precisely the solution. Scrum specifically rejects the idea of "just doing something on the side".
Unfortunately, most organizations believe in cults and magic, and believe (and act) that Scrum is a cargo cult where you say the magic words and hold the magic rituals and get the results.
Unfortunately, most organizations believe in cults and magic, and believe (and act) that Scrum is a cargo cult where you say the magic words and hold the magic rituals and get the results.
"When the plan is foggy, that’s the moment to communicate as broadly as possible."
Here's a good rule of thumb: Ask them to explain what has to be done, and then count the number of times they say "it should be pretty straightforward".
Consider those multipliers of complexity.
Here's a good rule of thumb: Ask them to explain what has to be done, and then count the number of times they say "it should be pretty straightforward".
Consider those multipliers of complexity.
I apply a similar algorithm, except I use the word "just" as variable. As in "we could just stick this in a DB", or "isn't it just about adding a checkbox to the page?"
Using Just and extremely easy should be where you make a milestone for each statement(s) after that .
Absolutely agree. I had come to the same conclusion about the same term. I had thought to call it "just-ifying", but then I remember that is already a real word.
Or measure how annoyed they are when you ask them to go into specifics about what they expect.
This. +500 The devil is always in the details something that sounds obvious but yet is hard to express clearly by PMs will def. be the thing that takes a while to implement (and more importantly to get all stake holders to agree on what "it" actually is)
Relevant XKCD [0].
Lots of topics vary wildly in complexity, depending on what's actually expected of the developer. For example, I could see how implementing an authentication system might take as little as a few hours to as much as a few months.
I think developers sometimes get overconfident when they can just reach for a library to do anything they need, so they underestimate the complexity of having to implement everything themselves. I've seen tons of great examples of this while doing frontend work. Need a typeahead component? Just pull in some plugin or library and wire it up, frontend development is so easy! But if you actually go implement your own you quickly realize there's lots of details to consider in order to make it accessible and user-friendly. Working with local data? Might want to go brush up on search algorithms. Throw in a bit of extra fun if you need to support multiple languages.
[0] https://xkcd.com/1425/
Lots of topics vary wildly in complexity, depending on what's actually expected of the developer. For example, I could see how implementing an authentication system might take as little as a few hours to as much as a few months.
I think developers sometimes get overconfident when they can just reach for a library to do anything they need, so they underestimate the complexity of having to implement everything themselves. I've seen tons of great examples of this while doing frontend work. Need a typeahead component? Just pull in some plugin or library and wire it up, frontend development is so easy! But if you actually go implement your own you quickly realize there's lots of details to consider in order to make it accessible and user-friendly. Working with local data? Might want to go brush up on search algorithms. Throw in a bit of extra fun if you need to support multiple languages.
[0] https://xkcd.com/1425/
There are some very rare cases where delivery date is more important than what you are delivering, but modern management seems to delight in generalizing this unusual occurrence to every situation. People do get promoted for having been able to deliver completely broken, useless and damaging solutions on time. If that’s the measure of project success you can expect dates to rule (even when they continuously slide). After all, if you are not a trained surgeon, and the only thing you are told is that a given surgery should last no more than X hours, guess what will be the one criterium for all your actions during the operation.
I love that metaphor.
I love that metaphor.
Where I work, we deliver on time. Customers schedule upgrades many months in advance, and in series or sync with other upgrades. They are on maintenance contracts to get the latest version.
If we deliver a broken product, than that is a failure to cut scope adequately. Do that once or twice and suffer through the consequences and you will learn not to let it happen again.
If we deliver a broken product, than that is a failure to cut scope adequately. Do that once or twice and suffer through the consequences and you will learn not to let it happen again.
Moving a feature into the next release cycle is equivalent to extending the deadline for that feature. You're right, though -- management does seem to have a strong preference for one terminology over the other.
That’s true, but if the product is big enough, with enough varying constituencies, then delivering something to a large chunk of those people on time is a lot better than delivering nothing to everybody on time.
I think there is a lot of "it depends" in here. If deployment is zero friction to the customer then maybe this applies. If deployment by customer is disrupting then forcing them to go through multiple release cycles due to bugs or lack of required features can be worse for them.
I just lived with a half-broken product for a year rather than deploy the more final full featured but less stable version multiple times from a vendor due to such deployment difficulty. I want quality and completeness over speed in that case.
I just lived with a half-broken product for a year rather than deploy the more final full featured but less stable version multiple times from a vendor due to such deployment difficulty. I want quality and completeness over speed in that case.
[deleted]
[deleted]
Yeah but not all things are like surgery. Often, « A good violent attack now is better than a perfect one next week » (George S. Patton)
That doesn't apply to software development unless you're a startup with limited funding and no positive cash flow. In the vast majority of cases, the software is already released and making money. Whether you finish the next release in 1 month or 2 is of no practical importance, except that it makes the manager look good. He can report a larger profit margin because the cost that went into that release is roughly half if it was released in 1 month rather than 2.
And therein lies the conflict that this post doesn't really address or resolve: there's rarely a discernible difference in revenue between a high quality release and a buggy, low quality release, but the profit margin of the former can be (and often is) much lower. A great real world example of this is PUBG.
And therein lies the conflict that this post doesn't really address or resolve: there's rarely a discernible difference in revenue between a high quality release and a buggy, low quality release, but the profit margin of the former can be (and often is) much lower. A great real world example of this is PUBG.
Since you picked a gaming example, I would like to present the idea that in gaming the opposite is true.
If you have a live game that you intend to last a long time, it’s extremely important to establish a reliable release cadence that the players can depend on.
Our company first released our game in 2012. After release we didn’t know how important this is. We just kinda made updates and released them when we finished them.
The player numbers never went above what we had at release. For a few years our numbers were pretty flat. We would have up releases and down releases but we never broke our initial numbers.
Then we changed to a cycle of having a release every 3 months.
This was a massive improvement. Most players won’t keep playing your game continuously forever, but if they always know that there will be a thing to come back for, and when that will be, they will stop playing before they are burned out with a plan to come back.
Suddenly our numbers grew with every release. Each 3 month cycle saw a large percentage increase over the previous one.
After a few years of that our game is massively larger than it was at release, and it’s still growing with each subsequent release.
I’m not saying that it’s okay to release a buggy game, you have to scope each release so that you can do it on time without being too buggy. What I am saying is that the release schedule is actually really really important.
If you have a live game that you intend to last a long time, it’s extremely important to establish a reliable release cadence that the players can depend on.
Our company first released our game in 2012. After release we didn’t know how important this is. We just kinda made updates and released them when we finished them.
The player numbers never went above what we had at release. For a few years our numbers were pretty flat. We would have up releases and down releases but we never broke our initial numbers.
Then we changed to a cycle of having a release every 3 months.
This was a massive improvement. Most players won’t keep playing your game continuously forever, but if they always know that there will be a thing to come back for, and when that will be, they will stop playing before they are burned out with a plan to come back.
Suddenly our numbers grew with every release. Each 3 month cycle saw a large percentage increase over the previous one.
After a few years of that our game is massively larger than it was at release, and it’s still growing with each subsequent release.
I’m not saying that it’s okay to release a buggy game, you have to scope each release so that you can do it on time without being too buggy. What I am saying is that the release schedule is actually really really important.
For context to other readers, Negitivefrags is talking about Path of Exile[0] and seems to be downplaying the success GGG has achieved in the last few years. The regular release of compelling content has driven PoE into a great position as the market leader for ARPGs.
One thing they didn't mention is that the regular release cycle lets you mess up and recover. For example, the Essence league(a 3 month batch of content) was underwhelming for most players. However, the Breach league following that regrew any goodwill that might've been lost.
[0] https://pathofexile.com
One thing they didn't mention is that the regular release cycle lets you mess up and recover. For example, the Essence league(a 3 month batch of content) was underwhelming for most players. However, the Breach league following that regrew any goodwill that might've been lost.
[0] https://pathofexile.com
> there's rarely a discernible difference in revenue between a high quality release and a buggy, low quality release, but the profit margin of the former can be (and often is) much lower.
A wonderful insight, thanks.
I guess that hints in a direction where "both are Right". For the technical teams, it's self-explanatory that "one does not simply push out crap". On the other hand, the MBAs and finance hear engineering say the same thing about mostly everything, and double profit margin is double profit margin, so the incentive structures that encourage faster releases probably seem completely plausible to them.
Not that things are that clear and clean in real life. But having drifted from pure engineering to engineering management during the years, I feel more and more sympathy towards some of the challenges of the "ugly and evil business side" by the year. Also, nothing is as hard as communication. Except trying to communicate goals with broad incentive structures, I guess.
A wonderful insight, thanks.
I guess that hints in a direction where "both are Right". For the technical teams, it's self-explanatory that "one does not simply push out crap". On the other hand, the MBAs and finance hear engineering say the same thing about mostly everything, and double profit margin is double profit margin, so the incentive structures that encourage faster releases probably seem completely plausible to them.
Not that things are that clear and clean in real life. But having drifted from pure engineering to engineering management during the years, I feel more and more sympathy towards some of the challenges of the "ugly and evil business side" by the year. Also, nothing is as hard as communication. Except trying to communicate goals with broad incentive structures, I guess.
> Whether you finish the next release in 1 month or 2 is of no practical importance, except that it makes the manager look good.
No, it also increases value to the customer, and therefore price. It also helps you stay ahead of the competition, also increasing price.
Can you elaborate on PUBG?
No, it also increases value to the customer, and therefore price. It also helps you stay ahead of the competition, also increasing price.
Can you elaborate on PUBG?
> it also increases value to the customer, and therefore price
Not always. Look at the most recent OS releases. Windows 8 and 10 had terrible adoption rates because they actually deliver a negative value for most users compared to what they already own (windows 7).
> It also helps you stay ahead of the competition, also increasing price.
Again, not always, for the same reasons mentioned above.
> Can you elaborate on PUBG?
From a technical point of view, PUBG is a train wreck. They had budgeted a 1 year development cycle, which for an online 3d FPS is ridiculously short. I think they initially launched it after a year and a half of development. But, from a sales point of view, PUBG has been very profitable. People are playing it despite the networking problems and relatively bad graphics because it fills a niche that hasn't been addressed by other game companies in years. But, there was no guarantee it would have been a hit. The condensed timeline and less than stellar graphics was their way of keeping development costs low. If the game hadn't been an instant hit, they could have still made a profit.
Not always. Look at the most recent OS releases. Windows 8 and 10 had terrible adoption rates because they actually deliver a negative value for most users compared to what they already own (windows 7).
> It also helps you stay ahead of the competition, also increasing price.
Again, not always, for the same reasons mentioned above.
> Can you elaborate on PUBG?
From a technical point of view, PUBG is a train wreck. They had budgeted a 1 year development cycle, which for an online 3d FPS is ridiculously short. I think they initially launched it after a year and a half of development. But, from a sales point of view, PUBG has been very profitable. People are playing it despite the networking problems and relatively bad graphics because it fills a niche that hasn't been addressed by other game companies in years. But, there was no guarantee it would have been a hit. The condensed timeline and less than stellar graphics was their way of keeping development costs low. If the game hadn't been an instant hit, they could have still made a profit.
PUBG is an example of how low quality releases can be profitable, not how "there's rarely a discernible difference in revenue between a high quality release and a buggy, low quality release"
Go back and read the sentence you quoted, in it's entirety.
> there's rarely a discernible difference in revenue between a high quality release and a buggy, low quality release, but the profit margin of the former can be (and often is) much lower.
I think you agree with the OP...
> there's rarely a discernible difference in revenue between a high quality release and a buggy, low quality release, but the profit margin of the former can be (and often is) much lower.
I think you agree with the OP...
No, I don't. I don't believe there's rarely a difference in revenue between a low quality release and a high quality release. Further, PUBG, at least as presented, doesn't support this assetion, since it doesn't show revenue failing to increase after a higher quality release.
[deleted]
>A great real world example of this is PUBG.
You mean, the bug-laden beta build they pushed out before Christmas and are selling for full price? Yes, I'm sure they made plenty of money, but they also hurt their reputation.
You mean, the bug-laden beta build they pushed out before Christmas and are selling for full price? Yes, I'm sure they made plenty of money, but they also hurt their reputation.
As long as you completely ignore the cost of technical debt and bug fixes, sure.
All projects have tech debt and bug fixes. If there was a surefire way of obliterating both of those things consistently, it would be an easy sell to management. But, because there isn't, they fall back on what they can measure: costs vs revenue.
"It is even better to act quickly and err than to hesitate until the time of action is past"
-- Carl von Clausewitz (On War?)
-- Carl von Clausewitz (On War?)
And, plenty of surgeries are done in situations where speed matters more than the quality of the surgery (emergency tracheotomy, amputation, etc.)
Speed never matters more than the quality of the surgery. You're conflating constraints and criteria. Speed is sometimes a constraint, but never a criteria.
But speed is a self-imposed constraint on most projects rather than a physical law, meaning it might be violated. Furthermore, there might be a smooth relationship between speed of execution and value returned (even outside of cost of production). So when evaluating how successful a project was (software, surgery, or otherwise), you often do want to use speed as a criterion, even if you initially thought of it as a sort of constraint for the sake of simplifying planning.
Constraints are criteria.
No they aren't. Constraints are necessary but not sufficient. Criteria are necessary and sufficient. In other words, necessity is a lower bound and sufficiency is an upper bound. Criteria is the upper bound, constraints are the lower bound.
[1] https://www.sfu.ca/~swartz/conditions1.htm
[1] https://www.sfu.ca/~swartz/conditions1.htm
You're also confusing an equality and a subset relationship.
No, they're not.
If you violate a constraint, delivery fails. If you pass it, delivery does not necessarily succeed.
If you fail to meet a criterion, delivery might fail. If you successfully meet all criteria, this is the definition of successful delivery.
Different places may assign different meanings to those terms in project-management speak, but those are the ones I've heard the most.
If you violate a constraint, delivery fails. If you pass it, delivery does not necessarily succeed.
If you fail to meet a criterion, delivery might fail. If you successfully meet all criteria, this is the definition of successful delivery.
Different places may assign different meanings to those terms in project-management speak, but those are the ones I've heard the most.
You're confusing an equality relationship and a subset relationship.
Patton's strategy was borrowed from his inspiration...Sherman. The goal was to make war intensely in order to end it quickly and let his soldiers return to their lives. Software development is not war.
It is, if you ask Ben Horowitz
Business often is, though.
Business never ends though. If you spend all your time making business intensely, you will burn everyone in your business out.
The metaphor extends further, actually. The "war" of business ends once a market consolidates.
Deadlines do matter in many situations. Like, for example, being able to announce a new product or feature at a conference with a fixed date. Or before a sales meeting with a new client, or before a yearly allocated budget expires, etc.
I have, however, also encountered arbitrary deadlines that people hang onto for no good reason.
I have, however, also encountered arbitrary deadlines that people hang onto for no good reason.
FYI - They use the same metaphor in Mythical Man Month and it's very apt.
> If you feel like you don’t know what you are doing it’s probably because you don’t know what you are doing and that’s bad.
I think this one depends on one's personality. I know people who have been relatively successful in their role for years who still regularly express impostor syndrome.
I think this one depends on one's personality. I know people who have been relatively successful in their role for years who still regularly express impostor syndrome.
[deleted]
> Incompetence is fiercely gregarious while knowledge is often fractious; the reason for this is that raw ideas transfer more easily through untrained minds than refined ideas transfer through trained minds.
This resonated with me and definitely gave me food for thought. Raw ideas with uninformed opinions can easily percolate throughout organizations and even across the industry. Feels like something we as a society need to more actively guard against.
This resonated with me and definitely gave me food for thought. Raw ideas with uninformed opinions can easily percolate throughout organizations and even across the industry. Feels like something we as a society need to more actively guard against.
I think this explains a great deal and was a concept I had been mulling over myself recently: basically there's an asymmetry in clueffulness that works to propagate cap around much more widely than you'd expect.
OT, but: funny, I felt the name was familiar, and turns out I commented on a post on this blog 12 years ago[0].
A reading lost due to the death of google reader, I presume.
[0] How time flies! https://minnenratta.wordpress.com/2005/12/23/le-proporzioni-...
[0] How time flies! https://minnenratta.wordpress.com/2005/12/23/le-proporzioni-...
> Teams don’t self-organize unless you organize them to do so.
...or, teams self-organize unless you have organized them not to, in which case, if you want them to self-organize, you have to hire an Agile coach and start putting up posters telling people what it means to be "self directed" and fire everyone who is insufficiently short-term in their thinking.
/s
...or, teams self-organize unless you have organized them not to, in which case, if you want them to self-organize, you have to hire an Agile coach and start putting up posters telling people what it means to be "self directed" and fire everyone who is insufficiently short-term in their thinking.
/s
Nitpicking.
> 20. The Sith are right, rage propels. But the Jedi are right, you must not let it control yourself. What nobody tells you is that the rage game is intrinsically tiring and rage will take control as soon as you get too tired, so stop well before.
37. Don't assume everyone reading your article gets the Star Wars reference.
> 20. The Sith are right, rage propels. But the Jedi are right, you must not let it control yourself. What nobody tells you is that the rage game is intrinsically tiring and rage will take control as soon as you get too tired, so stop well before.
37. Don't assume everyone reading your article gets the Star Wars reference.
Speaking as someone that has never seen Star Wars, I still get his point.
Teams don’t self-organize unless you organize them to do so.
Interesting. I wish there was a bit more detail on how you organize them to do so...
Interesting. I wish there was a bit more detail on how you organize them to do so...
Seating arrangements. Be it putting people who work well together in adjacent offices, or on adjacent tables.
Giving people freedom and allowance for failure, not having a strict "I am the boss" micromanaging hierarchy on the team.
Reward people for taking initiative. Find work that people want to do, and give them time to do it on their own but only if they self organize all of it, this builds necessary skills.
Taking someone who looks like they may have leadership potential aside and asking them to take on a small feature.
Combine all these together and you'll come in one day and find your team in a huddle tackling tasks together.
Requirements: Not being an insecure manager. Knowing that your value to the team and org is not in telling people what to do, but rather in helping them do what needs to be done. Sometimes this means communicating directives from on high, other times it means getting the team the resources that they've determined they need.
Giving people freedom and allowance for failure, not having a strict "I am the boss" micromanaging hierarchy on the team.
Reward people for taking initiative. Find work that people want to do, and give them time to do it on their own but only if they self organize all of it, this builds necessary skills.
Taking someone who looks like they may have leadership potential aside and asking them to take on a small feature.
Combine all these together and you'll come in one day and find your team in a huddle tackling tasks together.
Requirements: Not being an insecure manager. Knowing that your value to the team and org is not in telling people what to do, but rather in helping them do what needs to be done. Sometimes this means communicating directives from on high, other times it means getting the team the resources that they've determined they need.
Have you read Peopleware ? There's some good gems there
Most people are commenting on what bullet points they agreed or disagreed most with. I am sure, however, that there are other software engineering leads on HN --- what other lessons have you learned, and/or what were the best resources to learn them (if not just experience).
I have to disagree slightly on the paragraph about dates (#32). Engineers leaders cannot dismiss dates as one of the metric of their performances. The metric is not the goal nor the means in itself, though. In my view, entropic organization and management make this mistake constantly of confusing the metric with the job, like driving a car looking at the speed meter and not at the road (sounds absurd, I know, but is really what happens).
Agree. Dates are good for limiting scope. Without that constraint, it is usually very hard to set boundaries as to what should and what shouldn't go into a project. There is also validity to the notion that time is money. Eventually, we'll all be lying in our graves.
But yes - for measuring success, it's a terrible metric. One should prefer a project to be delayed, but proper, than delivered on time, but broken.
But yes - for measuring success, it's a terrible metric. One should prefer a project to be delayed, but proper, than delivered on time, but broken.
For a competent team, arbitrary dates, generally leaving not enough time, only serve to limit scope. A competent team will produce as fast as is possible, given a specified scope.
Right. I wish more managers/coaches/masters understood this.
Features are done when they're done (for a given definition of "done"). Once we're satisfied with what we have, we release it. Otherwise we keep working, or we scope down.
Strict deadlines are seemingly based on financial period expectations, rather than on what actually produces better software, and thus, ironically, more revenue for the same stockholders who were demanding a date. It seems more of a short-term strategy than long-term.
Anyway, that's my pessimistic, armchair interpretation of it.
Features are done when they're done (for a given definition of "done"). Once we're satisfied with what we have, we release it. Otherwise we keep working, or we scope down.
Strict deadlines are seemingly based on financial period expectations, rather than on what actually produces better software, and thus, ironically, more revenue for the same stockholders who were demanding a date. It seems more of a short-term strategy than long-term.
Anyway, that's my pessimistic, armchair interpretation of it.
I seem to recall a quote about "works expands to full available time".
I know you specifically say "for a competent team", but I just wanted to mention that for a lot of teams, the quote above is absolutely true.
I know you specifically say "for a competent team", but I just wanted to mention that for a lot of teams, the quote above is absolutely true.
I have to completely agree with that paragraph. As long as we are talking about metrics, impact is the one to measure.
Ok, if you already are measuring impact and has a correct prioritization of it above anything else, adding delivery date and time spent won't hurt. But if you don't prioritize it above anything else, you are simply begging for a huge failure.
Ok, if you already are measuring impact and has a correct prioritization of it above anything else, adding delivery date and time spent won't hurt. But if you don't prioritize it above anything else, you are simply begging for a huge failure.
Favorite quote:
> Delivery dates have often irrelevant but very simple to understand impacts. Good and bad solutions have dramatic but very difficult to understand impacts.
> Delivery dates have often irrelevant but very simple to understand impacts. Good and bad solutions have dramatic but very difficult to understand impacts.
Nice list, although I was horrified by one (sorry to need to pick on the one thing that was bad):
>Being overworked is not a good reason to hire. Instead, hire to be ready to catch opportunities, not to survive the current battles.
That's why we as programmers should say no to overwork, because only then will they see the need to hire. I only do overwork when some unexpected disaster happens, or when there is a sudden huge opportunity. In the other cases, they should plan better or hire more people, simple as that.
>Being overworked is not a good reason to hire. Instead, hire to be ready to catch opportunities, not to survive the current battles.
That's why we as programmers should say no to overwork, because only then will they see the need to hire. I only do overwork when some unexpected disaster happens, or when there is a sudden huge opportunity. In the other cases, they should plan better or hire more people, simple as that.
> 24. Don’t let entropy get at your daily routine. Avoid entropy-driven work.
Your anecdote is rule 24 in practice. Good job.
Your anecdote is rule 24 in practice. Good job.
"Being overworked is not a good reason to hire."
Because the world certainly needs more sociopathic management advice.
Because the world certainly needs more sociopathic management advice.
The way I understood this:
"If you are overworked, first look at your team, is everyone at their place and pulling their weight, evaluate your deadlines and promises, check your planning and management and your relationship with stakeholders. Because most of the times it's one of those things that's broken and probably affects the rest".
Theoretically, it might not be a good reason to hire. Maybe the problem is bad planning or project management. Hiring more people won't really solve that.
But, in general, I agree with you.
But, in general, I agree with you.
That's your (negative) take on it. You can do something about being overworked without hiring (evaluate deadlines and scope, learn to say no). There's a good chance that hiring people without establishing the underlying cause of "being overworked" will only lead to more people being overworked. If you're hiring because of "being overworked", you're hiring too late.
All of the comments about entropic organizations ring true and hit close to home. Way too close to home.
The idea that entropy works on the direction of "hard work -> easy work", instead of "complex work -> simple work" or even "more work -> less work" is a great insight.
Could you please elaborate on this?
The articles has some examples on the difficult -> easy propagation. Like discovering what a company does well and creating a vision that uses it is difficult; joining all current projects and creating a slogan that fits them all to use as a vision is easy. Measuring impact is difficult; setting and measuring deadlines is easy.
There is more there. I leads to an "I know it when I see it" understanding. If I tried to compress it into a definition I would certainly miss lots of relevant details, at least without refining it for some time, so I won't.
There is more there. I leads to an "I know it when I see it" understanding. If I tried to compress it into a definition I would certainly miss lots of relevant details, at least without refining it for some time, so I won't.
Thing one: use "learnt" instead of "learned" to sound multinational. ;)
So it is true Americans don't use past participles?
At least in this case yes. For us the past participle would simply be "learned"
>Mass emails and top-down communication are not taboo: just because most such communications are irrelevant it doesn’t mean yours will be perceived as such.
Mine are always perceived as such :-(
Mine are always perceived as such :-(
Have you considered studying how you communicate? There was something on HN recently titled How to write emails like a CEO (or similar).
I studied my old CEO's communication style, holding it up against how many of my peers communicated. I noticed that he got right to the point, expecting other people to assume he considered multiple ancillary points. My (lower status) peers' emails would meander, and read like they wanted to show their superiors how good/smart they were at their job, and that they thought of every last thing.
The high status person didn't feel the need to pre-emptively brain dump.
My larger point is if your emails are perceived in such a way, it's worth improving.
I studied my old CEO's communication style, holding it up against how many of my peers communicated. I noticed that he got right to the point, expecting other people to assume he considered multiple ancillary points. My (lower status) peers' emails would meander, and read like they wanted to show their superiors how good/smart they were at their job, and that they thought of every last thing.
The high status person didn't feel the need to pre-emptively brain dump.
My larger point is if your emails are perceived in such a way, it's worth improving.
Along similar lines: I often write an e-mail with all of the information I want to include, and read it over and edit it several times to cut down on things that aren't necessary. The unnecessary things can be as simple as an awkward prepositional phrase, but often they are a technicality that is hogging too much space in the e-mail.
I personally think this really improves my communication. In a workplace where people are expected to read through dozens of emails each day, it makes a difference in the information that's finally conveyed to my colleagues, which is often what matters the most to me.
I personally think this really improves my communication. In a workplace where people are expected to read through dozens of emails each day, it makes a difference in the information that's finally conveyed to my colleagues, which is often what matters the most to me.
Great point. I wonder how often people shoot emails out without serious editing.
>My (lower status) peers' emails would meander, and read like they wanted to show their superiors how good/smart they were at their job, and that they thought of every last thing.
The last part is key. If I don't list the things I've thought off, and write a briefer email, I guarantee I will get any of the following:
1. Followup emails with questions because they don't understand.
2. Emails of the type "Did you consider...?". This is the primary reason my emails can be lengthy, so that I can list all the things I considered so that I don't get questions asking about them.
3. Even worse, people not emailing me, but with them misunderstanding and doing the wrong thing, and then saying "Well I thought you meant..." leading me to ask "Where in my email did you get the idea that...?"
Do note that I'm not in a "superior" position. These are mostly emails to peers.
The last part is key. If I don't list the things I've thought off, and write a briefer email, I guarantee I will get any of the following:
1. Followup emails with questions because they don't understand.
2. Emails of the type "Did you consider...?". This is the primary reason my emails can be lengthy, so that I can list all the things I considered so that I don't get questions asking about them.
3. Even worse, people not emailing me, but with them misunderstanding and doing the wrong thing, and then saying "Well I thought you meant..." leading me to ask "Where in my email did you get the idea that...?"
Do note that I'm not in a "superior" position. These are mostly emails to peers.
Why send email at all? The only times I use email is when:
- I need to formalize something everybody already agreed to (record keeping)
- The content of the message is not all that important
Perhaps your organization is different, but usually your communications end with email, they don't start with it. Talk to people in private, give them a call, etc.
- I need to formalize something everybody already agreed to (record keeping)
- The content of the message is not all that important
Perhaps your organization is different, but usually your communications end with email, they don't start with it. Talk to people in private, give them a call, etc.
>Why send email at all?
- Old bug tracking system going away and how to use the new one
- New feature added to the testing infrastructure and how to use it
- Changes that affect the build system - requiring people to update their paths, etc.
- Weird bug I'm trying to debug (listing all approaches I've tried so far) (usually sent after consulting one or two people privately and getting nowhere).
>Talk to people in private, give them a call, etc.
This doesn't apply to any of the above. Usually my longer emails are for things everyone in the team needs to know.
What usually happens is:
1. Either the person did not read the email at all and start asking everyone for help when things don't work.
2. They read the email, but did not encounter the problem until a week later. Instead of trying to find the email and reading it, they just go to the author. Thus, the author has to explain things about 5 times (first time in the email, and the remaining 4 to people who did not want to read the email).
Granted, I could have put the information on the wiki and just sent a brief email with a link to the wiki page, but then I'll get people coming to me asking "Hey can you send me the wiki link again?" because they cannot figure out what to search for.
In general, people would rather talk than read. Even technical people. The primary reason people do not read my emails is that I am accessible. They would rather come to my cube, call me or IM me than read an email. This is why I put a minor barrier to reaching me: I'm usually not on IM. My next step will probably be to ask my manager to put my cube on the opposite end of the floor as the rest of my team. If I succeed, I'm sure the rate at which people read my emails will go up a lot. It's not a long walk, but that extra bit of effort will cause most people to try more options before walking.
- Old bug tracking system going away and how to use the new one
- New feature added to the testing infrastructure and how to use it
- Changes that affect the build system - requiring people to update their paths, etc.
- Weird bug I'm trying to debug (listing all approaches I've tried so far) (usually sent after consulting one or two people privately and getting nowhere).
>Talk to people in private, give them a call, etc.
This doesn't apply to any of the above. Usually my longer emails are for things everyone in the team needs to know.
What usually happens is:
1. Either the person did not read the email at all and start asking everyone for help when things don't work.
2. They read the email, but did not encounter the problem until a week later. Instead of trying to find the email and reading it, they just go to the author. Thus, the author has to explain things about 5 times (first time in the email, and the remaining 4 to people who did not want to read the email).
Granted, I could have put the information on the wiki and just sent a brief email with a link to the wiki page, but then I'll get people coming to me asking "Hey can you send me the wiki link again?" because they cannot figure out what to search for.
In general, people would rather talk than read. Even technical people. The primary reason people do not read my emails is that I am accessible. They would rather come to my cube, call me or IM me than read an email. This is why I put a minor barrier to reaching me: I'm usually not on IM. My next step will probably be to ask my manager to put my cube on the opposite end of the floor as the rest of my team. If I succeed, I'm sure the rate at which people read my emails will go up a lot. It's not a long walk, but that extra bit of effort will cause most people to try more options before walking.
[deleted]
>>Construction work is not a good metaphor for software/product development. Factory work neither.
I like this, really fed up with everyone comparing software development with construction work and/or building a house. Don't compare those, apples to oranges. Sure, borrow the best, most appropriate things, techniques, methodologies, approaches and not just from construction. Just don't compare.
I like this, really fed up with everyone comparing software development with construction work and/or building a house. Don't compare those, apples to oranges. Sure, borrow the best, most appropriate things, techniques, methodologies, approaches and not just from construction. Just don't compare.
Avoid metaphors in general. In my experience, metaphors lead to discussion about the correctness of the metaphor instead of the subject the metaphor was referring to. This is a waste of time.
Interestingly he (she?) seems confused and rage driven (!) over entropic organisations - i think the main issue with entropic organisations is simply size - there is no organisational approach that can ever make hundreds of thousands of people co-ordinate in a positive manner.
we don't lack the technology, just that there is no good strategy at that level.
we don't lack the technology, just that there is no good strategy at that level.
Fire people whenever you can. There’s often someone to fire, but not many opportunities to do so. When you are given a lot of opportunities to fire people
I like this. Put another way "we are a team not a family."
https://www.slideshare.net/reed2001/culture-1798664
I like this. Put another way "we are a team not a family."
https://www.slideshare.net/reed2001/culture-1798664
That may sound nice to some people on paper, but the reality is that it creates a negative feedback loop. Consider the following review of the company from a senior software engineer. This review is not unique in its opinion:
I worked at Netflix full-time (More than 3 years)
Pros
They pay a ridiculous amount of money.
Cons
Horrible culture, everyone is afraid they will get fired any second. People hire their own friends/groups or people with less skills/experience so they can defend themselves against weaker employees and throw them under the bus. Lord help you if you don't know anyone when you get hired to form a posse' with.
Advice to Management
Stop with all your nonsense pitch deck, it's dated, old and you aren't hired the best talent away from Google, FB, Amazon....the sooner you realize you are just a content company, and maybe pay reasonable salaries with reasonable fostering environment the better. Just ask yourself: how many employees would leave if you cut their salary. Probably every one.
I worked at Netflix full-time (More than 3 years)
Pros
They pay a ridiculous amount of money.
Cons
Horrible culture, everyone is afraid they will get fired any second. People hire their own friends/groups or people with less skills/experience so they can defend themselves against weaker employees and throw them under the bus. Lord help you if you don't know anyone when you get hired to form a posse' with.
Advice to Management
Stop with all your nonsense pitch deck, it's dated, old and you aren't hired the best talent away from Google, FB, Amazon....the sooner you realize you are just a content company, and maybe pay reasonable salaries with reasonable fostering environment the better. Just ask yourself: how many employees would leave if you cut their salary. Probably every one.
Above I mentioned "goal subordination" and claimed that there were good examples suggested in the OP. Well here
> Horrible culture, everyone is afraid they will get fired any second. People hire their own friends/groups or people with less skills/experience so they can defend themselves against weaker employees and throw them under the bus. Lord help you if you don't know anyone when you get hired to form a posse' with.
Classic goal subordination.
> Horrible culture, everyone is afraid they will get fired any second. People hire their own friends/groups or people with less skills/experience so they can defend themselves against weaker employees and throw them under the bus. Lord help you if you don't know anyone when you get hired to form a posse' with.
Classic goal subordination.
Company talk about "we are a family" is a red flag for a work environment where people may be pressured to work overtime ("it's more than a job; we're family.") or overlook inappropriate behavior ("that's just how Bob is; we can't fire him because family has got to stick together."). People on a team don't need to be "family" to be respectful and supportive of each other.
Companies like Netflix have the cachet and can retain people despite an anti-worker culture. It's also a self selecting group of over-achievers who may like the environment.
I'd argue most above average but not stellar workers would not put up with Netflix's implicit demands.
I'd argue most above average but not stellar workers would not put up with Netflix's implicit demands.
It doesn't necessarily self-select for over achievers. It could very well self-select for people who don't recognize their own (flawed, not empirically justified) biases with regards to what "high performance" means. Most of that Netflix deck is the same kind of vague "we hire only the best" and "our values are (list of over-broad, meaningless but impressive looking jargon)" expressed in different words.
I would gladly work for a place like Netflix for a year or two, bust my butt, put it on my resume and move on. My market value would make it well worth it.
Having worked at a “name” company is not the big boost to your value lots of people think it is. That’s a lie that those big companies use to get people to accept bad working conditions.
You can't just "work" at the company, you have to produce.
There was an anecdote about Netflix about how a group of engineers who were top performers were let go after they did their part in transistioning Netflix's data center to AWS.
So should we feel bad for the people that got laid off? They will be some of the most sought after people in the industry.
There was an anecdote about Netflix about how a group of engineers who were top performers were let go after they did their part in transistioning Netflix's data center to AWS.
So should we feel bad for the people that got laid off? They will be some of the most sought after people in the industry.
That's exactly it. And the thing is no matter where you worked, if you did great things and have great skills, you're going to get opportunities and recognition. If you don't have the skills and don't do the work, it doesn't matter where you filled a seat.
In my experience the HR people think more highly of resumes when a big-name company is on them. Maybe they shouldn't, but they do.
HR people have to market candidates internally, many times to hiring managers who tell their bosses “Your recruiters don’t bring me quality candidates.” To protect themselves, the recruiters go after brand names. (“Is it my fault they didn’t like someone from Cornell who worked at Google?”)
The reality is this is suboptimal for the company, but can still be rational for HR.
The reality is this is suboptimal for the company, but can still be rational for HR.
Is it really sub-optimal for the company? Consider that the goal of HR is not to hire the best, but to avoid hiring the worst.
I'm no different as an an architect. I don't always choose the best technology. I sometimes choose the most popular. The practical reason being its easier to find people who know it and there is plenty of documentation. The CYA reason is that if things go south, It's much easier to say it came highly reccomended. "No one ever got fired for buying IBM."
Right, but look who is stuck with IBM technology now.
It was an analogy. But, you'd be surprised.
https://www.serverwatch.com/server-news/ibm-mainframe-revenu...
https://www.serverwatch.com/server-news/ibm-mainframe-revenu...
It’s not the revenue that I’m knocking. It’s being stuck with obsolete legacy technology that you can’t get rid of. Better things are out there but you are stuck because someone else made a decision that wouldn’t get them fired. (I’m at a place that is going through the painful process of showing IBM the door)
Word of caution from doing exactly that: you're signalling to future employers that that's who you are now, and forever. It's a pathway to burnout if you're not careful.
As a long time employee and employer in this industry all it signals to me and people like me is that you managed to survive that environment for two years. The name brand on the resume -is- worth something. Maybe more than it ‘should’ be, but that’s reality. Work at Google for two years and I mostly know you got through a Google interview and you can probably code. Work at Yahoo for 10 years and I know you’re good at politics. Etc. ;)
There's something depressing about your comment that screams dystopic to me. You're effectively reducing someone's hard work down to notches on a belt. I realize why you do it, but it still rubs me the wrong way.
What a boring future we live in. :)
What a boring future we live in. :)
When I compare opportunities for mobility that we have as developers, I'm grateful for the industry. I can't imagine being "stuck" at a job I don't like. In the last 20 years it's only taken a month to find a new job once I started looking. One time, I quit a job on Monday without any job in the pipeline, I hadn't interviewed with anyone when I quit and by that Thursday, I received an offer from what was then one of the 10 most valuable companies in the U.S. (not a tech firm) making 10K more.
I'm not claiming to be a special snowflake. I'm just a regular old "Enterprise Developer".
But the thought of working 30 years at one company and receiving a pension, horrifies me.
Just like we are just "resources" to an employer, they are just resources for us to make money. No loyalty either way, no expectations.
They give me a paycheck every two weeks and I work hard and do my best work for those two weeks. Nothing more, nothing less.
I'm not claiming to be a special snowflake. I'm just a regular old "Enterprise Developer".
But the thought of working 30 years at one company and receiving a pension, horrifies me.
Just like we are just "resources" to an employer, they are just resources for us to make money. No loyalty either way, no expectations.
They give me a paycheck every two weeks and I work hard and do my best work for those two weeks. Nothing more, nothing less.
Thank you for your candidness. Your experience matches my own. It's a bittersweet grace, I suppose.
That said, I come from an area where for whatever reason, there was a large population of undocumented or otherwise illegal immigrants. One of my good friends, then and still, was able to get a work permit through deferred action. Her experience transitioning into a legal workforce has been nothing but depressive frustration to the exploitative and apathetic practices that her employers are able and willing to get away with. We both agree that the same practices happen in and out of tech.
While her struggle is strong and her ambition gets around a lot of niggling motivation problems. I can't say the same for many of my other friends in the same situation whose lives are irrecoverably fucked before being adults, despite their bleeding passion for what they do and care for.
Point is - peoples' lives are complicated and others' apathy only makes it worse. Your paycheck every two weeks and the decisions that follow can make or break a person's life. Please grow some empathetic balls, consider the power you have over others and try to look past lines on resumes and try to see the person behind it. "That's life" is not an excuse for your selfishness.
Thank you.
That said, I come from an area where for whatever reason, there was a large population of undocumented or otherwise illegal immigrants. One of my good friends, then and still, was able to get a work permit through deferred action. Her experience transitioning into a legal workforce has been nothing but depressive frustration to the exploitative and apathetic practices that her employers are able and willing to get away with. We both agree that the same practices happen in and out of tech.
While her struggle is strong and her ambition gets around a lot of niggling motivation problems. I can't say the same for many of my other friends in the same situation whose lives are irrecoverably fucked before being adults, despite their bleeding passion for what they do and care for.
Point is - peoples' lives are complicated and others' apathy only makes it worse. Your paycheck every two weeks and the decisions that follow can make or break a person's life. Please grow some empathetic balls, consider the power you have over others and try to look past lines on resumes and try to see the person behind it. "That's life" is not an excuse for your selfishness.
Thank you.
I hate to say this but I have mixed feelings.
From a personal standpoint, I always put family first and will go to bat with my manager all the way up to chain for anyone who has personal obligations that reports to me.
On the other hand, technology is more black and white. I don't expect anyone to know everything but I do expect a certain level of competence and being able to work independently based on your hired skill level - especially for contractors.
When I'm hiring contractors, I don't expect to have to handhold, mentor, etc. I'm not making a long term investment in them and they are getting a premium for it.
I don't see myself any differently. If I'm applying for a contract job, I know 90% of the job requirements. If I'm going in as a permsnent employee, I'll try to squeeze in with 50-70% of the requirements and bust my butt to get up to 90% proficiency.
From a personal standpoint, I always put family first and will go to bat with my manager all the way up to chain for anyone who has personal obligations that reports to me.
On the other hand, technology is more black and white. I don't expect anyone to know everything but I do expect a certain level of competence and being able to work independently based on your hired skill level - especially for contractors.
When I'm hiring contractors, I don't expect to have to handhold, mentor, etc. I'm not making a long term investment in them and they are getting a premium for it.
I don't see myself any differently. If I'm applying for a contract job, I know 90% of the job requirements. If I'm going in as a permsnent employee, I'll try to squeeze in with 50-70% of the requirements and bust my butt to get up to 90% proficiency.
If companies don't want good developers to jump ship, it's simple. Pay them market value and keep paying them market value not 2-3% wages when they know if the employee leaves, they are going to have to pay market value and they are going to lose the person with institutional knowledge.
Why work for a company that you wouldn’t like to work for for those 2 years rather than work for the company you want for the same time period and gain seniority?
What does "seniority" buy you as a software developer? I stayed at one company for 9 years and between bonuses being cut and 3% raises my pay at year 9 was only 8K more than year 2. Over the next 9 years and 4 companies, I'm making $70k more. This isn't anecdotal:
http://www.forbes.com/sites/cameronkeng/2014/06/22/employees...
There is a term for it "pay compression"
https://definitions.uslegal.com/p/pay-compression/
http://www.forbes.com/sites/cameronkeng/2014/06/22/employees...
There is a term for it "pay compression"
https://definitions.uslegal.com/p/pay-compression/
That’s true nearly anywhere your strongest negotiation position is during pre-employment.
But money isn’t everything and those pay rises suck I get 5-6% p/a without asking, must have been a heck of a bonus cut then.
But money isn’t everything and those pay rises suck I get 5-6% p/a without asking, must have been a heck of a bonus cut then.
This was between 1999 - 2008. Our quarterly bonuses started out at 20% and the yearly raises were 3%.
But even at 5-6% raises, that doesn't compare to the roughly 11% "raises" I've received by jumping jobs 4 times since 2008.
As far as money isn't everything. Yes there is a trade off between how much I'm willing to accept and commute times. All in all, the only reason I go to work every day is for the compensation.
As far as I can tell, the gravy train is over as far as being able to make 10K to 20K+ to switch jobs if I still want to be an active developer and I'm not willing to relocate. I'm okay with that. Now the criteria for jobs are what new skills I can learn, comparable compensation, new challenges, and work life balance including the commute and work for home opportunities.
But even at 5-6% raises, that doesn't compare to the roughly 11% "raises" I've received by jumping jobs 4 times since 2008.
As far as money isn't everything. Yes there is a trade off between how much I'm willing to accept and commute times. All in all, the only reason I go to work every day is for the compensation.
As far as I can tell, the gravy train is over as far as being able to make 10K to 20K+ to switch jobs if I still want to be an active developer and I'm not willing to relocate. I'm okay with that. Now the criteria for jobs are what new skills I can learn, comparable compensation, new challenges, and work life balance including the commute and work for home opportunities.
I'm not surprised. As far as I'm aware, larger companies don't top up your on-hire stock award once it has fully vested.
parent didn't say s/he wouldn't want to work for Netflix. just sayin'
[deleted]
If a company has to constantly fire a lot of people - supposedly for not performing well enough - then the company might want to investigate why it's so bad at making people reach their potential.
Note: a constantly looming threat of being fired might be involved in it too.
Note: a constantly looming threat of being fired might be involved in it too.
Unfortunately, "fire fast" is now known widely enough to become a business fad / cargo cult. Which means, people are going to do it because it's the thing to do, and not because there's a good business reason to do it.
As a consequence, a company could strategically use "fire fast" by claiming it as a policy but not doing it. This would attract the people who perceive themselves as high performers, with minimal impact on employee morale.
As a consequence, a company could strategically use "fire fast" by claiming it as a policy but not doing it. This would attract the people who perceive themselves as high performers, with minimal impact on employee morale.
This is true. Sometimes you have to let go of problem employees, but this should really be a last resort. Fire fast doesn't take into multiple considerations, such as the amount domain knowledge does this person possesses. If the person you want to get rid of has been there for 5 years, and knows certain systems in and out it may not be so easy to replace them.
Constant firing can also negatively affect your personal reputation. As a manager your job is to get people to succeed. Firing someone means that ultimately you failed in that. Sometimes this is unavoidable; there are times when people just aren't redeemable. Sometimes it's not. Good managers know the difference, but you have to remember that every time you let someone go for cause, that person probably didn't see it that way. That person has friends who work other places and all of them have a long memory. If word gets out that you quickly remove people who you can't seem to handle, people will want to stop working for you.
Constant firing can also negatively affect your personal reputation. As a manager your job is to get people to succeed. Firing someone means that ultimately you failed in that. Sometimes this is unavoidable; there are times when people just aren't redeemable. Sometimes it's not. Good managers know the difference, but you have to remember that every time you let someone go for cause, that person probably didn't see it that way. That person has friends who work other places and all of them have a long memory. If word gets out that you quickly remove people who you can't seem to handle, people will want to stop working for you.
If the person you want to get rid of has been there for 5 years, and knows certain systems in and out it may not be so easy to replace them.
One of the biggest mistakes a company can make is keeping a toxic employee around because of their domain knowledge. The company I mentioned that I worked for for 9 years made that mistake. The employee had plenty of domain knowledge but was toxic, insubordinate, and displayed a poor work ethic. I know they had to be glad when that employee left on his own accord.
That employee was me. I look back on those days in horror.
One of the biggest mistakes a company can make is keeping a toxic employee around because of their domain knowledge. The company I mentioned that I worked for for 9 years made that mistake. The employee had plenty of domain knowledge but was toxic, insubordinate, and displayed a poor work ethic. I know they had to be glad when that employee left on his own accord.
That employee was me. I look back on those days in horror.
I've only had a couple of longer term jobs, but at both employers, I noticed that the lowest level workers had a comprehensive oral history of every firing and interesting HR incident that had ever occurred, like an Icelandic saga. And of course it was told from their point of view. So you have to be aware that every firing will be remembered, you will never handle it perfectly, and you don't control the story. A firing has to be worth that price. That's a high bar.
I've learned a really, really bitter lesson in life about people. When I was about 23, I did have a good view of people although not supported with much data. Soon, I guessed that my view was wrong. Nope, I had been right. Net, after a lot struggle, I concluded, about people, in a nutshell:
There are a lot of seriously hurt, confused, uninformed, misinformed, damaged, hurting people out there who are so badly lost they are seriously constrained in what they can do.
Now, to be more clear, where they are constrained can be quite narrow and not broad. So, day in and day out, they can look fine. But for some real work in some well defined context, they can flop -- really be just unable to perform. Again, this can be tough to see without a lot of experience with them.
So, for firing, if you have a person who seems okay or even good in many ways but, still, somehow just can't do the job, with explanations, help, training, discussions, counseling, guidance, leadership, etc., then don't (A) be too surprised, (B) blame yourself or say that the fault is that of the organization, (C) conclude that you should try one more effort to fix the problem, (D) conclude that, of course, you should be able to fix the problem, etc.
Maybe reassign them to some work they can do, if can find that -- and sometimes it's possible.
Otherwise, just go ahead and conclude that they are unable to do the work, at least any of the work you have for them to do; don't be too surprised at this situation or conclusion; and let them go. Give them back to their families, the mental health community, the welfare system, or some such.
The big point is: Such broken people are surprisingly common.
For one level deeper, an explanation can be that their problems are not really cognitive or rational but emotional. And the main emotions can be fears, commonly from their being misinformed, uninformed, having had bad experiences, confused from what they have been through, etc.
There are a lot of seriously hurt, confused, uninformed, misinformed, damaged, hurting people out there who are so badly lost they are seriously constrained in what they can do.
Now, to be more clear, where they are constrained can be quite narrow and not broad. So, day in and day out, they can look fine. But for some real work in some well defined context, they can flop -- really be just unable to perform. Again, this can be tough to see without a lot of experience with them.
So, for firing, if you have a person who seems okay or even good in many ways but, still, somehow just can't do the job, with explanations, help, training, discussions, counseling, guidance, leadership, etc., then don't (A) be too surprised, (B) blame yourself or say that the fault is that of the organization, (C) conclude that you should try one more effort to fix the problem, (D) conclude that, of course, you should be able to fix the problem, etc.
Maybe reassign them to some work they can do, if can find that -- and sometimes it's possible.
Otherwise, just go ahead and conclude that they are unable to do the work, at least any of the work you have for them to do; don't be too surprised at this situation or conclusion; and let them go. Give them back to their families, the mental health community, the welfare system, or some such.
The big point is: Such broken people are surprisingly common.
For one level deeper, an explanation can be that their problems are not really cognitive or rational but emotional. And the main emotions can be fears, commonly from their being misinformed, uninformed, having had bad experiences, confused from what they have been through, etc.
I think that's reasonable, with the proviso that you could fire that employee with a tolerable effect on employee morale if you haven't already used up all of your "credits" on a policy of routine firings.
You have to be careful. I am currently in an org that has embraced this philosophy. Instead of making the survivors feel valued, it has motivated most of them to move into more stable environments. These employees have dependents and don't like the idea of having their health insurance in play on a daily basis.
People read Glassdoor. If your company earns a rep for rapidly and casually dismissing people, you will see good resumes dry up. In our case, the quality of candidates has nosedived. It's not clear why a strong candidate would join a company that opts to fire people so casually.
People read Glassdoor. If your company earns a rep for rapidly and casually dismissing people, you will see good resumes dry up. In our case, the quality of candidates has nosedived. It's not clear why a strong candidate would join a company that opts to fire people so casually.
On the other hand, if you feel you are a top performer and want to work with other top performers, you wouldn't want to work at a place with mediocre developers.
A good developer is not necessarily one that knows everything but has competence and can learn fast. I've worked with smart junior developers and developers with years worth of experience that couldn't cut it when given a novel to them problem.
A good developer is not necessarily one that knows everything but has competence and can learn fast. I've worked with smart junior developers and developers with years worth of experience that couldn't cut it when given a novel to them problem.
IME there's a fine line to balance between burning out your best people and over-pressuring them, vs being too accommodating of adequate-to-good people more interested in protecting their own turf/stability or playing political games than in getting the product as good as possible. In my ideal world I'd rather be in a pay-for-output-quality (not pure quantity or attention-getting) higher-pressure-but-not-insane-hours environment than in the latter, but sadly that doesn't seem super common.
The most frustrating problem for me is "top performers" who are very technically knowledgeable, so seen as stars by their direct managers, but have zero interest in any solutions that they don't directly design themselves, and little interest in taking feedback or admitting that their internal mental roadmap isn't 100% perfect.
The most frustrating problem for me is "top performers" who are very technically knowledgeable, so seen as stars by their direct managers, but have zero interest in any solutions that they don't directly design themselves, and little interest in taking feedback or admitting that their internal mental roadmap isn't 100% perfect.
The most frustrating problem for me is "top performers" who are very technically knowledgeable, so seen as stars by their direct managers, but have zero interest in any solutions that they don't directly design themselves, and little interest in taking feedback or admitting that their internal mental roadmap isn't 100% perfect.
How do you get to be a "top performer" if you aren't willing to learn? In the context that I'm in now as the lead developer, I am sure that I'm the top developer. But as a lead developer, I'm the most inexperienced leader in my entire company and I'm constantly learning what being a leader means.
How do you get to be a "top performer" if you aren't willing to learn? In the context that I'm in now as the lead developer, I am sure that I'm the top developer. But as a lead developer, I'm the most inexperienced leader in my entire company and I'm constantly learning what being a leader means.
I've observed that some engineers are competent, but too insecure to rely on anything but their own internal feedback.
> On the other hand, if you feel you are a top performer and want to work with other top performers, you wouldn't want to work at a place with mediocre developers.
This could just be because I'm a mediocre developer (1X) but:
1) Mediocre developers have the ability to consistently produce all the basic non-architectural grunt work in a reasonable amount of time with a reasonable level of quality. Frankly, the "top performers" tend to want to work on high impact/high visibility projects and tend to shirk any grunt work they are given. (i.e. Even something as simple as a combo box that handles shipping I've seen "top performers" repeatedly f up despite me warning them and having to completely scrap their implementations. It isn't that the developer isn't a top performer, they just are not willing to do boring CRUD work and literally every "top performer" I've worked with does that. Management doesn't care because they deliver high quality results on other "new" things but basic maintenance work is simply beneath them both in attitude and the time they commit to the task.)
2) Places that tend to focus on "just hiring top performers" tend to have trouble holding on to top performers as they are usually bribed into leaving if they bother to look around. Mediocre performers might take 12-18 months to get bribed away when interviewing while working. Top performers tend to land a better offer in less than 3 months of interviewing. Places that hire mediocre developers can frequently throw $40k/year + a week of PTO to get them to stay. (i.e A top performer at my last job that I'm friends with got a $40k/year raise in cash, a week of PTO to guarantee they'd stay indefinitely.)
3) Top performers are very good at being an architect, breaking new ground, and/or working on novel problems. They also tend to naturally prioritize high impact/high visibility projects. However, that often comes at the expense of doing routine work correctly and the long term maintainability/stability (as they frequently move on). I've found "Top Performer" is really code for "Person who focuses on getting involved on the highest impact project they can at any given time." And then end up resenting grunt work when such projects are not available to them.
This could just be because I'm a mediocre developer (1X) but:
1) Mediocre developers have the ability to consistently produce all the basic non-architectural grunt work in a reasonable amount of time with a reasonable level of quality. Frankly, the "top performers" tend to want to work on high impact/high visibility projects and tend to shirk any grunt work they are given. (i.e. Even something as simple as a combo box that handles shipping I've seen "top performers" repeatedly f up despite me warning them and having to completely scrap their implementations. It isn't that the developer isn't a top performer, they just are not willing to do boring CRUD work and literally every "top performer" I've worked with does that. Management doesn't care because they deliver high quality results on other "new" things but basic maintenance work is simply beneath them both in attitude and the time they commit to the task.)
2) Places that tend to focus on "just hiring top performers" tend to have trouble holding on to top performers as they are usually bribed into leaving if they bother to look around. Mediocre performers might take 12-18 months to get bribed away when interviewing while working. Top performers tend to land a better offer in less than 3 months of interviewing. Places that hire mediocre developers can frequently throw $40k/year + a week of PTO to get them to stay. (i.e A top performer at my last job that I'm friends with got a $40k/year raise in cash, a week of PTO to guarantee they'd stay indefinitely.)
3) Top performers are very good at being an architect, breaking new ground, and/or working on novel problems. They also tend to naturally prioritize high impact/high visibility projects. However, that often comes at the expense of doing routine work correctly and the long term maintainability/stability (as they frequently move on). I've found "Top Performer" is really code for "Person who focuses on getting involved on the highest impact project they can at any given time." And then end up resenting grunt work when such projects are not available to them.
I've found "Top Performer" is really code for "Person who focuses on getting involved on the highest impact project they can at any given time." And then end up resenting grunt work when such projects are not available to them.
To me, it sounds like your company's definition of a top performer is someone who is good at gaming the system. I guess your company is not unique in that regard.
To me, it sounds like your company's definition of a top performer is someone who is good at gaming the system. I guess your company is not unique in that regard.
How is it "gaming the system"? It's best for my career to be on the highest impact project. Either the company is going to reward me for succeeding or I can use that success on my resume to find another job.
Because the company is confusing project impact with individual impact. An ambitious idiot on a high ROI project is still an idiot.
It also fosters a culture where obsequious bullshit artists figure out to worm their way into projects and come out the other side with kudos.
If that type of gameplay is effective, the company is playing the wrong game. If you ask your director who the highest performer is and ask your colleagues the same question, and the answer is very different, that’s probably what your company is doing.
It also fosters a culture where obsequious bullshit artists figure out to worm their way into projects and come out the other side with kudos.
If that type of gameplay is effective, the company is playing the wrong game. If you ask your director who the highest performer is and ask your colleagues the same question, and the answer is very different, that’s probably what your company is doing.
How many companies ignore your projects’ business impact when evaluating performance? I’d guess none.
> This could just be because I'm a mediocre developer (1X) but:
If you're mediocre as in average, that makes you 4x, not 1x. The 10x developer is 10 times better than the worst performer who is still employed, or 2.5x the median.
I only point this out because lots of people get it wrong and end up unfairly underestimating their own competence.
If you're mediocre as in average, that makes you 4x, not 1x. The 10x developer is 10 times better than the worst performer who is still employed, or 2.5x the median.
I only point this out because lots of people get it wrong and end up unfairly underestimating their own competence.
That is a fair criticism. :/
I always tended to view "1X" as in "average" and then 10X as in "10X better than average" which I've seen happen in narrow competencies of a specific architecture/situation/business.
I always tended to view "1X" as in "average" and then 10X as in "10X better than average" which I've seen happen in narrow competencies of a specific architecture/situation/business.
If you can do competent work and add value to the company, you're already ahead of many developers, I've interviewed. Heck, you're already better than some "architects" I've worked with.
To anyone mildy deserving the title "performer", anything that sounds or smells like "grunt work" is merely an interesting candidate for (intelligent, self-contained, sustainable, documented of course) elimination-automation.
This can greatly benefit all of a project's/product's stakeholders in the medium-to-long term --- assuming the organization allows fully for this "performer instinct" to flower --- just as any garage up-start and foss/hobby project naturally would. Sure: there are likely-potential pitfalls implied here, in terms of scheduling/billing/accounting for such work. (Guess that's the part where non-developer team members such as POs/PMs/etc actually get to put in some non-janitorial efforts! =) But never insurmountable, and the "let's just keep some code-monkeys for the grunt-work" workaround/cop-out is mentally-cheap-but-otherwise-costly --- at least as soon as all the rockstars have been gobbled up by a single competitor! (Admittedly, that never seems to quite happen like that.)
This can greatly benefit all of a project's/product's stakeholders in the medium-to-long term --- assuming the organization allows fully for this "performer instinct" to flower --- just as any garage up-start and foss/hobby project naturally would. Sure: there are likely-potential pitfalls implied here, in terms of scheduling/billing/accounting for such work. (Guess that's the part where non-developer team members such as POs/PMs/etc actually get to put in some non-janitorial efforts! =) But never insurmountable, and the "let's just keep some code-monkeys for the grunt-work" workaround/cop-out is mentally-cheap-but-otherwise-costly --- at least as soon as all the rockstars have been gobbled up by a single competitor! (Admittedly, that never seems to quite happen like that.)
https://news.ycombinator.com/item?id=16031849
I'm still kind of amused y'all think you can just magically automate and abstract things perfectly without consequences in all situations.
I'm still kind of amused y'all think you can just magically automate and abstract things perfectly without consequences in all situations.
Magically? Without consequence? In all situations? I wouldn't ever (and didn't) go that far in my statements.. guess I'm not part of "y'all" =)
Yet you are arguing grunt work shouldn't exist and the fact it does means you should automate it. This may just be a sore point for me because of the number of times I've had to clean up messes created by people with the "automate all the things" attitude when they automate something they really, really shouldn't have.
Countering my point by claiming you should automate and then backtracking with "Well, not everything" isn't particularly productive tbh.
Countering my point by claiming you should automate and then backtracking with "Well, not everything" isn't particularly productive tbh.
Grunt work isn't everything though, it's more often than not highly manual, highly repetitive, low skill work. That sounds like a great candidate for automation.
I think the bigger issue is that you appear to be using the truth that you can't automate everything, to support the statement that you can't automate gruntwork, which I think depending on how you define gruntwork is false by definition.
I think the bigger issue is that you appear to be using the truth that you can't automate everything, to support the statement that you can't automate gruntwork, which I think depending on how you define gruntwork is false by definition.
By grunt work, I mean "low skill" for a software developer / white collar professional with a similar income. I don't mean like, minimum wage data entry type work.
I understand that. It sounds like you're describing something similar to what the Google sre book calls "Toil", and I would say that the goal should be to eliminate that kind of work.
While that definition focuses tightly on ops, you can extend it to general swe-ing. A manual, mechanical refactor is probably toil. The eng-time it takes scales linearly with code size. It can and should be automated.
To respond to the specific example in your linked post, you automate the f out of the process and then have the same person do it, but now it takes them minutes instead of hours, or hours instead of weeks.
[1]: https://landing.google.com/sre/book/chapters/eliminating-toi...
While that definition focuses tightly on ops, you can extend it to general swe-ing. A manual, mechanical refactor is probably toil. The eng-time it takes scales linearly with code size. It can and should be automated.
To respond to the specific example in your linked post, you automate the f out of the process and then have the same person do it, but now it takes them minutes instead of hours, or hours instead of weeks.
[1]: https://landing.google.com/sre/book/chapters/eliminating-toi...
The first thing that came to mind with that link was:
wget -r -nc -p --html-extension -k -np https://landing.google.com/sre/book/ -D google.com; mv ./landing.google.com/sre/* ./; rm -rf ./landing.google.com
> I understand that. It sounds like you're describing something similar to what the Google SRE book calls "Toil", and I would say that the goal should be to eliminate that kind of work.
Yes, to some degree.
You'll notice almost everything I point out is powerful automation handed to a user that doesn't really understand it is something to be avoided.
And when I say refactor, I don't really mean "code cleanup" so much as "removing technical debt that doesn't change the current buisness logic".
Keep in mind, my original definition of "Top Performer" was someone who resented even 10% Toil and basically would rather automate it shoddily than deal with it.
wget -r -nc -p --html-extension -k -np https://landing.google.com/sre/book/ -D google.com; mv ./landing.google.com/sre/* ./; rm -rf ./landing.google.com
> I understand that. It sounds like you're describing something similar to what the Google SRE book calls "Toil", and I would say that the goal should be to eliminate that kind of work.
Yes, to some degree.
You'll notice almost everything I point out is powerful automation handed to a user that doesn't really understand it is something to be avoided.
And when I say refactor, I don't really mean "code cleanup" so much as "removing technical debt that doesn't change the current buisness logic".
Keep in mind, my original definition of "Top Performer" was someone who resented even 10% Toil and basically would rather automate it shoddily than deal with it.
You can't automate everything, but it doesn't make sense from either the company's standpoint or the employee's standpoint to spend year after year doing work that an "average" programmer can do. Either the company is overpaying or the person is getting underpaid.
I agree with all of your characterizations. I couldn't spend year after year doing maintenance grunt work. Luckily, I get health benefits through my wife's job so I can jump back and forth between full time and contract work with abandon.
I consider myself a "top performer".
Yeah I know everyone considers themselves to be above average, but I'm the tech lead for my company so by job title and responsibility, I think I'm qualified to say that.
But I guess I need a more nuanced opinion. I wouldn't want to be on a team where my peers are mediocre at this point in my career. There is a difference in my mind between a "mediocre" developer and an "inexperienced" developer. A mediocre developer is one that isn't where they should be in terms of competence and expertise based on their years of experience.
Even worse, is an "experienced" developer who makes horrible architectural decisions.
I consider myself a "top performer".
Yeah I know everyone considers themselves to be above average, but I'm the tech lead for my company so by job title and responsibility, I think I'm qualified to say that.
But I guess I need a more nuanced opinion. I wouldn't want to be on a team where my peers are mediocre at this point in my career. There is a difference in my mind between a "mediocre" developer and an "inexperienced" developer. A mediocre developer is one that isn't where they should be in terms of competence and expertise based on their years of experience.
Even worse, is an "experienced" developer who makes horrible architectural decisions.
> I agree with all of your characterizations. I couldn't spend year after year doing maintenance grunt work. Luckily, I get health benefits through my wife's job so I can jump back and forth between full time and contract work with abandon.
I understand but maintenance/refactoring grunt work is technically necessary which is why I think going for 100% top performers is a bad hiring strategy for a business is all. Systems need to be refactored regularly to maintain business logic consistency between services, remain stable as the ecosytsem they communicate with changes, and be secured.
> Yeah I know everyone considers themselves to be above average, but I'm the tech lead for my company so by job title and responsibility, I think I'm qualified to say that.
I believe you. I'm not here to argue ability, just the strategic merit of focusing on top performers.
> But I guess I need a more nuanced opinion. I wouldn't want to be on a team where my peers are mediocre at this point in my career. There is a difference in my mind between a "mediocre" developer and an "inexperienced" developer. A mediocre developer is one that isn't where they should be in terms of competence and expertise based on their years of experience.
Ah, and I think this might be a miscommunication partially as well.
To me there are basically 4 buckets of developers:
1) Top Performers (2X+ Developers. Highly skilled but tend to focus on personal growth. Tends to ignore long term pain points because they just will not be there that long.)
2) Mediocre (.75-1.5X Developers who should be used to do the non-architectural grunt work and refactoring. They tend to want to stick with an employer long term and tend to focus on medium to long term effectiveness because they'll feel the pain of deviation from that.)
3) Incompetent Developers (Experienced developers with little to negative net value who probably should really be looking for a new career. Or anyone who else who is substantially below the Mediocre range for their experience level / pay expectations. )
4) Inexperienced Developers (Little to negative net value who will probably need a couple years experience before you really know if they are a top performer or mediocre.)
> Even worse, is an "experienced" developer who makes horrible architectural decisions.
That is probably the single most painful experience in every software developer's career. Poor architectural decisions that cannot be properly refactored due to budget constraints. The number of times I've seen an incompetent developer break primary keys during a system integration/transition is too numerous to count.
I understand but maintenance/refactoring grunt work is technically necessary which is why I think going for 100% top performers is a bad hiring strategy for a business is all. Systems need to be refactored regularly to maintain business logic consistency between services, remain stable as the ecosytsem they communicate with changes, and be secured.
> Yeah I know everyone considers themselves to be above average, but I'm the tech lead for my company so by job title and responsibility, I think I'm qualified to say that.
I believe you. I'm not here to argue ability, just the strategic merit of focusing on top performers.
> But I guess I need a more nuanced opinion. I wouldn't want to be on a team where my peers are mediocre at this point in my career. There is a difference in my mind between a "mediocre" developer and an "inexperienced" developer. A mediocre developer is one that isn't where they should be in terms of competence and expertise based on their years of experience.
Ah, and I think this might be a miscommunication partially as well.
To me there are basically 4 buckets of developers:
1) Top Performers (2X+ Developers. Highly skilled but tend to focus on personal growth. Tends to ignore long term pain points because they just will not be there that long.)
2) Mediocre (.75-1.5X Developers who should be used to do the non-architectural grunt work and refactoring. They tend to want to stick with an employer long term and tend to focus on medium to long term effectiveness because they'll feel the pain of deviation from that.)
3) Incompetent Developers (Experienced developers with little to negative net value who probably should really be looking for a new career. Or anyone who else who is substantially below the Mediocre range for their experience level / pay expectations. )
4) Inexperienced Developers (Little to negative net value who will probably need a couple years experience before you really know if they are a top performer or mediocre.)
> Even worse, is an "experienced" developer who makes horrible architectural decisions.
That is probably the single most painful experience in every software developer's career. Poor architectural decisions that cannot be properly refactored due to budget constraints. The number of times I've seen an incompetent developer break primary keys during a system integration/transition is too numerous to count.
I question the association between maintenance and mediocrity. It’s much easier to start a new project than to work effectively with a large codebase you didn’t write.
That is fair.
You'll notice the people that consider themselves top performers that responded to this post lean towards moving on rather than doing primarily maintenance work for years on end. I've seen similar sentiments echoed by others, hence the distinction.
You'll notice the people that consider themselves top performers that responded to this post lean towards moving on rather than doing primarily maintenance work for years on end. I've seen similar sentiments echoed by others, hence the distinction.
Some people are starters. Some are finishers. Some are maintainers. Few are good at all 3. Most people seem to label fast starters as "top performers". But you can be a "top performer" in any category.
However, I would claim that if you never do maintenance work, you don't really know if what you're writing is crap.
However, I would claim that if you never do maintenance work, you don't really know if what you're writing is crap.
I agree with you on that last bit as I'm basically a sysadmin/dev that gets stuck maintaining the systems when "top performers" move on to the next project. ;)
Could you elaborate on what you mean by "break primary keys"?
If you're not being challenged in your job (i.e. doing grunt work), you either need to find a harder job within the company (it might be automating away grunt work), or failing that, a different company.
Now I'm going to play devils advocate. What's wrong with doing grunt work and not being challenged? I know people who have been at the same job for 20 years maintaining the same system and not being challenged. They work their 40 hours a week, love the familiarity and stability, and go home.
I would die a thousand deaths doing that but sometimes I wish I had the type of personality that could deal with that lifestyle.
Realistically though, couldn't people say the same about me? I'm about 10% below the top salary I can get without going into management in my market. I should hit my top salary in about two years, except for cost of living raises. I'm okay with vertical moves being a "Senior Developer", "Architect", "Team Lead", "Consultant", etc. Some people would say why don't I want to be a manager or start my own company.
Now I'm going to play devils advocate. What's wrong with doing grunt work and not being challenged? I know people who have been at the same job for 20 years maintaining the same system and not being challenged. They work their 40 hours a week, love the familiarity and stability, and go home.
I would die a thousand deaths doing that but sometimes I wish I had the type of personality that could deal with that lifestyle.
Realistically though, couldn't people say the same about me? I'm about 10% below the top salary I can get without going into management in my market. I should hit my top salary in about two years, except for cost of living raises. I'm okay with vertical moves being a "Senior Developer", "Architect", "Team Lead", "Consultant", etc. Some people would say why don't I want to be a manager or start my own company.
There is no dishonor in that grunt work. It’s just that your work product will have limited impact.
I have a friend who has been a mainframe systems programmer for 30 years. He’s a master of his craft, and has a tool in his bag of tricks for every problem that happens. Most of his work helping people integrate with his mainframe to eventually replace it.
He’s a great guy and loves the life he wants to live. The problem is, few things in tech will live that long, and guru knowledge of some forgotten mainframe makes your options limited.
I have a friend who has been a mainframe systems programmer for 30 years. He’s a master of his craft, and has a tool in his bag of tricks for every problem that happens. Most of his work helping people integrate with his mainframe to eventually replace it.
He’s a great guy and loves the life he wants to live. The problem is, few things in tech will live that long, and guru knowledge of some forgotten mainframe makes your options limited.
The downside to doing it, for the people who do it, is that they will have a hard time finding another job if they get laid off. Their skills are likely outdated if they have been doing unchallenging grunt work for years.
Asking your best performers to do grunt work is a waste of their skills and may eventually drive them away. Let them add value by doing things that lesser performers are unable to do.
> I've found "Top Performer" is really code for "Person who focuses on getting involved on the highest impact project they can at any given time." And then end up resenting grunt work when such projects are not available to them.
Isn't that a good thing? If I were running a company, I would want the best people to focus on the things that had that highest impact on the bottom line. If grunt work is all you have, grunts are all you need.
> I've found "Top Performer" is really code for "Person who focuses on getting involved on the highest impact project they can at any given time." And then end up resenting grunt work when such projects are not available to them.
Isn't that a good thing? If I were running a company, I would want the best people to focus on the things that had that highest impact on the bottom line. If grunt work is all you have, grunts are all you need.
> Isn't that a good thing? If I were running a company, I would want the best people to focus on the things that had that highest impact on the bottom line. If grunt work is all you have, grunts are all you need.
That is why its a dangerous idea (to me). The people making these decisions frequently misjudge the facts on the ground about what is the "highest impact" on the bottom line.
It frequently means its a good starter who has no real understanding of the medium to long term maintenance issues created by their work. They also rarely suffer the consequences of bad decisions that make it into production but "work" for the first few weeks until they've been moved to a new project.
Let me give you an example of this scenario:
A team of high performers who deliver on time and on budget are given a project to launch a new Project integrated from Frontend to ERP. And, amazingly, they look like they will almost make it despite only getting 80% of the resources they originally asked for 12 months ago!
Awesome right? They did it.
Then, you bring in the mediocre gal who handled maintenance on the old system in for the last couple months while Team Awesome was getting the job DONE! They needed her to help them figure out how to deploy to production tho (she is the devops gal as well as the maintenance gal).
And in July (about a month into this), she goes "Guys, guys. This isn't going to work. We need to do X, Y, and Z. I know its technical and not customer facing but we risk f'n up <insert critical path item X we use to generate money>. I know its a bit late, but are you sure you want to automate everything to work off excel spreadsheets handled by <insert arrogant business guy>? We need to do load / integration testing with a mirror of the real data. I am not sure what we've done to test it is enough."
Team Awesome goes, "We are cutting it close and its important to meet the deadline. We spent a year working on this and we are sure things will work out."
Queue two weeks after the August launch and some minor bug fixes, Team Awesome moved on to a new project.
Things are rocky but seem workable for all of Sept. Maintenance Gal rings alarm bells about some weirdness with payment processing, etc. but is told there isn't time to look into it because "super important feature was missed and needs to be put in ASAP!!!"
Accounting starts reconciling things in Oct and realizes we misplaced $125k of which $50k was due to a shipping promotion the "system did not handle correctly". A member of Team Awesome gets pulled off a "very important project" to "help" turn things around. They claim they do and go back to the "very important project". Maintenance Gal sounds less like she is crying wolf at this point but is basically ignored by management.
November rolls around, biggest month of the year, and by the end of Cyber Monday panic ensues when the "fix" turns out to have not worked correctly and Arrogant Business Guy "worked around it" again. $400k in unintended expenses are racked up. Integration falls over and distribution has to upgrade shipping on thousands of orders. Another six figure expense.
By Christmas, "Team Awesome" is deflecting blame onto the only person that has worked on the project since August (Maintenance Gal who has done little but ring alarm bells about launching it being a bad idea and working overtime to hotfix issues).
Non-technical stakeholders still think Team Awesome is Awesome. Maintenance Gal is called into a meeting where they planned to put her on a PIP where Management basically accuses her of pushing that particular unit of the Company into the red with her incompetence. She defends herself as best she can with the documentation of her concerns in July, August, September, October, and November.
Sometimes Maintenance Gal becomes Unemployed Gal. Sometimes someone else does.
----
I've watched this happen to multiple people at multiple employers at this point. Its left me a bit disillusioned with the idea of "top performers" who focus on getting involved on the highest impact projects they can at any given time.
I probably should mention at this point I've never been fired or laid off in my ~10 year career. The one time this particularly freight train was aimed at me, I started interviewing in August and my two week notice was in the Monday after I was called in for the PIP discussion. I had been just waiting for my background check to clear by the time the PIP came up.
You might think that is specific enough to work out my identity (if anyone cared too) but I've seen similar things happen enough times I know that isn't possible. Lol. :)
That is why its a dangerous idea (to me). The people making these decisions frequently misjudge the facts on the ground about what is the "highest impact" on the bottom line.
It frequently means its a good starter who has no real understanding of the medium to long term maintenance issues created by their work. They also rarely suffer the consequences of bad decisions that make it into production but "work" for the first few weeks until they've been moved to a new project.
Let me give you an example of this scenario:
A team of high performers who deliver on time and on budget are given a project to launch a new Project integrated from Frontend to ERP. And, amazingly, they look like they will almost make it despite only getting 80% of the resources they originally asked for 12 months ago!
Awesome right? They did it.
Then, you bring in the mediocre gal who handled maintenance on the old system in for the last couple months while Team Awesome was getting the job DONE! They needed her to help them figure out how to deploy to production tho (she is the devops gal as well as the maintenance gal).
And in July (about a month into this), she goes "Guys, guys. This isn't going to work. We need to do X, Y, and Z. I know its technical and not customer facing but we risk f'n up <insert critical path item X we use to generate money>. I know its a bit late, but are you sure you want to automate everything to work off excel spreadsheets handled by <insert arrogant business guy>? We need to do load / integration testing with a mirror of the real data. I am not sure what we've done to test it is enough."
Team Awesome goes, "We are cutting it close and its important to meet the deadline. We spent a year working on this and we are sure things will work out."
Queue two weeks after the August launch and some minor bug fixes, Team Awesome moved on to a new project.
Things are rocky but seem workable for all of Sept. Maintenance Gal rings alarm bells about some weirdness with payment processing, etc. but is told there isn't time to look into it because "super important feature was missed and needs to be put in ASAP!!!"
Accounting starts reconciling things in Oct and realizes we misplaced $125k of which $50k was due to a shipping promotion the "system did not handle correctly". A member of Team Awesome gets pulled off a "very important project" to "help" turn things around. They claim they do and go back to the "very important project". Maintenance Gal sounds less like she is crying wolf at this point but is basically ignored by management.
November rolls around, biggest month of the year, and by the end of Cyber Monday panic ensues when the "fix" turns out to have not worked correctly and Arrogant Business Guy "worked around it" again. $400k in unintended expenses are racked up. Integration falls over and distribution has to upgrade shipping on thousands of orders. Another six figure expense.
By Christmas, "Team Awesome" is deflecting blame onto the only person that has worked on the project since August (Maintenance Gal who has done little but ring alarm bells about launching it being a bad idea and working overtime to hotfix issues).
Non-technical stakeholders still think Team Awesome is Awesome. Maintenance Gal is called into a meeting where they planned to put her on a PIP where Management basically accuses her of pushing that particular unit of the Company into the red with her incompetence. She defends herself as best she can with the documentation of her concerns in July, August, September, October, and November.
Sometimes Maintenance Gal becomes Unemployed Gal. Sometimes someone else does.
----
I've watched this happen to multiple people at multiple employers at this point. Its left me a bit disillusioned with the idea of "top performers" who focus on getting involved on the highest impact projects they can at any given time.
I probably should mention at this point I've never been fired or laid off in my ~10 year career. The one time this particularly freight train was aimed at me, I started interviewing in August and my two week notice was in the Monday after I was called in for the PIP discussion. I had been just waiting for my background check to clear by the time the PIP came up.
You might think that is specific enough to work out my identity (if anyone cared too) but I've seen similar things happen enough times I know that isn't possible. Lol. :)
Yes. I've seen that too. But that's a result of poor management.
I designed our current system from scratch, hired people, mentored existing junior developers, etc. and my manager was constantly questioning me about scaleability, maintainability, fault tolerance, logging, devops, security, etc.
I also asked her to always question my decisions and keep me honest. I ask everyone on the team to question my assumptions.
I designed our current system from scratch, hired people, mentored existing junior developers, etc. and my manager was constantly questioning me about scaleability, maintainability, fault tolerance, logging, devops, security, etc.
I also asked her to always question my decisions and keep me honest. I ask everyone on the team to question my assumptions.
It sounds to me like your definition of "high performer" is really "good politician." I know plenty of high performers who follow through all the way to deployment, monitor the program in production, and take full ownership of the entire thing.
Top performers have usually crept towards the high end of the salary available to them, and they're aware that grunt work isn't necessarily a good cost / value tradeoff for the company they're working for, nor a good tradeoff for their human capital vs income earned.
If you're not being challenged in your job (i.e. doing grunt work), you either need to find a harder job within the company (it might be automating away grunt work), or failing that, a different company.
If you're not being challenged in your job (i.e. doing grunt work), you either need to find a harder job within the company (it might be automating away grunt work), or failing that, a different company.
> If you're not being challenged in your job (i.e. doing grunt work), you either need to find a harder job within the company (it might be automating away grunt work), or failing that, a different company.
Honestly, the only serious challenge I have in my job is getting people to do stuff in a maintainable, reliable way despite the fact it costs a little more in QA of the automation (or manual change control processes that IT frequently resists). Automation is not the right solution when human QA and manual intervention is an order of magnitude less expensive than the potential problems created by a non-technical user.
You have to realize the only person who _really_ understands most heavily integrated systems are technical folks and automating abstractions to allow non-technical users to make sweeping system-wide changes is a bad idea (even if it is easier on IT).
> Top performers have usually crept towards the high end of the salary available to them, and they're aware that grunt work isn't necessarily a good cost / value tradeoff for the company they're working for, nor a good tradeoff for their human capital vs income earned.
The problem is, you can't always automate grunt work. For instance, matrix rate shipping is something that is (effectively) a business rule that is maintained manually across multiple systems. Someone, somewhere is going to have manually determine that business rule and apply it.
Now, lets say you are crafty and you automate the f out of this process so they just have to type some values into a spreadsheet and upload it. Or a form. Or whatever.
What happens if your validation is not 100% correct and you are relying on non-IT people to QA this update that impacts multiple systems?
You lose $50k before the defect is fixed because instead of having someone who understood the impact from end to end dealing with it, you gave it to a business person who found a novel way to work around your validation to "make it work". The cost of annual, manual updates by a 6 figure salaried programmer would have been less than $5k a year.
So the wise, automation oriented programmer fixes the defects in validation, writes some more unit tests, and so forth. Then, lo and behold, it happens a second time on Black Friday and you end up giving out 6 figures in $$ due to a "software error" that was due to a business person setting everything to $0.01 because they misunderstood something.).
Now, you might blame the business person but given this has happened for the Nth time before this person automated it...they should have known better and required some sort of manual validation step by QA/IT/whatever.
Some things you really, really must have a manual sanity check on because of how critical they are and the business risk involved and automating it to the point you hand it off to someone else for minimal manual work is not the right decision.
I've seen this with controlled substances, regulated products moving across borders, shipping, and a dozen other things. Non-technical people being handed powerful automated tools they don't 100% understand is not always the correct solution.
Honestly, the only serious challenge I have in my job is getting people to do stuff in a maintainable, reliable way despite the fact it costs a little more in QA of the automation (or manual change control processes that IT frequently resists). Automation is not the right solution when human QA and manual intervention is an order of magnitude less expensive than the potential problems created by a non-technical user.
You have to realize the only person who _really_ understands most heavily integrated systems are technical folks and automating abstractions to allow non-technical users to make sweeping system-wide changes is a bad idea (even if it is easier on IT).
> Top performers have usually crept towards the high end of the salary available to them, and they're aware that grunt work isn't necessarily a good cost / value tradeoff for the company they're working for, nor a good tradeoff for their human capital vs income earned.
The problem is, you can't always automate grunt work. For instance, matrix rate shipping is something that is (effectively) a business rule that is maintained manually across multiple systems. Someone, somewhere is going to have manually determine that business rule and apply it.
Now, lets say you are crafty and you automate the f out of this process so they just have to type some values into a spreadsheet and upload it. Or a form. Or whatever.
What happens if your validation is not 100% correct and you are relying on non-IT people to QA this update that impacts multiple systems?
You lose $50k before the defect is fixed because instead of having someone who understood the impact from end to end dealing with it, you gave it to a business person who found a novel way to work around your validation to "make it work". The cost of annual, manual updates by a 6 figure salaried programmer would have been less than $5k a year.
So the wise, automation oriented programmer fixes the defects in validation, writes some more unit tests, and so forth. Then, lo and behold, it happens a second time on Black Friday and you end up giving out 6 figures in $$ due to a "software error" that was due to a business person setting everything to $0.01 because they misunderstood something.).
Now, you might blame the business person but given this has happened for the Nth time before this person automated it...they should have known better and required some sort of manual validation step by QA/IT/whatever.
Some things you really, really must have a manual sanity check on because of how critical they are and the business risk involved and automating it to the point you hand it off to someone else for minimal manual work is not the right decision.
I've seen this with controlled substances, regulated products moving across borders, shipping, and a dozen other things. Non-technical people being handed powerful automated tools they don't 100% understand is not always the correct solution.
That's a fine rant on the trade-offs of automation vs manual intervention. It's one reason I used the word "might".
Perhaps another way to put what I was trying to say is that top performers are constantly looking to maximize the amount of value they're adding, and a day filled with grunt work is seldom that; while a job filled with grunt work and little else is actively damaging to your career, if you're capable of more.
Perhaps another way to put what I was trying to say is that top performers are constantly looking to maximize the amount of value they're adding, and a day filled with grunt work is seldom that; while a job filled with grunt work and little else is actively damaging to your career, if you're capable of more.
> Perhaps another way to put what I was trying to say is that top performers are constantly looking to maximize the amount of value they're adding, and a day filled with grunt work is seldom that; while a job filled with grunt work and little else is actively damaging to your career, if you're capable of more.
Yes.
Its a situation where the individual's interests (focusing on being visible on high impact projects that hit deadlines and then moving on before the maintenance and/or technical debt issues crop up) are diametrically opposed to the business's interests (building maintainable systems that do not have 5-6 figure bugs that likely exceed the development cost of something as simple as executing on a critical path combo box).
I've never worked for a business correctly values the impact of the former on the latter.
Yes.
Its a situation where the individual's interests (focusing on being visible on high impact projects that hit deadlines and then moving on before the maintenance and/or technical debt issues crop up) are diametrically opposed to the business's interests (building maintainable systems that do not have 5-6 figure bugs that likely exceed the development cost of something as simple as executing on a critical path combo box).
I've never worked for a business correctly values the impact of the former on the latter.
80% of drivers think they are better than average.
Something to keep in mind.
This!
I’ve worked in a shop that fired lots of people before, and the people doing the firing were some of the worst developers I’ve ever worked with.
I’ve worked in a shop that fired lots of people before, and the people doing the firing were some of the worst developers I’ve ever worked with.
Yes and I addressed this. If you are a Nascar driver, you can confidently say that you are a better than average driver.
If enough companies have been willing to hire you as a lead developer or an architect and you haven't gotten fired, you can can say with some confidence that you are better than average.
If enough companies have been willing to hire you as a lead developer or an architect and you haven't gotten fired, you can can say with some confidence that you are better than average.
> If you are a Nascar driver, you can confidently say that you are a better than average driver.
Better at going fast and turning left?
Better at going fast and turning left?
I have no idea why this was downvoted. It was funny and perfectly timed.
Depends on scope. The last place NASCAR driver is below average in his peer group!
Definitely its context. I stayed at one company 7 years longer than I should have and then started being more aggressive about my career in 2008. I was an average to slightly below average developer from 2009-2016. I chose jobs that between my interview skills and technical skills, I knew just enough to get into the door, learned all I could from people who were much better than I was and once my skill set outpaced the salary they were willing to give me, i left for another job.
Now, after being a journeyman for the 9 years, I'm the tech lead for a small development shop. I consider myself the top performer because what I do has the biggest development impact on the company.
Now, after being a journeyman for the 9 years, I'm the tech lead for a small development shop. I consider myself the top performer because what I do has the biggest development impact on the company.
Compared to what? The other lead developers at that company? That’s not how objective comparison works.
I did agree it was contextual whether you are a top performer within your peer group (in my case, I'm the developer lead for the company). But we don't just compete for jobs in the company you work for now, you compete in the entire market. How you define your market is based on location and willingness to relocate.
Surely. (Too many) firings have a negative impact on morale. Especially if not done once. I think the point being made though is that it is very uncomfortable to fire people, so managers tend to avoid it, even if it's the right thing to do.
That was the problem at Yahoo. It's better to have one mass layoff and be done with it instead of having multiple small layoffs.
His statement could be read both ways. If you keep low performing people, it can suck the life of the team. I've personally seen teams where the top people lower their standards and outputs because they have low performing members in the team, and if the management doesn't care enough about the impact they have on the team, they will not work hard to make a good product.
OTOH, I do think firing is a bit of a last resort. A lot of people can be coached to perform better. I support firing as a last resort when other reasonable methods have failed.
OTOH, I do think firing is a bit of a last resort. A lot of people can be coached to perform better. I support firing as a last resort when other reasonable methods have failed.
I thought "coaching" was the answer to. I came in as a tech lead where one "developer" hired by a previous regime didn't know how to write a JavaScript function and just couldn't logically figure out how to debug an issue and the other just couldn't focus on a problem and went way out in left field on the simplest tasks.
We got rid of both of them as part of a "restructuring". I've had to cut a few contractors short because they just couldn't handle what for all intents and purposes was a startup environment where everything was up in the air and we needed people who could adapt, figure things out, and learn fast without holding their hands.
In a place like Netflix, everything is brand new. No one in history has ever had to deal with the scale that they have to.
We got rid of both of them as part of a "restructuring". I've had to cut a few contractors short because they just couldn't handle what for all intents and purposes was a startup environment where everything was up in the air and we needed people who could adapt, figure things out, and learn fast without holding their hands.
In a place like Netflix, everything is brand new. No one in history has ever had to deal with the scale that they have to.
Xeoncross(2)
This is where I stopped reading. Maybe if you work for Netflix-tier company which swims in the new candidates this makes sense but otherwise it's a great way to get a bad fame and make remaining employees focus only on KPIs to avoid getting fired(Goodbye good code quality, mentoring etc.; Hello "please create a ticket before asking any questions").
Besides, a good organization hires mostly right candidates. Firing should be really exceptional.
Besides, a good organization hires mostly right candidates. Firing should be really exceptional.
This list made me realize I have only ever seen Entropic Organizations. Is there even any other kind?
A great article mostly nailing problem descriptions. This is usually represented too briefly. I believe “The Entropic Organization” (Teo) would be a highly cited book, cited by all kinds of management books emphasizing the solutions. Please, write TEO.
I'm not sure if this is brilliant advice or really bad advice.
> People appreciate when you fire the right people, so don’t worry about morale.
When you select for sociopaths, you get sociopaths.
When you select for sociopaths, you get sociopaths.
Title whinge: a multinational what?
(That's not intended as a pedant's review of the article, just a note on the title presented on HN, which was praised in a recent thread for making even small changes to improve the grammar and quality of the site.)
(That's not intended as a pedant's review of the article, just a note on the title presented on HN, which was praised in a recent thread for making even small changes to improve the grammar and quality of the site.)
“Multinational” is in regular use (reflected in most current dictionaries) as a standalone noun with an equivalent meaning to the noun phrase “multinational corporation”.
> When the plan is foggy, that’s the moment to communicate as broadly as possible. In fact you should not frame it as a plan, you frame it as the situation and the final state you want to achieve. When you have a detailed plan, that’s when you DON’T need to communicate broadly. So, clearly state the situation and clearly state the foggy goal to everyone who will listen.
This is a great way to clarify a complex problem, draw out and resolve disagreements in understanding, enlist others’ help, and methodically arrive at the optimal solution. It also works well for all kinds of problems, whether they be engineering-related, organizational, or interpersonal.