I am no stranger to changing careers. I started 16 years ago as a litigating lawyer, then moved to corporate law, and after 11 years of practice, left the law and went into middle management. Then I started my own startup. As my startup struggled to attain sustainability, I discovered a love for coding (largely out of necessity, in startup-land!). I set crazy learning goals, and switched my attention from my startup to code (mainly to become my own technical co-founder). And then I figured that since I love to code, and I love technology, I might as well become a dev.
Looking back I see how I've grown exponentially with each career change. But here's the unexpected professional advantage : each new 'job' benefited enormously from my previous experience, even though most people (especially non-career changers) thought it was a bad idea. As it turns out all the people who had strong views about it had never done it themselves.
Career changers have some very significant advantages that are often overlooked, and almost always underplayed
Right after I decided to try and land a dev job late last year, I also decided to document the strategies and plans that actually worked for me when I taught myself to code - by publishing a course on Udemy targeted at people (especially those that long to get into a tech role) who want to teach themselves this vital skill of the new world. As part of that process, and based on feedback from a number of colleagues and recruiters for dev roles, I realised that us career changers have some very significant advantages that are often overlooked, and almost always underplayed.
This is part 1 of 2. In this part I will cover the big advantages of having one or more previous careers offers when you switch to a career in dev. In part 2 I cover strategies that make you more compelling if you're worried about how your previous career will look when you interview for dev roles.
Experience
OK, so this is a no-brainer. But a shallow analysis of this will only mean that you don't actually leverage this asset properly. Why is experience in an unrelated, or semi-related field of any use? Most people would tell you that you need direct and "relevant" experience. And that is definitely the case when it comes to satisfying the specifics of the Job Description. But anyone that has actually reflected on their role will acknowledge that the real experience of the job is often quite different from the sanitized words in a JD. The difference is the same difference as a colouring in book before you colour it in and after. So here are the main reasons why experience really does matter, even if it is an unrelated field (potentially even more so then as it gives you depth and breadth of life experience).
1) Maturity. Dealing with teams teaches you soft skills, hard skills, and subconscious skills at dealing with personalities, temperaments, cultures, habits and mindsets.
2) Insight. other roles gives you insight into other functions in an organisation. For example, if you're implementing a billing system you will have a better awareness of critical aspects of the user's experience if you understand how a sales person uses billing data to manage the sales pipelines and increase customer acquisition or reduce churn. If you were previously in sales or marketing or had your own startup, you would really have valuable skills when it comes to designing the system and selecting SaaS products.
3) Context. Have worked in another team, in another role, in another organisation also helps you contextualise the drivers, habits, behaviours and motivations that influence how teams interact. Product, engineering, marketing, finance, they all have drivers and unique pressures and motives. Truly understanding the context of your co-workers and collaborators outside your narrow function makes you hugely valuable because it helps you cooperate better, which in turn encourages others to cooperate with you. No matter how skilled a dev you are, if you annoy the heck out of the folks who are driving revenue, you will struggle to be taken seriously, and that will impact the quality of your work life.
4) Cultural adaptiveness. The ability to understand context, have insight, and deal with coworkers maturely adds up to an overall skills that I call your cultural adaptability. This just isn't about different ethnic, regional or anthropological cultures. This is about team-cultures too, the unique dynamics that an organisation's culture produces in its teams. Being adaptive in this way makes you highly effective, and effective team players are more valuable as employees than talented but ineffective members. Being great at your role is much, much more than pure technical skill or intellectual horse power.
5) Communication. While a lot is written about improving communication in the engineering culture, the fact is that relatively poor communicators can still be highly effective if they have a broadened vocabulary in the context of their business. You may not have to know or care what Net Present Value or EBITDA is. But understanding these things will make you a better inter-team communicator. In exactly the same way that it helps if your finance person understands what a firewall, or API call is. Knowing some of the technical language spoken by other team members is flattering to them, useful to you, and beneficial for the organisation. And since these may be very boring to you (or not), the best way to pick up the vernacular is to have been in or close to those functions in a previous life, so you know not just what they mean but why they're important to your colleague.
6) Prioritization. Effective team members prioritise in a way that benefits the team and also the larger organisation. If you have previous experience in other domains, you will understand how something that is a low priority to you has an outsized impact on another function, and vice versa. This sensitivity to the co-worker's perspective and professional pressures is a huge asset when it comes to building rapport, trust, camaraderies, and very important - organisational influence.
7) Organisational Dynamics. This is the name for its healthy form. It's unhealthy twin is known as sh!tty politics. But it's a fact of life. You do not and should not have to participate. But it really helps to be able to detect it, foresee it, recognise it, sidestep it, and handle it. On rainy days it always helps to see a car speeding towards that puddle next to you, so you can avoid being splashed, right? In all its forms, the ability to navigate and deal constructively with Organisational Dynamics is a tremendous skill as it reduces stress, improves productivity, builds trust and credibility and delivers successful outcomes for the teams involved. If you've been only in one career or domain all your life you will become adept at recognising its forms in your specific function and in your context. But recognising it when it happens elsewhere but is coming soon to a colleague near you, is a huge strategic advantage as you can anticipate and prepare for it appropriately.
Thanks for reading!
If you would like to learn more about my journey into code, check out episode 53 of the freeCodeCamp podcast, where Quincy (founder of freeCodeCamp) and I share our experiences as career changers that may help you on your journey. You can also access the podcast on iTunes, Stitcher, and Spotify.
I will also hold a few AMAs and webinars in the coming months. If this is of interest to you please let me know by going here. And of course, you can also Tweet me at @ZubinPratap.