Follow

new blog post about how there's too much admin work in tech companies these days & why devs should care about project management more
blog.rachelbinx.com/2023/again

· · Web · 3 · 1 · 15

@binx Oooh! New Binx post!

My (small) company has been struggling with *not* having any PMs. I think the devs generally haven’t stepped forward to help manage projects because it takes away from doing dev things, but having no one has made for some chaotic times. I think there’s been a (re)recognition that someone needs to take point, in some manner. At least to get everyone talking “do we need this feature”?

@mez I would argue that "dev things" should include project management, people should have an active hand in deciding what to build before they go build it. And to be clear, I don't think that pure consensus is the path forward, there should be a point person who ultimately makes decisions. But (in my anecdotal experience) PMs are ill-suited for this because they don't understand the day to day dev work (since many are not technical)

@binx Yeah, I like this. I think the struggle I’ve seen is the translation from client to devs. There’s usually a business manager or sales person in the middle there, who *isn’t* a PM of any sort, so the communications to the devs are rough and it’s hard to know what and why is being built. We need both a point person & to close the gap with the client. I agree about dev things including PM, it really clarifies what needs to be done.

@binx “PMs…don’t understand day to day dev work” oooh yah a big project a few years ago with an “agile coach” PM painfully highlighted this. 😖

@binx I’m also curious about the compartmentalising you’re finding at tech companies. It seems like so many dev job listings are “full stack” still - or if they aren’t they’re React monolithic (but even those usually want knowledge of databases (usually graph) and more backend-y things like API development. Unless you’re referring more specifically to dev vs (project) management?

@mez this is again super anecdotal based on the last year of my job hunting — but does one do frontend dev? full-stack dev? UI engineering? UX design? product design? developer experience? From a Slack "frontend dev" post I saw recently, applicants are supposed to self-identify: "We’re currently hiring different levels of Frontend Engineers across pillars such as Conversations Search & Channels, Canvas, Quip, Virtual HQ, Developer Experience, Line of Business, Network, Expansion, and Platform."

@binx Frontend dev has gotten very blurry and broad, agreed.

Honestly, no idea what that slack post is looking for. Were those company specific things? How does one self-identify as “Conversations Search & Channels” 🤔

(sorry for the million replies!)

@mez I think it's reasonable for people to specialize over the course of their career, but if you get in a position where it's "oh you're just the UI engineer, wait for someone else to give you a spec to work off of" vs. being a part of determining what the feature should do in the first place, which cascades down to UI engineering decisions.

@binx Oh, look, it me and the hill I constantly die on at my office. 😅 (It’s gotten quite a lot better)
Just let me talk to the client!!

@binx To me this post highlights the massive difference between how our organization does project management vs the wild thing other companies seem to do with PM roles (usually called product management elsewhere…)

In our world project managers hold engineering accountable for breaking down their own work and filing their own stuff, (or if needed for newer or less focused engineers sits with them to work it out.) and reports the status of the project and whether it’s going to get done.

@binx Engineering remains largely responsible for what gets built (feat design), project management is largely responsible for when things get built.

And prioritization is a murky shared responsibility. :) (I.E. Engineering tells the folks who picks the snakes how good the feature is, project managers pick the snakes. Snake picking is not an exact science.)

@binx But we wildly agree on the underlying point that you shouldn’t turn your engineering team from a creative team into a tactical team and any system that does that is a bad system and will create bad product.

Sign in to participate in the conversation
Horsin' Around

This is a hometown instance run by Sam and Ingrid, for some friends.