Ask HN: How do you decide on when to leave/switch job?
Please elaborate on your reasons rather than one liners like boredom, pay hike, own business/consultancy, co-worker problem
71 comments
Best thing I have on this is a quote from Steve Jobs : "When I was 17, I read a quote that went something like: "If you live each day as if it was your last, someday you'll most certainly be right." It made an impression on me, and since then, for the past 33 years, I have looked in the mirror every morning and asked myself: "If today were the last day of my life, would I want to do what I am about to do today?" And whenever the answer has been "No" for too many days in a row, I know I need to change something.""
On a related note, I hate how that Aurelius quote is always cut off. The full quotation is, "Live every day as if it were your last: without frenzy, without apathy, without pretense." The point isn't that you should go party and have fun and not plan for the future, which the additional "without" clauses clarify. Aurelius meant that you should adopt an emotional state of peace and firm dedication. Because most people really would not party on their last day, if they knew. They would go about their business calmly, taking care of the most important priorities, making amends and sharing time with loved ones, ensuring that their affairs were in order and their conscience clean, and appreciating every detail of every moment as if it were infinitely precious. Nothing would upset them unduly because they would know nothing will affect them anymore soon.
Similarly, you probably wouldn't want to wake up and go to an awful job. If doing your job makes the world a better place, you can justify going because you know you are building a legacy, even with your final moments. If you're passionate about it, you can justify it. If the job allows you to provide for your loved ones, you would go even on your last day.
So Jobs like many others misunderstood the quote out of context but reached the conclusion Aurelius intended anyway. And that conclusion is good advice! If you're just doing the minimum to skate by, not really thriving, you're probably selling yourself short. Unless you have some other reason for working that gives meaning to your life (e.g. kids, funding a passion project/hobby, religion), it's just not worth going to a shitty job just for the paycheck.
Similarly, you probably wouldn't want to wake up and go to an awful job. If doing your job makes the world a better place, you can justify going because you know you are building a legacy, even with your final moments. If you're passionate about it, you can justify it. If the job allows you to provide for your loved ones, you would go even on your last day.
So Jobs like many others misunderstood the quote out of context but reached the conclusion Aurelius intended anyway. And that conclusion is good advice! If you're just doing the minimum to skate by, not really thriving, you're probably selling yourself short. Unless you have some other reason for working that gives meaning to your life (e.g. kids, funding a passion project/hobby, religion), it's just not worth going to a shitty job just for the paycheck.
These are some great comments; thanks for these!
I have seen this quote before, but I hadn't thought about it as a mantra before (ie. putting yourself in the mindset for focus and sales). As a leader of a company, you need to be able to convince your team that this job/task/project is the most important thing in the world. If you don't believe it yourself, you won't be able to sell them (or your customers) on it.
Not learning anymore. The previous job I was at was a rather boring one after a few months.
The company had already encountered most of the customizations clients requested and most of the new projects ended up being solely copy-paste work from older projects. This meant writing no new code but just applying older patch files and tweaking some config like the header and footer of the website.
Since I was not learning anything new anymore at this job it felt like a drag going to work.
I started interviewing for some other companies and one thing I wanted to be sure of was to have a job where I would actually write code instead of tweaking some config files all day long.
I have enjoyed every day at work since I decided to leave that company.
The company had already encountered most of the customizations clients requested and most of the new projects ended up being solely copy-paste work from older projects. This meant writing no new code but just applying older patch files and tweaking some config like the header and footer of the website.
Since I was not learning anything new anymore at this job it felt like a drag going to work.
I started interviewing for some other companies and one thing I wanted to be sure of was to have a job where I would actually write code instead of tweaking some config files all day long.
I have enjoyed every day at work since I decided to leave that company.
Agreed. A job needs to be mutually beneficial or you'll wind up hating every day of it.
I'm at a stage where I have learned a lot, but I find a lot of resistance to implementing my ideas for political reasons - e.g. in replacing our ticketing system, I drew up a proposal for something we already had licenses for, would integrate with our systems and provided features our developers would want. An unrelated team in America had been trialling some expensive software in isolation. I learned the software I was proposing, taught colleagues how to use the prototype, got positive feedback, got licensing sorted (free)... and my idea was swept aside because it wasn't the expensive software the guy in charge (who had approved my prototype) had already decided to go with.
Figured then there was little point in me learning stuff that would benefit this company because decisions have already been made, so I'm moving on.
I'm at a stage where I have learned a lot, but I find a lot of resistance to implementing my ideas for political reasons - e.g. in replacing our ticketing system, I drew up a proposal for something we already had licenses for, would integrate with our systems and provided features our developers would want. An unrelated team in America had been trialling some expensive software in isolation. I learned the software I was proposing, taught colleagues how to use the prototype, got positive feedback, got licensing sorted (free)... and my idea was swept aside because it wasn't the expensive software the guy in charge (who had approved my prototype) had already decided to go with.
Figured then there was little point in me learning stuff that would benefit this company because decisions have already been made, so I'm moving on.
+1 to this. The most important part of any job for me is "do I feel like I'm smarter at the end of the day because of this job?"
I had a job at an advertising agency, which, by most objective measures was a pretty decent job. However, I felt like about 95% of my work was "copy-paste, tweak-slightly". Eventually it got to a point where I wrote a script that could generate most of my work, and I realized that it was time to move on.
I had a job at an advertising agency, which, by most objective measures was a pretty decent job. However, I felt like about 95% of my work was "copy-paste, tweak-slightly". Eventually it got to a point where I wrote a script that could generate most of my work, and I realized that it was time to move on.
What I call the Dilbert-o-meter.
When you start noticing too many Dilbert comics acted out in real life, it's time to leave.
When you start noticing too many Dilbert comics acted out in real life, it's time to leave.
That's a pretty good rule. I worked at a telco and a co-worker pointed out that the seemed very likely that Scott Adams had hidden cameras and microphones in our offices.
When Dilbert-like rules and decisions start showing up to frequently, it's time to leave.
Generally speaking I don't think you should go work for companies with more that 50 - 100 employees. After that stupidity start showing up way too frequently.
When Dilbert-like rules and decisions start showing up to frequently, it's time to leave.
Generally speaking I don't think you should go work for companies with more that 50 - 100 employees. After that stupidity start showing up way too frequently.
There's a reason for stupidity starting to show: Dunbar's number - https://en.wikipedia.org/wiki/Dunbar%27s_number
I 100% agree with the application of this. I've become a bit more flexible however - I take a look at the upper bound consideration of this (closer to 150 - 200 people) and apply that to how many engineers have commit access to the source control system. The marketing, bean-counters and other walking business critters headcount don't concern me:)
I 100% agree with the application of this. I've become a bit more flexible however - I take a look at the upper bound consideration of this (closer to 150 - 200 people) and apply that to how many engineers have commit access to the source control system. The marketing, bean-counters and other walking business critters headcount don't concern me:)
I am at a company of 70 and we seem to still be not-stupid. But I think the general rule is correct; we don't have stupid here because nobody has time for it, and anyone who isn't pulling their weight is conspicuous and gets cut loose eventually.
My guess is that once headcount is over 100, the organizational details start to become too large to fit in any one person's head, and that creates blind spots in which stupid people can go unnoticed.
And if you get even larger than that, at some point stupid people just become part of the cost of doing business that shareholders are happy enough to put up with as long as the stupidity is contained and doesn't obviously diminish their returns.
My guess is that once headcount is over 100, the organizational details start to become too large to fit in any one person's head, and that creates blind spots in which stupid people can go unnoticed.
And if you get even larger than that, at some point stupid people just become part of the cost of doing business that shareholders are happy enough to put up with as long as the stupidity is contained and doesn't obviously diminish their returns.
Before I started my first job, the summer I left uni, I read the entire archive from 1989 to 2012 and laughed at it.
When my job started a few months later, I was absolutely floored when some of the stuff I saw there played out exactly as the comic.
I quit after 3 months. I could not get a single thing done in less than 3 weeks there.
When my job started a few months later, I was absolutely floored when some of the stuff I saw there played out exactly as the comic.
I quit after 3 months. I could not get a single thing done in less than 3 weeks there.
The Gervais principle illuminates a lot of what happens in large organizations. If you ever feel like what you do matters less than how you're perceived, then you're absolutely correct [1].
So far as when to leave, I try to keep track of the health of the division (in a Big Dumb Corp) or company (smaller companies). If the business area I'm in is no longer a focus for the company (opex vs capex) or not meeting targets (whatever they maybe; sales goals, customer retention, etc) then that's a strong signal to start looking.
A few other warning signs: churn in leadership, senior people leaving. When you see the organizational knowledge base packing up and leaving that's a bad sign.
Currently, I've chosen to work in a Dilbert wonderland. This Big Dumb Corp is so dumb it's astounding. I'm here and staying (for now) because the division I'm in is a growth area, my manager is cool, I have one semi interesting long term project to work on, and since they are so big and dumb, they're paying 10-15% above market rate on salary and benefits.
[1] https://www.ribbonfarm.com/2009/10/07/the-gervais-principle-...
So far as when to leave, I try to keep track of the health of the division (in a Big Dumb Corp) or company (smaller companies). If the business area I'm in is no longer a focus for the company (opex vs capex) or not meeting targets (whatever they maybe; sales goals, customer retention, etc) then that's a strong signal to start looking.
A few other warning signs: churn in leadership, senior people leaving. When you see the organizational knowledge base packing up and leaving that's a bad sign.
Currently, I've chosen to work in a Dilbert wonderland. This Big Dumb Corp is so dumb it's astounding. I'm here and staying (for now) because the division I'm in is a growth area, my manager is cool, I have one semi interesting long term project to work on, and since they are so big and dumb, they're paying 10-15% above market rate on salary and benefits.
[1] https://www.ribbonfarm.com/2009/10/07/the-gervais-principle-...
That about sums up the why of my recent job change. It was kind of hard to explain why I was leaving my job during interviews when the question was asked. It's hard to point out one thing and the individual Dilbert-y things seem like stupid reasons individually, but altogether they were a sign I needed to move on.
When your co-workers start getting routinely carted out by emergency workers for cardiac distress, seizures, and other problems developed since they started the job. A job can grind you down and I'm watching my current one eat some co-workers alive. There are limits to how much stress you can put a person through routinely.
Just switch often until you are sufficiently paid and found one that doesn't suffer from dysfunctions like employee/manager churn. Then use the capital you built up to work less, focusing on other things in life than work. Every time you switch you have to prove yourself again, you'll have to prove you are worthy the perks (working from home etc).
My recipe was switching around and then back to my first employer later in my career. A place I knew had good climate where I could stay 5-10 years with ease.
My recipe was switching around and then back to my first employer later in my career. A place I knew had good climate where I could stay 5-10 years with ease.
When a company starts focusing the majority of its energy inwards: politics, favoritism, infighting, thinking of how to look good internally, bullshit stats and presentations, you name it - but very little time spend on the customer or the product.
One of my reasons for leaving is that I'm watching our internal systems dissolve - some of the stuff I have responsibility for is hosted on rickety old systems that are long due for replacement, but management refuses to spend any money (or allocate time to rebuild them) because they're not customer-facing. Painful underinvestment for political reasons will be the death of this company. The IT team are fighting fires on a daily basis, and a major outage would probably have the 4 of them walking out (yes, 4 people supporting a global company). I've wisely decided to move on before it all melts.
When I feel like I can't bring as much to the company as I would like, and either coworkers, managers, company's culture prevents me to so or that I don't feel rewarded for my skills
I have a simple rule. If you're already seriously contemplating leaving, then it's time to leave. Because typically, it's only going to get worse from there.
Chris Dixon once posted something along the lines of this: "If you think you're going to fire someone six months from now, you should fire them now."
I believe that if you think things will get worse 6 months from now, then leave now.
Chris Dixon once posted something along the lines of this: "If you think you're going to fire someone six months from now, you should fire them now."
I believe that if you think things will get worse 6 months from now, then leave now.
+1. My father always says "when you're thinking about getting out of the boat, you're already out". Meaning, if you were 'in the boat', you would be thinking of fixing it.
I am currently in this situation. The company ran out of money and cant afford to pay us. That is a good indicator to find something else.
This is equivalent to looking for the exit when the ceiling has already collapsed.
For me these have been the reasons in the past:
- New job offers me a significant improvement in my standard of living. Twice, it's been the offer to move to a different country. It gives me a chance to experience different places and have better living conditions.
- I stop learning or feel like I am not adding any more value to my role. I start feeling stagnant and worry about future.
- New job offers me a significant improvement in my standard of living. Twice, it's been the offer to move to a different country. It gives me a chance to experience different places and have better living conditions.
- I stop learning or feel like I am not adding any more value to my role. I start feeling stagnant and worry about future.
If on a Sunday afternoon you get a sinking feeling of despair about having to go to work tomorrow, it's time to leave.
I've written a few articles on it.. one included a tyrant boss I had to escape and the other was simply outgrowing your company.
Check those articles out here:
http://www.confessionsoftheprofessions.com/the-opportunity/
http://www.confessionsoftheprofessions.com/outgrowing-compan...
Check those articles out here:
http://www.confessionsoftheprofessions.com/the-opportunity/
http://www.confessionsoftheprofessions.com/outgrowing-compan...
When the calendar becomes more important than the quality.
1) When I dont allowed to contribute in innovation or my inputs are being ignore by Manager/Leaders.
2) People leave managers not companies
2) People leave managers not companies
You always keep looking, and when something sufficiently better comes up, you switch.
Get offers in time, so you have some on hand in need.
Get offers in time, so you have some on hand in need.
If you find yourself doing maintenance work, move on.
There is nothing wrong with maintenance work, it is valuable and gives the company the ability to service its clients. However, if you are no longer able to improve the process and that is what you were doing before, move along.
Maintenance work is a big signal, don't ignore it.
There is nothing wrong with maintenance work, it is valuable and gives the company the ability to service its clients. However, if you are no longer able to improve the process and that is what you were doing before, move along.
Maintenance work is a big signal, don't ignore it.
When I see that smarter guys are leaving.
As long as you're aware that this may not happen if your org is experiencing Dead Sea Effect. Having just gone through this situation, it can be challenging to understand when you're bitter and when you really are surrounded by less-than-ideal developers. Imposter Syndrome complicates this, as well.
I'm reminded of a former co-worker that said he could write down the reasons why he'd eventually leave a job after two months, even if he stayed for years longer. Not always true and sometimes change is forced on us, but a useful insight.
Moving has a cost, in time and effort, and a risk. You can look at the benefits of the new job (and likely downsides!), and weigh them against the current one plus the cost of searching and moving.
Moving has a cost, in time and effort, and a risk. You can look at the benefits of the new job (and likely downsides!), and weigh them against the current one plus the cost of searching and moving.
I just encountered this 2 days ago.
When the company decides to adopt a new (to them) technology stack that is not part of where I see my future self.
When the company decides to adopt a new (to them) technology stack that is not part of where I see my future self.
New tech stacks can be learned. If it fits the development and product, why not? Even if you have a personal dislike for it, you could still learn from it. I find in-fighting, interpersonal quibbles and ridiculing of co-workers far more insufferable.
I've found that learning new tech is orders of magnitude simpler than whiners on the internet make it seem.
I put off learning Rails years ago because post after post talked about how hard it was to get it right, how the person behind CDBaby totally failed to make Rails work for him, etc., etc. Then I sat down to learn it, imagining it would be a long month, but I learned the basics in 2 days. The exact same thing happened with React. I put it off for so long, thinking it was so hard after reading so many posts. It turns out that it's pretty straightforward.
There's still an element of fear before approaching anything new. A voice in my head says "maybe I'm not smart enough anymore to understand this new tech, which looks like it was engineered by aliens." I need to remind myself that I have been able to understand and master everything I have attempted. But the posts out there make it seem learning something new is very hard.
I put off learning Rails years ago because post after post talked about how hard it was to get it right, how the person behind CDBaby totally failed to make Rails work for him, etc., etc. Then I sat down to learn it, imagining it would be a long month, but I learned the basics in 2 days. The exact same thing happened with React. I put it off for so long, thinking it was so hard after reading so many posts. It turns out that it's pretty straightforward.
There's still an element of fear before approaching anything new. A voice in my head says "maybe I'm not smart enough anymore to understand this new tech, which looks like it was engineered by aliens." I need to remind myself that I have been able to understand and master everything I have attempted. But the posts out there make it seem learning something new is very hard.
[deleted]
What about moving to old stacks like... PHP?
PHP's problem isn't its age, but that it was intended to do a very specific task in a very specific context, and people who came to it later lack a fundamental understanding of this. If, somehow through magic, PHP was invented today, it would still have this problem, which is the root of most of the other problems with PHP.
I only mention this because some "old stacks" are good, in the sense that they are heavily battle tested, and people still use them because they've been successful over a number of years. You have to be able to use your judgement as a professional to determine whether the move to the "old stack" stems from a good reason or not before deciding to jump.
(I personally would jump if I someone said "let's use PHP instead," but I don't think I would be in a job where PHP could be considered an alternative in the first place. Your situation could be different.)
I only mention this because some "old stacks" are good, in the sense that they are heavily battle tested, and people still use them because they've been successful over a number of years. You have to be able to use your judgement as a professional to determine whether the move to the "old stack" stems from a good reason or not before deciding to jump.
(I personally would jump if I someone said "let's use PHP instead," but I don't think I would be in a job where PHP could be considered an alternative in the first place. Your situation could be different.)
Then start calling recruiters like your life depends on it.
May I ask what the stack is?
We've just spent half a year moving a legacy* Java app to nodeJS and now some of them want to redo everything in Rails.
*: all the original engineers have left.
*: all the original engineers have left.
That sounds bad.
Generally, someone at the company should be saying no to these rewrites unless they have a very clear business motivation. Total rewrites easily spiral into being costly disasters, and usually don't solve a customer's problems. If nobody is at least trying to say no to these things, that means your company may have other problems with defining business objectives and fulfilling them.
Even if nobody understood the Java app, that itself is not a good enough reason to rewrite it in another stack. Actually, not understanding the current implementation is probably the worst reason to do a rewrite, because the team likely doesn't understand the problem well enough to successfully reimplement the solution.
The fact that they did this in nodeJS and now someone is talking about doing it in Rails makes it sound like there weren't strong reasons for choosing nodeJS established up front. It sounds like people are deciding these things based on hype and not actual technical merit, because the "sweet spots" of the three stacks you've mentioned are all quite different. There are good reasons to choose Java, nodeJS, or Rails for any given project, but there are generally not good reasons to bounce between them for the same project. The only case I can think of where that would make sense would be to move from Rails to Java due to scaling issues (e.g. if you are Twitter). I don't think there is much compelling reason to go the other way, unless your legacy Java app is super-dooper legacy like the FactoryFactoryFactoryFactoryFactory stuff people used to write in the early 2000s. Which itself might indicate an entirely different set of problems.
I'd bail out if I were you and try to work at a company with better engineers working for it. Even if this job is stable you will become a better engineer by being around better engineers who aren't going to be proposing giant rewrites.
Generally, someone at the company should be saying no to these rewrites unless they have a very clear business motivation. Total rewrites easily spiral into being costly disasters, and usually don't solve a customer's problems. If nobody is at least trying to say no to these things, that means your company may have other problems with defining business objectives and fulfilling them.
Even if nobody understood the Java app, that itself is not a good enough reason to rewrite it in another stack. Actually, not understanding the current implementation is probably the worst reason to do a rewrite, because the team likely doesn't understand the problem well enough to successfully reimplement the solution.
The fact that they did this in nodeJS and now someone is talking about doing it in Rails makes it sound like there weren't strong reasons for choosing nodeJS established up front. It sounds like people are deciding these things based on hype and not actual technical merit, because the "sweet spots" of the three stacks you've mentioned are all quite different. There are good reasons to choose Java, nodeJS, or Rails for any given project, but there are generally not good reasons to bounce between them for the same project. The only case I can think of where that would make sense would be to move from Rails to Java due to scaling issues (e.g. if you are Twitter). I don't think there is much compelling reason to go the other way, unless your legacy Java app is super-dooper legacy like the FactoryFactoryFactoryFactoryFactory stuff people used to write in the early 2000s. Which itself might indicate an entirely different set of problems.
I'd bail out if I were you and try to work at a company with better engineers working for it. Even if this job is stable you will become a better engineer by being around better engineers who aren't going to be proposing giant rewrites.
I might be worth giving it a chance. Being paid to learn new technology is a pretty good deal. If you still find you don't like it, then move.
Problem is that Rails isn't new to me.
If you're having bourbon for breakfast to cope with the current death march, you should have left months ago.
When I am bored with what I do.
Let me explain a bit more. Currently I work in php but I feel that what I do is not a challenge anymore. I've been doing php for 8 years now and I get the same problems over and over. I want to switch to something that challenges me.
When there's not a "project" in sight and I have little control over the direction of my work.
But then I'm a contractor, and I change up to every few months. Or weeks.
But then I'm a contractor, and I change up to every few months. Or weeks.
You have listed the most common reasons in your question (pay hike being the number one reason why people switch jobs and it's a correct reason).
I would add another possible reason. If you get an option to go work to a different country and the company will take care of your visa and offer you attractive relocation package. I think it can often be worth it to gain some international experience. You can always come back in few years.
I would add another possible reason. If you get an option to go work to a different country and the company will take care of your visa and offer you attractive relocation package. I think it can often be worth it to gain some international experience. You can always come back in few years.
What I'd like to know is how to decide when to leave/switch careers.
When either of these is true, I quit my job:
- I can't benefit the company I work for anymore,
- I feel I have stopped learning/advancing in my current position,
- I have stopped feeling satisfaction from my accomplishments.
- I can't benefit the company I work for anymore,
- I feel I have stopped learning/advancing in my current position,
- I have stopped feeling satisfaction from my accomplishments.
It's when I feel like I'm standing still. If I don't see how I can progress or improve myself then I have nothing left to gain there.
Life stability.
Happiness.
In that order. The balance between these two is something I need to maintain in order for me to say whether or not it's time to switch the job.
Happiness is a lot of things. This is a personal compass. For me it's a combination of doing work that's interesting, working with a company whose mission I believe in personally, while having a good life balance. If I say I'm signing out and saying bye at a particular reasonable time on any regular(!) day, and that's respected, that's good enough for me.
Life stability means do I have the means to support myself and those around me reasonably well. This is actually the primary point Sometimes the jobs that make me happy might not pay me all that great, but if I'm at a point in life where maybe other investments are paying off well, or I just don't need to have that much money, I can take the job. On the other hand I can have a job that pays me lots of money but I'm really really not happy with it. But sometimes it's necessary to suck it up until another opportunity comes to me. I can't just flip the bird to life's responsibilities and quit because I'm not happy. Sure maybe I readjust my needs to make stability to look cheaper, but the point is that all basics MUST be covered at all times.
Real world examples:
Second job of mine. The company vision had changed considerably since I joined it. After a merger it became less about innovation and while I don't say it's bad, I definitely didn't agree with it. At the time it was just my wife and I living in a not so expensive apartment and we had very few other responsibilities. So I quit. Admittedly to a slightly better paying job but the priority at that time was happiness since I had achieves baseline life stability (and a bit more too).
Didn't like the new job at all. Burnt me out and after 6 months I left to a new job. This was paying me less than my second job so quite a dip in earnings at the time. But it was exciting, and I loved so much of it. Again I was just about fine with stability since my wife was also working so the primary balancing factor was happiness.
6 months later though, my wife and I were expecting our son. This flipped the equation completely. My wife really was hoping she could exit the workplace so she could spend time with our baby when he was born and this meant a big change in stability requirements for me. I actually went back to the same business I had my third job with. It was a new product they were building so I expected it to be different this time around. That turned out to be wrong. I won't lie. I hated it. But I sucked it up to the point of near depression. Since the balance was starting to fall out of place, I hunted another job and I hope I've found my perfect place at Buffer. Right now it's everything I could ask for and has all my guiding principles in place.
Hope that lengthy exposition of my career helped out :D
Side note - Leaving the company I worked at twice was a hard one and led to a lot of tension. I felt horrible about bits of it, but I couldn't let my personal mental health deteriorate any further. I regret that I had to put the company through that as it almost felt exploitative (that was never my intention though). We parted on lukewarm terms but now have better relationships which mended slowly (not fully) over time.
Happiness.
In that order. The balance between these two is something I need to maintain in order for me to say whether or not it's time to switch the job.
Happiness is a lot of things. This is a personal compass. For me it's a combination of doing work that's interesting, working with a company whose mission I believe in personally, while having a good life balance. If I say I'm signing out and saying bye at a particular reasonable time on any regular(!) day, and that's respected, that's good enough for me.
Life stability means do I have the means to support myself and those around me reasonably well. This is actually the primary point Sometimes the jobs that make me happy might not pay me all that great, but if I'm at a point in life where maybe other investments are paying off well, or I just don't need to have that much money, I can take the job. On the other hand I can have a job that pays me lots of money but I'm really really not happy with it. But sometimes it's necessary to suck it up until another opportunity comes to me. I can't just flip the bird to life's responsibilities and quit because I'm not happy. Sure maybe I readjust my needs to make stability to look cheaper, but the point is that all basics MUST be covered at all times.
Real world examples:
Second job of mine. The company vision had changed considerably since I joined it. After a merger it became less about innovation and while I don't say it's bad, I definitely didn't agree with it. At the time it was just my wife and I living in a not so expensive apartment and we had very few other responsibilities. So I quit. Admittedly to a slightly better paying job but the priority at that time was happiness since I had achieves baseline life stability (and a bit more too).
Didn't like the new job at all. Burnt me out and after 6 months I left to a new job. This was paying me less than my second job so quite a dip in earnings at the time. But it was exciting, and I loved so much of it. Again I was just about fine with stability since my wife was also working so the primary balancing factor was happiness.
6 months later though, my wife and I were expecting our son. This flipped the equation completely. My wife really was hoping she could exit the workplace so she could spend time with our baby when he was born and this meant a big change in stability requirements for me. I actually went back to the same business I had my third job with. It was a new product they were building so I expected it to be different this time around. That turned out to be wrong. I won't lie. I hated it. But I sucked it up to the point of near depression. Since the balance was starting to fall out of place, I hunted another job and I hope I've found my perfect place at Buffer. Right now it's everything I could ask for and has all my guiding principles in place.
Hope that lengthy exposition of my career helped out :D
Side note - Leaving the company I worked at twice was a hard one and led to a lot of tension. I felt horrible about bits of it, but I couldn't let my personal mental health deteriorate any further. I regret that I had to put the company through that as it almost felt exploitative (that was never my intention though). We parted on lukewarm terms but now have better relationships which mended slowly (not fully) over time.
Buffer seems really nice! I like how transparent they are with salaries and that it's fully remote. What technologies are you guys using?
It's a wonderful place really. The people are also really nice and my only wish is that we could meet each other more in real life :D.
As for tech that we are using,
The main app uses php. But lately we've been breaking apart the app into micro services which are a combination of node js, golang, and Python/flask apps. We run it all on kubernetes. Meanwhile the front end has been transitioning towards being more react based :)
As for tech that we are using,
The main app uses php. But lately we've been breaking apart the app into micro services which are a combination of node js, golang, and Python/flask apps. We run it all on kubernetes. Meanwhile the front end has been transitioning towards being more react based :)
Nice. I need to find a job like that. I moved out to a new province and accepted the first job I got offered and I didn't like it.
Then I got offered and accepted a new job which seemed nice but it's just so boring.
I need to be more picky seeing how companies like Buffer exist. I always just take the first offer I get because I don't like interviews and I've been lucky enough to get a job offer after the first interview I do when looking, but it's pretty stupid in retrospect. It's a gamble that has long lasting effects.
Then I got offered and accepted a new job which seemed nice but it's just so boring.
I need to be more picky seeing how companies like Buffer exist. I always just take the first offer I get because I don't like interviews and I've been lucky enough to get a job offer after the first interview I do when looking, but it's pretty stupid in retrospect. It's a gamble that has long lasting effects.
If we collect all the reasons in this thread together it rules out a significant majority of companies. Just saying.
TL;DR:
The first few job changes I've made were, in large part, due to two things:
1. me trying to find a job in NYC that would allow for a seamless transition to TX while preserving my compensation and job responsibilities, and
2. Finding a job that will accelerate my transition into a senior management or technical sales role.
It took me a few years to find a job that met goal (1) (I'm actually making more now than I did in NYC by a healthy margin), and I have a strong feeling that my current job will really put the gas on goal (2).
Longer:
There were also minor reasons behind me switching roles:
* Job 1 -> Job 2: Lots of micromanaging and process that made it difficult to do real engineering. Job 2 was much more fun and provided free food and a wear-what-you-want policy. Also, $20k pay increase, which was a deciding factor.
* Job 2 -> Job 3: Potential of moving to Houston at Job 3. Job 2 was amazing but I felt like there was no way of growing my career vertically unless I wanted to become a Linux admin (which I, ironically, became anyway, at least of sorts) or quant (a very high bar to hit, at least at the time). $5k pay increase was not a factor.
* Job 3 -> Job 4: No opportunities in Houston outside of tech support with Job 3. Also, Google was Job 4; no way I was turning that down. They also had an office in Austin. $30k salary cut front loaded by a sign-on bonus and RSUs; opportunity to work at Google outweighed this.
* Job 4 -> Job 5: No relo opportunities available on the short-term (and very unlikely long term). The $35,000 pay cut also hurt over time despite sign-on and peer bonuses. I didn't stay long enough to vest my RSUs, which would have made up for most of the loss. Also didn't feel like I fit with the team well. Very different working/communication style that wasn't for me (it felt very isolated). I kind-of like being in a party atmosphere; open space, lots of noise, events all of the time, etc. My team didn't have any of that; very nice, but quiet, bunch of folks. Also didn't like how far I was from the money and how arguably meaningless the work felt, despite the work being really good engineering overall. (Google makes its money on Ads. I was in Corp Eng maintaining non-prod app servers.) I also ALSO didn't like how you effectively HAD to move to Mountain View or stay in NYC to advance (most of the senior folks are in MTV) and how it took many many years to make it into management at a salary that's slightly below market (even though RSU reloads effectively offset that). Also, Job 5 restored most of my lost salary ($30k pay increase, was a deciding factor).
* Job 5 -> Job 6: LOVED that place, but it was time to move to TX (couldn't take NYC anymore) and Job 5 wouldn't allow it despite having a sales office in Austin. (My boss and I tried to make an extended eng team there; CTO wasn't having it. She was nice, though.) ($10k pay cut but slightly over $10k gained from not having to pay income or state/city taxes. It was a minor factor. I would've seen more of that had I not fucked up my withholding that year!)
* Job 6 -> Job 7 (current): Really enjoyed working there too. Learned that I LOVE LOVE LOVE to travel. Wanted more of a sales-like position. Tried really hard to get myself plugged into sales pursuits; I networked with damn nearly every sales person in the US org and offered to effectively be their PowerPoint person lol. Did a lot of blogging and solo pursuits alongside my engineering work. Was VERY vocal about work that me and my teams have accomplished. Getting to where I wanted wasn't happening quickly enough; also, company outlook was shaky. Also turns out that I was dramatically underpaid (despite it being a lateral salary move). $25k pay increase was a factor.
The first few job changes I've made were, in large part, due to two things:
1. me trying to find a job in NYC that would allow for a seamless transition to TX while preserving my compensation and job responsibilities, and
2. Finding a job that will accelerate my transition into a senior management or technical sales role.
It took me a few years to find a job that met goal (1) (I'm actually making more now than I did in NYC by a healthy margin), and I have a strong feeling that my current job will really put the gas on goal (2).
Longer:
There were also minor reasons behind me switching roles:
* Job 1 -> Job 2: Lots of micromanaging and process that made it difficult to do real engineering. Job 2 was much more fun and provided free food and a wear-what-you-want policy. Also, $20k pay increase, which was a deciding factor.
* Job 2 -> Job 3: Potential of moving to Houston at Job 3. Job 2 was amazing but I felt like there was no way of growing my career vertically unless I wanted to become a Linux admin (which I, ironically, became anyway, at least of sorts) or quant (a very high bar to hit, at least at the time). $5k pay increase was not a factor.
* Job 3 -> Job 4: No opportunities in Houston outside of tech support with Job 3. Also, Google was Job 4; no way I was turning that down. They also had an office in Austin. $30k salary cut front loaded by a sign-on bonus and RSUs; opportunity to work at Google outweighed this.
* Job 4 -> Job 5: No relo opportunities available on the short-term (and very unlikely long term). The $35,000 pay cut also hurt over time despite sign-on and peer bonuses. I didn't stay long enough to vest my RSUs, which would have made up for most of the loss. Also didn't feel like I fit with the team well. Very different working/communication style that wasn't for me (it felt very isolated). I kind-of like being in a party atmosphere; open space, lots of noise, events all of the time, etc. My team didn't have any of that; very nice, but quiet, bunch of folks. Also didn't like how far I was from the money and how arguably meaningless the work felt, despite the work being really good engineering overall. (Google makes its money on Ads. I was in Corp Eng maintaining non-prod app servers.) I also ALSO didn't like how you effectively HAD to move to Mountain View or stay in NYC to advance (most of the senior folks are in MTV) and how it took many many years to make it into management at a salary that's slightly below market (even though RSU reloads effectively offset that). Also, Job 5 restored most of my lost salary ($30k pay increase, was a deciding factor).
* Job 5 -> Job 6: LOVED that place, but it was time to move to TX (couldn't take NYC anymore) and Job 5 wouldn't allow it despite having a sales office in Austin. (My boss and I tried to make an extended eng team there; CTO wasn't having it. She was nice, though.) ($10k pay cut but slightly over $10k gained from not having to pay income or state/city taxes. It was a minor factor. I would've seen more of that had I not fucked up my withholding that year!)
* Job 6 -> Job 7 (current): Really enjoyed working there too. Learned that I LOVE LOVE LOVE to travel. Wanted more of a sales-like position. Tried really hard to get myself plugged into sales pursuits; I networked with damn nearly every sales person in the US org and offered to effectively be their PowerPoint person lol. Did a lot of blogging and solo pursuits alongside my engineering work. Was VERY vocal about work that me and my teams have accomplished. Getting to where I wanted wasn't happening quickly enough; also, company outlook was shaky. Also turns out that I was dramatically underpaid (despite it being a lateral salary move). $25k pay increase was a factor.
When office politics become more important then the product and the customer.
If somebody comes in, lifts his leg to mark territory, you know the territory has just become worthless and its time to move on.
If somebody comes in, lifts his leg to mark territory, you know the territory has just become worthless and its time to move on.
It's very hard to avoid in anything but the smallest companies.
Its the signal of a dying creature. Once office politics are waged and won, hierarchy's are established- suddenly, communicating ideas openly for people only interested in the product and the customer - and by doing that jumping over hierarchy's is a criminal offense - the last terminal stage is reached.
The duration of the process may vary- the outcome does not.
The duration of the process may vary- the outcome does not.
> suddenly, communicating ideas openly for people only interested in the product and the customer - and by doing that jumping over hierarchy's is a criminal offense - the last terminal stage is reached.
This is not a bad thing. The key is some hierarchy is good. For example, often in small organizations the product is at the mercy of the loudest sales person, demanding the feature to make their sale. SalesPersonX needs FeatureY to close a $50,000 deal, when CustomerA, CustomerB, and CustomerC have all requested ImprovementD, maybe they'll renew without it, maybe not.
Someone needs to make this call: prioritize ImprovementD or FeatureY. Maybe they can both get done this year, maybe not. It's a business decision, either keep current customer happy or drive for sales. Usually SalesPersonX knows RockstarZ's number and calls him directly. RockstarZ get's burned out from the constant pressure and quits.
So, someone needs to be gathering feedback from customers and prospects, build a roadmap, then project management can concentrate on delivering features. Some hierarchy is required for long term growth and stability. If you're sales people are burning out your Devs, you've got a problem. And you're goddamned right I'm going be harsh on the sales guy who's calling my devs directly.
This is not a bad thing. The key is some hierarchy is good. For example, often in small organizations the product is at the mercy of the loudest sales person, demanding the feature to make their sale. SalesPersonX needs FeatureY to close a $50,000 deal, when CustomerA, CustomerB, and CustomerC have all requested ImprovementD, maybe they'll renew without it, maybe not.
Someone needs to make this call: prioritize ImprovementD or FeatureY. Maybe they can both get done this year, maybe not. It's a business decision, either keep current customer happy or drive for sales. Usually SalesPersonX knows RockstarZ's number and calls him directly. RockstarZ get's burned out from the constant pressure and quits.
So, someone needs to be gathering feedback from customers and prospects, build a roadmap, then project management can concentrate on delivering features. Some hierarchy is required for long term growth and stability. If you're sales people are burning out your Devs, you've got a problem. And you're goddamned right I'm going be harsh on the sales guy who's calling my devs directly.
The vast majority of corporate america is a dying creature then.
The problem is that the vast majority of the upstarts who will eat them will also die, -and- even the winners may not usurp anything for 20+ years. At which point they, too, will likely start 'dying'.
I think you exaggerate the diagnosis. As with a patient with a disease, you have to modify treatment. The reality is that learning to deal with office politics is an important skill to have.
It's really easy to say "politics" with a look of scorn on your face...and then turn around and read about 'influencers' and 'how to win friends and influence people' and '7 habits of highly effective people' and etc, and think "oh, hey, figuring out how to learn what people are thinking and appeal to people's needs is super important". They're the same thing.
'Jumping over hierarchy is a criminal offense' - sometimes yes, sometimes no. The point you miss is that with enough people, hierarchy can be necessary. If you've ever been in a position where you have to make strategic decisions, you -have- to delegate. In fact, many of the things that make me feel good as a developer, such as being empowered to make decisions (beyond just the code, but in terms of features and things), require someone else to trust me to make those decisions (i.e., delegation).
"Well, our whole team makes the decisions"; fine, are there other teams working on other things? Do you all make your own decisions? Because if so, you have delegated responsibilities to those other teams, just as they have with you. If not, then people who are less informed than you are getting a voice, and that's just unnecessary noise.
As soon as delegation occurs, I don't -want- people crossing over unless it's incredibly important. Same situation, of multiple teams; do you want someone on another team coming to you to complain about issues on their team? Of course not; that's for their team to fix. Unless the issue is something so bad it threatens you and your team, you don't want to hear about it.
In a hierarchy, the same thing happens. I delegate to someone and entrust them with seeing it to its success; I do not WANT someone re-burdening me with that problem, -unless- it's vital I be informed, and that person knows I am not being informed.
Yes, this can break. People can start valuing the hierarchy more than what it's attempting to achieve, I grant you. But as often as not what I've seen are people jumping up the hierarchy to complain about things that are not sufficiently urgent. And part of that is perspective; what is going to bother someone higher in the hierarchy is not necessarily what bothers someone lower down. And yes, understanding that, and knowing what to do about it, is "politics", but also, alternatively, it's "empathy and influence".
Or, put another way, what's the difference between 'manipulating' and 'influencing'? That's the difference between 'politics' and 'organizational intellect'. It's trying to achieve one's goals dealing with a single person, vs trying to achieve one's goals while dealing with multiple. Because when dealing with multiple people, there are always politics, and you can't merely throw up your hands and decide to never deal with it. I wish you could, I'm not always good enough to win the battles I need to win...but I recognize that it's not something I can just avoid.
The problem is that the vast majority of the upstarts who will eat them will also die, -and- even the winners may not usurp anything for 20+ years. At which point they, too, will likely start 'dying'.
I think you exaggerate the diagnosis. As with a patient with a disease, you have to modify treatment. The reality is that learning to deal with office politics is an important skill to have.
It's really easy to say "politics" with a look of scorn on your face...and then turn around and read about 'influencers' and 'how to win friends and influence people' and '7 habits of highly effective people' and etc, and think "oh, hey, figuring out how to learn what people are thinking and appeal to people's needs is super important". They're the same thing.
'Jumping over hierarchy is a criminal offense' - sometimes yes, sometimes no. The point you miss is that with enough people, hierarchy can be necessary. If you've ever been in a position where you have to make strategic decisions, you -have- to delegate. In fact, many of the things that make me feel good as a developer, such as being empowered to make decisions (beyond just the code, but in terms of features and things), require someone else to trust me to make those decisions (i.e., delegation).
"Well, our whole team makes the decisions"; fine, are there other teams working on other things? Do you all make your own decisions? Because if so, you have delegated responsibilities to those other teams, just as they have with you. If not, then people who are less informed than you are getting a voice, and that's just unnecessary noise.
As soon as delegation occurs, I don't -want- people crossing over unless it's incredibly important. Same situation, of multiple teams; do you want someone on another team coming to you to complain about issues on their team? Of course not; that's for their team to fix. Unless the issue is something so bad it threatens you and your team, you don't want to hear about it.
In a hierarchy, the same thing happens. I delegate to someone and entrust them with seeing it to its success; I do not WANT someone re-burdening me with that problem, -unless- it's vital I be informed, and that person knows I am not being informed.
Yes, this can break. People can start valuing the hierarchy more than what it's attempting to achieve, I grant you. But as often as not what I've seen are people jumping up the hierarchy to complain about things that are not sufficiently urgent. And part of that is perspective; what is going to bother someone higher in the hierarchy is not necessarily what bothers someone lower down. And yes, understanding that, and knowing what to do about it, is "politics", but also, alternatively, it's "empathy and influence".
Or, put another way, what's the difference between 'manipulating' and 'influencing'? That's the difference between 'politics' and 'organizational intellect'. It's trying to achieve one's goals dealing with a single person, vs trying to achieve one's goals while dealing with multiple. Because when dealing with multiple people, there are always politics, and you can't merely throw up your hands and decide to never deal with it. I wish you could, I'm not always good enough to win the battles I need to win...but I recognize that it's not something I can just avoid.
Im sure if you are higher up in this Ponzi Scheme you have all the time for a sophisticated justification.
But where i am, we need our attention on problem solving, attention on important (often cross-department) details - we do not have the time and resources for procedure-obsessed bureaucrats, leeching initiative and resources into there little Japanese gardens of power, while the project as a whole suffers- and all that ever returns from your proposed silod departments is excuses, blame-shifting and informal orders to not reveal information to other departments working on the same project.
I understand that this is human nature and it must run its course, because those who could actually fight it - are actually fighting for it. Still, if you are in a company to innovate and push the boundaries of tech (which usually needs short com-paths, teamwork and the ability to bounce ideas informal), this is the end of your path in this company.
Oh, and before you try to wriggle out by pointing at the "innovation" initiatives started by CEOs noticing the absence of exactly this- which becomes just another shiny hot powerpoint potato being pin balled from department to department. No, that is not it.
Finally something positive- sometimes.. power aggregates, and some control freak snatches too much of it, merging departments, and this one guy, running hierarchical amok, breaks the spell for a time. He basically destroys the attempts of the hierarchy to sabotage communication, by directly sampling data and pushing worthwhile endeavors against the resistance of the apparatus.
You should hear middle-management hiss at the employees, after the manager-type (lets call him the boar), just casually talks to the people involved and gets Information and Ideas, that where "NOT-SUPPOSED-TO-BE-COMMUNICATED", enabling work to be done and problems to be solved. Subversion saves the day and nobody admits it.
So here is, though i detest the personality type when in personal contact, a toast to the likes of Steve - who at least get things done after the calcification sets in.
But where i am, we need our attention on problem solving, attention on important (often cross-department) details - we do not have the time and resources for procedure-obsessed bureaucrats, leeching initiative and resources into there little Japanese gardens of power, while the project as a whole suffers- and all that ever returns from your proposed silod departments is excuses, blame-shifting and informal orders to not reveal information to other departments working on the same project.
I understand that this is human nature and it must run its course, because those who could actually fight it - are actually fighting for it. Still, if you are in a company to innovate and push the boundaries of tech (which usually needs short com-paths, teamwork and the ability to bounce ideas informal), this is the end of your path in this company.
Oh, and before you try to wriggle out by pointing at the "innovation" initiatives started by CEOs noticing the absence of exactly this- which becomes just another shiny hot powerpoint potato being pin balled from department to department. No, that is not it.
Finally something positive- sometimes.. power aggregates, and some control freak snatches too much of it, merging departments, and this one guy, running hierarchical amok, breaks the spell for a time. He basically destroys the attempts of the hierarchy to sabotage communication, by directly sampling data and pushing worthwhile endeavors against the resistance of the apparatus.
You should hear middle-management hiss at the employees, after the manager-type (lets call him the boar), just casually talks to the people involved and gets Information and Ideas, that where "NOT-SUPPOSED-TO-BE-COMMUNICATED", enabling work to be done and problems to be solved. Subversion saves the day and nobody admits it.
So here is, though i detest the personality type when in personal contact, a toast to the likes of Steve - who at least get things done after the calcification sets in.
I have 5 years as a dev, and two as a lead dev/architect. I am only recently taking on management tasks. My comment is not biased because I am "higher up in this ponzi scheme", it is predicated on -what I have seen-.
You are living in the happy little world I got to live in before my current job (when I was simply a senior dev), where there was enough protection of the dev team that I didn't need to concern myself about the business (beyond the occasional clarification of a story), didn't need to concern myself with departmental and organizational 'politics', and when I saw it I rolled my eyes at it, hated it, decided I'd never deal with that sort of thing, etc.
But even at the dev team level there were 'politics'; technical decisions would oftentimes be made based on who had the most clout. Now, that clout was usually due to, de facto, speaking to what the rest of the team cared about, understood, etc (i.e., technical language and priorities). But once you go inter-disciplinary, that stops being true.
Fundamentally, most people want to succeed, and they recognize that the way to do that is delivering results. Sometimes there are leeches, who learn to abuse the system and take credit while not helping deliver. It's abuses like this that deserve our condemnation. But the fact is that in an organization there are multiple roles, with differing priorities, and differing definitions of 'success', and fundamentally the way you deal with that -requires- a level of empathy and influence. You can decry it all you like, but that's reality, and something you'd benefit from adapting to rather than objecting to. I'd love it if everyone was technical, even those whose roles are solely focused on business direction and strategy. I'd love it if everyone thought like me, prioritized like me, and was completely objective in making decisions. But that's simply not the world we live in, and, I suspect, that would actually lead to a worse outcome (I'm not good at sales, for instance, and I don't have the insight into how best to sell something, even if it's technically superior and the UX is better than any competitors). You don't have to like it (and again, I -don't- like it), but that's the truth.
Please note, I'm not saying that every org is healthy. But I -am- saying that regardless of the health, understanding what people's motivations are, and how best to disseminate, discuss, debate, and prioritize information given the context you're in will help you tremendously.
You are living in the happy little world I got to live in before my current job (when I was simply a senior dev), where there was enough protection of the dev team that I didn't need to concern myself about the business (beyond the occasional clarification of a story), didn't need to concern myself with departmental and organizational 'politics', and when I saw it I rolled my eyes at it, hated it, decided I'd never deal with that sort of thing, etc.
But even at the dev team level there were 'politics'; technical decisions would oftentimes be made based on who had the most clout. Now, that clout was usually due to, de facto, speaking to what the rest of the team cared about, understood, etc (i.e., technical language and priorities). But once you go inter-disciplinary, that stops being true.
Fundamentally, most people want to succeed, and they recognize that the way to do that is delivering results. Sometimes there are leeches, who learn to abuse the system and take credit while not helping deliver. It's abuses like this that deserve our condemnation. But the fact is that in an organization there are multiple roles, with differing priorities, and differing definitions of 'success', and fundamentally the way you deal with that -requires- a level of empathy and influence. You can decry it all you like, but that's reality, and something you'd benefit from adapting to rather than objecting to. I'd love it if everyone was technical, even those whose roles are solely focused on business direction and strategy. I'd love it if everyone thought like me, prioritized like me, and was completely objective in making decisions. But that's simply not the world we live in, and, I suspect, that would actually lead to a worse outcome (I'm not good at sales, for instance, and I don't have the insight into how best to sell something, even if it's technically superior and the UX is better than any competitors). You don't have to like it (and again, I -don't- like it), but that's the truth.
Please note, I'm not saying that every org is healthy. But I -am- saying that regardless of the health, understanding what people's motivations are, and how best to disseminate, discuss, debate, and prioritize information given the context you're in will help you tremendously.
[deleted]