Dear new developer,
I’ve written before about how being a developer sets you up for a lot of adjacent professions. Jobs like:
- Engineering manager
- Technical trainer
- Startup CTO
- Product manager
- Developer advocate
- Sales engineer
I have either direct personal experience or have watched a colleague or friend transition to those types of jobs. I’m sure there are many that I’m missing.
I had someone ask me about developer advocacy and how she could transition into it. I gave some off the cuff advice that I’d like to formalize in this post.
Moving to an entirely different career (“I want to be a rock climbing guide!”) is a bit different, but if you are transitioning to an adjacent profession, I think there are four parts.
First off, find out more about the position: the responsibilities day to day, the types of problems you’ll face, what kinds of companies hire for the position, what kind of career growth is possible, the salary ranges, the challenges.
All this information will help you make an informed decision about whether a move is what you want to do. I’d spend a lot of time researching using Google because you can do that at your leisure.
If you decide from this research that you are interested in taking the next step, then you’ll want to talk to some people already doing the job.
Reach out to people who are or have done the job, whether internal to your current employer or on LinkedIn, and ask for their time. The research you’ve done previously should leave you with some questions. For example, for a developer relations position, you might ask the following questions:
- How do I find companies looking to hire devrel folks?
- How much experience do I really need?
- What is the split of coding vs speaking vs writing?
- Person X said Y about devrel, is that true in your experience?
If you do that, make sure you have a crystal clear agenda if you don’t know them personally, and that you communicate your focus. These folks are probably busy. Don’t start off the message saying you’d like to “pick their brain” for 30 minutes at coffee. Instead say:
I’ve been researching a career transition to developer relations and I notice you’ve been doing this for a few years. I’m especially interested in your experience at and would love 30 minutes of your time to ask some questions. If you’d prefer email, happy to do that as well.
If you are still interested in this change, the next step is to try it.
Give it a try
You should now have a good grasp of what kind of day to day work is needed for this adjacent profession. Now you want to try it in a low stakes way.
- Want to be a trainer? Research and give a talk about a new technology in the area you want to train in.
- If you are interested in product management, see if there are user interviews that need to be done for your current work. Can you sit in on one, or run it
- Devrel interesting? Write some blog posts about a technology you’d like to promote.
From your previous research, you should be able to find an easy way to practice some of these skills. You could find an open source project looking for help, ask around internally, or start/continue a side project.
Doing this has two benefits:
- You can learn even more about the profession.
- When you want to make a transition, you can point to this work as an example that you have the skills to do so.
How long should you do this? Ah, another example of the secretary problem. I don’t know. But you should try it a few times, enough to give you a feel.
Finally, if you are still interested, take the plunge.
You can transition internally or by getting a new job. If you do the former, the stakes are lower and you’ll come in with your existing reputation, which will presumably help you. However, it may be tough to do if the company doesn’t really have a need for the position. For example, I was interested in developer relations, but worked for a consulting company which didn’t have a developer facing product. It would have been difficult for that company to justify a developer relations position.
If you can, though, the internal transfer is a great way to go. While every internal political situation varies, if you think one is possible, I’d talk to the manager of the team to which you want to transition and to your own manager and see what they think. Is it possible? What is a good timeline? Should the transition be blended (two days in one position, three in the other) or have a firm cutoff? What would success look like?
In a smaller company, you may have more flexibility if you see a gap. One colleague stepped into product management successfully because she saw the company needed it and no one was doing it full time.
If you don’t see an internal option, interview with other companies. Be prepared with an explanation of why you want to make the transition and how they’ll benefit from hiring you. Your research and experimentation should provide you with plenty of anecdotes to share.
Finally, one nice aspect of software development is that if you take a year or three off in an adjacent field, you can come back. The change need not be permanent. You may need to brush up on some particular technologies, but in general I’ve found you can transition back fairly easily. And you’ll be a more valuable software developer if you know about product management, how to have a one to one, or marketing automation.