3 ms·

My theory is this happens for two reasons. First reason, product managers at a company start getting pulled into a lot of client management stuff. They have le

My theory is this happens for two reasons. First reason, product managers at a company start getting pulled into a lot of client management stuff. They have less time to spend on the product itself and the resulting vacuum is often filled by the lead dev. The lead dev demonstrates they can fill the vacuum, so starts getting asked to fill other vacuums relating to management and hiring. Second reason, management doesn’t have a clear image of what a “developer” role should look like in their company. E.g. at tiny startups a dev might be entirely responsible for a product and even help answer customer emails. (I’ve done that and I actually think it’s fine, as long as you and the rest of the company know that’s the deal.) At the extreme opposite end, a dev might have little autonomy and be practically writing the Python syntax version of tightly specified business logic. But most companies operate in the fuzzy middle and I think many struggle to define their concepts of dev / QA / product. In those companies, it’s easy for a dev to become someone who is officially “a developer” but with a bunch of semi-official hats. I might have to add a third reason to my theory, now that you’ve reminded me about cost cutting.

dvtrn 4y ago
management doesn’t have a clear image of what a “developer” role should look like in their company. combined with In those companies, it’s easy for a dev to become someone who is officially “a developer” but with a bunch of semi-official hats. results in a similar story with Devops and it's younger brother, SRE. My job role officially changed from "Devops Engineer" to "Site Reliability Engineer" when I switched jobs two years ago and I'm lacking in finding ways of differentiating the two. It's seemingly become the default response now on Devops communities when someone makes a thread saying "I want to get into Devops, what do you do?" that the job role means 'whatever the company wants it to mean', which is how we end up with Devops practitioners and teams getting turned into kitchen sinks for dealing with anything and everything the feature development groups aren't tasked with because of a severely unchallenged assumption that the dev team brings in revenue, while the operations people consume it. An assumption that's never said outright-mind you, but the organization and delegation of work between the two domains of functional teams, IMO says it pretty loudly.

dvtrn 4y ago

management doesn’t have a clear image of what a “developer” role should look like in their company. combined with In those companies, it’s easy for a dev to become someone who is officially “a developer” but with a bunch of semi-official hats. results in a similar story with Devops and it's younger brother, SRE. My job role officially changed from "Devops Engineer" to "Site Reliability Engineer" when I switched jobs two years ago and I'm lacking in finding ways of differentiating the two. It's seemingly become the default response now on Devops communities when someone makes a thread saying "I want to get into Devops, what do you do?" that the job role means 'whatever the company wants it to mean', which is how we end up with Devops practitioners and teams getting turned into kitchen sinks for dealing with anything and everything the feature development groups aren't tasked with because of a severely unchallenged assumption that the dev team brings in revenue, while the operations people consume it. An assumption that's never said outright-mind you, but the organization and delegation of work between the two domains of functional teams, IMO says it pretty loudly.