I am heading our PM team and am currently talking to one of the engineers on the team who is considering becoming a PM. I am planning to get them started just being more deeply involved in some small product tasks, but I am wondering about the eventual transition, especially whether it makes sense to aim to make the engineer a PM in the team they are currently working with (which doesn’t currently have a full-time PM, I would otherwise hire someone externally), or whether to move the candidate to a different team when they make the transition to full-time PM. I can see pros and cons: on one hand, the person already knows the team and product area well if they stay with the current team; on the other hand, it might be too tempting to stay a half-time engineer and help write code to fix issues instead of completely making the transition.
Curious what people’s experiences are in that respect!
An engineer moving to do PM is often a transition that will end in success. In regards to your question: it depends on the size of the organization, but I can not imagine any setup where the person would be able to keep writing code while fulfilling PM duties. Normally PMs have way more work (more being subjective here as well…)
If it’s not the case, I’d still make sure that the new responsibility are clear and that they exclude anything on the code. This must be delegated to someone else the moment your colleague changes position.
My first thought was whether the engineer is a vocal person who’s opinions are respected and valued on their existing team. If they struggle there then assigning them as a PM to work with that team could be tough.
Engineer moving to become a PM also needs a mindset shift. For e.g. engineers (myself included) are notorious about doing small optimization that end up being time sinks, but as PM’s they need to keep a watchful eye on these kind of projects and guard the team against them.
I would think moving the person to a completely new project might help in achieving this mindset shift in an easier way. Also they would be less tempted to roll up their sleeves and jump right into code to fix things, since they would be new to the project.
@Michael - My suggestion would be to take is slow and gradual. Many tasks on a development team in a developer-focused startup like yours could be done by either a PM or a developer. For example:
- Figuring out the design of a new API and ensuring that all internal stakeholders and some external customers are OK with it
- Prioritizing/vetting various partners to integrate with
- Preparing a short research paper about the customer impact of iOS15, and presenting the results to the team
- Performing an informal usability test where you ask a few customers to try out some UI prototypes and get their feedback.
- Gathering and prioritizing feedback from customers about a big feature that was just released
- Writing a blog post about some new feature you just released
- Meeting with internal stakeholders like Support and Sales to understand what tools and reports could make their lives easier.
- Evaluating options for developer tools that the team needs, e.g. a better CI system, or better GUI test automation tools.
And so on. My advice would be to partner with this developer’s manager and direct the team’s “PM/developer borderline” tasks to that person for a few months. You can position it to them (and everyone else) as a “try before you buy” exercise that won’t disrupt the team.Assuming this is a good employee you want to retain, the key is not to force a decision before they’ve gotten a good taste of the pros and cons of PM work, and you’ve gotten a good taste of what they’re good at. If the developer decides they don’t like doing PM-like work full-time, then they can slide back into regular engineer work. No harm, no foul. On the other hand, if they are working nights and weekends on the PM-ish tasks because they like it so much, that’s also useful data for them and you.When I’ve done this kind of “PM apprenticeship” in the past for non-PM colleagues, it’s almost always obvious at the end of a few months (sometimes even a few weeks) about which direction is best for them to go next. It’s also usually obvious whether staying on their current team or moving to another one will be best for them.TL;DR - It’s probably too early for you both to know the right way to go. So just let it develop naturally for a while, gather data, and then at the right time you can help this aspirant figure out what’s best for them and the company. At some point they’ll have to decide whether they want to be a PM-like developer or a very technical PM, but it’s helpful to defer that decision until you both know more.
Thanks everyone for the thoughtful replies! @Naomi yeah something along those lines was definitely what I was thinking; I guess I’m getting a bit anxious about all the knock-on effects (like thinking through staffing needs of the various teams for the foreseeable future)
Yep. You guys are doing well enough and growing fast enough that this will probably solve itself without worrying too much. Also, any long-term planning is fiction at your growth rate. As long as the company keeps growing fast, you’ll always have more headcount than bodies ready to work. Hiring is always the bottleneck. That smoothes out minor staffing issues like one particular person’s role. Playing headcount and recruiting chicken usually works out as long as growth keeps going.
The other thing is that, at least in my experience, at least half of the time non-PM folks kicking the tires on PM roles decided that their old role was a better fit for them. A big benefit of a gradual, low-stress apprenticeship is that it makes it easier for everyone if it doesn’t work out, which it often won’t. The worst outcome isn’t being overstaffed in one role vs. understaffed in another; the worst outcome is to lose a great contributor who can’t go back to their old job without losing face.
Good luck and let us know in a few months how it worked out!
Thanks @Naomi, and you’re probably right about growth sorting out all of these questions sooner rather than later
This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.