What else would they do if they weren't answering questions? Write some more CRUD code? I don't know what this person wants or what they expect their job to be. That's probably the underlying issue.
> I had a hard time thinking strategically about product. I was too busy supporting the entire organization on all things related to the product.
so that's a pretty clear indication of what was missing. Instead of being able to recognize broad industry trends and come up with broad product evolutions that meet those needs, this person is stuck answering quibbles about particular customers or particular implementations.
How about his managerial duties? Being constantly dragged into unrelated meetings will make you soon burned out and i think most people with management experience can relate to his writing
In an age where loyalty between employer and employee is long in rear window (if it wasn't just a useful fable from the get-go), all you are left with are the grim permutations of game theory, all wary glances and knife edges barely concealed. Being indispensable is the closest thing you have to security, and as for "stopping learning," well, most companies want you to do that in your off-time, anyway.
Throwing that away to become just another Pac-man gobbling tickets in a maze for the sake of being Agile or whatever reminds me of "...the struggle was finished. He had won the victory over himself. He loved Big Brother" in its joy at self-abnegation.
Reams could be and have been written about estrangement in society, the reduction of human relationships to mere transactionality, but being The Person Who Is Expert At This Thing in your little Dunbar's Number sized company (give or take) beats being some plastic gear, designed to be replaced as a sacrificial component, if you are interested in stability, continuity, or even something as antiquated as pride in your work.
I sort of get it -- at an early job, we had a lot of clientele. I inadvertently memorized, well, everything about them: faces, names, various ID numbers, and so on, and instead of the handy lookups provided, employees would just call me and ask. This got annoying. But I was also twenty-four and managed to push back enough to say, "You have the ability to look all of this up." Being bothered with dumb questions if you have all of this documentation and a wiki or whatever, yes, that is not acceptable, but I think there's a middle ground at least between being the Turing-complaint helpbot and just bolting out of there so you don't have to be The Guy in the Know.
There is something to be said for being indispensible for novel problems, instead of for known problems.
Some of the worst behavior I've seen in both myself and others has come when you can hold your company hostage by refusing to do something. Even when you are using it for 'the greater good', that's not a good look and not a great feeling. You shouldn't have to go with the nuclear option to get something done, even if 5/8ths of your coworkers all feel it's the right thing to do. And many people use it because they can, through some mix of hubris and/or burnout.
When people say things like, "first, fire all the heroes" it's situations like this that they are thinking of, among others.
Oh, fire all the heroes, I have worked at one of those places. The people in the know were let go, as some kind of pre-emptive strike of just that nature. Heaven forfend that anyone but the organization have leverage. This was managed before I had a chance to get a Chesterson's Fence view of the processes.
The result was not good: deciphering the how of things was bad enough, but the why, the contexts of the decisions was utterly gone. Nobody could say why things were done, and so it was either the old joke about the five monkeys or the Second System Effect. Glorious chaos, the confidence of our clients eroded, terror at making changes that might affect the way things had been, dread of not making changes to cope with extant problems.
Thanks, but I'll take the M.A.D. that results from the threat of the nuclear option over someone getting to yank out my heartplug ala Lynch's Dune.
Yeah I'm not sure that's meant to be taken literally, anymore than I think "If you meet Buddha upon the road, kill him," is an incitement to homicide.
The people who have reverence for the heroes are as much or more of a problem as the actual heroes, and they need to be shaken severely. It's going to be ugly any way you slice it because like so many things in software, you're in a position where someone should have yelled "stop" years before and instead things just kept going, far past unreasonable into a first-rate dystopia.
If you fire one belligerent hero as an example to the others, you might be able to make it work. But if you have one 'database guy' or 'backend person', odds are very good that they're going to go exactly as fast as they want to go and smile and say 'no' when people ask for major changes that would break up a logjam. If they aren't particularly articulate about why things are the way they are it's easy to get the impression they are running things instead of the titular managers.
Color me a little confused, but I think I kind of would lean toward letting the database person make the decisions about database rather than the titular managers. Haven't we all been through enough "management heard X technology is hot so we are gonna use that" fiascos?
Management's job is not to make decisions about databases for the database person, but to communicate about problems and priorities, and so on. Don't get me wrong, the dark hilarity of malicious compliance can be great when someone commands you, like they are some bumpkin who just rubbed a lamp and acquired a genie, to do something that is gonna bring down production at noon, cutting off your about-to-be-voiced objection, but let the managers manage and let the experts be experts.
That assumes the experts are indeed experts and not just saying no to an experienced consultant/contractor that management hired. Though I agree from the perspective that if the system goes down after the consultant leaves, it’s not their problem.
I’ve been around enough to know that these ultimately are political and cultural problems, and you either have to expect change to be slow in these situations or leave to find a different team…
I’ve tried a bit of both, and gotten frustrated, and in the end, the stance I’ve settled on is to be helpful to change people’s minds. It’s hard though. Being persistent and pushy with help will fail. Having the person you’re helping describe a problem or agree something is a problem, that is the first step to helping find a solution.
I guess another way of putting it is management can suggest using technology X but there should be some kind of identifiable problem to solve. There is always the exception though. For example, the problem identified might be that there are too many technologies and X is the new standard. That’s… sometimes the reason and … what can you do? Having been on both sides of the fence here, you never know, X might not be so bad… or you’ll need to fix a ton of bugs.
As long as you stay happy and helpful, you can maybe nudge things in the right direction? For example: X has uptime issues. If X is already adopted, document the known issues for devs or DevOps, or identify consultants for X that can provide training and support. Figure out how to get data into and out of X if you want to refactor later to a different approach and political winds blow that way. Write cheat sheets that can map what you’re using now to Technology X, and what might be unexpected.
Who knows, maybe enough people will have heard or seen your materials on Technology X that they’re not as impressed or share your viewpoint on it. And if you’re really unlucky, you’ll set yourself up to be the cheerleader for technology X. So… there are both risks and benefits to getting too involved in technology shifts/adoption.
You can’t have a dozen middle tier and front end people at the whims of one backend guy why isn’t interested in ramping someone up to load shed. That was a terrible contract, and at the end I’m sure they went back to the status quo. Him holding the reins of the data and his job while the initiative ramped down and they waited for the next time they got the political will to spend a bunch of money.
Maybe companies need some kind of "Chaos Monkey" system [0] in place for regular employees. Not in "terminating" random employee's contracts, but a culture were regular, maybe even some kind of random transferals onto other projects, or onto internal work regularly happens.
Everybody knows this and everybody should be prepared to a situation that tomorrow they are not working on the same problem they work on today. How would they structure work? How would they share knowledge? What can the organization to to ensure there always are fallbacks to everybody? At least fallbacks that if not perform at 100% but still on 80 - 90%.
Sadly in my org this would not work of the get go, as we often have personal access tokens to our clients' systems. This is sometimes even a contractual obligation as for specific clients we need to be vetted. But even in these cases we could be reassigned/reshuffled towards a slightly different proposition or at least be reassigned to an internal topic for a few days - just like we would not be able to work if we fell ill.
Genuinely the most weirded out I feel by the US is holiday culture. If a report took just two weeks I’d be asking them if they were sure they didn’t want a proper three week holiday (and I’m legally obliged to OK a four-week stretch over summer if the employee has the days available to take).
Finance is a mandatory continuous 2 week holiday with no access to company facilities or systems every year.
Plus all the other holidays. Sadly for some mostly junior US employees the 10 days for compliance leave left few other holidays - for the rest of the world, you still have 20 more days to use.
Nah, this isn't a great idea. It's not that far off what most companies do anyway. I think most companies have a misunderstanding of what the problem is. The problem isn't that a particular piece of knowledge isn't distributed, it's that all the knowledge isn't distributed (because it resides with one person). You don't want to go crazy with duplicating knowledge amongst the team, you just want to split it up.
One hero is bad. Zero heroes is worse. You want lots of heroes.
Trying to create a structure where anyone can jump into anything at a moment's notice just leads to everyone having a superficial level of expertise in everything and no responsibility (or worse, responsibility that they can't possibly fulfill so they just get thrown under the bus if they don't hit impossible delivery targets).
All that does is move you from one hero to zero without waiting for your one hero to quit. It's resigning yourself to the bad outcome just to get it over and done with.
The tricky part is that the 'one hero' structure tends to form pretty naturally, so you have to actively take steps to prevent it. If you put a standard team in place and let it run wild, unless the devs understand this problem initially, then eventually you'll just end up with everyone deferring up the chain of command for both knowledge and responsibility over time until a few years down the track whoever was the technical lead on the project is now your hero.
I much prefer to have an ad-hoc structure where important work is divided up amongst the team and each team member takes total responsibility for their part. More senior staff shouldn't be trying to own more code and more responsibility, they should be providing more support to others.
EDIT: I don't think I actually explained how distributing responsibility solves the bus factor problem, whoops. The idea is that part of that responsibility is for managing the bus factor of your own work. This only works if the code you're responsible for is small enough that you can realistically bring another dev or two into the fold and get them ramped up properly with real understanding of the code.
Depends what the failure is. If the important stuff is scattered around 20 different devs, one leaving is significantly less of a problem. I'd much rather piece together what someone was doing on one piece of work than have to try and piece together an entire 20 person project because the only one that knew how to drive the project left.
Also, if you own code and are responsible for it, part of that responsibliity should be making sure you have someone with just enough knowledge of the code to take it over should you leave. That's far more feasible if you own a small piece of it than if you own an entire code base.
Yeah. I see what you mean. This banking regulation to reduce and investigate fraud serves a similar purpose. With around 6 weeks of vacation time banks already have a great system in place as vacations tend to work like a force for handovers.
This was my exact situation circa a year ago. It wasn't a great look. It was an even worse feeling. It delayed the start of the project I refused by a year and didn't change management's view on how to get it done.
All that being said the writing was on the wall that I was facing either the nuclear option of resigning, or a second round of even more severe burnout by going along with it.
In hindsight my strategy going forward next time I'm presented with a plan that has predictably disastrous consequences is to simply let them have it their way. IDGAF if you wreck this thing further. I'll even help you do it. We'll maintain friendly relations and I'll leave the company near the end of the project but before it becomes apparent just how bad things really are.
If you can't beat em join em. Cynical as that is I have to protect my mental health and I'm willing to allow you to sacrifice the health of your company to do it.
Does anybody else ever reflect on how, in our modern world, utter servility is assumed? I mean are we all serfs now? Are we discussing the best method for licking master's boot?
And on top of it, Agile, which has always had the whiff of "Taylorism, but from the inside" about it. Always sprinting (huff huff huff); attention atomized by checking texts, emails, phones, voicemail, and of course iterating over an ever-increasing number of Slack channels (or Teams); everything in these bitty increments of moving the assembly line along. And this has to be accomplished through a kind of homogenization, which invariably leads to replacement. But sure, let's hot desk on rows of laminate-topped folding tables for the greater glory.
Agile might work for someone else, but I never saw it work. I saw this trying to be applied, amongst other methodologies, but the real sticking factor is whether a group of people feel like they are solving actual issues in the end. "Agile" or any methodology was a bit make-work, to fill a role that we can report on the specific progress of small things. At least for me, seeing people learning to handle issues, get through real features needed without the minute formalities has made them, and myself, more engaged in what I do. Being practical in the end gets you farther than having faith in a strict process.
> "Agile" or any methodology was a bit make-work, to fill a role that we can report on the specific progress of small things.
Agile isn't a methodology, and most methodologies described as Agile eschew formal minutiae.
The problem is, of course, that methodologies, of whatever origin, are, in practice, subject to top-down, non-Agile modification to suit the taste of managers who thrive of formalized minutiae, and, also, the starting point of methodologies for many shops isn't the original description by Agile practitioners who developed them while delivering superlative value but customized versions crafted by and marketed alongside consultants whose jobs are largely telling command-and-control-oriented managers what they want to hear.
I think its always been this way. Our parents told us democracy has won out, but in reality, its the same old story. People get fed ideas, of dreams, of one day, as an excuse, to serve. The lucky few are broadcaste around the clock to reinforce the general monenies stature. And dont give me no bull about "making it" from "nothing".
The only way to truely make it, is to find someone else, and jump on that bandwagon. Whether that some else is a government contract, or seed funding, or an admissions board. You rub someone elses back and hope to get your just deserts in due time.
I assume it’s a typo for something, but I can’t figure out what. If I google it I get results about money laundering, which doesn’t sound right from the context.
This is why teams should run people game days to test their resiliency to organizational outages. Unavailability: force team members to completely disconnect for a day. Consistency: if a team member ask a question about a process that should be documented in a runbook/TSG, instruct them to sometimes answer it incorrectly. Latency: delay responses to email/IM questions about live-site processes by 24 hours.
Yes in part. But I like the more random aspect to it as well as the additional dimensions.
It trains people to not rely on @xxxx in slack (or any other tool for comm). It trains people to write better documentation as they will receive unhappy messages from coworkers if it wasn't clear. And it trains people to RTFM first.
At least - there is a chance it can do all of this.
In the spirit of the old saying, "the two happiest days of a boat owner's life are the day they buy a boat, and the day they sell it."
The best advice I got starting out was, "be indispensable."
The best advice I got four years later was, "don't be indispensable."
In a growing company, the indispensable people may find themselves being left holding the bag while new initiatives are undertaken. I very quickly learned the meaning of 'working your way out of a job' after the first time this happened to me.
I'm sure there's some min-max game I'm not playing with regards to how easy I am to lay off, but once I learned there are worse fates that being laid off, I stopped looking for them. Being "stuck" with responsibilities is unpleasant when things are going well, but it's miserable when things are going badly. If you aren't the one who got laid off, then someone you used to trade off with doing onerous tasks certainly was, and now you're stuck doing it every single time.
If given the choice between "my company would be just fine without me" and "everything would fall apart if I didn't show up to work," the latter feels very good for a brief period when you're young, until the weight of that responsibility sinks in. "My company would be just fine without me," can mean "my work here is done," and you can ride off into the sunset with a clear conscience.
I have been in this situation myself, but my former boss has a conscience, as it turned out. My wife and I were on a vacation that was timed to celebrate an important birthday. I had spend days during the preceeding week training up two people on my team, and maybe one or two others, on various processes and contingencies. Yet still, when push came to shove, I was asked to get online to put out a fire. Luckily it only took an hour or two. A few days later I was surprised to find $1000 bucks deposited into my account from my boss as a thank you.
This system that I had hacked together, built out and maintained, kept on growing in size, complexity, attributable revenue and potential compliance liabilities. Within the year, I had to call the execs into a meeting to drive home the point that this wasn't a tenable way for us to operate. Everyone had known as much but it was still a tough pill to swallow. I let them get too spoiled at a huge cost to my own mental health.
I had to paint a dire picture to make my case that the system had to be rebuilt from scratch in order to be integrated into the main infrastructure. I ended up leaving a few months later as the rebuild was nearing completion. A couple of months down the road I was surprised to learn that they were still using a part of my system alongside the rebuild. Apparently their architecture couldn't support an algorithm that this component had relied on.
What's your goal, though? I'd like my company to not absolutely 100% need my constant presence, and I don't want to be in the author's position where he is not doing what he could be most valuable doing. But I do want my company to think "wow, that ivraatiems, we're sure lucky to have him." I would want them to think twice about firing me or laying me off if layoffs were happening. I definitely would not like to have to go look for a new job unexpectedly.
So, I want to be personally valuable to the company - maybe more valuable than the average engineer - but I don't want to have indispensable knowledge that locks me in place. Surely there's a middle ground here?
I worked at 3 companies between 2014-2020. My goal going in was to solve the set of problems I was hired to solve by the then new manager and “put myself out of job”.
Today working in a consulting department, I refuse to take on any work that may look like “staff augmentation”. I just do project based implementations with a definition of done and set aside time for training the customer.
I think the middle ground is to have a huge stash of savings. That way, the original proposition isn't really relevant anymore. (That proposition being, I need to be valuable so I don't get fired).
Being indispensable to a team or a manager in a large company can actually be self-destructive to your career. I realized this the hard way a long time ago when my managers refused to let me move for a promotion because I was "indispensable" and "critical to the project". I've always made it a point to know who my back-ups are and have my supervisors assign them formally.
In short, make it a point to share knowledge anyway. Keep a wiki, well written notes or documents, README.md's, whatever. Make it a point that people who are backing you up acknowledge and understand what you have and most importantly ask them to grow that body of knowledge.
That argument does not solve the problem. You will stay or go from one project that fails to the next like that. Better to have worked on projects that are still good on your CV.
Scenario: There is a project your boss is wholly responsible for. You, from a technical perspective, are absolutely indispensable to the success of said project. Maybe it's a small team, or everyone is overloaded, but you can draw a direct line between you quitting (or doing a bad job) and your boss getting called out or potentially fired.
Your boss, however, is not indispensable to their boss, nor is this project indispensable to the larger department. You ask for your raise because of your leverage. Your boss might be worried and try to get it for you. Their boss, not caring about this project that much in the broader context of their work, laughs and says no.
You can absolutely be critical to the success of a project, and even important to your boss's future, but have no real leverage over your situation. That's absolutely a reason to leave but it doesn't mean you'll be able to squeeze any more money out of the place before you do.
Such a great point to make. Specially since I see myself in similar situation. Maintaining a legacy system on which all the devs except me who worked in past have left. It is critical system or so I heard but as far as promotion/raise go, almost nothing for last 3 years.
However instead of getting angry I get that I may be important to direct boss or one level above. But as far as company goes they are all in cloud, next generation and what not. So my criticality is inconsequential in larger context.
Or even a lot of the middling ones. In the US something like a trillion dollars a year is spent on making people want to buy stuff. Not to mention all the social forces that encourage spending. Relatively few people manage to live far enough beneath their means that they can just quit a job on principle.
I happen to be one of the people who can (and has!) quit a job on principle. But it's very much a luxury good that I work hard to afford. And it's easier for me: no kids, no parents to care for, no mortgage to worry about. I would rather more people quit their jobs on principle (or risked it through efforts like unionization). But I mostly don't blame them if they feel like they can't.
I’ll take “people who haven’t bought a house or have kids” for 500, Alex
There’s a thread right now in r/experiencedDevs about a guy who is trying to buy a house while his employer is cratering around him. Stuff like that happens and tends to stick with you forever.
> refused to let me move for a promotion because I was "indispensable" and "critical to the project".
So would they rather have you quit? If not they should be willing to give you whatever title, pay bump, time off, etc. is necessary to keep you long enough for a replacement solution to be found. Otherwise if you just quit they’re stuck negotiating from a position of weakness to hire you back as a much higher paid contractor, or if you decide to take an extended vacation or work somewhere else they are left high and dry.
If you are truly “indispensable”, that makes you the one with all of the leverage. If they can jerk you around without pushback, then “indispensable” sounds more like a rhetorical device / excuse.
I would argue that exercising such leverage is not only for benefit of the indispensable but also for the organizations which are often inert unless enough initiative is given.
Indispensability (true or perceived) hurts not only person but organization as a whole. It creates tension between them, which might break at any point for any reason (a bus, reaching point of no return, dragging organization down) and create difficult to fill void once that happens.
I think it should, however, be considered from the true indispensability and not the perceived one. Perceived one is bullying employees, accidentally or on purpose. Sometimes it's bullying ourselves by creating overly controlled environment that solidified over years.
In perfect life scenario utilizing leverage would work as following: The Indispensable ask for a minor raise (1-5%) -> Company agrees, because The Indispensable is truly indispensable -> 1 month passes -> Repeat
After couple iterations there would be a break point because company will start to weight options and might decide to compensate instead of waiting for next month and another raise request. In this scenario The Indispensable stops being one, so their quality of work improves (less stress) and they get additional income. Company retains The Indispensable since they signaled and through adequate pressure achieved the goal. Fragile process with single point of failure is resolved with more stable solution.
Unfortunately it doesn't work in real life often. Some companies simply can't afford matching expectations, no matter how warranted they are. Indispensability there is simply a tax imposed on worker. Some people aren't confident and courageous enough to bring issues out and try to act on them (as business can be intimidating). Last and not least - true indispensability isn't black or white. There's a mixture of politics, perceived indispensability, true indispensability and controlling behavior by The Indispensable one.
So would they rather have you quit? If not they should be willing to give you whatever title, pay bump, time off, etc.
For large enough companies the 'company' is not a single unit making unified decisions. I might be "indispensable" to my boss, perhaps his boss, the project, and my department. However they don't have the power to give me a pay rise or extra time off outside the normal bounds set by their bosses. Me, my boss or even my department however aren't indispensable to the whole global multinational company we all work for.
If I quit and the project fails, then my boss and several people on that project might lose their jobs, and the remnants of that department might end up folded into some other department. My bosses boss might not get a nice bonus that year due to the fact that the project he was overseeing was a massive failure. However "The Company" and it's tens of thousands of other employees all around the world will keep on trucking as if nothing had happened.
To add on, it is a lot better story to tell during behavioral interviews:
“I was hired by the Director to solve $x problem. I led the project. I put processes in place. I led training for the team and they went public a year later. I met my former director for lunch a year later and most of my processes are still there in a slightly evolved form.”
About the same as above from my job after that. But change “Director” to “CTO” and change “went public” to “got acquired for 10x revenue”.
(Yes I can draw a direct line from the architectural changes that let them pivot to selling access to micro services to their value proposition when acquired)
> my department however aren't indispensable to the whole global multinational company we all work for.
Some of that is wishful thinking on their part. They can’t acknowledge that the riffraff keep the wheels on and may swing the other way as a form of denial. They probably treat waiters like shit too.
> However they don't have the power to give me a pay rise or extra time off outside the normal bounds set by their bosses.
Maybe. But - maybe they just follow the path of least resistance, which is to lean on you rather than go up to their bosses and say "John Smith is quitting, and when he does, this project will crash and burn. We must stop this or the company will lose $$$."
> So would they rather have you quit? If not they should be willing to [...]
I know that many folks here work in elite organizations, so maybe it's hard to fathom, but THE NORM for big companies is to be dumb as a box of rocks when it comes to organizational stuff and technical operations.
Talented people who are intrinsically cross-functional, curious, and who always to do what it takes to "help the team" often get hammered flat from years of the daily grind-stone and then just quit, like the OP.
In most places no one is even thinking about "retaining talent" until it's far too late.
Retaining talent conversations feel much like people who show up to AA after the liver disease diagnosis. They didn’t think it would happen to them, they didn’t look at it, and their sudden conversion is a rear-guard action, closing the barn door after the horses have gotten out.
If your bosses are saying “retention” out loud you are probably already fucked, even if your division seems to be doing okay.
It is very clear that bosses have had good luck bluffing or calling other people’s bluffs and many just do it as a matter of course. I bet you won’t quit over a 5% discrepancy in pay, and I’ll just ratchet that up every review period, and hope you don’t notice when that climbs to 10% under market.
It’s kind of the same game landlords play. I always find it somewhat amusing when a landlord forces a business out of a storefront and then the storefront sits empty for six months or a year. How long is it going to take you to break even on that?
For storefronts specifically, and depending on the country you're talking about, there's more likely than not an attempt to evade or avoid tax. For example, this is exactly why tourist attractions like Oxford Street in London are full of American Candy stores now. They'll be there for a few months and then be gone: the landlord saves on business rates because they'd found a tenant, and the actual company vanishes without having paid the rates they were responsible for.
In that case, it's beneficial to the landlord to have some scam shop in because even if they're not being paid rent, the money they're saving from an occupied storefront easily outweighs every other alternative.
Lots of commercial buildings are passed down from generations. You don't know how to think like them. They have the building its been generating money and they have lots of money so they don't care. They want toy X that costs $XXXX per month if the tenant leaves they don't get the toy and they lose the rent they don't need to live anyway. If the tenant stays they get the toy. Otherwise they don't care cause they are good financially. You would be amazed how man "business" decisions are made based on the basis of if it buys the owner the toy they want.
Toy is just a euphemism. It could be a service, it could be just showing up their friend jimmy that they made more money this year. IT could be to win a bet. IT could be the tenant scratched their Bently. It could be that somebody they don't like frequents the establishment.
It’s not about “I’m indispensable pay me more”. It’s about “I don’t want to have 1 year of experience 10 times”. I always want to have the optionality to change jobs . Things change. Culture changes.
I've heard this "one year of experience 10 times" phrase before. It seems to mean different things in different contexts to different people. Can you explain what it means to you and the implications?
I started my second job in 1999 it was for a bill processing/printing company. Companies would send us data files via ftp, we would merge the files and create files in a format used by industrial printers and mail them out. Later on we were one of the early integrators with CheckFree that was the backend for most online bill payment services.
I wrote mostly processing programs in VB6, Perl and C++. I did some GUI programming with C++/MFC/COM (ask your parents).
Fast forward to 2008, the world had moved on. But I was still using VB6 (discontinued in 2001) and C++/MFC. My compensation was only $7K more in 2008 than it was in 2000. There were other people doing the new shiny while I maintained the old systems.
I learned my lesson. Over the next 10 years, I changed jobs 5 times and doubled my income - nothing to brag about. It was still about what entry level developers get as return offers in BigTech. I was laser focused on keeping my skillset in sync with the market.
By 2017 though, I realized my market value as an enterprise dev was going to plateau in 3 years and my youngest was graduating from college. I started pivoting to “cloud” and got into “application modernization” consulting - basically a fancy term for cloud app development and deployments.
I got my current job in consulting in about two years ago.
Good lessons here on tracking the market, keeping skills up to date, and skating to where the puck is going. I imagine the modernization niche pays pretty well. :)
Ironically, “application modernization” seems to be the worse paying cloud specialty in the industry. At most consulting companies, “implementations” pays the least and is outsourced to cheaper labor and junior consultants.
I work at the one company that pays decently well for AWS + enterprise dev + consulting. It’s not hard to guess which one it is..
There's the risk of heroism too... you're indispensible because you're that one person who goes above and beyond and everyone sees you as the go-to when shit goes wrong.
I've been there a lot, not on purpose but in some organisations it's either that you get your hands dirty or you spend 10x as much time watching the buck being passed. It's definitely one of those things as a developer where you need to learn some management skills or end up burned out of the job.
Starting in a new role, or new company, often means that there is a period when I'm hard to replace, but since I try to automate everything I can and make the rest simple enough for anyone to do, I'm actively trying to make myself useless and out of a job. Funnily enough, it doesn't seem world is running out of undone work anytime soon and there are always more interesting problems to solve.
I remember reading "Anything you want" by Derek Sivers. There he describes, that he actually went towards "my company would just be fine without me" with his own company.
So regardless of being an employee doing bodyleasing towards their employer, being an employee that identifies with "their" company or being a boss/founder/owner/manager these two sides of the axis exist and one needs to find the spot that fits for them within that range.
I don't think there are "one size fits all" easy answers. Or at least if they are given imho and by my experience they are wrong more often than not.
It's a fine line. If you want to stay employed, but not be pigeonholed, you need your company to see a future with you in it, rather than always thinking of you in the present tense, dealing with the latest problems du jour.
I think for me these sorts of pre-emptions have always felt quite jarring, so the feedback loop for me is tighter than for some.
If you bring me a novel problem to solve, I will happily stop what I'm doing and help you figure it out. For some reason I've only rarely had problems getting back into whatever you interrupted. Whereas with fire drills I have trouble spinning back up into what I was doing before. Perhaps to do with finite energy reserves.
Ultimately I credit my early successes getting promoted to Lead to this pattern, because 'novel' problems either explain a wider portion of the overall architecture to me, or end up being all hands on deck when it turns out this issue is bad and is already in production. I cannot emphasize enough how much smarter you sound offering a solution you've had 30 minutes to an hour to think about instead of 10 minutes. The developer who triages an issue is two steps ahead of everyone else who is thinking on the fly. Doubly so if you have to wrangle everyone into a meeting room to discuss things. Unless the other people are vastly smarter or knowledgeable than you, you will hold your own in that conversation, even if you are somewhat junior. And if you're instead on a par, you will excel.
i think the indispensable idea is from an era where job stability is important and you might be at one company for decades.
The méthode en vogue of the current era is to jump ship every 2 years because that's the best way to get a raise/promotion. With that strategy being indispensable isn't that important because you will self-dispense in 2 years anyway.
I think one of the problems from "being indispensable" is the direction it takes. Being indispensable in regards to people "being left holding the bag while new initiatives are undertaken" means they are/were indispensable in regards to specific tasks/processes/skills or knowledge.
Personally I feel being indispensable can also be seen as being able to be thrown at (nearly) any problem and finding a solution. Catching the ball and creating the basis for a stable project for others to take over/maintain. I am working at an agency and more often than not there is a first small initiative at a client where we just do not know what is expected/needed in terms of skills and in what direction this initiative might go/grow.
So we often throw two people at the "problem". One more senior "jack of all trades" kind of person that can understand a lot of problems and knows how far they themselves can work towards a solution (and when to call in the subject matter experts). And one more junior person to support and learn by swimming in cold water together with said "senior" (can actually - depending on the problem be a junior/intermediate themselves - it depends).
These "jack of all trades" persons, thinking on their feet, being able to improvise and get things done, able to understand and dig into problems ans find solutions - these kinds of persons are indispensable - but they don't get stuck in one specific problem/project.
The processes around them are built in a way so that we free them for the next thing to come our way. And we do everything we can to create new people of that kind.
I'm not really familiar with the military context, but it's almost how I envision an advance/special forces unit operating in front of the actual lines and first creating a beachhead that the regular troops can then build on and bring their strengths to bear.
These types of individuals are indispensable - but ideally not each of the individuals on their own.
Deming sometimes used bus drivers as an example. Some of them might think it's not their job to smile and be nice to passengers. They're hired to drive the bus, and perhaps help out in emergencies, but not much beyond that.
However, being nice to passengers (performing "caring labour" as Graeber would have put it) increases the chances that people choose the bus over e.g. the metro or something else. Deming concluded that it's always your job to do whatever increases the chances of the company you're working for staying in business.
I still haven't found a good way to phrase it, but I'm starting to think that for knowledge/creative work, this can be specialised to something like, "it's your job to teach others to do what you think your job is."
For knowledge/creative organisations to stay in business over the long term, they need to continuously innovate, and for innnovation you want people to be strong generalists. Not just because it lets them spot opportunities they otherwise might not, but also because it lets the organisation run more efficiently with less paperwork, and because it gives people the autonomy they need to think clearly about things.
If the bus drivers were paid by the number of people who take the bus sure, but when are paid by the travel route distance, they have no obligation to do what they are not paid to do.
If you equate smiling at someone, or just being generally courteous, with "emotional labor," you need to make an emergency appointment with your therapist.
Being a good human being more often than not (occasional bad moods notwithstanding) should be a non-functional requirement for any job where you interact with other people. I have no problem with anyone, in any role, getting fired simply for being an asshole. The world would be a happier and better place for it.
> If you equate smiling at someone, or just being generally courteous, with "emotional labor," you need to make an emergency appointment with your therapist.
This entire conversation started based on an example that smiling brought economic benefits, not that you should do it because of socializing benefits. Answering in economic terms only makes sense.
I didn't say not smiling makes you an asshole, I'm making two separate points. The first was that expecting people to be generally courteous to other people, whether they're explicitly paid to or not, is something we should expect from everyone. It's called just being a human being. And again, everyone's allowed to have bad moods now and then. But in general, if you go through life with a scowl on your face and approach things from a standpoint of "I'm not being paid for this so I don't care, I'm not doing 'unpaid emotional labor,'" you're just kind of a jerk. That's the context of the last couple comments in this thread so it's important to keep the "I'm not being paid to smile so I'm not going to smile because that's labor" thing in mind.
The second point, which is related but I think still separate, is that I wish just being an asshole was enough to get fired. I sort of had it in my head but didn't really articulate that I was thinking of being an asshole as a more extreme version of what we're talking about, what I refer to above as just being kind of a jerk. Maybe on a scale of 1-10 being a jerk is a 3 but being an asshole is a 7 or 8.
The specific job includes customer service. It's what they are being paid for. Employees who do the job poorly are at greater risk for replacement by replacement hires. This is why many companies ask customers to rate individual service providers.
The passenger count is so heavily influenced by factors outside of the bus driver’s influence that this example doesn’t make sense.
Passengers don’t abandon bus routes because the bus driver didn’t smile at them. They abandon routes when the schedule is inconvenient, there are better alternatives to the bus, the fare is too high etc etc. None of these are in the control of the bus driver.
My old bus route to work used to amuse me greatly because on it there were two drivers who were the polar opposite of one another. One guy I assumed had previously been the pilot of a commercial airliner because he used to greet everyone who got onto the bus with that sort of demeanor and make announcements etc. Always brightened my day. The other guy was the grumpiest piece of shit bus driver I've seen anywhere in my life who would frequently berate passengers and oftentimes frighten unsuspecting foreigners. Everyone who needed to get to where they were going showed up and took the bus regardless. It's about the least important variable there is and it averages out to getting a reasonably OK bus driver almost all the time across the different busses you take and the different times of day you take them.
Ah, this must be why bus drivers are commonly paid in company shares. Incentive alignment! Makes sense.
Wait, they're not? So why should they care, when their bosses don't care even enough to set up a direct reward to bus performance and some way for them to have agency over that reward?
Though it would be cool if there was a bus service that had direct, fine-grained association between curteous behavior and reward in the form of immediate payment and future business, possibly mediated via ratings - I was making a joking reference to Uber here, but "Uber for busses" is genuinely something that I want to exist. Ie. not "Uber Bus", but the standard Uber model of engaging a driver directly, only this time applied to longer timespans to allow better schedule coordination. For instance, some way to say "Hey, I need a bus from X to Y some time between 6 and 7 every workday for the next six months, which time and pickup location is cheapest?" would allow for some pretty cool optimizations in routing. Possibly combined with a Kickstarter-like model where a bunch of people can express prospective interest.
If I’m working for a private company. Guess how much I care about “equity” that will statistically be meaningless?
On the other hand, I did implementations as a Senior Develop/de facto “cloud architect” that moved the needle meaningfully at a company with $5 million in revenue. Those same types of implementations happen multiple times daily at a company worth over $1 trillion. Nothing I’m going to ever do will ever have a meaningful affect on the stock price of the company I work at now.
Kind of sounds like the company share price is too coarse-grained. That sort of thing might work better if the company was split into separately traded sub-units, of which the parent company owns some controlling fraction of voting shares. Admittedly the bureaucratic overhead starts being awkward.
There are four companies worth over 1 trillion. How could you split any of them in a way that my small implementations by their standards would make a difference? I purposefully focus on the “nose of the camel in the tent” type work.
I like smaller proof of concept + training type projects.
I agree there is not necessarily a good way to do this in any given company structure. However, if a company can figure out how to do it, other things being equal I would expect it to eat its competitors' lunch. (As with how Uber doesn't need to mandate that drivers should be nice; it just falls naturally out of the incentive structure.)
This is what Citymapper's Smartbus tried to do in 2017 - regulations don't make it easy, so negotiations with the municipal authority and Transport for London are still ongoing...
You can; groups of people hire a mini bus or coach and negotiate where and when it travels all the time for social events, work parties, school trips, etc.
BTW, this sort of smugness is why Detroit is a shattered husk of what it used to be.
When Deming still had all of his hair, he had trouble getting traction in the states. Japan, on the other hand, was intrigued by his ideas and wanted some quality time from him. If you look at the history of the Toyota Production System, they usually credit Taiichi Ohno and Toyoda, with the origin story sometime in the 80’s, after Detroit was already in flames, but before that was Deming, and for some reason he is usually not mentioned.
> However, being nice to passengers (performing "caring labour" as Graeber would have put it) increases the chances that people choose the bus over e.g. the metro or something else.
Increases is a relative measure. It may be 10% or it may be 0.0001%. At very small values it becomes basically a zero because humans are non-divisible unit at which point your theory is basically in the rabbit’s hole of magic and wizardry.
This happened in the first company I worked for. It was a big, well known engineering company, and when things started going south they had to negotiate with the state labor department to do large layoffs, which required giving financial cushions to let go employees. I was a star employee - so while everyone else was being laid off with nice, big compensation packages (like 6-12 months of salary), I was stuck in a company on fire that obviously had no future. I was, in effect, punished for being "indispensable".
Ethical issues aside it's easy to see how people in that situation can basically just stop working / start interview prepping while waiting for the layoff.
After about 20 or so years now, one of the main things I've learned is that you aren't as indispensable as you think you are. You might think the company will go under or otherwise degrade when you leave, but that never happens. The company will trudge along without you. That being said though, if you do believe yourself to be "indispensable" to a degree in which the burden of you leaving is large, then by all means, use that to your advantage in obtaining raises/promotions/etc.
Or you are indespensible, and the company could go under, but you can charge them huge afternoon-consulting fees while working a new, better day-job elsewhere.
"My Company would be fine without me" also means you can take vacation, medical appointments, heck even weekend (crazy concept!).
"Being Indispensable" can also mean two years of no physical or mental time off; it was not fun!
I am currently lucky that all my layers of higher management understand that if my team can function effectively without me for a period of time, that means I'm doing my job well . I was able to take 2 months of paternity without things falling completely apart, and it was a proud moment for me and the team (plus great chance to bond with family). Sure there were things to catch up on and new initiatives and some bad habits to work through, but it was overall a success.
(In addition to "be indispensable" vs "don't be indispensable", one of the best pieces of advice I got and share is "The moment you get a new job/role/position, start looking for your replacement". I did not understand the value of that the first few years, but I now 100% do. I know a lot of HN SME/IC's believe "it's my boss's job to replace me / I'm in & out in a year or two", but if you are even remotely looking for a sustainable career in a company or small market/industry, it will speak VOLUMEs to your foresight, care and team&business responsibility if you have a trained, capable backup identified and positioned, for your times off as much as for your eventual ambitions).
I'm not sure how that directly relates to my or original post; but let me try to engage:
I don't understand first sentence; but based on second sentence, my interpretation of your key point is that you may have excellent technical or functional skills, but if your personality / behaviour / look don't fit, people may still find way to get rid of you.
I believe that is true; and I believe that can be true in both positive and nefarious ways.
I've been a hands-on pure techie for 15 years; I've been in leadership/managerial positions lately; and I cannot believe how positively ignorant I was to ever think my technical skills were the only or even primary consideration.
A person knowing a technology is great. But a person then needs to:
* Understand client's top down business goals and priorities (as opposed to bottom-up technical priorities) to prioritize their tasks and recommendations. E.g. As a DBA, you want to spend your time optimizing tables and indexes and access paths that you have; but business may well prioritize new functionality that will gain them market advantage or reduce cost more than optimizing a technical parameter will. And this tension goes forever in every facet of technology.
* Be able to gather true requirements, eek them out of client and product owner and functional & business team. A person who builds exactly and only what a clueless functional person tells them to, is... OK. A fine junior resource. A person who's been around the block and cares enough about business to ask keen questions to identify needs client/functional wasn't fully aware, identify edge cases, danger zones, risks and discuss them in understandable language, is a worthy senior developer
* Work with the team. Coach junior team members; at least consider feedback from everybody - junior, senior, client, management, functional, business, and integrate it appropriately to make yourself more valuable to them. Make their day better - through your work, yes, but also your attitude. Do you help inspire and motivate and get team members excited, or do you drag them down? Do you help move things along or do you get people stuck in some detail forever?
* Communicate well. Strive to understand and be understood. Ensure your team mates and management know what you're doing, how you're doing, how well you're doing, the thoughts and plans, and risks/barriers/issues/constraints you're encountering (as much as they need/desire to). Be self-guided when you can; Ask for help when you reach your limits. (those two goals are a LIFEtime's work to improve and hone and fine tune:). Ensure everybody understands the plan and agrees to plan. Be at all times aware other people's context/background/assumptions/knowledge/perspective may be completely, wildly different than yours; avoid unspoken assumptions and ambiguities.
* Understand your management's goals and help them succeed. It is stunning to me how few technical people (myself historically included!!:) didn't know, and did not want to know, what the management/business goals are. We have this duality of "Just tell me what to do, I don't want to deal with politics and business crap" and "I'm angry that we are not doing what I think we should be doing, how I think we should be doing it".
etc etc etc.
This is not to say that teams and companies don't abuse the "cultural fit" notion; or that north america isn't way too prescriptive about "being a team player to the point of being a yes-person"; or that there isn't racism/nationalism/personal preferences and bias in recruiting and other decisions. There 100% is negative and unproductive ways to people manager, and I see it all the time. But I think many of us would benefit from awareness that our technical/functional skills are a) not the only thing we are judged on and ...
> I don't understand first sentence; but based on second sentence, my interpretation of your key point is that you may have excellent technical or functional skills, but if your personality / behaviour / look don't fit, people may still find way to get rid of you.:
So if you get vocal (online) the security services get involved, its as simple as that, they will keep you busy, and so will other people, whether you like it or not, but not everyone gets to spot when the spooks are getting involved, which is partly their job ie to have deniability of their actions, but thats the way it is.
2nd point, spot on, correct.
The rest of your post is what you have experienced but you dont mention office/team politics, that also plays a part, plus customers who despite all the training are fixated on something else and wont accept a superior solutions until perhaps years later.
Some management are just as bad at conveying their needs as staff at the other end of the hierarchy. People dont always know what they want until its gone.
You can get buried under communication, effective communication is generally better, but everyone is different.
Everyone has a different opinion on the best approach.
> "My Company would be fine without me" also means you can take vacation, medical appointments, heck even weekend (crazy concept!).
This is so worth it! A decade ago, I was the technical cofounder of a still-small startup. For a while, it was just me and my co-founder. But when we got signs of product-market fit, I hired a team of developers. We set it up so the default was pair programming with frequent pair rotation, with a lot of other tweaks to make it very collaborative.
This paid off in a lot of ways, but for me the biggest came when my mom got sick. I had to fly across the country and stay for weeks at a time to help her and coordinate her care. I was worried things might grind to a halt. But because every commit to the code base involved at least two people, it was fine. There were things I understood better than others, but there was nothing that was a scary mystery that nobody had touched.
When I left the company, it was the same deal. We were on good terms, so they were welcome to call. But they rarely if ever did! It was great to pop in now and again and see them just chugging ahead.
This was the big lesson I learned recently and I whole heartedly agree. It's can be very dangerous to your mental health to not have this perspective if you wind up emotionally trapped in a bad situation.
There is actually no contradiction there. You want to be indispensable for the position you wish you have, and dispensable for any position you don't wish.
If your interests change, your dispensability should change with it. But this is very hard to achieve, so you get a complex goal of optimizing for many things at the same time.
Quite interesting. I have learned to make myself useful by making myself redundant, as in the team won't be on fire if I leave. I think it is good to be valuable because you do good work but not so much that if you want to leave for a different company you would leave your old team in a bad shape or if you want to move to a different team the move would get blocked because you are indispensible.
Many American companies only give 2-3 weeks of combined sick + vacation time, which isn't really enough for "a long vacation" - furthermore, many companies have a "use it or lose it" and don't let you roll over PTO.
Long story short, it's impossible to take a long vacation while working for many companies.
In my experience companies offer may offer sabbaticals, HR may promote them, the documentation may be shiny; but it is career suicide for anoyone who hasnt already made it to the top.
You must have worked for some awful companies. Everywhere I've worked the sabbatical was highly encouraged and the people came back refreshed and often got promoted soon afterwards.
I have never worked for a company that offers sabbaticals and I'm fairly certain I don't even know anyone that works for a company that offers them. I've never met anyone who has mentioned taking one either. AFAIC, they aren't even real.
The list I posted is certainly not exhaustive. Many companies offer them for the exact reason I stated above -- so they don't come to rely on a single worker.
I actually took 3 months off and completely disconnected. A large portion of my direct team churned while I was off, a long time engineer took his own life, and I came back to the same issues but magnified.
Overall, it's not unreasonable to assume I'm a control freak and couldn't let projects go. However I'm a big proponent of letting fires burn and I delegate to no end. My particular type of stuck was exasperated by a corporate culture that has sales quotas pulled out of the air and implementation that was tracking time down to the minute because 90% had to be billable. In that culture there's no incentive or ability for individuals to learn.
The neediness of Sales folks is relatable. I worked at a company where Sales thought "@channel" was a person they should ping as often as possible.
And no amount of documentation solves this because documentation is useless if it can't present itself at the time of need. Because rest assured, no once (including me) can find anything using the horrible Confluence search.
But sadly this solves it for the people relying on your documentation. Not for you if you rely on anyone else's documentation if they don't act accordingly.
Confluence search is alright. The problem with Confluence is the undisciplined people who mess up their spaces to the point where the search comes up with too many mostly duplicate results, where you can't be sure which one is the latest valid version.
At my job, we use Confluence extensively, with dozens if not hundreds of spaces, and in some spaces, searching for something is a delight, while in others it is impossible to find anything without already knowing their byzantine structure.
Usually, the "good" spaces are ones with one or three "custodians" who mercilessly impose a sane structure upon the space. The "bad" spaces are always those where dozens of people create articles and sections as they see fit, without any coordination.
If you need to know the structure to search, IMO the search experience is broken. Most searchers want to type topic related words and expect useful results.
Yes, but that's because the space contains so many duplicate or almost duplicate articles that search results have no chance of being good. I see the problem in the searched content, not in the search engine itself.
The internet also contains "so mamy duplicate or almost duplicate" articles, and yet Google can provide a useful search for Internet articles. You're telling me it's somehow impossible to achieve the same thing for a company's intra - even though it has several orders of magnitude fewer articles to index?
One quick and easy way to improve Confluence's search would be to rank often-visited articles higher than rarely-visited articles.
I would hope that going by popularity is something a search engine WILL ABSOLUTELY NOT DO in a corporate setting. This is a completely different scenario than what we have on the public WWW, so unless your corporation has a situation where people maliciously copy articles from others, trying to pass them off as their own content, in which case the search engine quality is the least of your problems. :)
Anyway, as I've already stated, Confluence spaces which are well looked after and are not allowed to get cluttered are a delight to search in, and as a bonus also a delight to just browse through.
P.S. Google Search results are often lousy and full of low quality results anyway, I'm not sure mentioning it makes your point as well as you think it does. As everywhere - crap goes in, crap comes out. :)
Personally I haven't seen "well looked after" Confluence spaces. I have experience with 4 different companies that used Confluence for their infra, and in my experience it has always been a mess. The reason I advocated for ranking by popularity is that those messy Confluence pages are filled to the brim with obsolete outdated articles that nobody intentionally visits. For example, in many firms people post meeting notes to Confluence. So you have 10 000 pages of quality "notes from project abc weekly meeting 5.4.2014". Now, imagine yourself searching a Confluence space like that. You type in a particular phrase, and there is a perfect match in meeting notes from 2017, a perfect match from preliminary design document from 2013, etc. These results constantly drown out the actual pages you are searching for, which are typically more actively-updated, more recent pages. It would be a huge improvement to rank these pages higher purely based on their popularity.
Search is great if you already know the answer (all search does is match answers to pages).
Search is not a substitute for good documentation. Neither is "read the code" or "you should just know", which are the most common answers I get from developers.
I faced some of these issues in a company, and the best solution we found was creating a massive “FAQ” single page where (browser) search could get you what you wanted, and a firm policy that any question asked should end with a modification to the document.
All questions had to include the search terms used to find the answer, and if it was a “failure to find”, those search terms would be included in the “related tags” section of the question for next time.
> I worked at a company where Sales thought "@channel" was a person they should ping as often as possible
I find some people just don't know (or care about) the right way to use Slack. They need to be taught "Hey, don't bother 100 people in this channel for your niche question." Some are oblivious, some don't care about other people. Either way someone needs to pull them aside and say "stop it".
Having management that allows that to continue indicates an unhealthy organization.
How did they make the Confluence search be so horrible? I once searched a page title without noticing I was already at that page, and it couldn't find it. I literally copied the title in and it still didn't find it. truly an awesome (as in awe and fear inspiring) piece of software.
Early career me thought that being indispensable was a good thing for career safety and leverage for promotions and whatever else, but that turned out to be far from the truth.
In my experience if a company is so incompetent as to allow a single person to genuinely become indispensable, they're also so incompetent as to barely know it, and do nothing about that person leaving.
Only after leaving will the fires really begin (or intensify), which is probably just a variation on business as usual anyway.
The great swindle that capitalist ideology has pulled is simultaneously convincing workers that 1) they are completely dispensable ('we can replace you'), but 2) that they are also completely indispensable ('we need you'). The former keeps the worker scared that they can be fired at any second, the latter makes the worker feel guilty about quiting (or not answering their phone at 6am on a Sunday).
The amazing thing is that, depending on what the corporation needs, the worker is made to feel either of these things.
The post in the OP is the worker feeling the latter, with a twist: being made to feel indispensable to shove off as much work as possible on the worker.
The first thing to remember is – no one is indispensable. If you get hit by a bus tomorrow the company will go on without you. People may have a bit of trouble at first, but new processes will develop and new people will gain expertise just as you have now. Heck the company might be better off in the long run without knowledge bottlenecks.
Second, being indispensable doesn't do a whole lot for job security. If the company is doing well, you need to perform exactly at average to stay employed, no more. And if the company is down in the dumps and there are mass layoffs, who is going to judge how much knowledge you have in your head? All the people who know how good you are are probably getting fired as well.
Third, you are probably not as important as you think you are. Upper management isn't sitting around singing your praises in their weekly meeting. No, they are focused on the rising star who is executing new ideas and launching new product lines. You are meanwhile being taken for granted.
Now, if you are in this position the author writes about, the time to get out of it is now. Realize that no one can help you but yourself. Start redirecting people, or ignore them altogether. Make noise up the management ladder. Play dumb if you have to. Eventually the rest of the company will find some new punching bag and leave you alone.
Too true. My favorite quote on this topic is that "work will never love you back". It's easy to get wrapped up in what we are doing (sometimes the less important it is to the world, the more I need to get wrapped up in it to be motivated), but work pales in comparison to:
* a good conversation with a friend
* time outside, contemplating nature and purpose
* a hug from a family member
But we don't treat it like that, unfortunately.
Of course, we all need to eat and I realize I'm speaking from a position of privilege (not worried about where my next meal is coming from).
Once you get to an income of X (where X varies by location, needs, but is definitely a finite number), time is so much more valuable than money.
I just want to note that this is a poor generalization. Much like how people wonder how I have the discipline to get up early and workout, it's because I enjoy it. I also enjoy my job the vast majority of the time, and I suspect many others do also. My dad always comments "I'm amazed you get paid to play on the computer all day...", "Me too dad, me too".
As a generalization, it's a good one. That there are exceptions doesn't make it a poor generalization.
If you enjoy your work more than other things, that's great. For me, even within the domain of tech, there are much more interesting things I'd like to do with tech than what I do for my job - and most of the things on my list will not be supported by the market - they're confined to hobbies.
What would you say is a good generalization when it comes to work life balance? There's sure a spectrum, from the folks who love to work (or even workaholics) to slackers who don't want to.
There are people who are indispensable to the point that entire products, teams, or companies rely on them (for better or worse). The company very well may not go on running if they are hit by a bus. At the very least a product (or products) may be cut and teams made vestigial or laid off.
This is something I wish I'd understood earlier in my career. Your company doesn't care about you, nor should you expect them to. You might give 110% and be a well-regarded model employee. But I guarantee the day after you leave they'll advertise your position and replace you.
I’ve gotten laid off twice despite department VPs two levels up trying to keep me.
The second time I realized that there is no point in trusting in anything related to my relationship with the company.
It doesn’t matter how good you are when the people making decisions either don’t know or don’t care. Eventually you become inconvenient in some way and you get removed.
reversedly, I was at a company where I kept focusing on 'stuff', trying to respond on time, hit deadlines, etc. Went to lunch with someone and he kept saying "chill out, don't sweat it". We were late back from lunch. It bothered me, but not him. I found out a few months later he was dating the niece of the dept manager. The two of them were friends with another lead on the floor. This is why he was always 'chill' about stuff. He never hit deadlines or delivered great stuff... it didn't matter. He was 'in'.
Maybe he was in because he was pleasant to work with and not stressed all the time? I've seen new busybodies like you (maybe) and no one wants to be around them.
being given deadlines ("get XYZ done by march 1")... i take that as... "this needs to be done by march 1". This was very much more towards 'nepotism' than "oh he's just so pleasant".
Colleague (new, like me) was given task of "build web software feature X for the marketing team, and you have to ensure colleague B is trained". Colleague B ... did not understand browser technology or server vs client stuff (literally - 'how do you upload a file?' and 'how do you submit form data'?). Colleague tells boss "I can work on training B, or get feature done, but can't do both by the deadline in 2 weeks". "That's your problem, get it done". Feature was done, but marketing team didn't want it ("why did you build this?"), and B wasn't 'trained', and this reflected very very negatively on my colleague. The 'chill' guy? Regularly missed deadlines and delivered buggy stuff. But hey... he's chill, so everything must be cool, right?
If you have loose deadlines... just say "this is a loose deadline".
Unsure how doing work you were assigned is being a 'busy body', but hey, you were there, and I wasn't, right?
This is also a place where the tech leads in charge kept pronouncing that HTML tables were "depreciated" and we should build all tabular data in divs only. In 2004. As in "transform these dozens of Excel spreadsheet data in to something that looks like a table, but... hey you can't use tables, because they're depreciated". If you can't even use the word correctly... I'm not sure I can trust you. This effort took 8 people 3.5 weeks to recreate 'table-like' visuals (across Netscape and IE 5 and 6) with discrete CSS for each browser because... 'depreciated')... It should have taken 2 people a day, and initially it DID, because it was done, then... 8 people were roped in to redo it all without tables.
But seriously, this is me, though to a lesser degree (this guy sounds much awesomer then me).
10 years ago, I exited a shrinking technology community. I loved it, but the signs were on the wall. I knew I’d be one of the last ones to turn out the lights. I was just past 41. The prospect of looking for work at 50+ with guru expertise in a Cobol like technology terrified me.
There seemed to be two basic paths at the time. Embedded or web. It seemed like web development was getting commoditized, community college grads earning $17/hr to hammer out a web site for the local pet store. Embedded seemed more lucrative, and I had a decent level of C competency.
I made a choice to become a polyglot as well. I would embrace the “best tool for the job” mantra, and avoid being pigeonholed by any single technology.
An opportunity in our small community opened up to be somewhat entrepreneurial for a medium size company and I jumped in. Our number of participants is no where near as large as the article. 10 at most. But 10 years later, I’m indispensable. I own the embedded C code that runs the 3 different node types on a proprietary LoRa network. The protocol that communicates with the edge device that runs embedded Linux, running multiple systemd services, the uboot configuration, the cooperating Python programs, our own BLE driver from said Linux board, the MQTT and BLE communications schemes and binary json like protocol that communicates to apps. The Kotlin code that runs the two apps. The horror that is working with BLE on Android. The objective-C then Swift code that runs the same two iOS apps. The elixir service that transforms MQTT traffic to swaggerified API. The ansible scripts that configure our servers. Etc. I try to document things, write good code, unit tests, but there’s still a huge amount of “how it all fits together” and “we tired that, don’t want to go there” knowledge in my head.
I have enjoyed learning all these things and more. But I regret I never get the time to get really good at any of them. I regularly experience tuple dysphoria (“how do we do tuples in this language again?”) and other similar “why do all of these languages need to do the same thing differently?” And feel like I always probably need to go figure out how docker works or some other new thing so that I can keep pushing our product offering into new and exciting places.
And like the fine article, I am well remunerated, I am indispensable, I don’t know if I can keep this up til retirement, and it’s kinda lonely. I don’t see a way out. People want to pay $120K for a dedicated Elixir developer, not 180 for “does a lot of fricking things kinda.”
A couple years ago, we hired someone to “help Travis” but it didn’t work out so well. I’m still trying to figure out why.
(I should add that there’s still interest in hiring another body to participate in this madness of polyglot indispensable-ness, if such a thing sounded appealing, email’s in the profile)
To me stuff like this sounds lovely. But sadly I am neither proficient enough to be anywhere near the level of what you need as a "help Travis" person.
I am my own kind of JOAT (jack of all trades) thing. I do mostly data work. Mostly web stuff. Nowadays a lot of strategy, architecture but also still implementation, JS work, python, ETL. Currently building an internal system next to client work for our team to have a play ground. So setting up a fake online shop with fake traffic (selenium) so that the web analysts can try out new tools with somewhat realistic levels of traffic and see if these tools might be something that helps clients solve their problems.
I love the fact that I have colleagues who do parts of that stuff and from whom I can still learn a lot. And I like the diversity of it.
But I agree - regarding the technologies I use there is a longing for "the time to get really good at any of them".
That sounds a lot like my current situation (though awesomer in turn than me). I'm doing everything from servers to microcontrollers, Android barcode scanners to power tools, running network cable to restoring antique lamps (really!). Trying to keep syntax, data types and structures straight in Python, PHP/HTML/JS, and Arduino/C++. Maintaining the network of security cameras. Sometimes database stuff too.
This is a dream job for me but I wonder where I can possibly advance from here. I know they don't (can't? won't.) pay enough for me to be able to afford to stay here forever. And I'd really like to work with a team instead of being the only person who can do a bunch of things.
I had a helper too for a while and it was awesome. But they moved away and I've been struggling to keep up. I tried training a few other people to help and they weren't really into it. It did at least force me to come up with some better documentation.
I wonder if this is where most developers end up getting. You can stick to being good at one language/ecosystem, but the more you age the more things you learn and unlearn, the more components and scope the company adds.
Alternate title: How it took OP years to realise their teammates and colleagues deserve agency.
No such thing as "indispensable". Very few companies and projects die to a singular departure, you're just not that special kiddo.
What's actually happened here is a selfish desire to know things without sharing them. If you learn something new, share it somewhere.
"People came to ask the Oracle questions only the Oracle could answer for the Oracle refused to share knowledge by any other means".
Confluence is pretty good if you use it properly. Weekly knowledge share sessions are also handy.
Learning a thing and sitting on it makes you an asshat, not an asset. Seems OP learned the hardway, but they still need to remove their ego from the equation.
You're not good at knowing things (basic human capability that), you're terrible at sharing them.
You can lead a colleague to documentation, but you can't make them think.
It doesn't sound to me like knowledge is being hoarded here; it's all there for the taking, but OP's colleagues have discovered it's more convenient for them to ask OP rather than seeking it out for themselves.
Maybe that's an issue with discoverability, or maybe OP has a history of being too available for questions. Sounds to me like OP might in fact be sharing too freely, thus making documentation/experimentation less attractive.
> You can lead a colleague to documentation, but you can't make them think.
You can point them to the docs that answer their repeat questions rather than spending time to write a unique response every time. Author writes that this worked when the questions and answers were made available to others,
> One thing I instituted that helped was a specific Teams channel called Knowledge Transfer. Any questions that would normally have been DM’d to me could be posted there, publicly for all to see. In theory, others could step up to answer these. I could also forward DMs there to respond to publicly or refuse to answer in DM and require them to retype their question in the Knowledge Transfer channel. Rarely did others step up to answer, but it became more like a SoFuckingAgile office hours, which was still a big improvement.
Kinda seems like the author found a working solution- public email, aka a forum:
> One thing I instituted that helped was a specific Teams channel called Knowledge Transfer. Any questions that would normally have been DM’d to me could be posted there, publicly for all to see. In theory, others could step up to answer these. I could also forward DMs there to respond to publicly or refuse to answer in DM and require them to retype their question in the Knowledge Transfer channel. Rarely did others step up to answer, but it became more like a SoFuckingAgile office hours, which was still a big improvement.
I don't like how you're blaming the author of the article here. My experience is that people, be it from the business or from the Product team or Sales or wherever, are happy to ignore documentation and come directly to the person they see as the knower. You can document all you like, they will still come to you and you are the bad guy if you don't answer them and point them to the wiki.
Do some people exist who don't share their knowledge? Definitely. In fact they are rewarded in many cases because they get whatever they want (usually outside of a higher salary)
However, author wouldn't be writing an article like this if he was happy in that position.
We are not indispensable even to human relationships we assume we would be (forever and ever), how come we consider ourselves indispensable to legal entities like companies?
This was a rhetorical question, i have done that mistake in both occasions. In the case of companies, it isn’t even worth it.
In any job; you are not indispensible. You may think so, or others may tell you so. But you are not. You can easily be replaced. It is just a question of cost.
And while it is fun to fantasize about snarky comebacks. Don't do it.
In ten years time, no one will remember what sort of professional contribution you made. But they will remember whether you were nice or not.
I can relate to some of this because I like to understand how things work, like the article author said about himself.
At every job I get hit up with questions because I put in the time to figure things out. I often get annoyed if the other person hasn't done their homework before coming to me, and that comes through in my communication. Because of that, I have a reputation as someone who is "prickly" and thus someone to contact as a last resort.
Quite frankly, I like it that way. I'm still helpful to coworkers, but not so helpful that they'll ask me before finding other ways to get their question answered.
The people most common to enter this state are people who don't trust their co-workers to do the right thing and instead get involved so heavily that in the end they are pulling all the strings. You may call them "control freaks". Sometimes branding themselves as "perfectionists".
When reading his story it became apparent that that's likely his problem. Unless literally everybody in his org was completely lazy (which, honestly, is unlikely), he clearly drowned other people's requests for help with "oh just get out of my way, I'll just do it myself" and there you go, next dependency on himself is introduced. Note that I'm not insinuating that it was on purpose. It's just the natural result of somebody not letting others do things, and fail and learn on their own on the way.
Kudos for realizing that it's a problem and for pulling out of the process. But we only see his side of the story here.
> It's just the natural result of somebody not letting others do things, and fail and learn on their own on the way.
How is this supposed to work though? You can do it yourself and succeed, or you can allow others to fail. If others are constantly failing where you (feel like you) could have succeeded, that’s it’s own form of exhausting.
That's right. That's a problem for management to solve though, not for the guy in the center who could have succeeded all over the place where everybody else keeps failing all the time.
If that's really the case. It could also be the case that there are sometimes just different opinions, and one side of the argument is just more persistent and dominant and "just does it themselves", instead of accepting that a different solution would also have brought the org to a good result. Then that lone superstar gets frustrated (because they think they have to do things themselves), their colleagues get frustrated (because there is that guy that just does things on their own and better be quiet than pick a fight) and it's overall not sustainable for the org. Again, a problem for management to solve.
Yes, sometimes helping people learn means letting them make mistakes. Watching someone do something slowly and poorly can test your patience. But they'll be faster and better the next time. Have patience for them to learn, while being available to guide them when needed or when their mistakes would impact the customer.
I would say your assumption here is unkind and itself lazy.
I have often seen this kind of situation and the cause has always been the same: The most senior in the organisation are ridiculously poor at building their org.
They have hired someone who is pretty great at stuff and they got them by accident, for cheap due to some circumstance, and now attempt to grow without realising they got lucky.
They hire net negative contributors and making it more difficult to deliver, not less. They cannot comprehend that there won’t be some magic that turns these people into productive and driven employees without their own growth in skills, attitude, and care in direction. They are likely incapable of such things.
The person or people at the center of this are stuck, yes. They can’t spread their knowledge because others will actively avoid admitting the docs exist, or refuse to ask Google or another employee. They certainly can’t spread their attitude and skills because no-one else cares or has the incentive or ability to skill up.
There is only one eventual route for the capable and driven: leave and go somewhere where there are better people in senior roles.
If everybody around is relatively incompetent, then the superstar at the center can't fix that. The overall result that the org produces is based on everybody and eventually "regresses to the mean" of what everybody contributes. Management and also the superstar need to accept that.
I write "relative" because it's a matter of perspective. Maybe from the superstars perfectionist perspective, the others are incompetent, but from the outside they are "good enough". Or maybe they are not, but the point is that there is a mismatch and the superstar needs to either accept that or leave. The third alternative, trying to lift things to the superstars (real or perceived) standard by "I'll just do it myself" is not sustainable and results in situations as in the discussed article.
Yes, your conclusion that this person / people should leave is the same as mine. I’m also saying, however, that the person / people you’re describing as ‘superstar’ don’t have to be that at all. There doesn’t need to be a 10x contributor and lots of average people. Just a 1x contributor and lots of 0.01x or -10x people.
Too many owners / managers believe that to grow your business you just need to add people, that they are great at hiring people, and everyone will just sort themselves out and work together. They are then surprised that this doesn’t happen, despite their faith in their own competence at making this happen.
I’m not saying there aren’t perfectionists out there with an inability to share or unwillingness to let go. Just that the situation being described could be exactly as described and not just one side of a story.
I think this isn’t justified. There’s people who are control freaks, but it’s not necessarily OPs case.
In a product I delivered (I do hardware design), I helped the “firmware team” (one guy at that point) to get started because I was more experienced, and stuck helping with some small modules to get things ready for demos and things of that nature.
Later the team expanded, so I let go of firmware development and went back to my work, and the code slowly changed to the point that I wasn’t really aware of what the device did in scenario X, much less how it did that.
I still was the go-to guy when it came to questions about the device behavior for months, even if all my replies where “I have no idea, ask this people”.
All it takes is for someone to say “that guy has been working on this since the beginning”, and a lot of questions will find your inbox when others are unsure about the answer.
2- keep track of the convo. If it is going off the rails help the engineer get back on the rails
3- if the engineer cannot help, jump on a call and explain to the engineer how to help. Then let them help.
This is how teams grow. This also let's you, the technical leader, inject yourself and assist the team without being the only source of truth. And also you become trusted.
I was leading the large project, it was a core system for a financial organization.
Because of a fast pace and because of the fast growth and because of the unexperienced management, it was impossible to quickly train and delegate things to the appropriate people.
I was often getting a call from the devs, asking for help, and I was like “it works so and so, check the X file and find the Y method, that’s where you should apply changes. When you do that don’t forget to do Z.”
I was also getting calls from the top or middle level management. They were asking me things about the product specifications, marketing metrics, etc…
Literally everything “that guy” that knew everything.
The pace didn’t slow down, the opposite, company wanted to grow like crazy. I couldn’t keep up with everything. I remember I had a honeymoon in Thailand and I was literally hanging on a phone to dictate people how things worked and what they should have to do.
Things ended up miserably. The new CEO came and we agreed that I needed help with the delegation: I needed suitable people on-board and time to teach them. The process started. But it was going slow. We still had a fast pace of growth and I was trying to hire and delegate along the way.
After some time, I was accused to be a “ corporate parasite”, keeping all the knowledge to myself to be indispensable and irreplaceable. I left the company soon. Did my best to transfer the knowledge before that.
In the end, it’s been one of the best experiences I had. I grew professionally and mentally, nowadays I easily spot the problems while they become big, know who is who in a glance and so on… I learned a lot along the way.
Several advices someone might find useful:
1) If you cant align with the decision makers you either have to get used to it or move on. Mostly you have no control on the other peoples’ thoughts. If it’s broken, it’s broken. Period. Don’t prolong your decision.
2) Always under-commit and sometimes try to over-deliver. Depended on the quality of your management or organization you might want to over over-deliver and be respected. If you’re in a situation like this then good for you.
3) If you want to grow your organization and the team, you must learn how to delegate tasks and get deliverables, without micro-managing people.
4) In the end, its more about people and less about technologies. Your job is to understand, manage and delight people and solve all the problems along the way.
>1) If you cant align with the decision makers you either have to get used to it or move on. Mostly you have no control on the other peoples’ thoughts. If it’s broken, it’s broken. Period. Don’t prolong your decision.
295 comments
[ 3.0 ms ] story [ 275 ms ] thread> I had a hard time thinking strategically about product. I was too busy supporting the entire organization on all things related to the product.
so that's a pretty clear indication of what was missing. Instead of being able to recognize broad industry trends and come up with broad product evolutions that meet those needs, this person is stuck answering quibbles about particular customers or particular implementations.
Throwing that away to become just another Pac-man gobbling tickets in a maze for the sake of being Agile or whatever reminds me of "...the struggle was finished. He had won the victory over himself. He loved Big Brother" in its joy at self-abnegation.
Reams could be and have been written about estrangement in society, the reduction of human relationships to mere transactionality, but being The Person Who Is Expert At This Thing in your little Dunbar's Number sized company (give or take) beats being some plastic gear, designed to be replaced as a sacrificial component, if you are interested in stability, continuity, or even something as antiquated as pride in your work.
I sort of get it -- at an early job, we had a lot of clientele. I inadvertently memorized, well, everything about them: faces, names, various ID numbers, and so on, and instead of the handy lookups provided, employees would just call me and ask. This got annoying. But I was also twenty-four and managed to push back enough to say, "You have the ability to look all of this up." Being bothered with dumb questions if you have all of this documentation and a wiki or whatever, yes, that is not acceptable, but I think there's a middle ground at least between being the Turing-complaint helpbot and just bolting out of there so you don't have to be The Guy in the Know.
Some of the worst behavior I've seen in both myself and others has come when you can hold your company hostage by refusing to do something. Even when you are using it for 'the greater good', that's not a good look and not a great feeling. You shouldn't have to go with the nuclear option to get something done, even if 5/8ths of your coworkers all feel it's the right thing to do. And many people use it because they can, through some mix of hubris and/or burnout.
When people say things like, "first, fire all the heroes" it's situations like this that they are thinking of, among others.
The result was not good: deciphering the how of things was bad enough, but the why, the contexts of the decisions was utterly gone. Nobody could say why things were done, and so it was either the old joke about the five monkeys or the Second System Effect. Glorious chaos, the confidence of our clients eroded, terror at making changes that might affect the way things had been, dread of not making changes to cope with extant problems.
Thanks, but I'll take the M.A.D. that results from the threat of the nuclear option over someone getting to yank out my heartplug ala Lynch's Dune.
The people who have reverence for the heroes are as much or more of a problem as the actual heroes, and they need to be shaken severely. It's going to be ugly any way you slice it because like so many things in software, you're in a position where someone should have yelled "stop" years before and instead things just kept going, far past unreasonable into a first-rate dystopia.
If you fire one belligerent hero as an example to the others, you might be able to make it work. But if you have one 'database guy' or 'backend person', odds are very good that they're going to go exactly as fast as they want to go and smile and say 'no' when people ask for major changes that would break up a logjam. If they aren't particularly articulate about why things are the way they are it's easy to get the impression they are running things instead of the titular managers.
Management's job is not to make decisions about databases for the database person, but to communicate about problems and priorities, and so on. Don't get me wrong, the dark hilarity of malicious compliance can be great when someone commands you, like they are some bumpkin who just rubbed a lamp and acquired a genie, to do something that is gonna bring down production at noon, cutting off your about-to-be-voiced objection, but let the managers manage and let the experts be experts.
I’ve been around enough to know that these ultimately are political and cultural problems, and you either have to expect change to be slow in these situations or leave to find a different team…
I’ve tried a bit of both, and gotten frustrated, and in the end, the stance I’ve settled on is to be helpful to change people’s minds. It’s hard though. Being persistent and pushy with help will fail. Having the person you’re helping describe a problem or agree something is a problem, that is the first step to helping find a solution.
I guess another way of putting it is management can suggest using technology X but there should be some kind of identifiable problem to solve. There is always the exception though. For example, the problem identified might be that there are too many technologies and X is the new standard. That’s… sometimes the reason and … what can you do? Having been on both sides of the fence here, you never know, X might not be so bad… or you’ll need to fix a ton of bugs.
As long as you stay happy and helpful, you can maybe nudge things in the right direction? For example: X has uptime issues. If X is already adopted, document the known issues for devs or DevOps, or identify consultants for X that can provide training and support. Figure out how to get data into and out of X if you want to refactor later to a different approach and political winds blow that way. Write cheat sheets that can map what you’re using now to Technology X, and what might be unexpected.
Who knows, maybe enough people will have heard or seen your materials on Technology X that they’re not as impressed or share your viewpoint on it. And if you’re really unlucky, you’ll set yourself up to be the cheerleader for technology X. So… there are both risks and benefits to getting too involved in technology shifts/adoption.
I have been in this exact situation. I left the company as a result; kickbacks and graft aren’t my thing.
Everybody knows this and everybody should be prepared to a situation that tomorrow they are not working on the same problem they work on today. How would they structure work? How would they share knowledge? What can the organization to to ensure there always are fallbacks to everybody? At least fallbacks that if not perform at 100% but still on 80 - 90%.
Sadly in my org this would not work of the get go, as we often have personal access tokens to our clients' systems. This is sometimes even a contractual obligation as for specific clients we need to be vetted. But even in these cases we could be reassigned/reshuffled towards a slightly different proposition or at least be reassigned to an internal topic for a few days - just like we would not be able to work if we fell ill.
[0]: https://github.com/Netflix/SimianArmy/wiki/Chaos-Monkey
Plus all the other holidays. Sadly for some mostly junior US employees the 10 days for compliance leave left few other holidays - for the rest of the world, you still have 20 more days to use.
One hero is bad. Zero heroes is worse. You want lots of heroes.
Trying to create a structure where anyone can jump into anything at a moment's notice just leads to everyone having a superficial level of expertise in everything and no responsibility (or worse, responsibility that they can't possibly fulfill so they just get thrown under the bus if they don't hit impossible delivery targets).
All that does is move you from one hero to zero without waiting for your one hero to quit. It's resigning yourself to the bad outcome just to get it over and done with.
The tricky part is that the 'one hero' structure tends to form pretty naturally, so you have to actively take steps to prevent it. If you put a standard team in place and let it run wild, unless the devs understand this problem initially, then eventually you'll just end up with everyone deferring up the chain of command for both knowledge and responsibility over time until a few years down the track whoever was the technical lead on the project is now your hero.
I much prefer to have an ad-hoc structure where important work is divided up amongst the team and each team member takes total responsibility for their part. More senior staff shouldn't be trying to own more code and more responsibility, they should be providing more support to others.
EDIT: I don't think I actually explained how distributing responsibility solves the bus factor problem, whoops. The idea is that part of that responsibility is for managing the bus factor of your own work. This only works if the code you're responsible for is small enough that you can realistically bring another dev or two into the fold and get them ramped up properly with real understanding of the code.
Also, if you own code and are responsible for it, part of that responsibliity should be making sure you have someone with just enough knowledge of the code to take it over should you leave. That's far more feasible if you own a small piece of it than if you own an entire code base.
All that being said the writing was on the wall that I was facing either the nuclear option of resigning, or a second round of even more severe burnout by going along with it.
In hindsight my strategy going forward next time I'm presented with a plan that has predictably disastrous consequences is to simply let them have it their way. IDGAF if you wreck this thing further. I'll even help you do it. We'll maintain friendly relations and I'll leave the company near the end of the project but before it becomes apparent just how bad things really are.
If you can't beat em join em. Cynical as that is I have to protect my mental health and I'm willing to allow you to sacrifice the health of your company to do it.
"between"?
Loyalty towards employees almost never existed in some societies.
And on top of it, Agile, which has always had the whiff of "Taylorism, but from the inside" about it. Always sprinting (huff huff huff); attention atomized by checking texts, emails, phones, voicemail, and of course iterating over an ever-increasing number of Slack channels (or Teams); everything in these bitty increments of moving the assembly line along. And this has to be accomplished through a kind of homogenization, which invariably leads to replacement. But sure, let's hot desk on rows of laminate-topped folding tables for the greater glory.
Isn't 'lean manufacturing" a direct descendant of Taylor and agile a direct descendant from 'lm'?
Agile isn't a methodology, and most methodologies described as Agile eschew formal minutiae.
The problem is, of course, that methodologies, of whatever origin, are, in practice, subject to top-down, non-Agile modification to suit the taste of managers who thrive of formalized minutiae, and, also, the starting point of methodologies for many shops isn't the original description by Agile practitioners who developed them while delivering superlative value but customized versions crafted by and marketed alongside consultants whose jobs are largely telling command-and-control-oriented managers what they want to hear.
The only way to truely make it, is to find someone else, and jump on that bandwagon. Whether that some else is a government contract, or seed funding, or an admissions board. You rub someone elses back and hope to get your just deserts in due time.
I assume it’s a typo for something, but I can’t figure out what. If I google it I get results about money laundering, which doesn’t sound right from the context.
It trains people to not rely on @xxxx in slack (or any other tool for comm). It trains people to write better documentation as they will receive unhappy messages from coworkers if it wasn't clear. And it trains people to RTFM first.
At least - there is a chance it can do all of this.
The best advice I got starting out was, "be indispensable."
The best advice I got four years later was, "don't be indispensable."
In a growing company, the indispensable people may find themselves being left holding the bag while new initiatives are undertaken. I very quickly learned the meaning of 'working your way out of a job' after the first time this happened to me.
I'm sure there's some min-max game I'm not playing with regards to how easy I am to lay off, but once I learned there are worse fates that being laid off, I stopped looking for them. Being "stuck" with responsibilities is unpleasant when things are going well, but it's miserable when things are going badly. If you aren't the one who got laid off, then someone you used to trade off with doing onerous tasks certainly was, and now you're stuck doing it every single time.
If given the choice between "my company would be just fine without me" and "everything would fall apart if I didn't show up to work," the latter feels very good for a brief period when you're young, until the weight of that responsibility sinks in. "My company would be just fine without me," can mean "my work here is done," and you can ride off into the sunset with a clear conscience.
It also makes it way easier to take your vacation time.
If your employer is harmed by you taking vacation, they will find ways to make you miserable for it.
Ouch, I know this one well and it almost cost me my marriage.
This system that I had hacked together, built out and maintained, kept on growing in size, complexity, attributable revenue and potential compliance liabilities. Within the year, I had to call the execs into a meeting to drive home the point that this wasn't a tenable way for us to operate. Everyone had known as much but it was still a tough pill to swallow. I let them get too spoiled at a huge cost to my own mental health.
I had to paint a dire picture to make my case that the system had to be rebuilt from scratch in order to be integrated into the main infrastructure. I ended up leaving a few months later as the rebuild was nearing completion. A couple of months down the road I was surprised to learn that they were still using a part of my system alongside the rebuild. Apparently their architecture couldn't support an algorithm that this component had relied on.
What a mess!
So, I want to be personally valuable to the company - maybe more valuable than the average engineer - but I don't want to have indispensable knowledge that locks me in place. Surely there's a middle ground here?
Easy, right?
Today working in a consulting department, I refuse to take on any work that may look like “staff augmentation”. I just do project based implementations with a definition of done and set aside time for training the customer.
In short, make it a point to share knowledge anyway. Keep a wiki, well written notes or documents, README.md's, whatever. Make it a point that people who are backing you up acknowledge and understand what you have and most importantly ask them to grow that body of knowledge.
Scenario: There is a project your boss is wholly responsible for. You, from a technical perspective, are absolutely indispensable to the success of said project. Maybe it's a small team, or everyone is overloaded, but you can draw a direct line between you quitting (or doing a bad job) and your boss getting called out or potentially fired.
Your boss, however, is not indispensable to their boss, nor is this project indispensable to the larger department. You ask for your raise because of your leverage. Your boss might be worried and try to get it for you. Their boss, not caring about this project that much in the broader context of their work, laughs and says no.
You can absolutely be critical to the success of a project, and even important to your boss's future, but have no real leverage over your situation. That's absolutely a reason to leave but it doesn't mean you'll be able to squeeze any more money out of the place before you do.
However instead of getting angry I get that I may be important to direct boss or one level above. But as far as company goes they are all in cloud, next generation and what not. So my criticality is inconsequential in larger context.
I happen to be one of the people who can (and has!) quit a job on principle. But it's very much a luxury good that I work hard to afford. And it's easier for me: no kids, no parents to care for, no mortgage to worry about. I would rather more people quit their jobs on principle (or risked it through efforts like unionization). But I mostly don't blame them if they feel like they can't.
There’s a thread right now in r/experiencedDevs about a guy who is trying to buy a house while his employer is cratering around him. Stuff like that happens and tends to stick with you forever.
So would they rather have you quit? If not they should be willing to give you whatever title, pay bump, time off, etc. is necessary to keep you long enough for a replacement solution to be found. Otherwise if you just quit they’re stuck negotiating from a position of weakness to hire you back as a much higher paid contractor, or if you decide to take an extended vacation or work somewhere else they are left high and dry.
If you are truly “indispensable”, that makes you the one with all of the leverage. If they can jerk you around without pushback, then “indispensable” sounds more like a rhetorical device / excuse.
Indispensability (true or perceived) hurts not only person but organization as a whole. It creates tension between them, which might break at any point for any reason (a bus, reaching point of no return, dragging organization down) and create difficult to fill void once that happens.
I think it should, however, be considered from the true indispensability and not the perceived one. Perceived one is bullying employees, accidentally or on purpose. Sometimes it's bullying ourselves by creating overly controlled environment that solidified over years.
In perfect life scenario utilizing leverage would work as following: The Indispensable ask for a minor raise (1-5%) -> Company agrees, because The Indispensable is truly indispensable -> 1 month passes -> Repeat
After couple iterations there would be a break point because company will start to weight options and might decide to compensate instead of waiting for next month and another raise request. In this scenario The Indispensable stops being one, so their quality of work improves (less stress) and they get additional income. Company retains The Indispensable since they signaled and through adequate pressure achieved the goal. Fragile process with single point of failure is resolved with more stable solution.
Unfortunately it doesn't work in real life often. Some companies simply can't afford matching expectations, no matter how warranted they are. Indispensability there is simply a tax imposed on worker. Some people aren't confident and courageous enough to bring issues out and try to act on them (as business can be intimidating). Last and not least - true indispensability isn't black or white. There's a mixture of politics, perceived indispensability, true indispensability and controlling behavior by The Indispensable one.
For large enough companies the 'company' is not a single unit making unified decisions. I might be "indispensable" to my boss, perhaps his boss, the project, and my department. However they don't have the power to give me a pay rise or extra time off outside the normal bounds set by their bosses. Me, my boss or even my department however aren't indispensable to the whole global multinational company we all work for.
If I quit and the project fails, then my boss and several people on that project might lose their jobs, and the remnants of that department might end up folded into some other department. My bosses boss might not get a nice bonus that year due to the fact that the project he was overseeing was a massive failure. However "The Company" and it's tens of thousands of other employees all around the world will keep on trucking as if nothing had happened.
“I was hired by the Director to solve $x problem. I led the project. I put processes in place. I led training for the team and they went public a year later. I met my former director for lunch a year later and most of my processes are still there in a slightly evolved form.”
About the same as above from my job after that. But change “Director” to “CTO” and change “went public” to “got acquired for 10x revenue”.
(Yes I can draw a direct line from the architectural changes that let them pivot to selling access to micro services to their value proposition when acquired)
Some of that is wishful thinking on their part. They can’t acknowledge that the riffraff keep the wheels on and may swing the other way as a form of denial. They probably treat waiters like shit too.
Maybe. But - maybe they just follow the path of least resistance, which is to lean on you rather than go up to their bosses and say "John Smith is quitting, and when he does, this project will crash and burn. We must stop this or the company will lose $$$."
I know that many folks here work in elite organizations, so maybe it's hard to fathom, but THE NORM for big companies is to be dumb as a box of rocks when it comes to organizational stuff and technical operations.
Talented people who are intrinsically cross-functional, curious, and who always to do what it takes to "help the team" often get hammered flat from years of the daily grind-stone and then just quit, like the OP.
In most places no one is even thinking about "retaining talent" until it's far too late.
If your bosses are saying “retention” out loud you are probably already fucked, even if your division seems to be doing okay.
It’s kind of the same game landlords play. I always find it somewhat amusing when a landlord forces a business out of a storefront and then the storefront sits empty for six months or a year. How long is it going to take you to break even on that?
In that case, it's beneficial to the landlord to have some scam shop in because even if they're not being paid rent, the money they're saving from an occupied storefront easily outweighs every other alternative.
Toy is just a euphemism. It could be a service, it could be just showing up their friend jimmy that they made more money this year. IT could be to win a bet. IT could be the tenant scratched their Bently. It could be that somebody they don't like frequents the establishment.
Option A) You truly are indispensable and critical to the project, and soon you're going to be their best-paid employee.
Option B) They will now find ways to make you dispensable. And then you'll qualify for that promotion.
I started my second job in 1999 it was for a bill processing/printing company. Companies would send us data files via ftp, we would merge the files and create files in a format used by industrial printers and mail them out. Later on we were one of the early integrators with CheckFree that was the backend for most online bill payment services.
I wrote mostly processing programs in VB6, Perl and C++. I did some GUI programming with C++/MFC/COM (ask your parents).
Fast forward to 2008, the world had moved on. But I was still using VB6 (discontinued in 2001) and C++/MFC. My compensation was only $7K more in 2008 than it was in 2000. There were other people doing the new shiny while I maintained the old systems.
I learned my lesson. Over the next 10 years, I changed jobs 5 times and doubled my income - nothing to brag about. It was still about what entry level developers get as return offers in BigTech. I was laser focused on keeping my skillset in sync with the market.
By 2017 though, I realized my market value as an enterprise dev was going to plateau in 3 years and my youngest was graduating from college. I started pivoting to “cloud” and got into “application modernization” consulting - basically a fancy term for cloud app development and deployments.
I got my current job in consulting in about two years ago.
I work at the one company that pays decently well for AWS + enterprise dev + consulting. It’s not hard to guess which one it is..
I've been there a lot, not on purpose but in some organisations it's either that you get your hands dirty or you spend 10x as much time watching the buck being passed. It's definitely one of those things as a developer where you need to learn some management skills or end up burned out of the job.
I found the problem. It’s not “your company”, it’s “the purchaser of your time and attention”. Act accordingly.
So regardless of being an employee doing bodyleasing towards their employer, being an employee that identifies with "their" company or being a boss/founder/owner/manager these two sides of the axis exist and one needs to find the spot that fits for them within that range.
I don't think there are "one size fits all" easy answers. Or at least if they are given imho and by my experience they are wrong more often than not.
I think for me these sorts of pre-emptions have always felt quite jarring, so the feedback loop for me is tighter than for some.
If you bring me a novel problem to solve, I will happily stop what I'm doing and help you figure it out. For some reason I've only rarely had problems getting back into whatever you interrupted. Whereas with fire drills I have trouble spinning back up into what I was doing before. Perhaps to do with finite energy reserves.
Ultimately I credit my early successes getting promoted to Lead to this pattern, because 'novel' problems either explain a wider portion of the overall architecture to me, or end up being all hands on deck when it turns out this issue is bad and is already in production. I cannot emphasize enough how much smarter you sound offering a solution you've had 30 minutes to an hour to think about instead of 10 minutes. The developer who triages an issue is two steps ahead of everyone else who is thinking on the fly. Doubly so if you have to wrangle everyone into a meeting room to discuss things. Unless the other people are vastly smarter or knowledgeable than you, you will hold your own in that conversation, even if you are somewhat junior. And if you're instead on a par, you will excel.
The méthode en vogue of the current era is to jump ship every 2 years because that's the best way to get a raise/promotion. With that strategy being indispensable isn't that important because you will self-dispense in 2 years anyway.
Personally I feel being indispensable can also be seen as being able to be thrown at (nearly) any problem and finding a solution. Catching the ball and creating the basis for a stable project for others to take over/maintain. I am working at an agency and more often than not there is a first small initiative at a client where we just do not know what is expected/needed in terms of skills and in what direction this initiative might go/grow.
So we often throw two people at the "problem". One more senior "jack of all trades" kind of person that can understand a lot of problems and knows how far they themselves can work towards a solution (and when to call in the subject matter experts). And one more junior person to support and learn by swimming in cold water together with said "senior" (can actually - depending on the problem be a junior/intermediate themselves - it depends).
These "jack of all trades" persons, thinking on their feet, being able to improvise and get things done, able to understand and dig into problems ans find solutions - these kinds of persons are indispensable - but they don't get stuck in one specific problem/project.
The processes around them are built in a way so that we free them for the next thing to come our way. And we do everything we can to create new people of that kind.
I'm not really familiar with the military context, but it's almost how I envision an advance/special forces unit operating in front of the actual lines and first creating a beachhead that the regular troops can then build on and bring their strengths to bear.
These types of individuals are indispensable - but ideally not each of the individuals on their own.
However, being nice to passengers (performing "caring labour" as Graeber would have put it) increases the chances that people choose the bus over e.g. the metro or something else. Deming concluded that it's always your job to do whatever increases the chances of the company you're working for staying in business.
I still haven't found a good way to phrase it, but I'm starting to think that for knowledge/creative work, this can be specialised to something like, "it's your job to teach others to do what you think your job is."
For knowledge/creative organisations to stay in business over the long term, they need to continuously innovate, and for innnovation you want people to be strong generalists. Not just because it lets them spot opportunities they otherwise might not, but also because it lets the organisation run more efficiently with less paperwork, and because it gives people the autonomy they need to think clearly about things.
Being a good human being more often than not (occasional bad moods notwithstanding) should be a non-functional requirement for any job where you interact with other people. I have no problem with anyone, in any role, getting fired simply for being an asshole. The world would be a happier and better place for it.
This entire conversation started based on an example that smiling brought economic benefits, not that you should do it because of socializing benefits. Answering in economic terms only makes sense.
I don’t want a bus driver to fake cheerfulness. He’s there to get me from a to b, not to pretend to be my friend.
The second point, which is related but I think still separate, is that I wish just being an asshole was enough to get fired. I sort of had it in my head but didn't really articulate that I was thinking of being an asshole as a more extreme version of what we're talking about, what I refer to above as just being kind of a jerk. Maybe on a scale of 1-10 being a jerk is a 3 but being an asshole is a 7 or 8.
This are 3 different things.
For employees not to be rude to customers as part of basic work requirements.
But putting on a false smile and feigning warmth to get a tip is a very different thing.
It's quite common and accepted in the US. But also seen as soulless and emotionally manipulative in many other cultures.
What sort of mad world do we live in where that’s even expected of minimum wage employees?
Passengers don’t abandon bus routes because the bus driver didn’t smile at them. They abandon routes when the schedule is inconvenient, there are better alternatives to the bus, the fare is too high etc etc. None of these are in the control of the bus driver.
Wait, they're not? So why should they care, when their bosses don't care even enough to set up a direct reward to bus performance and some way for them to have agency over that reward?
Though it would be cool if there was a bus service that had direct, fine-grained association between curteous behavior and reward in the form of immediate payment and future business, possibly mediated via ratings - I was making a joking reference to Uber here, but "Uber for busses" is genuinely something that I want to exist. Ie. not "Uber Bus", but the standard Uber model of engaging a driver directly, only this time applied to longer timespans to allow better schedule coordination. For instance, some way to say "Hey, I need a bus from X to Y some time between 6 and 7 every workday for the next six months, which time and pickup location is cheapest?" would allow for some pretty cool optimizations in routing. Possibly combined with a Kickstarter-like model where a bunch of people can express prospective interest.
On the other hand, I did implementations as a Senior Develop/de facto “cloud architect” that moved the needle meaningfully at a company with $5 million in revenue. Those same types of implementations happen multiple times daily at a company worth over $1 trillion. Nothing I’m going to ever do will ever have a meaningful affect on the stock price of the company I work at now.
I like smaller proof of concept + training type projects.
They could even make it so that the people who actually take the bus negotiate the time and place.
This would be great for events outside the city.
You can; groups of people hire a mini bus or coach and negotiate where and when it travels all the time for social events, work parties, school trips, etc.
When Deming still had all of his hair, he had trouble getting traction in the states. Japan, on the other hand, was intrigued by his ideas and wanted some quality time from him. If you look at the history of the Toyota Production System, they usually credit Taiichi Ohno and Toyoda, with the origin story sometime in the 80’s, after Detroit was already in flames, but before that was Deming, and for some reason he is usually not mentioned.
Increases is a relative measure. It may be 10% or it may be 0.0001%. At very small values it becomes basically a zero because humans are non-divisible unit at which point your theory is basically in the rabbit’s hole of magic and wizardry.
"Being Indispensable" can also mean two years of no physical or mental time off; it was not fun!
I am currently lucky that all my layers of higher management understand that if my team can function effectively without me for a period of time, that means I'm doing my job well . I was able to take 2 months of paternity without things falling completely apart, and it was a proud moment for me and the team (plus great chance to bond with family). Sure there were things to catch up on and new initiatives and some bad habits to work through, but it was overall a success.
(In addition to "be indispensable" vs "don't be indispensable", one of the best pieces of advice I got and share is "The moment you get a new job/role/position, start looking for your replacement". I did not understand the value of that the first few years, but I now 100% do. I know a lot of HN SME/IC's believe "it's my boss's job to replace me / I'm in & out in a year or two", but if you are even remotely looking for a sustainable career in a company or small market/industry, it will speak VOLUMEs to your foresight, care and team&business responsibility if you have a trained, capable backup identified and positioned, for your times off as much as for your eventual ambitions).
I don't understand first sentence; but based on second sentence, my interpretation of your key point is that you may have excellent technical or functional skills, but if your personality / behaviour / look don't fit, people may still find way to get rid of you.
I believe that is true; and I believe that can be true in both positive and nefarious ways.
I've been a hands-on pure techie for 15 years; I've been in leadership/managerial positions lately; and I cannot believe how positively ignorant I was to ever think my technical skills were the only or even primary consideration.
A person knowing a technology is great. But a person then needs to:
* Understand client's top down business goals and priorities (as opposed to bottom-up technical priorities) to prioritize their tasks and recommendations. E.g. As a DBA, you want to spend your time optimizing tables and indexes and access paths that you have; but business may well prioritize new functionality that will gain them market advantage or reduce cost more than optimizing a technical parameter will. And this tension goes forever in every facet of technology.
* Be able to gather true requirements, eek them out of client and product owner and functional & business team. A person who builds exactly and only what a clueless functional person tells them to, is... OK. A fine junior resource. A person who's been around the block and cares enough about business to ask keen questions to identify needs client/functional wasn't fully aware, identify edge cases, danger zones, risks and discuss them in understandable language, is a worthy senior developer
* Work with the team. Coach junior team members; at least consider feedback from everybody - junior, senior, client, management, functional, business, and integrate it appropriately to make yourself more valuable to them. Make their day better - through your work, yes, but also your attitude. Do you help inspire and motivate and get team members excited, or do you drag them down? Do you help move things along or do you get people stuck in some detail forever?
* Communicate well. Strive to understand and be understood. Ensure your team mates and management know what you're doing, how you're doing, how well you're doing, the thoughts and plans, and risks/barriers/issues/constraints you're encountering (as much as they need/desire to). Be self-guided when you can; Ask for help when you reach your limits. (those two goals are a LIFEtime's work to improve and hone and fine tune:). Ensure everybody understands the plan and agrees to plan. Be at all times aware other people's context/background/assumptions/knowledge/perspective may be completely, wildly different than yours; avoid unspoken assumptions and ambiguities.
* Understand your management's goals and help them succeed. It is stunning to me how few technical people (myself historically included!!:) didn't know, and did not want to know, what the management/business goals are. We have this duality of "Just tell me what to do, I don't want to deal with politics and business crap" and "I'm angry that we are not doing what I think we should be doing, how I think we should be doing it".
etc etc etc.
This is not to say that teams and companies don't abuse the "cultural fit" notion; or that north america isn't way too prescriptive about "being a team player to the point of being a yes-person"; or that there isn't racism/nationalism/personal preferences and bias in recruiting and other decisions. There 100% is negative and unproductive ways to people manager, and I see it all the time. But I think many of us would benefit from awareness that our technical/functional skills are a) not the only thing we are judged on and ...
So if you get vocal (online) the security services get involved, its as simple as that, they will keep you busy, and so will other people, whether you like it or not, but not everyone gets to spot when the spooks are getting involved, which is partly their job ie to have deniability of their actions, but thats the way it is.
2nd point, spot on, correct.
The rest of your post is what you have experienced but you dont mention office/team politics, that also plays a part, plus customers who despite all the training are fixated on something else and wont accept a superior solutions until perhaps years later.
Some management are just as bad at conveying their needs as staff at the other end of the hierarchy. People dont always know what they want until its gone.
You can get buried under communication, effective communication is generally better, but everyone is different.
Everyone has a different opinion on the best approach.
This is so worth it! A decade ago, I was the technical cofounder of a still-small startup. For a while, it was just me and my co-founder. But when we got signs of product-market fit, I hired a team of developers. We set it up so the default was pair programming with frequent pair rotation, with a lot of other tweaks to make it very collaborative.
This paid off in a lot of ways, but for me the biggest came when my mom got sick. I had to fly across the country and stay for weeks at a time to help her and coordinate her care. I was worried things might grind to a halt. But because every commit to the code base involved at least two people, it was fine. There were things I understood better than others, but there was nothing that was a scary mystery that nobody had touched.
When I left the company, it was the same deal. We were on good terms, so they were welcome to call. But they rarely if ever did! It was great to pop in now and again and see them just chugging ahead.
You can always do that.
If your interests change, your dispensability should change with it. But this is very hard to achieve, so you get a complex goal of optimizing for many things at the same time.
OP could have just taken a long vacation.
Long story short, it's impossible to take a long vacation while working for many companies.
The worker on sabatical is just a lazy bum who cant be bothered to go to work (or an hard working inspirational visionary C suite executive).
Anyway, at my company (F500), if you take over 30 days unpaid, you need to reapply for your job.
77 Companies that offer sabbaticals: https://fairygodboss.com/career-topics/sabbaticals-77-compan...
Overall, it's not unreasonable to assume I'm a control freak and couldn't let projects go. However I'm a big proponent of letting fires burn and I delegate to no end. My particular type of stuck was exasperated by a corporate culture that has sales quotas pulled out of the air and implementation that was tracking time down to the minute because 90% had to be billable. In that culture there's no incentive or ability for individuals to learn.
And no amount of documentation solves this because documentation is useless if it can't present itself at the time of need. Because rest assured, no once (including me) can find anything using the horrible Confluence search.
But sadly this solves it for the people relying on your documentation. Not for you if you rely on anyone else's documentation if they don't act accordingly.
At my job, we use Confluence extensively, with dozens if not hundreds of spaces, and in some spaces, searching for something is a delight, while in others it is impossible to find anything without already knowing their byzantine structure.
Usually, the "good" spaces are ones with one or three "custodians" who mercilessly impose a sane structure upon the space. The "bad" spaces are always those where dozens of people create articles and sections as they see fit, without any coordination.
If you need to know the structure to search, IMO the search experience is broken. Most searchers want to type topic related words and expect useful results.
One quick and easy way to improve Confluence's search would be to rank often-visited articles higher than rarely-visited articles.
Anyway, as I've already stated, Confluence spaces which are well looked after and are not allowed to get cluttered are a delight to search in, and as a bonus also a delight to just browse through.
P.S. Google Search results are often lousy and full of low quality results anyway, I'm not sure mentioning it makes your point as well as you think it does. As everywhere - crap goes in, crap comes out. :)
Search is not a substitute for good documentation. Neither is "read the code" or "you should just know", which are the most common answers I get from developers.
This is a symptom of bad communication.
I faced some of these issues in a company, and the best solution we found was creating a massive “FAQ” single page where (browser) search could get you what you wanted, and a firm policy that any question asked should end with a modification to the document.
All questions had to include the search terms used to find the answer, and if it was a “failure to find”, those search terms would be included in the “related tags” section of the question for next time.
I find some people just don't know (or care about) the right way to use Slack. They need to be taught "Hey, don't bother 100 people in this channel for your niche question." Some are oblivious, some don't care about other people. Either way someone needs to pull them aside and say "stop it".
Having management that allows that to continue indicates an unhealthy organization.
Message says, e.g.:
Of course it doesn't always help!In my experience if a company is so incompetent as to allow a single person to genuinely become indispensable, they're also so incompetent as to barely know it, and do nothing about that person leaving.
Only after leaving will the fires really begin (or intensify), which is probably just a variation on business as usual anyway.
The amazing thing is that, depending on what the corporation needs, the worker is made to feel either of these things.
The post in the OP is the worker feeling the latter, with a twist: being made to feel indispensable to shove off as much work as possible on the worker.
Second, being indispensable doesn't do a whole lot for job security. If the company is doing well, you need to perform exactly at average to stay employed, no more. And if the company is down in the dumps and there are mass layoffs, who is going to judge how much knowledge you have in your head? All the people who know how good you are are probably getting fired as well.
Third, you are probably not as important as you think you are. Upper management isn't sitting around singing your praises in their weekly meeting. No, they are focused on the rising star who is executing new ideas and launching new product lines. You are meanwhile being taken for granted.
Now, if you are in this position the author writes about, the time to get out of it is now. Realize that no one can help you but yourself. Start redirecting people, or ignore them altogether. Make noise up the management ladder. Play dumb if you have to. Eventually the rest of the company will find some new punching bag and leave you alone.
Too true. My favorite quote on this topic is that "work will never love you back". It's easy to get wrapped up in what we are doing (sometimes the less important it is to the world, the more I need to get wrapped up in it to be motivated), but work pales in comparison to:
* a good conversation with a friend
* time outside, contemplating nature and purpose
* a hug from a family member
But we don't treat it like that, unfortunately.
Of course, we all need to eat and I realize I'm speaking from a position of privilege (not worried about where my next meal is coming from).
Once you get to an income of X (where X varies by location, needs, but is definitely a finite number), time is so much more valuable than money.
I just want to note that this is a poor generalization. Much like how people wonder how I have the discipline to get up early and workout, it's because I enjoy it. I also enjoy my job the vast majority of the time, and I suspect many others do also. My dad always comments "I'm amazed you get paid to play on the computer all day...", "Me too dad, me too".
If you enjoy your work more than other things, that's great. For me, even within the domain of tech, there are much more interesting things I'd like to do with tech than what I do for my job - and most of the things on my list will not be supported by the market - they're confined to hobbies.
* time outside, contemplating nature and purpose
* a hug from a family member
you can do all these while working a lot....
The second time I realized that there is no point in trusting in anything related to my relationship with the company.
It doesn’t matter how good you are when the people making decisions either don’t know or don’t care. Eventually you become inconvenient in some way and you get removed.
Colleague (new, like me) was given task of "build web software feature X for the marketing team, and you have to ensure colleague B is trained". Colleague B ... did not understand browser technology or server vs client stuff (literally - 'how do you upload a file?' and 'how do you submit form data'?). Colleague tells boss "I can work on training B, or get feature done, but can't do both by the deadline in 2 weeks". "That's your problem, get it done". Feature was done, but marketing team didn't want it ("why did you build this?"), and B wasn't 'trained', and this reflected very very negatively on my colleague. The 'chill' guy? Regularly missed deadlines and delivered buggy stuff. But hey... he's chill, so everything must be cool, right?
If you have loose deadlines... just say "this is a loose deadline".
Unsure how doing work you were assigned is being a 'busy body', but hey, you were there, and I wasn't, right?
This is also a place where the tech leads in charge kept pronouncing that HTML tables were "depreciated" and we should build all tabular data in divs only. In 2004. As in "transform these dozens of Excel spreadsheet data in to something that looks like a table, but... hey you can't use tables, because they're depreciated". If you can't even use the word correctly... I'm not sure I can trust you. This effort took 8 people 3.5 weeks to recreate 'table-like' visuals (across Netscape and IE 5 and 6) with discrete CSS for each browser because... 'depreciated')... It should have taken 2 people a day, and initially it DID, because it was done, then... 8 people were roped in to redo it all without tables.
I ended up quitting in less than a year.
not surprising really.. I've been with this company for approx 17 years now.
Busted up at this point.
But seriously, this is me, though to a lesser degree (this guy sounds much awesomer then me).
10 years ago, I exited a shrinking technology community. I loved it, but the signs were on the wall. I knew I’d be one of the last ones to turn out the lights. I was just past 41. The prospect of looking for work at 50+ with guru expertise in a Cobol like technology terrified me.
There seemed to be two basic paths at the time. Embedded or web. It seemed like web development was getting commoditized, community college grads earning $17/hr to hammer out a web site for the local pet store. Embedded seemed more lucrative, and I had a decent level of C competency.
I made a choice to become a polyglot as well. I would embrace the “best tool for the job” mantra, and avoid being pigeonholed by any single technology.
An opportunity in our small community opened up to be somewhat entrepreneurial for a medium size company and I jumped in. Our number of participants is no where near as large as the article. 10 at most. But 10 years later, I’m indispensable. I own the embedded C code that runs the 3 different node types on a proprietary LoRa network. The protocol that communicates with the edge device that runs embedded Linux, running multiple systemd services, the uboot configuration, the cooperating Python programs, our own BLE driver from said Linux board, the MQTT and BLE communications schemes and binary json like protocol that communicates to apps. The Kotlin code that runs the two apps. The horror that is working with BLE on Android. The objective-C then Swift code that runs the same two iOS apps. The elixir service that transforms MQTT traffic to swaggerified API. The ansible scripts that configure our servers. Etc. I try to document things, write good code, unit tests, but there’s still a huge amount of “how it all fits together” and “we tired that, don’t want to go there” knowledge in my head.
I have enjoyed learning all these things and more. But I regret I never get the time to get really good at any of them. I regularly experience tuple dysphoria (“how do we do tuples in this language again?”) and other similar “why do all of these languages need to do the same thing differently?” And feel like I always probably need to go figure out how docker works or some other new thing so that I can keep pushing our product offering into new and exciting places.
And like the fine article, I am well remunerated, I am indispensable, I don’t know if I can keep this up til retirement, and it’s kinda lonely. I don’t see a way out. People want to pay $120K for a dedicated Elixir developer, not 180 for “does a lot of fricking things kinda.”
A couple years ago, we hired someone to “help Travis” but it didn’t work out so well. I’m still trying to figure out why.
(I should add that there’s still interest in hiring another body to participate in this madness of polyglot indispensable-ness, if such a thing sounded appealing, email’s in the profile)
I am my own kind of JOAT (jack of all trades) thing. I do mostly data work. Mostly web stuff. Nowadays a lot of strategy, architecture but also still implementation, JS work, python, ETL. Currently building an internal system next to client work for our team to have a play ground. So setting up a fake online shop with fake traffic (selenium) so that the web analysts can try out new tools with somewhat realistic levels of traffic and see if these tools might be something that helps clients solve their problems.
I love the fact that I have colleagues who do parts of that stuff and from whom I can still learn a lot. And I like the diversity of it.
But I agree - regarding the technologies I use there is a longing for "the time to get really good at any of them".
This is a dream job for me but I wonder where I can possibly advance from here. I know they don't (can't? won't.) pay enough for me to be able to afford to stay here forever. And I'd really like to work with a team instead of being the only person who can do a bunch of things.
I had a helper too for a while and it was awesome. But they moved away and I've been struggling to keep up. I tried training a few other people to help and they weren't really into it. It did at least force me to come up with some better documentation.
No such thing as "indispensable". Very few companies and projects die to a singular departure, you're just not that special kiddo.
What's actually happened here is a selfish desire to know things without sharing them. If you learn something new, share it somewhere.
"People came to ask the Oracle questions only the Oracle could answer for the Oracle refused to share knowledge by any other means".
Confluence is pretty good if you use it properly. Weekly knowledge share sessions are also handy.
Learning a thing and sitting on it makes you an asshat, not an asset. Seems OP learned the hardway, but they still need to remove their ego from the equation.
You're not good at knowing things (basic human capability that), you're terrible at sharing them.
It doesn't sound to me like knowledge is being hoarded here; it's all there for the taking, but OP's colleagues have discovered it's more convenient for them to ask OP rather than seeking it out for themselves.
Maybe that's an issue with discoverability, or maybe OP has a history of being too available for questions. Sounds to me like OP might in fact be sharing too freely, thus making documentation/experimentation less attractive.
You can point them to the docs that answer their repeat questions rather than spending time to write a unique response every time. Author writes that this worked when the questions and answers were made available to others,
> One thing I instituted that helped was a specific Teams channel called Knowledge Transfer. Any questions that would normally have been DM’d to me could be posted there, publicly for all to see. In theory, others could step up to answer these. I could also forward DMs there to respond to publicly or refuse to answer in DM and require them to retype their question in the Knowledge Transfer channel. Rarely did others step up to answer, but it became more like a SoFuckingAgile office hours, which was still a big improvement.
You also gloss over the fact that he addressed this in the article (things were documented, people just kept coming to him anyway).
> One thing I instituted that helped was a specific Teams channel called Knowledge Transfer. Any questions that would normally have been DM’d to me could be posted there, publicly for all to see. In theory, others could step up to answer these. I could also forward DMs there to respond to publicly or refuse to answer in DM and require them to retype their question in the Knowledge Transfer channel. Rarely did others step up to answer, but it became more like a SoFuckingAgile office hours, which was still a big improvement.
While I've never seen a company die due to a single departure, I've seen plenty of projects die due to a single departure.
Do some people exist who don't share their knowledge? Definitely. In fact they are rewarded in many cases because they get whatever they want (usually outside of a higher salary)
However, author wouldn't be writing an article like this if he was happy in that position.
This was a rhetorical question, i have done that mistake in both occasions. In the case of companies, it isn’t even worth it.
And while it is fun to fantasize about snarky comebacks. Don't do it.
In ten years time, no one will remember what sort of professional contribution you made. But they will remember whether you were nice or not.
Be nice.
At every job I get hit up with questions because I put in the time to figure things out. I often get annoyed if the other person hasn't done their homework before coming to me, and that comes through in my communication. Because of that, I have a reputation as someone who is "prickly" and thus someone to contact as a last resort.
Quite frankly, I like it that way. I'm still helpful to coworkers, but not so helpful that they'll ask me before finding other ways to get their question answered.
When reading his story it became apparent that that's likely his problem. Unless literally everybody in his org was completely lazy (which, honestly, is unlikely), he clearly drowned other people's requests for help with "oh just get out of my way, I'll just do it myself" and there you go, next dependency on himself is introduced. Note that I'm not insinuating that it was on purpose. It's just the natural result of somebody not letting others do things, and fail and learn on their own on the way.
Kudos for realizing that it's a problem and for pulling out of the process. But we only see his side of the story here.
How is this supposed to work though? You can do it yourself and succeed, or you can allow others to fail. If others are constantly failing where you (feel like you) could have succeeded, that’s it’s own form of exhausting.
If that's really the case. It could also be the case that there are sometimes just different opinions, and one side of the argument is just more persistent and dominant and "just does it themselves", instead of accepting that a different solution would also have brought the org to a good result. Then that lone superstar gets frustrated (because they think they have to do things themselves), their colleagues get frustrated (because there is that guy that just does things on their own and better be quiet than pick a fight) and it's overall not sustainable for the org. Again, a problem for management to solve.
I have often seen this kind of situation and the cause has always been the same: The most senior in the organisation are ridiculously poor at building their org.
They have hired someone who is pretty great at stuff and they got them by accident, for cheap due to some circumstance, and now attempt to grow without realising they got lucky.
They hire net negative contributors and making it more difficult to deliver, not less. They cannot comprehend that there won’t be some magic that turns these people into productive and driven employees without their own growth in skills, attitude, and care in direction. They are likely incapable of such things.
The person or people at the center of this are stuck, yes. They can’t spread their knowledge because others will actively avoid admitting the docs exist, or refuse to ask Google or another employee. They certainly can’t spread their attitude and skills because no-one else cares or has the incentive or ability to skill up.
There is only one eventual route for the capable and driven: leave and go somewhere where there are better people in senior roles.
I write "relative" because it's a matter of perspective. Maybe from the superstars perfectionist perspective, the others are incompetent, but from the outside they are "good enough". Or maybe they are not, but the point is that there is a mismatch and the superstar needs to either accept that or leave. The third alternative, trying to lift things to the superstars (real or perceived) standard by "I'll just do it myself" is not sustainable and results in situations as in the discussed article.
Too many owners / managers believe that to grow your business you just need to add people, that they are great at hiring people, and everyone will just sort themselves out and work together. They are then surprised that this doesn’t happen, despite their faith in their own competence at making this happen.
I’m not saying there aren’t perfectionists out there with an inability to share or unwillingness to let go. Just that the situation being described could be exactly as described and not just one side of a story.
In a product I delivered (I do hardware design), I helped the “firmware team” (one guy at that point) to get started because I was more experienced, and stuck helping with some small modules to get things ready for demos and things of that nature.
Later the team expanded, so I let go of firmware development and went back to my work, and the code slowly changed to the point that I wasn’t really aware of what the device did in scenario X, much less how it did that.
I still was the go-to guy when it came to questions about the device behavior for months, even if all my replies where “I have no idea, ask this people”.
All it takes is for someone to say “that guy has been working on this since the beginning”, and a lot of questions will find your inbox when others are unsure about the answer.
1- redirect to another engineer.
2- keep track of the convo. If it is going off the rails help the engineer get back on the rails
3- if the engineer cannot help, jump on a call and explain to the engineer how to help. Then let them help.
This is how teams grow. This also let's you, the technical leader, inject yourself and assist the team without being the only source of truth. And also you become trusted.
Win. Win. Win.
I was leading the large project, it was a core system for a financial organization.
Because of a fast pace and because of the fast growth and because of the unexperienced management, it was impossible to quickly train and delegate things to the appropriate people.
I was often getting a call from the devs, asking for help, and I was like “it works so and so, check the X file and find the Y method, that’s where you should apply changes. When you do that don’t forget to do Z.”
I was also getting calls from the top or middle level management. They were asking me things about the product specifications, marketing metrics, etc…
Literally everything “that guy” that knew everything.
The pace didn’t slow down, the opposite, company wanted to grow like crazy. I couldn’t keep up with everything. I remember I had a honeymoon in Thailand and I was literally hanging on a phone to dictate people how things worked and what they should have to do.
Things ended up miserably. The new CEO came and we agreed that I needed help with the delegation: I needed suitable people on-board and time to teach them. The process started. But it was going slow. We still had a fast pace of growth and I was trying to hire and delegate along the way.
After some time, I was accused to be a “ corporate parasite”, keeping all the knowledge to myself to be indispensable and irreplaceable. I left the company soon. Did my best to transfer the knowledge before that.
In the end, it’s been one of the best experiences I had. I grew professionally and mentally, nowadays I easily spot the problems while they become big, know who is who in a glance and so on… I learned a lot along the way.
Several advices someone might find useful:
1) If you cant align with the decision makers you either have to get used to it or move on. Mostly you have no control on the other peoples’ thoughts. If it’s broken, it’s broken. Period. Don’t prolong your decision.
2) Always under-commit and sometimes try to over-deliver. Depended on the quality of your management or organization you might want to over over-deliver and be respected. If you’re in a situation like this then good for you.
3) If you want to grow your organization and the team, you must learn how to delegate tasks and get deliverables, without micro-managing people.
4) In the end, its more about people and less about technologies. Your job is to understand, manage and delight people and solve all the problems along the way.
This times 1000.