Sam Gimbel

Tech, Beer, and Strange Thoughts.

Developer Growth

A friend of mine is an engineering manager with direct reports interested in pursuing product management. I'm reposting the Q&A he and I had on the subject. Hopefully it's useful!

What would you recommend to a junior developer as far skills to hone if she wants to eventually transition into product?

Developers who want to transition into product need to find a way to step out of the role of implementor and view the product holistically, from the perspective of the customer and the business. Product Management is half product and half management. This is the product angle. Rather than seeing the problem you’re actively solving as priority 1, a PM-neé-dev needs to see how solving this problem will contribute to delivering value for the business.

For instance: You have a referral program to build for an ecommerce site that’s having trouble with acquisition. A dev’s job is to build the best referral program based on the constraints given, and to negotiate with product/design until the code can represent that "best.” A dev trying to be a product manager should seek to understand the relative impact that referrals have on the business and negotiate instead to spend an amount of time/budget proportional to the expected value being provided by shipping that feature.

As for things to read/do, practice is key. Product managers come in flavors (UX, Data-Driven, Technical, etc.) and it takes a chunk of time to uncover how you’ll best support a team of engineers and designers. The Dev-to-PM transition is tricky in that devs who are new to the PM world tend to pigeonhole themselves as “technical product managers” by mistake. To avoid this, try working on a side-project or getting a junior PM generalist role before determining your "flavor." Keep in mind that these flavors are equally useful for new PMs and hiring managers alike, in much the same way that “full-stack” describes a dev's trajectory to recruiters without providing a very detailed description of who that person is.

On the flip side, what do you as a PM expect from your interactions with a 2nd-year developer, and what makes a Jr developer great to work with?

PMs don’t directly manage engineers, but we do seek to develop talent wherever we see it. In that sense I expect junior devs to have opinions about what they consider to be good and bad development decisions, but to set aside those opinions when suggestions are made by experienced product managers or engineering managers. In general I expect my junior devs to put their ego second to their need and desire to learn and grow, and I typically see that transition from junior to mid-level when scoping/product discussions become rooted in the dev’s experience solving similar problems rather than on theoretical knowledge of the space.

The other thing I expect from junior devs that I don’t expect from more experienced developers is rapid and noticeable growth. While your own growth may stay internally linear, to the outside world it’s asymptotic after a certain point. As a manager I expect to see self-driven growth that is noticeable over 3-6 months. After a year of working with a junior person I expect them to be able to evaluate themselves with enough self-awareness to know where they stand and where they’re headed. The junior devs i see at the 1-year mark who can make this honest self-evaluation are usually ready to be considered mid-level somewhere in year 2, all else being equal (and it never is).

As the product owner, what parts of the process do you think have opportunities for ownership by the dev team beyond implementation?

The adage is that Product owns the “why” and the “what” and engineering owns the “how.” In Agile with an embedded product owner this works quite well, as engineering is expected to determine the course of implementation as well as the implementation itself. In less agile environments I expect a lot more dev involvement in the planning or prototyping stages in order to reduce the risk of building for production. Typically this includes feasibility sessions, estimation sessions, and dev/design-driven prototypes. We do prototypes to lower feature ambiguity, so the product mandate for these early versions will be less structured than that for a production feature. This is a perfect opportunity to get engineering and design involved in the early creative process and run with a feature with the understanding that their work may get thrown out entirely.

Giving dev teams a lot of leeway up front uncovers a ton of interesting possibilities and constraints and builds social capital for "laying down the hammer" when making compromises about taking on technical debt or cutting scope. In general, good managers should earn the trust of their teammates by allowing for group autonomy whenever appropriate. It’s the easiest way to get your teams to grow and to root out personnel problems early.

In general, what marks a solid product/dev relationship as far as creating the best conditions for personal/career development for all involved?

This plays into the paradox that is product management: we manage the product outcomes, not the people involved, so the most “control” we can ever have over teams comes from dictating the relative priorities of features in the pipeline. Good product PEOPLE generally get shit built on time, but not all product people are good MANAGERS. Developing teams over time requires good management acumen which requires a high level of trust, team cohesion, and patience. I personally do not try to grow teams that can’t figure their own internal shit out. The first thing a dev team needs in order to grow is an agreement that they want to grow at all. Divas, brogrammers, whatever you call them, there is a brand of developer that tends to impede team growth by taking the best assignments, working in a vacuum, or failing to communicate. The best thing a motivated developer can do is avoid these types, get on a good team, and seek out product mentorship if their team is underperforming. I expect developers to advocate for their own growth, not their own fame/fortune. That means offering to take shit assignments they know will teach them something new and presenting learnings to whoever is interested when something exciting is uncovered. I also expect devs to recognize success and failure as two equally possible outcomes. You can't win them all.

Good product MANAGERS will find ways to facilitate team growth based on the strengths and needs of individuals on their teams. Taking the self-advocacy of individuals to heart is step one, followed by long-term efforts to get that individual involved on assignments that play to their stated direction. Good product managers shield their developers from bullshit while allowing them to flourish doing work that allows them to grow. Nothing a PM does can substitute for experience, and nothing a PM does can help an individual grow if the individual is not honest with herself about what she wants or does not communicate this to the product manager. To that end I find the best PM/Dev relationships to be based on mutual interest, trust, and lots of off-topic conversation. It’s very hard to facilitate the growth of a one-dimensional being, so getting to know your teams is crucial.

The ideal end-game for this relationship is one where a spec is not needed to begin work. A team can hear the product vision and recognize immediately where to get started. This is ideal for Product as we can step out of the process/project-management role and spend our time determining the right features to build. On the flip-side, this engineering team should be able to succinctly state their concerns about a given path and have the PM recognize why this is so. That relationship describes a high-trust environment and cuts out swaths of negotiation and ambiguity common to less gelled teams.

Finally, engineers should expect good PMs to bring new work to the right team in the first place by merit of knowing the individuals on the team and their strenths and direction of growth. New PMs typically pitch product initiatives to rooms of close-mouthed, confused developers who are all wondering why the hell they, of all the engineers in the org, are being tasked with this assignment. Experienced PMs spend product inception meetings ironing out the final steps in getting features prioritized because the team in the room has been aware of the product's importance for some time and is already thinking about how to solve that specific problem.

It's hard to stress enough that the proper relationship between PMs and devs is a two-way street of communication and trust. Product managers don't write code or HTML, but if you're lucky enough to have a good one on your team they can make the work-lives of individual teammates richer and more rewarding, especially over time.