Skip to main content

Should you leave your current company?

I recently left my company and it definitely made me think about when is it time to move on.  Here are some of my thoughts:


  • Make sure your personal life is ready for it.  Don't just see dollar signs or a new shiny object.  Look at how it will impact you, your family, friends, your social circles and your everyday life.  You would be surprised how much you depend on your coworkers as friends and way of getting through the grind when it is going tough.
  • I recommend leaving if you are going through several months of being unsatisfied.  If you are not growing as much as you are giving to the company, it might be time to move on.  You should be a leader and that means innovating and growing people and processes.  If you are at a point where the company can't grow like your passion pushes you, then there is nothing you can do.  This is especially important around DevOps.  
  • Don't leave just for money.  Unless someone is going to double your salary, leave for what makes you get up in the morning.  I believe the statement, your career should be what you would do if you had no job.  If you love research, reading and studying DevOps, but your company is not heading that way, find somewhere that is doing it so you can live it.  If you go somewhere else that gives you a big raise but they are just like your current company or worse, you will be unhappy.  (BTW, I would dig ditches if someone doubled my salary.  That is a life changer.)
  •  Pay attention to the little things.  The commute, the vacation schedules, culture, dress code, office space, benefits, work life balance, and make sure it is at least as good as what you had.
    • I will blog more on commute soon.
  • If you are in a management position, make sure your team is prepared for you to go.  If you are a good leader, they should freak out, be sad, even mad but it was your job to prepare them for that day.
  • If your job is impacting your family, you should consider leaving.  The obvious situation is if you have to work too much to be with your family but the less obvious is when your job is not satisfying and it impacts your everyday mood with your spouse or family.  When you have a career you want to be exited about it, especially to your spouse and children.  If you are not happy or always negative about it, your kids could grow up seeing how bad a career is and impact them down the road.
  • You should leave because you want to grow as a person.  Yes, you work for the company but the company grows you, your knowledge, your experience and your life.  I read once if you are not evolving, you are dying.  This really hit me hard.  Every day you die a little because something you used to know or do, no longer applies.  If you don't fill that with something new, you start becoming irrelevant.  If you love IT or DevOps, you should consider moving on if you are not able to or are not being pushed to grow.
  • If the company culture changes, and you don't like where it is going.  Companies get bought or change leadership through out a career. If you don't like the way it is heading or changed from the reason you started working at the company, it is probably better to start looking to see if there is something that might fit you better.

A quick note on when you should not leave:
  • Your family life and flexibility matches your family needs.  Don't sacrifice your family for a new job, unless you and your spouse is ready for it.  
  • You can create change and leadership will let you.  Don't leave a company if you can be a change agent.  You will feel a great satisfaction changing a team, organization or company from old ways to better ways.
As you can see there are more reasons to leave than there are to stay but there is huge risk in changing for the wrong reasons.  I know a guy that left our company and came back 3 days later.  If you are going leave, make sure you know everything you can about the new company.  When you do decide to leave, make sure you covered everything.  Pray about it, talk to people about it, and research but commit to with all your heart.



Comments

Popular posts from this blog

2020 State of DevSecOps by Accurics

 This is an excellent report for all IT Pros and Engineers.   Highlights: Storage is most impacted solution Open security groups or network configuration Secrets are not so secret Unused resources are not secure. Take a look at these.  Look again.  These are not highly skilled problems.  They just need guidelines and proactive management.  The article uses policy as code as a solution for many of the problems.  I will drill into each of these more in the future.  I wanted to get the awareness out first and then, come back to solutions.  

Manage IT by Johanna Rothman

I just completed this book. I think it is a really good book which covers a whole lot of software development. This book could possibly be the best book for first time project managers. I believe many of the PMs understand PMM but do not understand software development. This book gives a view of each project role. The only one that it does not cover is Business Analyst or requirements documentation. It does cover QC, development and of course PMs. It gives a PM a view into development processes like TDD, CI and estimation. Many PMs that are new to SD can read this book and get a great start to manager an SD project. If you are a PM or know some, read this book. http://www.jrothman.com/

Matrix Organizations are bad for Software Dev

Development teams need to be teams first and company people second. What happens when your team wants to start using user stories and index cards, but your analyst team manager thinks Use Cases are the best way to document requirements? How about when your QA process is not mature and you keep releasing with defects but the QA manager does not do anything about it? How about your project manager never buys into the team and only cares about being on time and on budget because their review is based on it. Maybe the tech lead wants requirements that never change and never lets the client change their mind. The technical manager taught your tech lead and agrees with everything the tech lead says. Agile or what I like to call "Successful Teams" are teams. They do what it takes to do what the customer wants, deliver features. I am not saying only agile teams are successful but successful teams are agile. If your organization is matrix, get your leadership buy in to override...