metaluna
|
home
|
articles
I've had a long career journey, starting as a build engineer on Windows 98 (yes, 98!) back when I was just eighteen, all the way up to now where I am now as Chief Product Officer. Looking back on my career there were a few things that I lucked into or discovered on my own that I wish I'd known a long time ago, and so figured I'd share with anyone getting started who might be interested in a similar career path, along with some advice on how to think about the phases of your career that worked well for me.
For me, beginning my career on the engineering side of things was natural since I always enjoyed and was tinkering with computers from a young age. I used to stop off at the computer store on my way home from school and "hang out" until dinner time - eventually they started paying me to fix computers, and one of the techs there gave me a book on Perl (which was just coming up at the time as an automation language) which gave me the skills needed to land the aforementioned build engineering job as a contractor at Microsoft.
Things are a bit different now, and technology education has become more formalized, but you can help yourself similarly stand out by contributing to open source projects. Look for ones in particular that are very popular and people are familiar with - popular frameworks are great since lots of companies have visibility into them, and hiring someone who is a contributor to the framework(s) you use is not a guarantee of success, but it's a very positive signal. Open source projects need a lot of help, so whatever your technical angle that speaks to you: technical writing, coding, maintaining infrastructure.. these are all possibilities.
In my early career the operations side of the house was the most natural fit because I loved building automation and maintaining it; every new company I worked for was a chance to improve this perfect little framework I was iterating on at every company. As an aside, if I'd had more of a product mind then I might have realized that I should have turned my framework into a product. If you find yourself building the same thing for everyone, instead of doing it for one at a time on staff maybe you could do it for 30 (or more) companies at a time if you build a product, so look for those kinds of patterns.
At this point in your career your main goal is building a wide foundation, so try to get exposure to many different things. You probably don't need to specialize in just one language or stack, so be open to opportunities that come along and you'll get to learn the differences and similarities between different approaches to solving problems. Putting yourself out there by changing companies a few times to learn how to get up to speed and be productive quickly is a great skill, though you don't want to job hop too much or you'll find some employers are no longer interested. In that case, contracting can be great since the stability can sometimes be less important when you're young and it's not seen as a negative as you move between different employers.
After a few years and experiences at different companies, you've probably learned enough to know what you like or don't like. Now's the time to dive deep into what fires your passion and master something - could be an industry and the common problems and solutions that are needed there, it could be a tech stack, or it could be a company growth phase. In my case it was the video game industry and the creative people that you work with in that kind of environment, but it sort of doesn't matter what it is. What does matter is that this is important enough to you, and you could see yourself doing it for long enough, that you're ready to make it the basis from which you're going to be able to jump into product management.
During this phase of your career it's important to get a handle on three main things:
The first is pretty self-explanatory, but the second and third deserve a bit more detail. Being an engineer with a customer focus means that you're not just building up your skills for some future theoretical product manager job, but you're setting yourself up to also be an excellent engineer. Some day when you achieve your dream of moving into product management, you'll see how wonderful it is to have an engineering partner who takes the time to understand the problem space, the user, and collaborates with you on the best solution. Now's your chance to be that engineer and make yourself, your team, and your product better. Your peers and managers will see and appreciate this so much.
As far as mastering the problem space, this is very open to interpretation and can mean a lot of different things depending on your aptitudes, the area of focus you've chosen, and the kinds of users/problems that come into play. It builds on your user focus, but I think ultimately comes down to a kind of learned pattern recognition skill where you can pause, look at the big picture, and see the assumptions and trends that can be challenged to move things forward.
This takes a ton of experience and time to develop, and the pure-engineering equivalent is probably analagous to knowing when it's time to do large rearchitecture of your system (and be confident that the decision won't become a regret in retrospect). But, if you spend this phase of your career focused on building this skill, it's something you can achieve.
At this point in my career, for me this was a transition from just building build and release automation to also include coordinating how releases are planned and executed. It was a natural progression, and I was able to leverage the skills I'd built up focused on the technical implementation to also cover automating things like release gates, quality management, publishing technology, and so on.
This was just one side of the coin, though, by being focused on my customer (who were now the internal teams who were trying to ship software) I gained a deeper understanding of the priorities of the business and how what I did could really make a difference - not in some abstract way, but by solving clear problems with real impacts. At this point in my career I started learning a ton of process frameworks which helped give me tools and a vocabulary to understand the problems and explain my solutions.
Made it this far? Then you are hugely valuable to any product organization relevant to your focus area. It can sometimes be hard to get past HR resume filters if you haven't already had product manager as a title, so this is where your network you've built up comes into play. People will remember you as that customer-focused engineer who gets things done, and will be able to vouch for you to the hiring product manager directly. You can also use Twitter or other non-traditional approaches to try to find people in the area that you've chosen and just be up front that you're a non-standard candidate but are looking to make a move.
Once you're in your first role (congrats!), there are a few traps that you can get into that you need to be careful to avoid. All of these I think come from the fact that you feel like an expert in the product area you're now managing. You are still an expert, but your users/customers are also important. It can be easy to disregard them or think you know better, but in my experience the most rewarding parts of my career are engaging with people on my product. They appreciate your expertise, and they offer viewpoints and perspectives that you may have forgotten or never known. It would be a big mistake to decide you know best and push forward based on your experience.
Product management has been a wonderful mid-career change in my life and it's hard to imagine ever wanting to do anything else. Even if I did, I think I'd still think like a product manager in that role. If your goal is to transition from a technical role into a (technical) product role, I wish you luck in your journey and hope that your experience will be as fulfilling as mine has been. If you have any questions drop me a note and I'd be happy to chat. I'd also be happy to look into my network if you're ready to "make the leap."