13 ms·

Load 'em up and throw 'em under the bus

662 points by picture 4y ago

clnq 4y ago
An important cautionary tale to the “I’ll take on the world to save the project” types. Do you want working the job of 3-4 people while being paid a salary of one to become your baseline, not meeting which would make you an under-performer in the eyes of the management? If not, stop and delegate. If yes, good luck burning out while blocking your own career progression. I’ve seen this in so many tech companies and with so many well-intentioned engineers. And it always ends sadly. Either in a burn out resignation (worse if the break-up is messy because the company is desperate to keep the “high performer”), or a dead career (even if the engineer can sustain the pace, management won’t want to promote them out of the situation). Or worse, if the engineer becomes stuck in this situation, they will ruin their health through stress, and then the consequences of returning to 1x workload and being an “under-performer” will follow anyway. It can go poorly in so many ways, but only poorly.
- jjtheblunt 4y ago
  Every way you just mentioned seems to depend on a layer of managers assessing things? I ask that because I've observed in both deeply hierarchical (and dysfunctional as all hell) Amazon, and super flat (at least for a long time) Apple, and your characterizations only fit the bureaucracies. (I've observed the same at other places as well.)
  - clnq 4y ago
    You bring up an interesting point. I have not seen this in flat or small companies as I have not worked in many. But I imagine that those surrounding the engineer will still feel that their expectations are no longer met if the engineer tries to return to normality from their superhero role. Though perhaps the colleagues might understand the full circumstances of the situation better in a tighter or less hierarchical team. Ultimately, if someone has the engineer's back when they need to stop being the proverbial "Atlas who holds up the world", then maybe things could end better. But there are few managers that have the insight to notice it and grace to do something about it. The kind manager (or colleague) described in the article we are discussing is not common. So whatever the circumstances, generally it does end badly if the engineer significantly over-commits to save the project.
    - jjtheblunt 4y ago
      True
- franciscop 4y ago
  Since my top-comment is #1 and it's a bad example, I'll give a positive example here. In this company I joined I worked really hard. It was very exciting work, an innovative startup, pretty good pay (for my locale), great coworkers and manager. I still worked around ~8h/day, but those were VERY intense 8-hours and after few weeks it was clear that our office/team was shipping A LOT faster than other teams in HQ. It was a really nice combination IMHO: - Our manager was amazing at getting the work requests and converting them into technical tasks/projects, while shielding us of the BS that was literally raining from HQ. No one lasted too long when he eventually left, and they even closed the office a bit after. - Because of the timezone difference, we had meetings for 1-2h in the morning and then calm for the rest of the day to execute on those tasks. Our manager had more, but that was a really good balance for IC. - While we had different levels of seniority (and all hired as the same "mid-level"), we worked well together and all were reasonably knowledgeable, no one needed handholding. So yeah, after few months/1 year we got some major projects finished. One of which I made the major technical part, for which I struggled and fought like never before, and successfully delivered it. Our CEO used this project even for presentations to our investors and clients (was supposed to be an internal tool). So my manager got me from mid-level ("Software Engineer") to Staff Engineer, a whole 2-level bump and 40%-50% salary increase approx. So sometimes working hard does pay off :)
  - Glawen 4y ago
    you were just leveling with your teammates which were also hard workers. I experienced this in my last job and I'm trying to reproduce it, but I find it difficult to recreate in another environment. It is different than being a super hero and hand hold a project while your teammates watch you from the side.
- PartiallyTyped 4y ago
  > If yes, good luck burning out while blocking your own career progression. Is there a career blockage if you don't stick around? The more you do, the more you learn, the more you learn the faster you do, the faster you do, the more you do. > management won’t want to promote them out of the situation Management can pay a higher salary to retain them. A vertical career into management is not for everyone. > they will ruin their health through stress, and then the consequences of returning to 1x workload and being an “under-performer” will follow anyway. Doesn't look like that if you leave a paper trail of everything you do.
  - clnq 4y ago
    > A vertical career into management is not for everyone. That's a different question which is even more polarizing - should good engineers become managers. But to be clear, I brought up promotion because that's why many people make the decision to take on these responsibilities to save the project. It could be a pay raise or a promotion to a higher engineering level. > Doesn't look like that if you leave a paper trail of everything you do. It works this way from what I've seen, I'm sorry to say. But I've seen a lot. The paper trail is good evidence in a grievance situation but it's hard to restore one's reputation through the grievance process - formal or informal. > Is there a career blockage if you don't stick around? No, and leaving, to my mind, is the easiest healthy choice if an engineer finds themselves in this situation. However, it is still an undesirable situation to put oneself in if one wants career growth. If leaving is the way they wish to achieve that, it's better to just leave than to suffer for a while and then leave. If they wish to achieve career growth in the company, this will block them. In any case, it's wasted time from a career advancement perspective. You could say that working in a high-pressure situation would teach the engineer something, and maybe it's true. But mostly it will make the engineer make many mistakes and be overwhelmed. Which is why most people argue that learning in a relaxed environment is much more practical. Even people who study extreme medicine (battlefield medicine, mountain rescues, and similar topics) study it in a safe environment. They do real life simulations but in a supervised way. Throwing an engineer into the fire to teach them handling a pressure-cooker situation would be much like asking an extreme medicine doctor to learn on the battlefield. You could say they would learn, but probably a lot of what they would learn is to make mistakes.
- crabbone 4y ago
  This is a very simplistic view of the situation. It doesn't usually work like that in the real world. In the company I left few years ago I was a lead developer in a department which started with me alone, then at times grew up to four developers and shrank to just two. Here's what it looked like: we were almost always advertising a position in my department, and about once a week I had to meet another Python developer with X years of experience in infra, who was barely literate... No, really, it was that bad. After each such interview, I had to go back to my boss and decide whether we should give this guy / girl a chance, or should we spend more time and money looking for more candidates. I tried both strategies. I tried to hold out until we find a better candidate, and we were simply wasting time running in circles. I tried to advocate hiring someone simply on a basis that they looked promising. I had to promise my boss to bring them up to speed, and that was a year of misery of dealing with someone who made such a painstakingly slow progress, being such a huge time sink that in the end I had to abandon that person to have at least something done. Infra projects, especially in large-scale products tend to be this way. Outside, theres' a huge pool of "Python programmers", but most of them are really "Django programmers", they have no idea how computers work, and will require years of mentorship to obtain that knowledge. Few will see that as valuable as it's not a common enough requirement. Few will have the determination or passion to get to the point where they are confident and independent that they may continue their education on their own. On the other hand, those who gained such experience don't like infra jobs for the very reason that they end up recruiting novice programmers and leave for more system-like jobs. And this dynamic affects every department both at a macro and at a micro level: people either learn how to be good and leave, or they never do and get replaced by the next batch. In the end, it's fairly typical that infra department will be "carried" by a single employee who's spend ages working there + a number of younglings who come and go never contributing anything of note. I wouldn't say it's a management problem. Infra isn't the only department which sees that kind of dynamics. QA is pretty much the same way. Front-end used to be more like that, but I don't know what the situation is today. It's caused by the pathological relationship which reinforces itself with time that prevents expertise from growing both locally in an org and generally in the field.
- oosk 4y ago
  It doesn't always end sadly -- it really depends on the individual and the company. In my case, I ended up doing the job of maybe 5-10 developers for a year and a half leading up to the launch of a product at a large tech company. It was tough, but I believed in the product and wanted it to succeed, so I didn't mind putting in the extra time. I was also fairly young at the time, so I could handle marathon coding sessions without burning out. After it launched (successfully), I developed a reputation within the company that let me basically have my pick of projects for the remainder of my time there. Additionally, I was awarded a 7-figure stock grant that ended up being worth 8 figures by the time it fully vested, so it worked out well financially too. I view that project as sort of a career-defining moment, and I'm extremely glad I did it.
- treis 4y ago
  I don't think the engineer in the OP did a good job. They were the last link in the knowledge chain. It's on them to pass the knowledge along and onboard the newbies. Is it possible that they got saddled with a bunch of incompetent and lazy new hires? Sure. But by simple numbers it's more likely that the hero was the problem than it is that 4 other people are incompetent beyond help.
  - _corvo_ 4y ago
    I don't think the engineer in the OP did a good job. They were the last link in the knowledge chain. It's on them to pass the knowledge along and onboard the newbies. I find it weird that you’re blaming the Engineer and not the managers or culture. Isn’t it on them to make sure that knowledge is passed as well?
    - treis 4y ago
      That's forcing the engineer to do what they should be doing. You can blame them for not doing that but that doesn't absolve the engineer of not doing what they should be doing.
hakunin 4y ago
One mismatch I often see between engineers and management. Engineers: "I must not be doing the best I can, because I'm not keeping up with work. Gotta work faster, gotta do better." Managers: "engineers are professionals with strong opinions who will always tell me when/if they need anything to help them get their work done. Right? If they aren't saying anything, it's their own fault, right? They're adults, right?" Unfortunately many engineers (and humans generally) can't easily recognize and articulate what they need. One theory of mine is that we assign senior-sounding roles in this industry too readily. "Senior engineer" sounds like they would know how to handle this, but while they might be great at programming, they often have little experience recognizing their own limitations, asking for help/resources, and understanding that this level of self-awareness and focus on outcomes would make them look better, not worse. If I was to give one piece of advice to an engineer in a similar position: you will always look more mature and professional if you evaluate your situation and explain what sort of help you need, than if you silently keep burning yourself out while the quality keeps slipping. If you're management and you actually reprimand them for asking for help, you will have trouble retaining engineers. It would be justifiable for them to look for work elsewhere on these grounds.
- SkyPuncher 4y ago
  I'll put a simpler, more likely explanation. It's dangerous to complain about being overworked. It puts hard barriers on your limits.
  - hakunin 4y ago
    I assume you're explaining the fear, because the opposite is true. You'd be lifting a barrier. The barrier is you doing all the legwork while having all the institutional knowledge. Business cannot afford you doing the legwork, you need to be mentoring and delegating.
    - imilk 4y ago
      Completely agree. If you never say that you are at capacity you become the dumping ground for work that other people should be doing.
hd95489 4y ago
I’m surprised they didn’t house this person. The key to a dysfunctional company is to completely screw over your key workers and drive them out while promoting poor preforming people
- ryandrake 4y ago
  I was expecting that kind of twist too because I’ve seen it in so many companies: Heroic old timer doing the job of 4 engineers because the poor performers were not carrying their own weight. One of the poor performers, instead of doing his work, spends his time schmoozing, boasting, and bullshitting his managers, who then reward him with promotion and fire the old timer. The team falls apart because they fired the only person doing anything, and the brown-noser successfully blames the ex-old-timer. Take as old as time…!
  - klabb3 4y ago
    Absolutely. The majority of old timers are heroes who don’t need to stay and tend to their understaffed garden. However. There are also old timers who refuse to delegate, only ever giving mindless tasks and not training the new folks to be self-sufficient. “They would just screw it up, it’s better if I do just do it, it’s both faster and better.” You could argue that’s a leadership problem as well, of course, but my response would be that if you’re the only one who understands a system, you are a leader, and leaders have a responsibility even if they aren’t managers by title.
    - scruple 4y ago
      > You could argue that’s a leadership problem as well, of course, but my response would be that if you’re the only one who understands a system, you are a leader, and leaders have a responsibility even if they aren’t managers by title. Hear, hear! Anyone who has on-boarded to some legacy system has probably experienced this from one end or the other. The trouble seems to be in getting the heroes, as it were, to recognize that they have a responsibility to properly on-board and train, while simultaneously getting their managers to give them the space to do this work and properly prioritizing it (while also helping to keep the fires at bay... Easily 50% of the on-boarding challenges I have faced in my career were because the person who was responsible for on-boarding me was constantly fire-fighting by themselves).
busthrowaway844 4y ago
Throwaway for raw honesty. I've worked under an engineering leader for a few years now that I think must get a bonus to meet every quarterly goal. Others must also, based on their behavior around these events. I've felt the weight of the team being so understaffed for the workload for so long that I've pendulum swung from high morale (i.e this is important good work) to such an abyss of low morale. I'm having a hard time shaking it and I could really stand to be more productive on things I find interesting and important about the work. I guess this article resonated with me enough to post about it. Makes you weary after awhile.
babbledabbler 4y ago
This is a common pitfall for software engineers and one that is easy to fall into especially if you haven't gone through it before. Dysfunctional technical systems are symptoms of dysfunctional political systems. If the political system is not rehabilitated, the technical system will continually evolve dysfunctional traits no matter how much development effort is spent. It falls to management to ensure the political system is functioning properly but software engineers should keep this in mind to avoid getting caught up in the gears of such systems.
draw_down 4y ago
[dead]
ChuckMcM 4y ago
This is a good tale, and one that folks really should take to heart. I have observed when good engineers get an over developed sense of ownership they will move "heaven and earth" to get things done. If you're managing one of these heroes it is your job to spread the load of what they do across the team so that no individual is so overloaded everything suffers. New managers who had been engineers before management and care about the work always tell me "I feel like I'm not doing anything, I should be helping or something." And I tell them, your job is to look. Look at your team, who is working late nights, who isn't. Who is meeting their commitments, who isn't. Let their actions guide you getting them what they need to be the best they can be, things that you, and only you, as the manager can get for them. That often means blocking incoming requests for more "stuff" (features what not), carving out time for your "doers" to help bring the new people up to speed. As part of an IBM manager training video there was a discussion about how the US Navy trains every person on a submarine to do every job because you never know when the person whose job it is won't be available to do it. That really resonated with me and I tried in future groups to try to overlap skills and cross train folks so that everyone could both appreciate what their peers were doing, but could also help out in a crunch if one part of the work needed more effort briefly.
- jeffrallen 4y ago
  > Your job is to look A really dramatic way of learning this is to be a volunteer firefighter. After a couple of years of experience where you know all the roles, they have you try out incident commander in an exercise. Now your job is to keep your head up, your eyes open, your hands off the equipment and manage your team. And you fail and fail again until you finally understand the role of a tactical commander (line manager).
  - ChuckMcM 4y ago
    I really love that example. Thanks for sharing it.
  - bluGill 4y ago
    The problem is you can do any single job better than the people under you, but by doing any job you can't keep track of anything else and so all the other jobs you are not touching get worse by more than the one you do.gets better.
somsak2 4y ago
interesting story but wrong conclusion. this isn't about a management problem but rather a case of an IC taking on too much themselves. had they never attempted to do the work of 3-4 people, this general problem would have become apparent much sooner. instead they overworked themselves and put their own role at risk for a sub par rating. do not allow yourself to be overworked for more than a few days at most. it never ends well.
- jeffrallen 4y ago
  > for more than a few days Yes! But do occasionally fall on a grenade for your team. Pull one 12 hour day to get a deployment plan just right, to check that one last rollback scenario, etc. Plan 8 hours for a bug and then follow it for 24, if the rabbit hole it takes you into is important. Develop the discernment to be able to say "this is where I'm going to overwork one time this quarter". And say it, literally out loud if you need to. You need to be able to look yourself in the mirror and say, "my boss counts on me" before you can go and tell him the same thing.
  - H8crilA 4y ago
    Why though? I don't want to overwork a single day per week/quarter/year. And I have absolutely no fairness problems with that. If it can't be done this week it will be done next week. It's your problem to deal with it, and my problem to make the tech work.
    - jeffrallen 4y ago
      Because knowing something is important to the organization and to you and choosing to do it is not overworking. It is delivering the necessary effort at the right time to end up proud of your work. And with a reasonable boss, there's nothing stopping you from knocking off early the next Friday.
  - whitemary 4y ago
    No, thanks.
- 4y ago
wpietri 4y ago
As Gerry Weinberg wrote in Secrets of Consulting, "No matter how it looks at first, it's always a people problem." It's situations like this that keep getting me sucked into management issues. I join something just wanting to build good stuff. But the problems are so rarely technical ones. I remember once when a friend of mine had joined a company with terrible bug problems. They brought me in to solve a particularly nasty one where a key client's key users were having regular web app failures that presented as network issues. And also to give them my take on the devs. After a week of late nights, I discovered that certain versions of IE had weird Keep-Alive behaviors, which then had a bad interaction with their load balancers and their web servers. I changed some configurations so the older IE versions had each HTTP collection closed immediately, which was slightly slower but always worked. Victory achieved, thorn pulled from paw, etc, etc. That sounded like as technical a problem as they come. But the root causes were really people problems. The key client was a large company with an IT department that was overloaded and underfunded, so lots of users were stuck on ancient Windows versions. And my friend's company had a salesperson as a CEO, one who would promise new features to close deals without ever checking with the development team. They were massively overloaded. They had to ship and ship and ship, leaving no time for testing or debugging or polishing. They were just drowning in bugs, so the CEO thought they were bad developers. But given time and room, they could have figured it out just as well. So I told my friend the developers were great; it was the dysfunctional relationship between the CEO and the overstuffed backlog that was the problem. I never heard how it turned out, but I have my suspicions.
kart23 4y ago
> Then I got lucky and intercepted a few of the zanier ideas while he was still under the stupid-high load, and we got some other people to step up and start spreading the load around. it’s also up to that IC to recognize they are being overworked, and spread that load themselves. And if they’re having trouble doing so, surface that to the manager and get help.
- vianneychevalie 4y ago
  That’s the core of the issue: when you’re so overworked that you (a) don’t have the time to reflect upon it and thus (b) don’t realize that the situation is terrible. It’s a not a new trope, Jack London’s Martin Eden addresses the inability of physical workers to gain culture and reflect on their situation simply through the exhaustion they’re subject to.
- ok_dad 4y ago
  Or, you get replaced or fired. Don’t bet on most managers to actually help.
  - midoridensha 4y ago
    Even if your direct manager wants to help, he may be overruled by his manager or the upper management. Your direct manager frequently doesn't have any ability to do much except pass information up.
- wiseowise 4y ago
  That’s if you have coworkers capable enough.
physicsguy 4y ago
I think I’m this person in my current role, and it’s 100% management related. I interviewed for a team and hand picked some very skilled people to try and relieve my load… and then the company decided to move them off of that project and onto another big contract they’ve signed. At the same time I’m just completely frazzled. Very hard to get yourself out of this situation when there is no buy in from the organisation that there is an issue.
- H8crilA 4y ago
  Leave, leave, leave. The universal solution to all problems in a market(like) economy.
  - physicsguy 4y ago
    Right now it’s not an option as I will be going off on an extended period of paid paternity leave in a few weeks, but I’ll be looking after that.
    - scruple 4y ago
      Sure, but you can look during. You don't owe them anything. You've earned paternity leave and they haven't earned your tenure beyond it.
megablast 4y ago
Need to learn to say no and push back. Shouldn't need someone to come and tell you this is ok.
- MonkeyMalarky 4y ago
  But you risk a shitty performance review which still almost happened. Management should not be giving bad reviews for not meeting unrealistic goals.
dizhn 4y ago
I don't know why, maybe because I came across them around the same time, but whenever I read rachelbytheway I am hearing Paula Poundstone's voice in my head.
ok_dad 4y ago
> I got to know him, and found out that he wasn't batshit or even malicious. He was just under WAY too much load, and was shipping insanity as a result. I felt like this at my last job but they fired me instead when I asked for time off without pay for a few months.
jimjonescoolaid 4y ago
Duh!
unxdfa 4y ago
Am in this situation. The 3-4 load isn’t caused by me but is the minimum work necessary to keep the company from crashing and burning. The cause was a cargo cult restructuring that caused enough ceremony, overhead and friction that ingrained expertise left. The company made no effort to retain people either and won’t pay enough to attract new talent. The solution is simple and will be applied within the next quarter.
- kozinc 4y ago
  If you're the one with the 3-4 load, can you rely on the company to hire more people? For the worker, the solution is to find a job with a smaller load. For the company, it's to either to find more people to join or to convince the person who manages the high load to stay on as long as possible.
  - unxdfa 4y ago
    Well they had a chance to and failed so I'm fucking off.
- anthlax 4y ago
  Atlas shrugged
  - unxdfa 4y ago
    That's an interesting perspective.
lacker 4y ago
It's a tough situation to handle, because if someone is simply struggling at their job, it can have the same symptoms. They claim they have too much work to do, and important projects always end up delayed, with their tasks being the ones that are delaying everyone. As a manager you need to make a judgment call about how much work they are actually taking on, but that can be tricky when you're less familiar with the codebase than the individual is. Either way, you still want to move critical tasks off their plate.
hdhddhshhshd 4y ago
[dead]
franciscop 4y ago
This is very common? The most extreme example I've seen by a Dilbert-level hapless manager was assigning me and a coworker to a fullstack project. I was doing front-end, and he was doing backend, and by the nature of the project AND some bad tech decisions the backend was an order of magnitude more complex than the front-end. I did pick up React to learn then so at least I also had some of a challenge. That's on the technical side, on the project side it was even worse, I had an earlier MVP to base my designs on while he (backend guy) had to deal with multiple basically hostile 3rd party vendors. The predictable happened, after just 1 month it was 100% clear to me that it was impossible to work at the same pace, so I mocked up all the endpoints I expected, built most of the front-end and was done in 5-6 months, after multiple iterations with the previous business person who made the MVP. The backend (remember, 1 guy) had just gotten the Auth right basically, and almost nothing else in working conditions yet. My manager reaction? He was pissed that I had done it against a mock API instead of the inexisting real one, told me to wait until the end-points were ready and integrate them and wouldn't give me any other work otherwise despite of my best arguments. What happened is during the next 3 months I was basically writing and rewriting the app, becoming very proficient in React. Then the manager started to hear heat from above, and he started to complain about my coworker in a very similar situation of this article, so I started to look for a new job. That backend coworker left few days after me and never came back (I was probably the only non-hostile one, even friendly, to him at work by that point).
- scary-size 4y ago
  What prevented you from helping him? edit: This comes off as a rhetorical question. I'm really just interested what happened here. The project was assigned to both of you. I imagine that implies some responsibility for the whole of the project. You spent your "free" time learning React. Was there an organisational blocker that prevented you from helping him out, in any capacity?
  - coldtea 4y ago
    That his expertise (and desired field) is a totally different layer?
t344344 4y ago
I love companies like that. If you are a bit proactive, you can snatch the easiest parts, and get rewarded just for sending reports.
gniv 4y ago
This is an interesting management-training problem. When you're left with a single veteran developer in a team, what to do? The instinct would be to give them extra support/leeway etc. But I wonder if the better solution is to simply remove that person from the team and replace them with a junior. Short-term pain but long-term gain, maybe?
- dtech 4y ago
  That's only a good idea if the veteran actively prevents the situation from getting better, e.g. by being possesive and contrarian, trives on being the hero etc. This does tend to happen a lot in these situations. The team will also need to have the skill to actually do better. If the veteran is not sabotaging things firing only throws away the most valuable source of knowledge the team has.
gorgoiler 4y ago
Anyone who follows this blog — it is frequently linked to from this place — would be able to understand the code words and time frame to figure out which company this refers to. It’s a small world and it’s not difficult to guess which piece of tech, which team, and which engineers and managers were involved as well. The story is a good one but, like all gossip, it’s a guilty pleasure. When someone spreads gossip about a third party then you can assume they do it about you as well. It is toxic and the opposite of building trust. If the engineers referred to in the story were asked for comment or OK’d the post (not that they have to) then I’m completely off base with everything I just said.
- ornornor 4y ago
  I for one have no clue whatsoever about which company this might be, and even less who the individual people (other than the author) might be. The world is bigger than SV, most of us have never set foot there or know anybody there.
- deleted 4y ago
  [deleted]
- doitLP 4y ago
  Please enlighten us. I figure the company is likely Amazon, and it’s some core service like EC2 given that underpins basically everything and has different agents running on each box that are handled by different teams like CloudWatch?
  - philjohn 4y ago
    Not Amazon - the clue is "You know, Cat Pics" - what's a service where you can share photos of things, like your life, your pets etc?
- walleeee 4y ago
  Is there not an enormous difference between spreading gossip (in my mind, always about someone in particular, which this is absolutely not, or at least not to anyone not neck deep in bay area software circles) and relating instructive, anonymized anecdotes? I'm not sure how you're reading this as gossip.
bragadiru_mafia 4y ago
Probable network behaviour. The other team members are part of a “network” and their goal is to 1) get non network members to do the work and then 2) get rid of them and 3) take over more projects, expand hold on the org. Crafty!
danjac 4y ago
I've been in that position once early on in my career - single developer bearing the load of a project that should have been the work of 3-4 people. It didn't end well - I got the thing done but performance, quality etc were way below par and I got away from the project and company as fast as I could. Nowadays with more experience (not just technical) I would have seen the shit show coming a mile off. The key factor here was that management dictated a timetable then pulled a fast one and decided to pre-release with a "soft launch" three-quarters of the way through. It was insanity, and older-me would have quit on the spot and told them where to stick it where the sun didn't shine. As it was I got something out the door more or less on time, but it was absolutely nothing else to be proud of. My advice to younger-me and junior developers in general is that management are generally clueless about software development, even if they did it once in the past (hello Elon Musk) and part of your job is to push back against unrealistic deadlines and features and if you don't do that, you are doing yourself and your company a disservice. Don't let hubris and fear get the better of you.
mdekkers 4y ago
I’m in this story and I don’t like it. I’m currently in a similar situation, and am desperately looking to move on. The market is not kind right now. We have a properly dilbert-esque management layer of PHBs with meaningless titles running around demanding that all technical aspects of the project are explained to them in detail, several times, blame their frustration of not understanding on our inability to explain properly, and then overrule every recommendation and design decision. Most of my emails are more disclaimers then content and everything is BCCed to my private email, because disasters are waiting to happen and this is an industry where “disaster” is weeks in the global news cycles. It’s incredibly exhausting.
op00to 4y ago
Note management never took accountability and nothing really changed in the management situation.
a_c 4y ago
Management problem is an engineering problem. Management is how you engineer your organization. I don't know how big the organization the author is working at, too big in my opinion, too big in complexity. What I observe, could be wrong - the team "writing" the service is different from the team "fixing" the service. It is like letting one guy write code, the other guy compile code, but on a team level. Feedback of quality is lost. - "Then I got lucky and intercepted a few of the zanier ideas". It is common in tech companies nowadays, but I think is really not ideal, one party for ideation, one part for implementation. This is not making full use of engineers in my opinion. Give me a recipe, I cook for you. Engineer can be both chef and a cook, but people seem to be happy being a cook. Feedback between ideas and implementation is lost. - "The surprise came later, when the biannual review cycle ". If it is performance review. It is too sparse. Engineers might already be gone and good luck keeping the service up - "They wanted to give this person some bullshit sub-par rating". Lacking objective measurement. Maybe that's why they run the review biannually. Subjective rating is time consuming. I imagine it having to compile "evidence" from various source, and give "justification". You always want the feedback be quick and whole. Code compilation fast, test run fast, CI/CD fast, HTTP return fast, usage gathering fast, the feedback about whether your piece of code is useful fast, the feedback about team's performance fast. In engineering, we take for granted that things can happen almost in real-time. But in management, somehow feedback (reports, performance) need to be "compile" X times per Y period. In engineering, we somehow have the thinking that abstract only when the code is repeated the 3rd time. Hence we avoid abstracting the wrong thing. In management, we often form an abstraction (team) based on some vague notion on how things are compartmentalize. Oh yeah let's have 2 frontend and 2 backend on the completely new recommendation feature. That's the team formation. Engineering and management have a lot in common
- jeremyjh 4y ago
  There was not another team fixing the bugs. I understood her original team to be some kind of SWAT team that works across the org to triage and pin root cause of high impact issues and outages. That kind of team deals with incidents, but they don’t fix software bugs. How could they possibly do that across many different teams and codebases?
tristor 4y ago
I have been that guy, unfortunately nobody stepped in to prevent me from being thrown under the bus, and it ended up with me departing a company where I otherwise loved the people I worked with. It ultimately ended up being one of the driving factors of some burn out, that in working through made me leave engineering altogether for a different role. This can happen especially in startups, because you're always resource constrained, growing faster than you can handle (you hope), and everyone wears multiple hats. That is all fine, generally, it only becomes a problem when you never (after several cycles of hiring) get help to remove some hats and/or you end up being held responsible for failures outside your control due to that situation. Now in a different role, I make it a point to try to identify teams that are overloaded, shield them from unfair expectations, and advocate for additional resourcing. If you bother looking, it's generally pretty obvious, but most managers are focused on managing up, not managing down, so ICs at the bottom are ignored unless they're a source of waves that come back through management onto their chain.
chiefalchemist 4y ago
This sounds much like The Phoenix Project. https://www.amazon.com/Phoenix-Project-DevOps-Helping-Business/dp/0988262509 https://www.amazon.com/Phoenix-Project-DevOps-Helping-Busine... It's a solid read for anyone in engineering or close (e.g., project manager).
flybrand 4y ago
It's straight out of Goldratt and Theory of Constraints, ultimately the constraint becomes leadership. How many issues can leaders address in a day? How do they prioritize the personnel needs of their team?
languagehacker 4y ago
Anyone else get the impression that this blames managers without thinking about making sure the members of the team made cross-training a priority? There's really not enough context to have a good opinion on this anecdote. Rachel has a very specific perspective, as always, and I often think she interprets her observations to fit that perspective. Don't we all.
marcus_holmes 4y ago
Looking forward to hearing the similar stories that will be coming from Twitter in a year or two. Egotistical shouty bosses are a great source of tech war stories :)
dcchambers 4y ago
Beautifully written and I'm happy there was a positive outcome in this instance. I feel like most of us have a similar story. I don't know if it's unique to tech, but every team I've been a part of has had a "well everyone who originally built this product left and we don't really know how to manage it so it's just sort of hobbling along but management won't prioritize decommissioning or supporting it so it keeps all of us up at night." Do other industries have this issue? How can we fix this problem?
- fuzzfactor 4y ago
  >How can we fix this problem? You're being called upon to fix "stupid".
deleted 4y ago
[deleted]
D-Coder 4y ago
Sometimes you have to manage your manager.
throwawaaarrgh 4y ago
Blaming management seems like a symptom of a larger problem: people continuing to work for unethical companies. If you're not willing to quit due to bad management, they'll just keep having bad management. I've never heard of a company that cared more about the welfare of employees than the company's bottom line. The natural result is employees are expendable assets, like machinery.
crudgen 4y ago
Often ICs stay for 2 years in a company, start a project, but aren't happy with org/management/career progression and move to the next company before having to deal with the problems they have created. Eventually other developers who weren't assigned on this project now also need to maintain this project, without having the detailed knowledge of existing mechanisms and prevalent tech debt. Those developers did work on their own project and now need to care about both or even more projects. The developers are basically invisible to upper management. PMs are the point of contact which translate between higher managment and the devs. Higher management often operates on such a high level, that they are disconnected from reality and work on a abstract level, basically using the inputs of the PMs. The PMs often also were never that technical, instead they realized soon that career progression is only possible in mgmt. This leads to the incentive to spawn new projects a PM can lead. Eventually there are too many (poorly defined) projects with too few (original) developers. New developers are unhappy since they have to work with legacy code and the devs who are spread over multiple projects and still have some original knowledge, don't have enough time/incentive to properly take care about project development (plus, spent a lot of time in "agile" meetings for each project). Adding no career paths for devs (since the company only focuses on mgmt), this leads again to the starting point, where the ICs leave the company.

662 points by picture 4y ago

clnq 4y ago

An important cautionary tale to the “I’ll take on the world to save the project” types. Do you want working the job of 3-4 people while being paid a salary of one to become your baseline, not meeting which would make you an under-performer in the eyes of the management? If not, stop and delegate. If yes, good luck burning out while blocking your own career progression. I’ve seen this in so many tech companies and with so many well-intentioned engineers. And it always ends sadly. Either in a burn out resignation (worse if the break-up is messy because the company is desperate to keep the “high performer”), or a dead career (even if the engineer can sustain the pace, management won’t want to promote them out of the situation). Or worse, if the engineer becomes stuck in this situation, they will ruin their health through stress, and then the consequences of returning to 1x workload and being an “under-performer” will follow anyway. It can go poorly in so many ways, but only poorly.

jjtheblunt 4y ago
Every way you just mentioned seems to depend on a layer of managers assessing things? I ask that because I've observed in both deeply hierarchical (and dysfunctional as all hell) Amazon, and super flat (at least for a long time) Apple, and your characterizations only fit the bureaucracies. (I've observed the same at other places as well.)
- clnq 4y ago
  You bring up an interesting point. I have not seen this in flat or small companies as I have not worked in many. But I imagine that those surrounding the engineer will still feel that their expectations are no longer met if the engineer tries to return to normality from their superhero role. Though perhaps the colleagues might understand the full circumstances of the situation better in a tighter or less hierarchical team. Ultimately, if someone has the engineer's back when they need to stop being the proverbial "Atlas who holds up the world", then maybe things could end better. But there are few managers that have the insight to notice it and grace to do something about it. The kind manager (or colleague) described in the article we are discussing is not common. So whatever the circumstances, generally it does end badly if the engineer significantly over-commits to save the project.
  - jjtheblunt 4y ago
    True
franciscop 4y ago
Since my top-comment is #1 and it's a bad example, I'll give a positive example here. In this company I joined I worked really hard. It was very exciting work, an innovative startup, pretty good pay (for my locale), great coworkers and manager. I still worked around ~8h/day, but those were VERY intense 8-hours and after few weeks it was clear that our office/team was shipping A LOT faster than other teams in HQ. It was a really nice combination IMHO: - Our manager was amazing at getting the work requests and converting them into technical tasks/projects, while shielding us of the BS that was literally raining from HQ. No one lasted too long when he eventually left, and they even closed the office a bit after. - Because of the timezone difference, we had meetings for 1-2h in the morning and then calm for the rest of the day to execute on those tasks. Our manager had more, but that was a really good balance for IC. - While we had different levels of seniority (and all hired as the same "mid-level"), we worked well together and all were reasonably knowledgeable, no one needed handholding. So yeah, after few months/1 year we got some major projects finished. One of which I made the major technical part, for which I struggled and fought like never before, and successfully delivered it. Our CEO used this project even for presentations to our investors and clients (was supposed to be an internal tool). So my manager got me from mid-level ("Software Engineer") to Staff Engineer, a whole 2-level bump and 40%-50% salary increase approx. So sometimes working hard does pay off :)
- Glawen 4y ago
  you were just leveling with your teammates which were also hard workers. I experienced this in my last job and I'm trying to reproduce it, but I find it difficult to recreate in another environment. It is different than being a super hero and hand hold a project while your teammates watch you from the side.
PartiallyTyped 4y ago
> If yes, good luck burning out while blocking your own career progression. Is there a career blockage if you don't stick around? The more you do, the more you learn, the more you learn the faster you do, the faster you do, the more you do. > management won’t want to promote them out of the situation Management can pay a higher salary to retain them. A vertical career into management is not for everyone. > they will ruin their health through stress, and then the consequences of returning to 1x workload and being an “under-performer” will follow anyway. Doesn't look like that if you leave a paper trail of everything you do.
- clnq 4y ago
  > A vertical career into management is not for everyone. That's a different question which is even more polarizing - should good engineers become managers. But to be clear, I brought up promotion because that's why many people make the decision to take on these responsibilities to save the project. It could be a pay raise or a promotion to a higher engineering level. > Doesn't look like that if you leave a paper trail of everything you do. It works this way from what I've seen, I'm sorry to say. But I've seen a lot. The paper trail is good evidence in a grievance situation but it's hard to restore one's reputation through the grievance process - formal or informal. > Is there a career blockage if you don't stick around? No, and leaving, to my mind, is the easiest healthy choice if an engineer finds themselves in this situation. However, it is still an undesirable situation to put oneself in if one wants career growth. If leaving is the way they wish to achieve that, it's better to just leave than to suffer for a while and then leave. If they wish to achieve career growth in the company, this will block them. In any case, it's wasted time from a career advancement perspective. You could say that working in a high-pressure situation would teach the engineer something, and maybe it's true. But mostly it will make the engineer make many mistakes and be overwhelmed. Which is why most people argue that learning in a relaxed environment is much more practical. Even people who study extreme medicine (battlefield medicine, mountain rescues, and similar topics) study it in a safe environment. They do real life simulations but in a supervised way. Throwing an engineer into the fire to teach them handling a pressure-cooker situation would be much like asking an extreme medicine doctor to learn on the battlefield. You could say they would learn, but probably a lot of what they would learn is to make mistakes.
crabbone 4y ago
This is a very simplistic view of the situation. It doesn't usually work like that in the real world. In the company I left few years ago I was a lead developer in a department which started with me alone, then at times grew up to four developers and shrank to just two. Here's what it looked like: we were almost always advertising a position in my department, and about once a week I had to meet another Python developer with X years of experience in infra, who was barely literate... No, really, it was that bad. After each such interview, I had to go back to my boss and decide whether we should give this guy / girl a chance, or should we spend more time and money looking for more candidates. I tried both strategies. I tried to hold out until we find a better candidate, and we were simply wasting time running in circles. I tried to advocate hiring someone simply on a basis that they looked promising. I had to promise my boss to bring them up to speed, and that was a year of misery of dealing with someone who made such a painstakingly slow progress, being such a huge time sink that in the end I had to abandon that person to have at least something done. Infra projects, especially in large-scale products tend to be this way. Outside, theres' a huge pool of "Python programmers", but most of them are really "Django programmers", they have no idea how computers work, and will require years of mentorship to obtain that knowledge. Few will see that as valuable as it's not a common enough requirement. Few will have the determination or passion to get to the point where they are confident and independent that they may continue their education on their own. On the other hand, those who gained such experience don't like infra jobs for the very reason that they end up recruiting novice programmers and leave for more system-like jobs. And this dynamic affects every department both at a macro and at a micro level: people either learn how to be good and leave, or they never do and get replaced by the next batch. In the end, it's fairly typical that infra department will be "carried" by a single employee who's spend ages working there + a number of younglings who come and go never contributing anything of note. I wouldn't say it's a management problem. Infra isn't the only department which sees that kind of dynamics. QA is pretty much the same way. Front-end used to be more like that, but I don't know what the situation is today. It's caused by the pathological relationship which reinforces itself with time that prevents expertise from growing both locally in an org and generally in the field.
oosk 4y ago
It doesn't always end sadly -- it really depends on the individual and the company. In my case, I ended up doing the job of maybe 5-10 developers for a year and a half leading up to the launch of a product at a large tech company. It was tough, but I believed in the product and wanted it to succeed, so I didn't mind putting in the extra time. I was also fairly young at the time, so I could handle marathon coding sessions without burning out. After it launched (successfully), I developed a reputation within the company that let me basically have my pick of projects for the remainder of my time there. Additionally, I was awarded a 7-figure stock grant that ended up being worth 8 figures by the time it fully vested, so it worked out well financially too. I view that project as sort of a career-defining moment, and I'm extremely glad I did it.
treis 4y ago
I don't think the engineer in the OP did a good job. They were the last link in the knowledge chain. It's on them to pass the knowledge along and onboard the newbies. Is it possible that they got saddled with a bunch of incompetent and lazy new hires? Sure. But by simple numbers it's more likely that the hero was the problem than it is that 4 other people are incompetent beyond help.
- _corvo_ 4y ago
  I don't think the engineer in the OP did a good job. They were the last link in the knowledge chain. It's on them to pass the knowledge along and onboard the newbies. I find it weird that you’re blaming the Engineer and not the managers or culture. Isn’t it on them to make sure that knowledge is passed as well?
  - treis 4y ago
    That's forcing the engineer to do what they should be doing. You can blame them for not doing that but that doesn't absolve the engineer of not doing what they should be doing.

hakunin 4y ago

One mismatch I often see between engineers and management. Engineers: "I must not be doing the best I can, because I'm not keeping up with work. Gotta work faster, gotta do better." Managers: "engineers are professionals with strong opinions who will always tell me when/if they need anything to help them get their work done. Right? If they aren't saying anything, it's their own fault, right? They're adults, right?" Unfortunately many engineers (and humans generally) can't easily recognize and articulate what they need. One theory of mine is that we assign senior-sounding roles in this industry too readily. "Senior engineer" sounds like they would know how to handle this, but while they might be great at programming, they often have little experience recognizing their own limitations, asking for help/resources, and understanding that this level of self-awareness and focus on outcomes would make them look better, not worse. If I was to give one piece of advice to an engineer in a similar position: you will always look more mature and professional if you evaluate your situation and explain what sort of help you need, than if you silently keep burning yourself out while the quality keeps slipping. If you're management and you actually reprimand them for asking for help, you will have trouble retaining engineers. It would be justifiable for them to look for work elsewhere on these grounds.

SkyPuncher 4y ago
I'll put a simpler, more likely explanation. It's dangerous to complain about being overworked. It puts hard barriers on your limits.
- hakunin 4y ago
  I assume you're explaining the fear, because the opposite is true. You'd be lifting a barrier. The barrier is you doing all the legwork while having all the institutional knowledge. Business cannot afford you doing the legwork, you need to be mentoring and delegating.
  - imilk 4y ago
    Completely agree. If you never say that you are at capacity you become the dumping ground for work that other people should be doing.

hd95489 4y ago

I’m surprised they didn’t house this person. The key to a dysfunctional company is to completely screw over your key workers and drive them out while promoting poor preforming people

ryandrake 4y ago
I was expecting that kind of twist too because I’ve seen it in so many companies: Heroic old timer doing the job of 4 engineers because the poor performers were not carrying their own weight. One of the poor performers, instead of doing his work, spends his time schmoozing, boasting, and bullshitting his managers, who then reward him with promotion and fire the old timer. The team falls apart because they fired the only person doing anything, and the brown-noser successfully blames the ex-old-timer. Take as old as time…!
- klabb3 4y ago
  Absolutely. The majority of old timers are heroes who don’t need to stay and tend to their understaffed garden. However. There are also old timers who refuse to delegate, only ever giving mindless tasks and not training the new folks to be self-sufficient. “They would just screw it up, it’s better if I do just do it, it’s both faster and better.” You could argue that’s a leadership problem as well, of course, but my response would be that if you’re the only one who understands a system, you are a leader, and leaders have a responsibility even if they aren’t managers by title.
  - scruple 4y ago
    > You could argue that’s a leadership problem as well, of course, but my response would be that if you’re the only one who understands a system, you are a leader, and leaders have a responsibility even if they aren’t managers by title. Hear, hear! Anyone who has on-boarded to some legacy system has probably experienced this from one end or the other. The trouble seems to be in getting the heroes, as it were, to recognize that they have a responsibility to properly on-board and train, while simultaneously getting their managers to give them the space to do this work and properly prioritizing it (while also helping to keep the fires at bay... Easily 50% of the on-boarding challenges I have faced in my career were because the person who was responsible for on-boarding me was constantly fire-fighting by themselves).

busthrowaway844 4y ago

Throwaway for raw honesty. I've worked under an engineering leader for a few years now that I think must get a bonus to meet every quarterly goal. Others must also, based on their behavior around these events. I've felt the weight of the team being so understaffed for the workload for so long that I've pendulum swung from high morale (i.e this is important good work) to such an abyss of low morale. I'm having a hard time shaking it and I could really stand to be more productive on things I find interesting and important about the work. I guess this article resonated with me enough to post about it. Makes you weary after awhile.

babbledabbler 4y ago

This is a common pitfall for software engineers and one that is easy to fall into especially if you haven't gone through it before. Dysfunctional technical systems are symptoms of dysfunctional political systems. If the political system is not rehabilitated, the technical system will continually evolve dysfunctional traits no matter how much development effort is spent. It falls to management to ensure the political system is functioning properly but software engineers should keep this in mind to avoid getting caught up in the gears of such systems.

draw_down 4y ago

[dead]

ChuckMcM 4y ago

This is a good tale, and one that folks really should take to heart. I have observed when good engineers get an over developed sense of ownership they will move "heaven and earth" to get things done. If you're managing one of these heroes it is your job to spread the load of what they do across the team so that no individual is so overloaded everything suffers. New managers who had been engineers before management and care about the work always tell me "I feel like I'm not doing anything, I should be helping or something." And I tell them, your job is to look. Look at your team, who is working late nights, who isn't. Who is meeting their commitments, who isn't. Let their actions guide you getting them what they need to be the best they can be, things that you, and only you, as the manager can get for them. That often means blocking incoming requests for more "stuff" (features what not), carving out time for your "doers" to help bring the new people up to speed. As part of an IBM manager training video there was a discussion about how the US Navy trains every person on a submarine to do every job because you never know when the person whose job it is won't be available to do it. That really resonated with me and I tried in future groups to try to overlap skills and cross train folks so that everyone could both appreciate what their peers were doing, but could also help out in a crunch if one part of the work needed more effort briefly.

jeffrallen 4y ago
> Your job is to look A really dramatic way of learning this is to be a volunteer firefighter. After a couple of years of experience where you know all the roles, they have you try out incident commander in an exercise. Now your job is to keep your head up, your eyes open, your hands off the equipment and manage your team. And you fail and fail again until you finally understand the role of a tactical commander (line manager).
- ChuckMcM 4y ago
  I really love that example. Thanks for sharing it.
- bluGill 4y ago
  The problem is you can do any single job better than the people under you, but by doing any job you can't keep track of anything else and so all the other jobs you are not touching get worse by more than the one you do.gets better.

somsak2 4y ago

interesting story but wrong conclusion. this isn't about a management problem but rather a case of an IC taking on too much themselves. had they never attempted to do the work of 3-4 people, this general problem would have become apparent much sooner. instead they overworked themselves and put their own role at risk for a sub par rating. do not allow yourself to be overworked for more than a few days at most. it never ends well.

jeffrallen 4y ago
> for more than a few days Yes! But do occasionally fall on a grenade for your team. Pull one 12 hour day to get a deployment plan just right, to check that one last rollback scenario, etc. Plan 8 hours for a bug and then follow it for 24, if the rabbit hole it takes you into is important. Develop the discernment to be able to say "this is where I'm going to overwork one time this quarter". And say it, literally out loud if you need to. You need to be able to look yourself in the mirror and say, "my boss counts on me" before you can go and tell him the same thing.
- H8crilA 4y ago
  Why though? I don't want to overwork a single day per week/quarter/year. And I have absolutely no fairness problems with that. If it can't be done this week it will be done next week. It's your problem to deal with it, and my problem to make the tech work.
  - jeffrallen 4y ago
    Because knowing something is important to the organization and to you and choosing to do it is not overworking. It is delivering the necessary effort at the right time to end up proud of your work. And with a reasonable boss, there's nothing stopping you from knocking off early the next Friday.
- whitemary 4y ago
  No, thanks.
4y ago

wpietri 4y ago

As Gerry Weinberg wrote in Secrets of Consulting, "No matter how it looks at first, it's always a people problem." It's situations like this that keep getting me sucked into management issues. I join something just wanting to build good stuff. But the problems are so rarely technical ones. I remember once when a friend of mine had joined a company with terrible bug problems. They brought me in to solve a particularly nasty one where a key client's key users were having regular web app failures that presented as network issues. And also to give them my take on the devs. After a week of late nights, I discovered that certain versions of IE had weird Keep-Alive behaviors, which then had a bad interaction with their load balancers and their web servers. I changed some configurations so the older IE versions had each HTTP collection closed immediately, which was slightly slower but always worked. Victory achieved, thorn pulled from paw, etc, etc. That sounded like as technical a problem as they come. But the root causes were really people problems. The key client was a large company with an IT department that was overloaded and underfunded, so lots of users were stuck on ancient Windows versions. And my friend's company had a salesperson as a CEO, one who would promise new features to close deals without ever checking with the development team. They were massively overloaded. They had to ship and ship and ship, leaving no time for testing or debugging or polishing. They were just drowning in bugs, so the CEO thought they were bad developers. But given time and room, they could have figured it out just as well. So I told my friend the developers were great; it was the dysfunctional relationship between the CEO and the overstuffed backlog that was the problem. I never heard how it turned out, but I have my suspicions.

kart23 4y ago

> Then I got lucky and intercepted a few of the zanier ideas while he was still under the stupid-high load, and we got some other people to step up and start spreading the load around. it’s also up to that IC to recognize they are being overworked, and spread that load themselves. And if they’re having trouble doing so, surface that to the manager and get help.

vianneychevalie 4y ago
That’s the core of the issue: when you’re so overworked that you (a) don’t have the time to reflect upon it and thus (b) don’t realize that the situation is terrible. It’s a not a new trope, Jack London’s Martin Eden addresses the inability of physical workers to gain culture and reflect on their situation simply through the exhaustion they’re subject to.
ok_dad 4y ago
Or, you get replaced or fired. Don’t bet on most managers to actually help.
- midoridensha 4y ago
  Even if your direct manager wants to help, he may be overruled by his manager or the upper management. Your direct manager frequently doesn't have any ability to do much except pass information up.
wiseowise 4y ago
That’s if you have coworkers capable enough.

physicsguy 4y ago

I think I’m this person in my current role, and it’s 100% management related. I interviewed for a team and hand picked some very skilled people to try and relieve my load… and then the company decided to move them off of that project and onto another big contract they’ve signed. At the same time I’m just completely frazzled. Very hard to get yourself out of this situation when there is no buy in from the organisation that there is an issue.

H8crilA 4y ago
Leave, leave, leave. The universal solution to all problems in a market(like) economy.
- physicsguy 4y ago
  Right now it’s not an option as I will be going off on an extended period of paid paternity leave in a few weeks, but I’ll be looking after that.
  - scruple 4y ago
    Sure, but you can look during. You don't owe them anything. You've earned paternity leave and they haven't earned your tenure beyond it.

megablast 4y ago

Need to learn to say no and push back. Shouldn't need someone to come and tell you this is ok.

MonkeyMalarky 4y ago
But you risk a shitty performance review which still almost happened. Management should not be giving bad reviews for not meeting unrealistic goals.

dizhn 4y ago

I don't know why, maybe because I came across them around the same time, but whenever I read rachelbytheway I am hearing Paula Poundstone's voice in my head.

ok_dad 4y ago

> I got to know him, and found out that he wasn't batshit or even malicious. He was just under WAY too much load, and was shipping insanity as a result. I felt like this at my last job but they fired me instead when I asked for time off without pay for a few months.

jimjonescoolaid 4y ago

Duh!

unxdfa 4y ago

Am in this situation. The 3-4 load isn’t caused by me but is the minimum work necessary to keep the company from crashing and burning. The cause was a cargo cult restructuring that caused enough ceremony, overhead and friction that ingrained expertise left. The company made no effort to retain people either and won’t pay enough to attract new talent. The solution is simple and will be applied within the next quarter.

kozinc 4y ago
If you're the one with the 3-4 load, can you rely on the company to hire more people? For the worker, the solution is to find a job with a smaller load. For the company, it's to either to find more people to join or to convince the person who manages the high load to stay on as long as possible.
- unxdfa 4y ago
  Well they had a chance to and failed so I'm fucking off.
anthlax 4y ago
Atlas shrugged
- unxdfa 4y ago
  That's an interesting perspective.

lacker 4y ago

It's a tough situation to handle, because if someone is simply struggling at their job, it can have the same symptoms. They claim they have too much work to do, and important projects always end up delayed, with their tasks being the ones that are delaying everyone. As a manager you need to make a judgment call about how much work they are actually taking on, but that can be tricky when you're less familiar with the codebase than the individual is. Either way, you still want to move critical tasks off their plate.

hdhddhshhshd 4y ago

[dead]

franciscop 4y ago

This is very common? The most extreme example I've seen by a Dilbert-level hapless manager was assigning me and a coworker to a fullstack project. I was doing front-end, and he was doing backend, and by the nature of the project AND some bad tech decisions the backend was an order of magnitude more complex than the front-end. I did pick up React to learn then so at least I also had some of a challenge. That's on the technical side, on the project side it was even worse, I had an earlier MVP to base my designs on while he (backend guy) had to deal with multiple basically hostile 3rd party vendors. The predictable happened, after just 1 month it was 100% clear to me that it was impossible to work at the same pace, so I mocked up all the endpoints I expected, built most of the front-end and was done in 5-6 months, after multiple iterations with the previous business person who made the MVP. The backend (remember, 1 guy) had just gotten the Auth right basically, and almost nothing else in working conditions yet. My manager reaction? He was pissed that I had done it against a mock API instead of the inexisting real one, told me to wait until the end-points were ready and integrate them and wouldn't give me any other work otherwise despite of my best arguments. What happened is during the next 3 months I was basically writing and rewriting the app, becoming very proficient in React. Then the manager started to hear heat from above, and he started to complain about my coworker in a very similar situation of this article, so I started to look for a new job. That backend coworker left few days after me and never came back (I was probably the only non-hostile one, even friendly, to him at work by that point).

scary-size 4y ago
What prevented you from helping him? edit: This comes off as a rhetorical question. I'm really just interested what happened here. The project was assigned to both of you. I imagine that implies some responsibility for the whole of the project. You spent your "free" time learning React. Was there an organisational blocker that prevented you from helping him out, in any capacity?
- coldtea 4y ago
  That his expertise (and desired field) is a totally different layer?

t344344 4y ago

I love companies like that. If you are a bit proactive, you can snatch the easiest parts, and get rewarded just for sending reports.

gniv 4y ago

This is an interesting management-training problem. When you're left with a single veteran developer in a team, what to do? The instinct would be to give them extra support/leeway etc. But I wonder if the better solution is to simply remove that person from the team and replace them with a junior. Short-term pain but long-term gain, maybe?

dtech 4y ago
That's only a good idea if the veteran actively prevents the situation from getting better, e.g. by being possesive and contrarian, trives on being the hero etc. This does tend to happen a lot in these situations. The team will also need to have the skill to actually do better. If the veteran is not sabotaging things firing only throws away the most valuable source of knowledge the team has.

gorgoiler 4y ago

Anyone who follows this blog — it is frequently linked to from this place — would be able to understand the code words and time frame to figure out which company this refers to. It’s a small world and it’s not difficult to guess which piece of tech, which team, and which engineers and managers were involved as well. The story is a good one but, like all gossip, it’s a guilty pleasure. When someone spreads gossip about a third party then you can assume they do it about you as well. It is toxic and the opposite of building trust. If the engineers referred to in the story were asked for comment or OK’d the post (not that they have to) then I’m completely off base with everything I just said.

ornornor 4y ago
I for one have no clue whatsoever about which company this might be, and even less who the individual people (other than the author) might be. The world is bigger than SV, most of us have never set foot there or know anybody there.
deleted 4y ago
[deleted]
doitLP 4y ago
Please enlighten us. I figure the company is likely Amazon, and it’s some core service like EC2 given that underpins basically everything and has different agents running on each box that are handled by different teams like CloudWatch?
- philjohn 4y ago
  Not Amazon - the clue is "You know, Cat Pics" - what's a service where you can share photos of things, like your life, your pets etc?
walleeee 4y ago
Is there not an enormous difference between spreading gossip (in my mind, always about someone in particular, which this is absolutely not, or at least not to anyone not neck deep in bay area software circles) and relating instructive, anonymized anecdotes? I'm not sure how you're reading this as gossip.

bragadiru_mafia 4y ago

Probable network behaviour. The other team members are part of a “network” and their goal is to 1) get non network members to do the work and then 2) get rid of them and 3) take over more projects, expand hold on the org. Crafty!

danjac 4y ago

I've been in that position once early on in my career - single developer bearing the load of a project that should have been the work of 3-4 people. It didn't end well - I got the thing done but performance, quality etc were way below par and I got away from the project and company as fast as I could. Nowadays with more experience (not just technical) I would have seen the shit show coming a mile off. The key factor here was that management dictated a timetable then pulled a fast one and decided to pre-release with a "soft launch" three-quarters of the way through. It was insanity, and older-me would have quit on the spot and told them where to stick it where the sun didn't shine. As it was I got something out the door more or less on time, but it was absolutely nothing else to be proud of. My advice to younger-me and junior developers in general is that management are generally clueless about software development, even if they did it once in the past (hello Elon Musk) and part of your job is to push back against unrealistic deadlines and features and if you don't do that, you are doing yourself and your company a disservice. Don't let hubris and fear get the better of you.

mdekkers 4y ago

I’m in this story and I don’t like it. I’m currently in a similar situation, and am desperately looking to move on. The market is not kind right now. We have a properly dilbert-esque management layer of PHBs with meaningless titles running around demanding that all technical aspects of the project are explained to them in detail, several times, blame their frustration of not understanding on our inability to explain properly, and then overrule every recommendation and design decision. Most of my emails are more disclaimers then content and everything is BCCed to my private email, because disasters are waiting to happen and this is an industry where “disaster” is weeks in the global news cycles. It’s incredibly exhausting.

op00to 4y ago

Note management never took accountability and nothing really changed in the management situation.

a_c 4y ago

Management problem is an engineering problem. Management is how you engineer your organization. I don't know how big the organization the author is working at, too big in my opinion, too big in complexity. What I observe, could be wrong - the team "writing" the service is different from the team "fixing" the service. It is like letting one guy write code, the other guy compile code, but on a team level. Feedback of quality is lost. - "Then I got lucky and intercepted a few of the zanier ideas". It is common in tech companies nowadays, but I think is really not ideal, one party for ideation, one part for implementation. This is not making full use of engineers in my opinion. Give me a recipe, I cook for you. Engineer can be both chef and a cook, but people seem to be happy being a cook. Feedback between ideas and implementation is lost. - "The surprise came later, when the biannual review cycle ". If it is performance review. It is too sparse. Engineers might already be gone and good luck keeping the service up - "They wanted to give this person some bullshit sub-par rating". Lacking objective measurement. Maybe that's why they run the review biannually. Subjective rating is time consuming. I imagine it having to compile "evidence" from various source, and give "justification". You always want the feedback be quick and whole. Code compilation fast, test run fast, CI/CD fast, HTTP return fast, usage gathering fast, the feedback about whether your piece of code is useful fast, the feedback about team's performance fast. In engineering, we take for granted that things can happen almost in real-time. But in management, somehow feedback (reports, performance) need to be "compile" X times per Y period. In engineering, we somehow have the thinking that abstract only when the code is repeated the 3rd time. Hence we avoid abstracting the wrong thing. In management, we often form an abstraction (team) based on some vague notion on how things are compartmentalize. Oh yeah let's have 2 frontend and 2 backend on the completely new recommendation feature. That's the team formation. Engineering and management have a lot in common

jeremyjh 4y ago
There was not another team fixing the bugs. I understood her original team to be some kind of SWAT team that works across the org to triage and pin root cause of high impact issues and outages. That kind of team deals with incidents, but they don’t fix software bugs. How could they possibly do that across many different teams and codebases?

tristor 4y ago

I have been that guy, unfortunately nobody stepped in to prevent me from being thrown under the bus, and it ended up with me departing a company where I otherwise loved the people I worked with. It ultimately ended up being one of the driving factors of some burn out, that in working through made me leave engineering altogether for a different role. This can happen especially in startups, because you're always resource constrained, growing faster than you can handle (you hope), and everyone wears multiple hats. That is all fine, generally, it only becomes a problem when you never (after several cycles of hiring) get help to remove some hats and/or you end up being held responsible for failures outside your control due to that situation. Now in a different role, I make it a point to try to identify teams that are overloaded, shield them from unfair expectations, and advocate for additional resourcing. If you bother looking, it's generally pretty obvious, but most managers are focused on managing up, not managing down, so ICs at the bottom are ignored unless they're a source of waves that come back through management onto their chain.

chiefalchemist 4y ago

This sounds much like The Phoenix Project. https://www.amazon.com/Phoenix-Project-DevOps-Helping-Business/dp/0988262509 https://www.amazon.com/Phoenix-Project-DevOps-Helping-Busine... It's a solid read for anyone in engineering or close (e.g., project manager).

flybrand 4y ago

It's straight out of Goldratt and Theory of Constraints, ultimately the constraint becomes leadership. How many issues can leaders address in a day? How do they prioritize the personnel needs of their team?

languagehacker 4y ago

Anyone else get the impression that this blames managers without thinking about making sure the members of the team made cross-training a priority? There's really not enough context to have a good opinion on this anecdote. Rachel has a very specific perspective, as always, and I often think she interprets her observations to fit that perspective. Don't we all.

marcus_holmes 4y ago

Looking forward to hearing the similar stories that will be coming from Twitter in a year or two. Egotistical shouty bosses are a great source of tech war stories :)

dcchambers 4y ago

Beautifully written and I'm happy there was a positive outcome in this instance. I feel like most of us have a similar story. I don't know if it's unique to tech, but every team I've been a part of has had a "well everyone who originally built this product left and we don't really know how to manage it so it's just sort of hobbling along but management won't prioritize decommissioning or supporting it so it keeps all of us up at night." Do other industries have this issue? How can we fix this problem?

fuzzfactor 4y ago
>How can we fix this problem? You're being called upon to fix "stupid".

deleted 4y ago

[deleted]

D-Coder 4y ago

Sometimes you have to manage your manager.

throwawaaarrgh 4y ago

Blaming management seems like a symptom of a larger problem: people continuing to work for unethical companies. If you're not willing to quit due to bad management, they'll just keep having bad management. I've never heard of a company that cared more about the welfare of employees than the company's bottom line. The natural result is employees are expendable assets, like machinery.

crudgen 4y ago

Often ICs stay for 2 years in a company, start a project, but aren't happy with org/management/career progression and move to the next company before having to deal with the problems they have created. Eventually other developers who weren't assigned on this project now also need to maintain this project, without having the detailed knowledge of existing mechanisms and prevalent tech debt. Those developers did work on their own project and now need to care about both or even more projects. The developers are basically invisible to upper management. PMs are the point of contact which translate between higher managment and the devs. Higher management often operates on such a high level, that they are disconnected from reality and work on a abstract level, basically using the inputs of the PMs. The PMs often also were never that technical, instead they realized soon that career progression is only possible in mgmt. This leads to the incentive to spawn new projects a PM can lead. Eventually there are too many (poorly defined) projects with too few (original) developers. New developers are unhappy since they have to work with legacy code and the devs who are spread over multiple projects and still have some original knowledge, don't have enough time/incentive to properly take care about project development (plus, spent a lot of time in "agile" meetings for each project). Adding no career paths for devs (since the company only focuses on mgmt), this leads again to the starting point, where the ICs leave the company.