OUT OF YOUR COMFORT ZONE
Why you should probably leave your current project
Does everybody know you and come to you for every kind of problem? Maybe you’ve become part of the problem and missing out big for yourself.
It’s easy to stay in the same company and project for years. Time flies and you know everybody, you know all the products, and the code you wrote can be found at all the places. Life feels great, as you’ve also accumulated a reputation, a lot of experience, and you don’t have to prove yourself anymore.
Even though it’s not obvious, not everything about this is shiny and good. There can be many downsides: for your employer, your customers, your colleagues, and yourself.
This is an article about my personal journey, the learnings, obstacles on the way, mental attitudes, and the understanding of when it’s time to let go and tackle something new.
My Story
I graduated at the end of 2016 from college in Germany and took my first real full-time software engineering job at a consulting company just a few months later. Since that day, I’m solely working on the same project.
In the beginning, our team was already large with mostly six dedicated developers and we were working on a monolith java backend. Infrastructure was maintained by an in-house team we had almost no contact with.
Looking back at the time, everything changed. The team grow even more but was split because it wasn’t manageable anymore in an agile way, we moved all of our services to AWS, created new services from scratch, and extended our responsibilities in the portfolio in a big way.
Today, we’re just five developers, maintaining and extending many applications, including their infrastructure and operations. So to summarize: there’s more responsibility and tasks than ever with a smaller team.
I’ve learned more than I could ever imagine and quickly went from developing small features to designing and taking responsibility for new architectures and being involved in almost every decision. I got to know many people — developers, product owners, architects, and business analysts — and learned even more from them while simultaneously becoming a respected member of the community.
I just recently started to realize what I personally missed out on and what my effect on others or the project really was.
Understanding that it’s not only about you
I was solely focused on finished tasks, writing code, making decisions, and learning everything I could. Working over-hours was a standard and not an exception and mostly I started before 6 AM so I could have a few hours of uninterrupted work before everybody else started, giving me some personal advantage. Even if starting early, I was mostly working past 6 PM.
This is neither healthy for you nor your team.
Your value for your team is not defined by how many tasks can only be done by you or how much knowledge you acquired in comparison to your colleagues.
It’s about your openness, willingness to help others grow, and the ability to adapt to all challenges ahead.
At least for me, this took quite a while to understand, and not leaving my project at some time so I had to start over, not being a leader, did not help with that. I worked on being able to do anything — even completely on my own — with the goal that I’m the most important resource in the project.
Funnily enough, that’s the best way to jeopardize a project and not bring exponential growth to you and your team. If you start to distribute your knowledge and help others to follow your path, everything changes.
Recognizing the signs
It’s easy to see everything through rose-colored glasses and you need a lot of self-awareness and willingness to change. The longer you are at your current position, the more important it gets.
You’re the omniscient oracle
This one is quite obvious. There’s too much load on you, too much bundled knowledge, or your team fears every holiday you take.
Don’t be charmed by that like I was in the past.
Losing the objective, junior glasses, and being defensive instead of challenging
As a junior, you don’t bring a lot of experience. It’s easier for you to see things objectively because there’s no past baggage you’re carrying with you, clouding your view.
I’ve lost this on my path occasionally, being too confident through my prior experiences and having a “this is the correct solution”-attitude.
Always try to embrace others’ opinions and views, really understanding what’s going on in their heads instead of already forging counterarguments while you’re listening. Maybe their solution is way superior.
Encourage your colleagues to speak out on topics they don’t know much about and always highlight that making mistakes is a fundamental part of growing.
Getting emotionally attached to your code
Building a software product and writing code is like doing art. You’re often free on how you achieve certain goals and implement features and there’s a personal note on everything. It’s like your handwriting. It’s unique.
That’s why it’s easy to get personally attached and feeling emotionally attacked if somebody refactors or throws away your hard work. If you solely wrote a component, it’s not “your component”. Somebody refactoring does not mean he’s not recognizing your work.
Everything is a team effort. Let go of pride and ego.
Aggressive leadership, over-engagement, and toxicity
As you mature in your role you’ll automatically gain more responsibility. The longer you’re working on your current project, the more knowledge you’ll acquire and the more history you’ll be aware of.
Every over-hour you do is not only something you do for the team, but it can also put a burden on your colleagues because you’re raising the bar. It can be frustrating — even if you’re highly motivated — competing against somebody just outdoing everything by putting in double the time you’re able to do.
As your authority grows automatically with the years, it’s easy to lose track of how much you're steering the ship and taking decisions without involving others' opinions anymore. Have a clear look at giving others room for challenging your views.
“But what’s in it for me?”
Probably you’re doing really fine right now and you’re in your comfort zone — life is pretty good and why should you leave into some uncertainty? There’s a lot of reasoning for this.
Adapting and strengthening your attitude
If there’s one primarily needed skill in our industry, then it will be adaptability. Everything changes constantly, at a fast pace and there’s nothing that will change this. Every day there is a new framework, technology, service, product, or programming language that you may only just heard of but will probably become a new standard in the future. Alone in the year 2020, AWS launched nearly a dozen of new services.
Switching a project will force you to adapt to a new environment, learn new things, get into code from other people, and ultimately enhance your adaptability to new environments.
If you’re new to a project, your previous reputation is not worth much. You have to prove yourself again.
Money
Aside from successfully working and engaging at a FAANG company, the largest salary jumps are done by switching projects or employers. Getting a 10% raise where you’re currently working, is probably just a dream, but fairly easy when switching because you’ve got some power over the anchoring effect.
Extending your network and reputation
Even if there’s a good rotation in your current project, switching to a completely new employer or project will introduce you to a large number of new people. Everyone knows something you don’t, so you can learn and grow faster. Personally, I’m sure that your network is your most important asset in your career.
Gaining new insights into a different area
Most companies are focused on a niche and therefore you’ll generally just be involved in the same business cases. If you’re only working on a dedicated project, this is even more true.
Diving into new technologies to broaden your skills
Software products that are going into production often lasting there for years or even decades. The longer you’re working in the same spot, the more you’re gaining operational responsibilities, and the more you’re bound to work on the same technologies and frameworks. This has the major advantage of becoming an expert in those but at the same time hinders you to grow horizontally.
Quoting Curtis Einsmann — one of my software engineering role models who worked at AWS for several years — on this topic:
I prefer to focus on the tech used on my current project. Learn those well.
This depth helps me cultivate mental models. I leverage these as projects shuffle — which is often. Breadth comes over time.
Regularly forcing yourself to start at new projects will unavoidably grow and widen your skills.
Last but not least: fun and excitement
Not everything is about self-improvement, making the most money, or being the most efficient human being. Work should also be about fun and being excited day in and day out. It’s difficult to keep your excitement high if you stick to the same projects for years or even decades.
Leaving your nest and stepping into another door can help you grow new enthusiasm. Nothing’s more exciting than jumping into some calculated uncertainty with new people around.
Key Takeaways
Take reflections regularly on your current working situation and think outside the box. Probably taking a change is worth the risks because it could bring you a lot of benefits and joy. It’s easy to stay where you are, but that’s also a dangerous way of missing out on true potential.
Regrets about life are mostly about things you didn’t do or try, not about the things you did.
So just go out and do it.
Thank you for reading.
