As has been noted on my blog bio (shown below) and my LinkedIn profile, I recently started a new job. Generally speaking, this isn’t Earth shattering news. People start new jobs all the time. In fact, among even the biggest tech firms, the average job tenure is just around 2 years. For me, I was at my previous employer for almost 8 years. Still, this was not a haphazard or spontaneous decision, and my reasoning, though unique to me, I think carries a few principles worth sharing.
For context, the job I left was as director of a division within a small professional services firm. The job I took is as a principal software engineer for a small but growing software product company.
I was ready for a new challenge.
Between 2001 and 2018, I have largely done professional services and consulting work. I worked for myself and as independent contractor for a time. I worked for the consulting arm within a larger software company. Then I worked for a pure professional services firm. In all of these contexts, the work was generally the same: find a customer with a business need, determine and design a software-based solution, then build that solution as cost-effectively as possible. These projects were almost exclusively billed by the hour, and had fixed (and typically aggressive) timelines to deliver.
Consulting is something I think I have particular skills at, but it is a uniquely constrained way of doing business. I found, whether working for myself, or working for someone else, that there is a big limit on freedom in this model. You end up only doing the work people hire you for, whether or not it’s using the latest tech, and you inevitably take technical shortcuts or skip over best practices in order to deliver within the terms of the budget. Consequently, after 17 years of operating in this model, I was craving a blue sky opportunity without many of the anchors that project-based, billable hours consulting intrinsically bring to the job.
That said, consulting is not all bad. The steady stream of new industries, customers, problems to solve, and yes, various constraints all serve to make you think differently and master the skills of problem solving. Learning and practicing task estimation and time management is key in any role.
So now, the new challenge is thinking like a product developer. Building features, not customizations. Working on a release schedule rather than a customer timeline. These are different types of problems to solve, and ones I happily confront. In short, I reached a time where I was ready to solve new challenges that were unfamiliar, rather than the ones I had seen repeatedly through my consulting career.
I wanted to catch a wave.
Part of my new role, and a large part of the corporate strategy of the company in which I am now employed, is embracing the Internet of Things. IoT is clearly the buzzword du jour in 2018, and it’s a wave I knew I would regret missing.
I am of a generation that graduated from university in the late 1990s, at the height of the dotcom bubble. My first job out of college, however, was not with a VC-backed startup, but rather in corporate IT. While I don’t regret taking a job at a more established company, not being part of that trend is something I’ve always held as a gap in my experience.
In 2007, when Apple released the first iPhone and largely started the smartphone revolution, I was starting a new job with a software company focused on web apps. I never leared xCode. I never really got engaged in mobile development, apart from various proof-of-concept apps or demos for presentations. This wave of development passed me over, and it’s something I’ve always been frustrated about.
In 2018, at the middle of my career, I was determined not to let another massive tech wave pass me by. My job search was consequently narrowly focused on companies building or adopting IoT solutions. I looked specifically for organizations that demonstrated a commitment to IoT as a core foundation, not a passing fad. And, thankfully, I found both.
I needed to refresh my skills.
While I have been a coder for nearly my entire career, professional services projects don’t always provide opportunities to write code. Further, many times, the code being written is not large enterprise systems, but one-off point solutions. Consequently, I found myself in a place where many of the coding skills (and habits, frankly) that I employed were due of a refresh.
This facet of the decision is largely what moved me out of a management role and back in to an engineering role. I wanted to get back to coding, and be able to apply my experience building systems in an environment that would force me to learn the techniques I lacked the opportunity to hone in my previous work. In fact, after only a few days on the job, interacting with members of my team and reviewing code others had written, I saw pretty quickly what areas I need to refresh. I built a learning plan, and have been able to get ramped up on the concepts. What’s more, is I now have bona fide work to do that allows me to apply these lessons.
Bottom Line: Don’t be afraid to jump
One of the hardest aspects of this career change was reaching a point where I could allow myself to make a choice for my own benefit, rather than worrying about the outcome or impact of me leaving my previous job. I needed to essentially be selfish. In that choice, though, I have been able to advance both my personal growth and career track. So if there is a lesson to take away, it’s that you are in control of your path, and you shouldn’t be afraid to cause disruption along the way.
Note: my hope too in this change is that I can renew my blogging habits. Look for new posts about IoT, Azure, and working on a great team.
Leave a Reply