The Dev ?? PM Paradox
Looking at the man in the mirror

The Dev ?? PM Paradox

Here's a trend I've noticed in tech that I'm not sure anyone else has picked up on. It seems like there's a growing number of software engineers that are moving into product. Conversely, it also seems like there are a lot of PMs that are moving into engineering or design. Why?

First things first, I tried to find some data on this and came up embarrassingly empty handed. There are a decent number of reddit posts talking about it but no solid numbers. If you know how I can source some stats for this, I'd love to hear from you.

Engineers are traditionally in their happy place when they can focus on the "how" but still have full trust and visibility on the "why" of whatever product they're building. Organizations that do this well have developers with a high confidence in the decision making process. A lot of the job that a developer does is implementation and if they start second-guessing higher level decisions then something is probably broken in the product management process. This is where I think the first motivator is starting to emerge for engineers going into product - trust.

Put yourself in the shoes of an amazing developer. You care deeply about delivering amazing features. You pour your heart and soul into your work and come out with beautifully written and architected code. You deliver on time and get a pat on the back from your local PM. A few months later you check the metrics. No one is using your feature. Or even worse, it's still not released yet.

What do you do?

Probably nothing initially. It more than likely becomes a bullet point in a retro. But if this happens once, it's more than likely going to happen again.

So it does, and you start to ask "What's the point?". Why spend energy creating things if they aren't going to be used? When the next feature rolls around, you start to pick up the slack from the product team. You ask hard questions. You dig through insights. You look at problems. And you realise that this is a much better use of your time. You go on reddit and ask "What does it take to move from engineering to product?".

I've painted a dismal picture here, but there's another, brighter path that people can take to this same conclusion. Picture a customer-centric organization that exposes as many customer insights as it can to all of its staff. In an organization like this, some people may naturally be drawn to high level problem solving. Individual motivations differ between everyone, and some engineers see programming as more of a tool than a vocation. To those engineers, the broader problems that customers face may be a lot more appealing than the technical specifics on how you solve those problems. They naturally move up the "stack" so to speak and they naturally transition to product simply by following their interest.

So engineers moving to product isn't always some massive organization failure. What about the other direction?

Put yourself into some different shoes. This time it's an amazing Product Manager. You deeply care about customer problems and go above and beyond to make the people your product serves feel listened to. You engage with your engineers; cut scope accordingly; prioritize and communicate like only the best PMs do. Then, during your monthly chat with an executive, you are told your team is going to be building AI next quarter because "it's the future". Goodbye well designed features, hello single sentence requirement from the CEO. For the next 6 months you are a jira ticket machine. Eventually the CEO loses interest. It's never released.

What do you do?

Probably nothing initially. But you might think "At least the devs get to actually create things.". You upskill on design or dev depending on your affinity. Over the next few years you transition out of Product, never to return.

I'm pulling together some stories from my personal network here, but I've seen this trend in a few places. I call it the Dev - PM paradox. Both parties believe the other creates more impact. I can imagine both of the people I've described here existing in the same organization. Hell, I can imagine them being the exact same person at different points in their career.

I don't think good devs or good PMs can do much about this (other than quit). The change has to happen higher up, at the exec level. Both of the scenarios I've created here are an example of organizational dysfunction. If leadership don't care, then nothing will change. That's the solution to the paradox. Care about your company. Care about your people. Care about the symptoms.

Ingo Schommer

Staff Developer and Head of Security at Runn

8 个月

I'm a developer who co-managed the product that we built at back at Silverstripe (under our fantastic Head of Product Benn Crawford, supported by the talented Bryn Whyman). Silverstripe CMS is a hybrid with both devs and CMS authors as users. In my experience and this context, there was a large overlap between product and software architecture decisions. I was very passionate about the long-term direction of the wider product, and frankly couldn't have imagined working there without a seat at the table. Making the technical team around me more effective by influencing highlevel decision making was a big motivator (since it also determined how I spent much of my main job as a dev). I loved (and leveraged) substantiating technical proposals with product metrics and genuine customer feedback. In hindsight, having a foot in both areas managing a complex product also meant I didn't cater as well for user groups that were further away from my technical comfort zone. We somehow always found time for refactoring, but never enough to implement "auto save" in the CMS... In the end, the grey area between dev and product is what drove me into the startup world through Runn. And I couldn't be happier!

Chris Moore

Venture Studio co-founder & GP

8 个月

I was a dev (well, CTO) that also looked after product. There's a few people that can balance the "how" with the "why" and the doing with the planning..

Lilita Alute-Cīrule

???? A Witch ?? in Deep Life's Branding ??

8 个月

How & Why are always there together, right? & sometimes you create things just to experience, are you capable to create them. Even if not in the engineering. But when it aligns to the client & the market too - great fit for fun & cash.

回复
Shubhanan Deshpande

Engineering & Data Leadership

8 个月

I’ve seen this Jacob, and one of the issues I ”identified” is over-hiring of some form, driven by some rationale to over-serve the customers (or investors) in some way. When there are extra hands, extra work becomes work; and ultimately, the focus on real value is affected. I agree with you that this is organisational dysfunction, and I believe the leadership should be very sensitive to this.

回复

要查看或添加评论,请登录

Jacob Duval的更多文章

  • Unknown Unknowns

    Unknown Unknowns

    We've had a few projects at Runn blow over our initial estimates recently, and we've put in a lot of effort into…

    7 条评论
  • Introducing Rough.app

    Introducing Rough.app

    For the last year, George Czabania and I have been building something cool, and today is the day we're finally going to…

    17 条评论
  • How to prevent a Return To Office Mandate

    How to prevent a Return To Office Mandate

    The post-COVID corporate landscape is weird, to say the least. We're in this no-man's-land where the old office culture…

    8 条评论
  • Crappy metrics are killing Software Teams

    Crappy metrics are killing Software Teams

    TLDR; Org metrics fine. Individual metrics bad.

    8 条评论
  • Enterprise sales are hard

    Enterprise sales are hard

    I'm an engineer, not a sales person. Even as a CTO, I thought that distinction would shield me from any pain as we…

    2 条评论
  • What I don't like about Shape Up

    What I don't like about Shape Up

    We use Shape Up at Runn . If you haven't heard of Shape Up, check out my brief pitch on why you should give it a try.

    2 条评论
  • The Remote Work Manifesto: Part 1

    The Remote Work Manifesto: Part 1

    I've been managing remote engineering teams for over ten years, here's what I think works and what doesn't. Hiring…

    7 条评论
  • The only rule is don't burn out

    The only rule is don't burn out

    Statistically speaking, you've experienced burnout. There is actually an insane amount of research on burnout, and I'm…

    7 条评论
  • Your values are what your values are

    Your values are what your values are

    I'm not a fan of company values. They are often only created as a box ticking exercise by leadership, and are…

    4 条评论
  • The rise of corporate orthodoxy

    The rise of corporate orthodoxy

    The post-covid corporate landscape is a weird place. Pre-covid, companies could rely on the pressure cooker of…

    8 条评论

社区洞察

其他会员也浏览了