> 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?
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.
I hear you. I'm one of those people too, or I was (maybe). What got me wasn't even the core failures themselves, but all the lies and pretense about it. If we are to ignore our fundamental flaws in order for sales to score their next big hit, at least be honest. Just admit we only really care about quarterly results. Don't pretend we are on some wonderful mission instead of the duct taping ragtag conmans that we really are. I can handle the mess, kind of, I surely can't handle all the falsehoods.
But people do need some level of chill to hold it all together. If there isn't some sunny shiny thing on the horizon at least, then it is too hard to put in any effort and get out of bed. The worse the situation is, the greater the need for soothing. I have a personal law that says something like: the level of organizational dysfunction is directly and inversely proportional to the degree to which reality is allowed to disturb a positive story. You could call it institutional codependency.
In really dysfunctional organizations you will find shocking levels of denial and incongruence between the state of affairs and what can be spoken about without being sidelined. This breeds bitterness, because there is an actual and insurmountable difference in needs. Some people can't thrive in a minefield of falsehoods. Being earnest is an actual need, for some people it is more important than being fun and positive. For others people, it is the other way around.
The biggest lesson for me was that there really is a difference between organizations in this kind of dysfunction. The trick is to kick yourself in the butt and move around. Bitterness is just a signal you stayed too long in a context where you are stifled. Even if the ideal context doesn't exist, there are likely places where you are vastly more appreciated and it is worth the effort to try and find them.
This whole article and comment section, but especially this thread and the parent, made think of "How to Get Promoted", particularly the advice to "be happy and easy-going", "don't make anyone look bad" and "perform rituals enthusiastically."
I don't agree with all of this, but I feel it's an excellent comment that touches on the need for a balance between sincerity and good vibes. I'm currently in the situation where dysfunction is turning me bitter, and recognising that's not what I want.
You’re not wrong, but there’s nuance here. A pessimist will often hide behind the shield of sincerity. But they are often no more capable of fixing problems than the cheerleader, which means not only are they ineffectual, they make everyone else feel bad along the way.
Ultimately you want competent, realistic and upbeat.
I agree, actually. Bitterness doesn't solve anything. Dysfunctional orgs are usually beyond salvation.
For me, the question is: can I say the deadline is unrealistic and off by 2x as a matter of fact and can we discuss how to deal with that, as a matter of fact, not blaming anyone? Just the facts.
Sometimes this is impossible because the mere mention of it makes me the pessimist and is putting everyone in a bad mood.
Yeah. I do agree that if you find yourself being bitter, it is the org, usually, not you.
> can I say the deadline is unrealistic and off by 2x as a matter of fact and can we discuss how to deal with that, as a matter of fact, not blaming anyone? Just the facts.
I'd hope so, but at my company the conversation would either end (CTO would say "I got to go join another meeting") or it would be interpreted as you "saying no."
One thing that really came into focus for me once I got into my 40s and had had a chance to see all different manner of successful and dysfunctional teams from many different vantage points is that any binary assessment of an org as good or bad is overly reductive. Most orgs have good sides and bad sides, and a mature perspective is to either do what one can do improve the bad parts, or cut bait and find a new org. I realize this is a privileged perspective, but competent software engineers have options. I truly believe that if you're not part of the solution you're part of the problem—not in a malicious way, but systemic dysfunction is far more common than malintent, so if you truly see no path in contributing towards a better work environment then what are you doing with your life?
Maybe, yes. I tend to agree. From their point of view however, the people who don't value fun as much are whiny and annoying, and maybe we are but probably because we aren't heard.
Well, speaking for myself, I tend to be much less whiny about things if I have the feeling someone takes me seriously.
I value fun, but I think my problem is I go to work to WORK. You would think companies would want this. I accept some level of "not work" because that is life, but when I'm actively being prevented from doing work due to dysfunction, I get really upset.
I guess I should just be "overemployed" so I can retire earlier LOL.
I don't think so. I value fun and positivity and I think I'm the opposite of fake. I don't have patience for being fake.
I'll attend every social event, I clock out roughly on time, and I do what's needed of me without making a fuss. Want that stupid feature? Sure, as long as it's not morally reprehensible, I'll build it.
What's any of that got to do with being fake? I don't suck up, and do things for the sake of promotion, I don't lie about things. If you ask for my opinion, I'll share it, even if it's negative. I don't think that makes me unfun though.
I'm not talking about a "stupid feature" I'm talking about your CTO saying something like "let's move to containerized SQLite instances for all our databases instead of using sql server" etc..
Just, unnecessary, arguably-insane things. I don't give a fuck if you want a stupid feature. That isn't my job. My job is, however, to give input into if I think certain changes to the platform are going to be detrimental. Just saying "yeah bossss!!!" to everything is not my job, and would be shallow and fake.
I got better over the years. In a later organization I actually gathered signatures to become the staff council for the employees(a German thing). People thought it was ironic, because some of the the things I wanted where also in conflict with what the previous staff council wanted. I noticed a couple of things though:
1. The union did not actually help the workers nor care. Even though a lot of them paid pretty high monthly membership fees.
2. The staff council leaderships usually get corrupted after a while once they get some perks from management.
I got pushed out eventually, I received a settlement, because they didn't want me to open my mouth about the things I'd seen. I had some major impact in their long term results, especially since they had grift going on in their construction project which would have led to 10 year old networking infrastructure be installed. Physical access control that didn't have wirings installed and core drills with no space left for future extensions.
I could have stayed for another 5-10 years since I was not firable, but they made sure to pull me of projects, so I wouldn't look behind the curtain. I still have most of the employees and some of the senior leadership report these things to me though because of the trust they had in me.
It's a hard path to choose and it's a thankless job in terms of career. The question is how happy are you will all your peers and subordinates and even the non grifting subcontrators(in case of the construction) be grateful to you.
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.
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.
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.
>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.
The company lives on sales, not on software. Sale of flakey software is better than delay to un-flakey it.
Wow. This response showed me a big blind spot of my own, and how I could have been using the same language to talk about something completely different without clarifying a basic point in advance: I've written customer-facing software and in-house employee software for 20+ years. But almost all the code I've ever written has been for companies whose business is something other than software... and where I have worked for software companies has been in the early prototypes and beta phases where bugs were an embarrassment. I've never worked on retail software that had generational code debt - or even ones that had a dedicated sales team driving features and development. I have worked with people who were more interested in feature explosion than in nailing down existing issues... and assuming they're not the boss of the company, I consider it important to speak up about fixing issues before moving on. But that is, I realize, a completely different ballgame than working for a company that primarily sells software to end users.
Brother, this is the norm at small to large companies. Maybe five person shops need to get things done, but once a company hits like 15-20 people, yeah... people get hired and stay hired because people like them, rarely because of their output.
Yes, its important (and very hard) to walk the fine line between pushing back and letting those above you do their jobs. At the end of the day, not every decision is yours to make. Its important that you ensure that every decision is an _informed_ decision however.
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.
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.
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.
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.
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.
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.
> 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
This is my experience with good managers but also that they sympathize with the difficulties and successes of design and implementation otherwise they'll act in a way the hurts morale. Here it helps being a former individual contributor in the role being managed.
This is just "stated preferences" vs "revealed preferences", and teams understanding what managers actually care about from experienced with those revealed preferences.
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.
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
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.
Engineering managements job is to make sure the whole endeavor of building and maintaining the software is successful. In order to do this they must wield some power as necessary, but if everything is running smoothly as described above then it’s demotivating for them to be stepping on the toes of the cross-functional ICs (Eng, PM, DS).
This might make EM seem like a cushy job, but in practice things are always a mess at various levels, and a good EM needs to wade in and sort out all kinds of conflicts that can lead to entire teams outputs being wasted. To do a good job the EM must have solid technical death, good product and business understanding, and excellent listening and communication skills. More specific needs depend on the company, org and situation in question. Being a good engineering manager is incredibly difficult in large orgs, and it’s rare to find them giving the difficulty in assessing them and the resulting market for lemons making it viable career path to fail upwards (or at least sideways).
A manager’s job is to make themselves obsolete. This means hiring, retention, mentorship, training, sharing context, etc. until the team is self-sufficient.
Generally, managers work on ensuring the business keeps surviving. That’s their main responsibility. Staffing, retention, alignment of sales/ development, etc.
Most good management does that well in harmony with the product. Bad management focuses on that at the expense of the product.
Plenty of companies have the roles of technical leads and managers overlap which honestly can make a lot of sense depending of how your engineering org is setup.
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.
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.
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.
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.
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.
That's correct. It's a reference to Brooks' The Mythical Man-Month[1], in which the term "language lawyer" was used to refer to someone who knows all the details about the specs of a programming language.
I didn't read it as lawyering of C code... maybe I misunderstood that. If that's the case I'd retract my statement. I thought they meant other engineers using "lawyering" skills ...(logical communication)... to convince a manager to take one architectural path over another.
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?