9 ms·

People can read their manager's mind (2015)

190 points by l0b0 4y ago

tuatoru 4y ago
(2015)
- dang 4y ago
  Added. Thanks!
willvarfar 4y ago
> Corollary 1. Who can, and sometimes does, un-rot the fish from the bottom? An insane employee. Someone who finds the forks, crashes, etc. a personal offense, and will repeatedly risk annoying management by fighting to stop these things. Especially someone who spends their own political capital, Myself, I recognise myself here. And I'm trying my best to find my sanity. Anyone got any stories of themselves or others being insane? How did it pan out?
- hzay 4y ago
  [flagged]
  - dang 4y ago
    Please don't cross into personal attack. We ban accounts that break the site guidelines like that. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
    - hzay 4y ago
      Sorry!
- serioussecurity 4y ago
  I've spent much of my last four years systematically turning down every project a specific director has launched. The turn downs save enormous amounts of our hardware budget, and each time are measured as not happening users. No one has yet noticed that basically none of that directors projects are still running and put together that the things he builds stop working after two years. I keep getting paid good senior engineer money, and don't have to think too hard about what my next project should be. But it's really demoralizing to realize that he will continue to be promoted.
- deleted 4y ago
  [deleted]
- mrkeen 4y ago
  Not good, my dude! I've always been agitated by core failures moreso than my teammates. (E.g. Search engines not returning results, music players not starting/stopping when you hit the button, finance systems needing needing manual adjustments) I want to scream when management pushes new fringe features when the main ones are flakey. I'm starting to work on myself though, so I don't care as much. In most cases, you're not an employee building correct software for an employer who values it, even if that's the way it should be. You're in a company whose employees/managers flow in and out, and they just want to be surrounded with good vibes. Chill people get rehired, bitter people get booted.
  - noduerme 4y ago
    Like, maybe this is naive because I've probably never worked long at a corporation as large as the one you're probably at, but... if I were a senior VP and our main software was flakey while we were pushing fringe features, I would want to hear this from you. I'm not saying that it's always worked for me, but in cases like that I've always just done an end-run past the chain of command.
    - msy 4y ago
      Which is why you likely won't be a senior VP. Sales are demanding the fringe feature to meet a RFP requirement & the flakiness in the main software isn't meaningfully impacting renewals. These things are not (always) accidents.
      - noduerme 4y ago
        >> Which is why you likely won't be a senior VP I'll take that in the spirit of a compliment ;) What I mean is, I've definitely worked for organizations that were resistant to fixing things that were only mildly broken, but I've never worked for one where there wasn't someone you could talk to who would put the brakes on to fix something if you made the case that it had to be addressed before building new features. Particularly if the case was that the new features would have to be rebuilt soon if you didn't address these problems first.
    - 4y ago
- trabant00 4y ago
  As anything else it depends. You have to find the right balance between annoying management and fixing the problems against their will. I went on multiple jobs from making managers lose their temper in meetings to them coming to me first asking for help. But I was also offered a significant compensation to just leave a company, which I took cause it had come to outright war. I don't think you can "find your sanity" as I believe that taking technical issues personal is just the way some people are built. But you can and should learn politics even if you find it repulsive.
  - roflyear 4y ago
    Yeah. Over the last four years, I have had a lot of really successful products at my current company - but for all of them, I basically had to do it "rogue" which takes a lot for me to do, because I value having buy-in from the business and management. But, they needed to be done, and I was right - even though I was fought on the products. It sucks.
- andersource 4y ago
  I was pretty much like this for a long time, 1 / 10 would not recommend. For me the change was gradual but basically it was a couple of realizations revolving around separating my identity from my career and finding personal stuff I'd rather pour my emotional energy into, instead of pouring it to fight my employer to do things I thought they should be wanting me to do.
- terminal_d 4y ago
  Companies either want you to be technically proficient or to support the hierarchy. You need to suss out what kind of company you work for and act accordingly.
- deleted 4y ago
  [deleted]
- d23 4y ago
  Looks like you’ve found a bunch of other people in the club here. I don’t think I can muster the energy to type my story up, but it’s comforting in some way to know I’m not alone.
- JamesSwift 4y ago
  It can be exhausting having the target on your back all the time, but if you are confident in yourself and are approaching things honestly then its generally "fine". Id rather the frustration of fighting through the BS and knowing I tried to make a difference, than going along with it and also hating it at the same time. You can only control the things within your control however, and if you find yourself spinning into insanity fighting things that you ultimately do not control then thats when you need to take a step back and be honest about if you gave it your best shot. If you did, then let it go and allow the other members of the organization to do their own jobs however they think is best.
  - bick_nyers 4y ago
    Admitting you gave it your best shot is incredibly difficult for those who are overly self-critical or suffer from imposter syndrome. For me I had to accept that even if it wasn't my best shot it was good enough, and any system relying on perfection to be successful is inherently unstable.
    - JamesSwift 4y ago
      Thats a good point, its not about convincing yourself you've done _everything_ you could. Theres almost always the nuclear option of quitting. But its about choosing your battles appropriately and giving it "enough" of an effort to say that you gave it an honest attempt. Hopefully then circle back and try again next time. Assuming an org that isn't completely off the deep end of toxicity and politics, things do get slightly easier over time as people respect that you are fighting for the right things and are generally correct in your analyses.
- corobo 4y ago
  I found personal offence in them putting me on a PIP after a hip break (Being on morphine makes you bad at your job?? Give me more than 10 sick days and I'll not be trying to work high as balls, lol). Picture the film Office Space. There were 3 managers for like 14 people. It was insanity. One day I'll write my mashup of The Office and Office Space based on working there now the NDA is expired haha. Nothing whistleblowery, just hilariously silly stuff happening constantly. We agreed via my solicitor that that was a dumb move to have made and they settled so I'd go away. It later turned out I was working with undiagnosed ADHD so it might not have been all bad all the time but man I'd die on a lot of hills back then. I used to wonder who got the bad luck from me being employee #13, me or them haha. Freelance now. Y'all solve your own office problems, I'm not getting involved.
- fatnoah 4y ago
  > Corollary 1. Who can, and sometimes does, un-rot the fish from the bottom? An insane employee. Someone who finds the forks, crashes, etc. a personal offense, and will repeatedly risk annoying management by fighting to stop these things. Especially someone who spends their own political capital, You're not alone. I am this person, but I also have the advantage of being management. In one case, I led a 9 month ninja effort refactor an entire spaghetti monolith in semi-opposition to my boss' (CEO) wishes. We did it very smartly, though, which was to have a plan in place that was to a) have a plan b) focus on observability in the final product and c) used "extreme campfire rules" to implement. First steps were hard, which was where we completely reorganized everything into logical services with defined APIs within the monolith. During the couple months, overall product velocity slowed, so we tread with care and hustled to get stuff out on time. After that point, the resulting code sanity increased velocity so we could focus on things like revamping logging to be massively more useful, better data migrations, consistent deploy process for developer machines, dev integration server, staging, and production servers, and implementation of automated service and integration testing. The net result of 9 months of work was shipping tons of new features, virtually eliminating any down time (from hours a month to minutes per year), and a net loss of about 20% of the codebase. It was a smashing success that I couldn't tell anyone else on the management team about. I did get the ultimate payoff a couple years later when we were acquired by a $30B company and received many kudos during the technical due diligence process for the state of our architecture and reliability.
- bick_nyers 4y ago
  This is me. At my last job I was doing 3 jobs at once. 1 was what people THOUGHT my actual job was (gotta support the old system to buy myself enough time to roll out the new system, 1 was an additional job to get promoted/salary brought up to industry standards (risk manager for health tech., it didn't work), and 1 (what I was actually hired for 2+ years ago) was doing a rewrite properly to solve 50% of the engineering problems plaguing the company for near a decade once and for all (got it to 99% completion, but has been stuck in QA and Compliance hell for 8 months now on legacy features that are 1 out of 1 million requests). Oh but I accidentally did job #1 too well so now the rewrite I originally got hired to do is now not a priority on anyone's mind. Oh and I did job #2 so well that now I am getting daily requests from Compliance, and they are acting like my boss, as if the Architect, PM, overstepping and undertrained CS reps. and actual boss wasn't enough. Ok now I'm just venting at this point but it's therapeutic. I feel as though I've aged 10 years in the past 2 and I burned out very bad 4 months ago, still haven't recovered. Unemployed now. The worst part? I'm not sure I'm not going to try it again. Should I accept "mediocraty"? Should I strive to leverage my abilities to the fullest to truly be transformative in technology? Maybe I should just focus on getting "fuck you" money so I can work for free on things that actually have an impact.
- kthejoker2 4y ago
  If I've learned one thing, repeatedly, experience by painful experience: Time is an illusion, professional time doubly so. Don't waste it worrying about what might have been or never was, accept your failures, be magnanimous about others', and always work to make things better tomorrow. Maybe there's a Sliding Doors world out there where you can try all the possibilities and see where they take you, but time's arrow flows in one direction here. So choose the paths that you think move things up and to the right, and if you find yourself heading down and to the left, have a laugh and try again.
mcv 4y ago
Not all managers are that involved in implementation details. My experience is that most managers value deliverables: new features for users. Software engineers value good structure and reducing technical debt. Good managers listen to their engineers and let them tackle tech debt, and smart engineers tell managers that tackling tech means they can deliver new features faster and more reliably in the future.
- jahewson 4y ago
  > Software engineers value good structure and reducing technical debt A small minority of them do. As far as I can tell what most software engineers value is the act of writing code.
  - mcv 4y ago
    Well alright. I value the act of writing pretty code. But in many teams, I often see managers wanting more features, while I frequently see the devs argue for taking some time to address technical debt. Maybe there's some selection bias in me always being one of those devs.
  - aflag 4y ago
    In my experience most developers just want to reduce the cognitive load as much as possible. That sometimes means rewriting a lot of things so they make sense to them.
  - maximus-decimus 4y ago
    I value good software. I ENJOY writing code.
- Lutger 4y ago
  Managers do value the value of solving technical debt, because ultimately these changes maintain and improve the ability to deliver features. The problem is they often are unable to see how technical improvements affect the capacity to deliver. It doesn't help that developers also sometimes can't see it, and make mistakes overengineering or improving something that is of little value. In this sense it is a bit like the prevention paradox during the pandemic. If you are successful in preventing an outbreak, people will hate you for it because most people only feel the pain of the measures they had to take, and the absence of an outbreak only shows them those measures were useless. Then, to worsen things, there are also genuine mistakes in handling the pandemic and those are forever used as proof the measures are useless and its proponents incompetent. It really takes a lot of discernment to cut through all this.
dang 4y ago
Discussed at the time: People can read their manager's mind - https://news.ycombinator.com/item?id=10820158 https://news.ycombinator.com/item?id=10820158 - Dec 2015 (60 comments)
noduerme 4y ago
Lotta specific bitterness here. This reads a lot like a manifesto from someone about to shoot up their office. One example: >> A manager enjoys "software architecture", design patterns, and language lawyer type of knowledge Sorry, what is "language lawyer type of knowledge"? Does the OP mean the ability of others to better articulate and convince the manager of the reasons for making certain architectural decisions? There's something about the phrase "language lawyer type of knowledge" which is specifically derisive of engineers who are committed to the larger task and willing to make a case for their approach. It's a phrase which aims to diminish the value of reasoned debate in communicating pros and cons of various approaches; it's practically an ad hominem attack against anyone who uses words to make a point. My read of this was that the person who wrote it got fired for poor communication skills, was bitter, and penned a poorly written attempt at post-justifying their failure.
- flangola7 4y ago
  I read "language lawyering" as a person who sees language not as a means to communicate ideas in good faith, but as a weapon, a means to an end. The type of person who will nitpick and engage in prescriptive behaviors like quoting literal dictionary definitions back at a person rather than address the meaning and intent that they have obviously conveyed.
  - noduerme 4y ago
    Maybe, but this was used in the same breath as design patterns and software architecture. Those both are inevitably opinionated. I personally don't think engineers should get married to one set of patterns or architecture; we should keep learning on the job and find new tools, the best tools that suit the schema. But conflating what may well be good arguments for a design pattern with bad-faith "lawyering" shows a high level of contempt for the people OP would be working with, and suggests OP was more put off by the style of debate than they were by the content.
- wheybags 4y ago
  Pretty sure they mean arcana like the nitty gritty of how to parse a function pointer declaration in c (from reading the spec, which is written like law). Could be wrong though.
bcherny 4y ago
This article reads like this person has not worked in a well run engineering organization. In a good org: - Managers do not set goals. Teams set goals (EM, TL, PM, DS, etc. need to collaborate on the goal and be bought into it). - There is a system of checks to make sure goals are good. Teams need to make sure their leadership is bought into their goals, and that the goals ladder up to company goals. - Managers do not prescribe technical approaches. This is something TLs should do. - TLs are empowered to propose and work on infra and tech debt that are harder to measure with KPIs. These still need milestones and some measure of success.
- SideburnsOfDoom 4y ago
  > reads like this person has not worked in a well run engineering organization. Could be, it's not unusual. You might be surprised how common it is. And it is useful to address the real world of that.
  - bcherny 4y ago
    For sure. I hope it helps others to understand how an eng org should be run, so that they can help adjust their org’s approach. If incentives and process aren’t set up right, there’s only so much you can do to bandaid over the dysfunction.
- thesumofall 4y ago
  I might misread you. I would believe the best approach is a top-down / bottom-up approach that combines strategic directives with tactical and local goals. Otherwise, you would essentially say that the owners of a company would not be allowed to shape the direction of their own company, but that they would have to accept to be convinced by whatever the individual teams come up with. There are many valid goals that will never make sense for the individual teams to prioritize on their own but require a mix of top-down / bottom-up goal setting
  - bcherny 4y ago
    I agree. From my comment: > Teams need to make sure their leadership is bought into their goals, and that the goals ladder up to company goals.
hathym 4y ago
Why did the employee bring a mirror to work? To reflect the boss's thoughts back to him!
steveBK123 4y ago
This is just "stated preferences" vs "revealed preferences", and teams understanding what managers actually care about from experienced with those revealed preferences.
smcin 4y ago
Good 2015 article, but some extra considerations that rarely get explicitly mentioned: - the construction of a system of incentives/goals(/'recognition') is a large component in building a team/organization - people within the same org often have different incentives, and possibly over different timeframes; sometimes very different timeframes. Sometimes time-bound, sometimes event-bound (achieve X before IPO/Series X/ options vest/market crashes). - often incentives are constructed to set teams/depts at each others' throats, while paying lip-service to the concept of cooperation: salespeople get compensated short-term for getting sales, marketing get compensated for generating buzz and promising new features, QA and build get compensated for stability, performance, absence of bugs, engineering (typically) compensated for a basket of metrics intended to deliver product-market fit and growth. Essentially the VCs figure that within a year they will either fire the VP of Sales or Engineering. - the canonical example is a salesperson selling a deal with a toxic customer or overpromising nonexistent stuff which engineering won't be able to deliver, then pocketing their sales commission, buying the luxury car and quietly exiting the building - incentives can be conflicting between departments (this ain't Barney the Dinosaur), and designing that well is a Goldilocks quantity. Often you don't know the (actual) incentives/goals/OKR of your manager, or other depts: - sometimes, with enough time, you can deduce by observing (who got 'recognized'? promoted? fired? reorg'ed? quit? and who actually did the work?) You ask around and figure who's going up and who's going down. - I've seen a case where in retrospect a manager was simply there for the duration of his sponsored executive MBA, and didn't give a hoot about product-related metrics. The most important thing for him was not to actually fix anything or release anything, but keep the other managers around him sweet and happy, even though the company was losing huge market share and failing, stock was tanking. Eventually (soon after graduating from the MBA) he jumped off the sinking ship and went back to his former employer. (The company failed and its assets were firesaled. But this didn't affect his career. This first made me realize that it's quite common to have a massive disparity in (nominal or actual) incentives) > People generally don't do what they're told, but what they expect to be rewarded for. Corollary 3b: what they're rewarded for is often not explicitly stated. So people have a certain innate or acquired level of cynicism about what they're officially being told ('communicated'), and how they can game it and collude with others. Counter-Corollary 1. + Corollary 2.: before attempting to un-rot the fish from either the top or (especially) the bottom, stop, look both ways, listen to your intuition and think "Who appears to be benefiting, or at least is unperturbed by the current state of rottenness? What do their incentives seem to be? [and who in turn constructed those incentives?]" Corollary 2. When does the fish un-rot from the top? > Finally, don't expect people to enlighten you and tell you what your blind spots are. Becoming a manager means losing the privilege of being told what's what. It's a trap to think of oneself as just the same reasonable guy and why wouldn't they want to talk to me. The right question is, why would they? That part, tucked down the bottom, is brilliant, and should probably be the lede paragraph.

190 points by l0b0 4y ago

tuatoru 4y ago

(2015)

dang 4y ago
Added. Thanks!

willvarfar 4y ago

> Corollary 1. Who can, and sometimes does, un-rot the fish from the bottom? An insane employee. Someone who finds the forks, crashes, etc. a personal offense, and will repeatedly risk annoying management by fighting to stop these things. Especially someone who spends their own political capital, Myself, I recognise myself here. And I'm trying my best to find my sanity. Anyone got any stories of themselves or others being insane? How did it pan out?

hzay 4y ago
[flagged]
- dang 4y ago
  Please don't cross into personal attack. We ban accounts that break the site guidelines like that. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
  - hzay 4y ago
    Sorry!
serioussecurity 4y ago
I've spent much of my last four years systematically turning down every project a specific director has launched. The turn downs save enormous amounts of our hardware budget, and each time are measured as not happening users. No one has yet noticed that basically none of that directors projects are still running and put together that the things he builds stop working after two years. I keep getting paid good senior engineer money, and don't have to think too hard about what my next project should be. But it's really demoralizing to realize that he will continue to be promoted.
deleted 4y ago
[deleted]
mrkeen 4y ago
Not good, my dude! I've always been agitated by core failures moreso than my teammates. (E.g. Search engines not returning results, music players not starting/stopping when you hit the button, finance systems needing needing manual adjustments) I want to scream when management pushes new fringe features when the main ones are flakey. I'm starting to work on myself though, so I don't care as much. In most cases, you're not an employee building correct software for an employer who values it, even if that's the way it should be. You're in a company whose employees/managers flow in and out, and they just want to be surrounded with good vibes. Chill people get rehired, bitter people get booted.
- noduerme 4y ago
  Like, maybe this is naive because I've probably never worked long at a corporation as large as the one you're probably at, but... if I were a senior VP and our main software was flakey while we were pushing fringe features, I would want to hear this from you. I'm not saying that it's always worked for me, but in cases like that I've always just done an end-run past the chain of command.
  - msy 4y ago
    Which is why you likely won't be a senior VP. Sales are demanding the fringe feature to meet a RFP requirement & the flakiness in the main software isn't meaningfully impacting renewals. These things are not (always) accidents.
    - noduerme 4y ago
      >> Which is why you likely won't be a senior VP I'll take that in the spirit of a compliment ;) What I mean is, I've definitely worked for organizations that were resistant to fixing things that were only mildly broken, but I've never worked for one where there wasn't someone you could talk to who would put the brakes on to fix something if you made the case that it had to be addressed before building new features. Particularly if the case was that the new features would have to be rebuilt soon if you didn't address these problems first.
  - 4y ago
trabant00 4y ago
As anything else it depends. You have to find the right balance between annoying management and fixing the problems against their will. I went on multiple jobs from making managers lose their temper in meetings to them coming to me first asking for help. But I was also offered a significant compensation to just leave a company, which I took cause it had come to outright war. I don't think you can "find your sanity" as I believe that taking technical issues personal is just the way some people are built. But you can and should learn politics even if you find it repulsive.
- roflyear 4y ago
  Yeah. Over the last four years, I have had a lot of really successful products at my current company - but for all of them, I basically had to do it "rogue" which takes a lot for me to do, because I value having buy-in from the business and management. But, they needed to be done, and I was right - even though I was fought on the products. It sucks.
andersource 4y ago
I was pretty much like this for a long time, 1 / 10 would not recommend. For me the change was gradual but basically it was a couple of realizations revolving around separating my identity from my career and finding personal stuff I'd rather pour my emotional energy into, instead of pouring it to fight my employer to do things I thought they should be wanting me to do.
terminal_d 4y ago
Companies either want you to be technically proficient or to support the hierarchy. You need to suss out what kind of company you work for and act accordingly.
deleted 4y ago
[deleted]
d23 4y ago
Looks like you’ve found a bunch of other people in the club here. I don’t think I can muster the energy to type my story up, but it’s comforting in some way to know I’m not alone.
JamesSwift 4y ago
It can be exhausting having the target on your back all the time, but if you are confident in yourself and are approaching things honestly then its generally "fine". Id rather the frustration of fighting through the BS and knowing I tried to make a difference, than going along with it and also hating it at the same time. You can only control the things within your control however, and if you find yourself spinning into insanity fighting things that you ultimately do not control then thats when you need to take a step back and be honest about if you gave it your best shot. If you did, then let it go and allow the other members of the organization to do their own jobs however they think is best.
- bick_nyers 4y ago
  Admitting you gave it your best shot is incredibly difficult for those who are overly self-critical or suffer from imposter syndrome. For me I had to accept that even if it wasn't my best shot it was good enough, and any system relying on perfection to be successful is inherently unstable.
  - JamesSwift 4y ago
    Thats a good point, its not about convincing yourself you've done _everything_ you could. Theres almost always the nuclear option of quitting. But its about choosing your battles appropriately and giving it "enough" of an effort to say that you gave it an honest attempt. Hopefully then circle back and try again next time. Assuming an org that isn't completely off the deep end of toxicity and politics, things do get slightly easier over time as people respect that you are fighting for the right things and are generally correct in your analyses.
corobo 4y ago
I found personal offence in them putting me on a PIP after a hip break (Being on morphine makes you bad at your job?? Give me more than 10 sick days and I'll not be trying to work high as balls, lol). Picture the film Office Space. There were 3 managers for like 14 people. It was insanity. One day I'll write my mashup of The Office and Office Space based on working there now the NDA is expired haha. Nothing whistleblowery, just hilariously silly stuff happening constantly. We agreed via my solicitor that that was a dumb move to have made and they settled so I'd go away. It later turned out I was working with undiagnosed ADHD so it might not have been all bad all the time but man I'd die on a lot of hills back then. I used to wonder who got the bad luck from me being employee #13, me or them haha. Freelance now. Y'all solve your own office problems, I'm not getting involved.
fatnoah 4y ago
> Corollary 1. Who can, and sometimes does, un-rot the fish from the bottom? An insane employee. Someone who finds the forks, crashes, etc. a personal offense, and will repeatedly risk annoying management by fighting to stop these things. Especially someone who spends their own political capital, You're not alone. I am this person, but I also have the advantage of being management. In one case, I led a 9 month ninja effort refactor an entire spaghetti monolith in semi-opposition to my boss' (CEO) wishes. We did it very smartly, though, which was to have a plan in place that was to a) have a plan b) focus on observability in the final product and c) used "extreme campfire rules" to implement. First steps were hard, which was where we completely reorganized everything into logical services with defined APIs within the monolith. During the couple months, overall product velocity slowed, so we tread with care and hustled to get stuff out on time. After that point, the resulting code sanity increased velocity so we could focus on things like revamping logging to be massively more useful, better data migrations, consistent deploy process for developer machines, dev integration server, staging, and production servers, and implementation of automated service and integration testing. The net result of 9 months of work was shipping tons of new features, virtually eliminating any down time (from hours a month to minutes per year), and a net loss of about 20% of the codebase. It was a smashing success that I couldn't tell anyone else on the management team about. I did get the ultimate payoff a couple years later when we were acquired by a $30B company and received many kudos during the technical due diligence process for the state of our architecture and reliability.
bick_nyers 4y ago
This is me. At my last job I was doing 3 jobs at once. 1 was what people THOUGHT my actual job was (gotta support the old system to buy myself enough time to roll out the new system, 1 was an additional job to get promoted/salary brought up to industry standards (risk manager for health tech., it didn't work), and 1 (what I was actually hired for 2+ years ago) was doing a rewrite properly to solve 50% of the engineering problems plaguing the company for near a decade once and for all (got it to 99% completion, but has been stuck in QA and Compliance hell for 8 months now on legacy features that are 1 out of 1 million requests). Oh but I accidentally did job #1 too well so now the rewrite I originally got hired to do is now not a priority on anyone's mind. Oh and I did job #2 so well that now I am getting daily requests from Compliance, and they are acting like my boss, as if the Architect, PM, overstepping and undertrained CS reps. and actual boss wasn't enough. Ok now I'm just venting at this point but it's therapeutic. I feel as though I've aged 10 years in the past 2 and I burned out very bad 4 months ago, still haven't recovered. Unemployed now. The worst part? I'm not sure I'm not going to try it again. Should I accept "mediocraty"? Should I strive to leverage my abilities to the fullest to truly be transformative in technology? Maybe I should just focus on getting "fuck you" money so I can work for free on things that actually have an impact.
kthejoker2 4y ago
If I've learned one thing, repeatedly, experience by painful experience: Time is an illusion, professional time doubly so. Don't waste it worrying about what might have been or never was, accept your failures, be magnanimous about others', and always work to make things better tomorrow. Maybe there's a Sliding Doors world out there where you can try all the possibilities and see where they take you, but time's arrow flows in one direction here. So choose the paths that you think move things up and to the right, and if you find yourself heading down and to the left, have a laugh and try again.

mcv 4y ago

Not all managers are that involved in implementation details. My experience is that most managers value deliverables: new features for users. Software engineers value good structure and reducing technical debt. Good managers listen to their engineers and let them tackle tech debt, and smart engineers tell managers that tackling tech means they can deliver new features faster and more reliably in the future.

jahewson 4y ago
> Software engineers value good structure and reducing technical debt A small minority of them do. As far as I can tell what most software engineers value is the act of writing code.
- mcv 4y ago
  Well alright. I value the act of writing pretty code. But in many teams, I often see managers wanting more features, while I frequently see the devs argue for taking some time to address technical debt. Maybe there's some selection bias in me always being one of those devs.
- aflag 4y ago
  In my experience most developers just want to reduce the cognitive load as much as possible. That sometimes means rewriting a lot of things so they make sense to them.
- maximus-decimus 4y ago
  I value good software. I ENJOY writing code.
Lutger 4y ago
Managers do value the value of solving technical debt, because ultimately these changes maintain and improve the ability to deliver features. The problem is they often are unable to see how technical improvements affect the capacity to deliver. It doesn't help that developers also sometimes can't see it, and make mistakes overengineering or improving something that is of little value. In this sense it is a bit like the prevention paradox during the pandemic. If you are successful in preventing an outbreak, people will hate you for it because most people only feel the pain of the measures they had to take, and the absence of an outbreak only shows them those measures were useless. Then, to worsen things, there are also genuine mistakes in handling the pandemic and those are forever used as proof the measures are useless and its proponents incompetent. It really takes a lot of discernment to cut through all this.

dang 4y ago

Discussed at the time: People can read their manager's mind - https://news.ycombinator.com/item?id=10820158 https://news.ycombinator.com/item?id=10820158 - Dec 2015 (60 comments)

noduerme 4y ago

Lotta specific bitterness here. This reads a lot like a manifesto from someone about to shoot up their office. One example: >> A manager enjoys "software architecture", design patterns, and language lawyer type of knowledge Sorry, what is "language lawyer type of knowledge"? Does the OP mean the ability of others to better articulate and convince the manager of the reasons for making certain architectural decisions? There's something about the phrase "language lawyer type of knowledge" which is specifically derisive of engineers who are committed to the larger task and willing to make a case for their approach. It's a phrase which aims to diminish the value of reasoned debate in communicating pros and cons of various approaches; it's practically an ad hominem attack against anyone who uses words to make a point. My read of this was that the person who wrote it got fired for poor communication skills, was bitter, and penned a poorly written attempt at post-justifying their failure.

flangola7 4y ago
I read "language lawyering" as a person who sees language not as a means to communicate ideas in good faith, but as a weapon, a means to an end. The type of person who will nitpick and engage in prescriptive behaviors like quoting literal dictionary definitions back at a person rather than address the meaning and intent that they have obviously conveyed.
- noduerme 4y ago
  Maybe, but this was used in the same breath as design patterns and software architecture. Those both are inevitably opinionated. I personally don't think engineers should get married to one set of patterns or architecture; we should keep learning on the job and find new tools, the best tools that suit the schema. But conflating what may well be good arguments for a design pattern with bad-faith "lawyering" shows a high level of contempt for the people OP would be working with, and suggests OP was more put off by the style of debate than they were by the content.
wheybags 4y ago
Pretty sure they mean arcana like the nitty gritty of how to parse a function pointer declaration in c (from reading the spec, which is written like law). Could be wrong though.

bcherny 4y ago

This article reads like this person has not worked in a well run engineering organization. In a good org: - Managers do not set goals. Teams set goals (EM, TL, PM, DS, etc. need to collaborate on the goal and be bought into it). - There is a system of checks to make sure goals are good. Teams need to make sure their leadership is bought into their goals, and that the goals ladder up to company goals. - Managers do not prescribe technical approaches. This is something TLs should do. - TLs are empowered to propose and work on infra and tech debt that are harder to measure with KPIs. These still need milestones and some measure of success.

SideburnsOfDoom 4y ago
> reads like this person has not worked in a well run engineering organization. Could be, it's not unusual. You might be surprised how common it is. And it is useful to address the real world of that.
- bcherny 4y ago
  For sure. I hope it helps others to understand how an eng org should be run, so that they can help adjust their org’s approach. If incentives and process aren’t set up right, there’s only so much you can do to bandaid over the dysfunction.
thesumofall 4y ago
I might misread you. I would believe the best approach is a top-down / bottom-up approach that combines strategic directives with tactical and local goals. Otherwise, you would essentially say that the owners of a company would not be allowed to shape the direction of their own company, but that they would have to accept to be convinced by whatever the individual teams come up with. There are many valid goals that will never make sense for the individual teams to prioritize on their own but require a mix of top-down / bottom-up goal setting
- bcherny 4y ago
  I agree. From my comment: > Teams need to make sure their leadership is bought into their goals, and that the goals ladder up to company goals.

hathym 4y ago

Why did the employee bring a mirror to work? To reflect the boss's thoughts back to him!

steveBK123 4y ago

This is just "stated preferences" vs "revealed preferences", and teams understanding what managers actually care about from experienced with those revealed preferences.

smcin 4y ago

Good 2015 article, but some extra considerations that rarely get explicitly mentioned: - the construction of a system of incentives/goals(/'recognition') is a large component in building a team/organization - people within the same org often have different incentives, and possibly over different timeframes; sometimes very different timeframes. Sometimes time-bound, sometimes event-bound (achieve X before IPO/Series X/ options vest/market crashes). - often incentives are constructed to set teams/depts at each others' throats, while paying lip-service to the concept of cooperation: salespeople get compensated short-term for getting sales, marketing get compensated for generating buzz and promising new features, QA and build get compensated for stability, performance, absence of bugs, engineering (typically) compensated for a basket of metrics intended to deliver product-market fit and growth. Essentially the VCs figure that within a year they will either fire the VP of Sales or Engineering. - the canonical example is a salesperson selling a deal with a toxic customer or overpromising nonexistent stuff which engineering won't be able to deliver, then pocketing their sales commission, buying the luxury car and quietly exiting the building - incentives can be conflicting between departments (this ain't Barney the Dinosaur), and designing that well is a Goldilocks quantity. Often you don't know the (actual) incentives/goals/OKR of your manager, or other depts: - sometimes, with enough time, you can deduce by observing (who got 'recognized'? promoted? fired? reorg'ed? quit? and who actually did the work?) You ask around and figure who's going up and who's going down. - I've seen a case where in retrospect a manager was simply there for the duration of his sponsored executive MBA, and didn't give a hoot about product-related metrics. The most important thing for him was not to actually fix anything or release anything, but keep the other managers around him sweet and happy, even though the company was losing huge market share and failing, stock was tanking. Eventually (soon after graduating from the MBA) he jumped off the sinking ship and went back to his former employer. (The company failed and its assets were firesaled. But this didn't affect his career. This first made me realize that it's quite common to have a massive disparity in (nominal or actual) incentives) > People generally don't do what they're told, but what they expect to be rewarded for. Corollary 3b: what they're rewarded for is often not explicitly stated. So people have a certain innate or acquired level of cynicism about what they're officially being told ('communicated'), and how they can game it and collude with others. Counter-Corollary 1. + Corollary 2.: before attempting to un-rot the fish from either the top or (especially) the bottom, stop, look both ways, listen to your intuition and think "Who appears to be benefiting, or at least is unperturbed by the current state of rottenness? What do their incentives seem to be? [and who in turn constructed those incentives?]" Corollary 2. When does the fish un-rot from the top? > Finally, don't expect people to enlighten you and tell you what your blind spots are. Becoming a manager means losing the privilege of being told what's what. It's a trap to think of oneself as just the same reasonable guy and why wouldn't they want to talk to me. The right question is, why would they? That part, tucked down the bottom, is brilliant, and should probably be the lede paragraph.