4 ms·

Some companies seem to be glomming project management into the list of job responsibilities for the dev lead on the team. Oftentimes this results in a role wher

Some companies seem to be glomming project management into the list of job responsibilities for the dev lead on the team. Oftentimes this results in a role where the dev lead is 1/4 project management (or scrum master), 1/4 engineer, 1/4 people manager, and 1/4 hiring manager. Say what you will about it, but I think the trend will continue as organizations try to cut costs with the coming economic downturn.

BFLpL0QNek 4y ago
Noticed this to and it’s not great. The person is spread to thin and there’s a lot of different skills to do each role well. The best project manager I had was a film producer moonlighting as a pm between films. The film producing experience, tight deadlines, tight budgets, scheduling, lots of cross functional teams, bringing them together at the right time etc really carried over well.
wembeley 4y ago
I don't believe this is strictly a cost-cutting measure. I think companies are realizing subconsciously that people who can do this are worth their weight in gold (although I might be biased as one of them) because they can put together the whole picture of software development. You can certainly achieve the same effect with a well-functioning team, but that's harder to manufacture than hiring one person who can put the whole thing together in their head. Of course the tradeoff is what you said: these people get burnt out if not carefully managed and they are probably less optimal than they could be performing any one of those roles in isolation. But the value of getting a synthesis across those functions and moving a project in the right direction is extremely valuable.
- watwut 4y ago
  The problem with that setup is that such one person is super rarely actually keeping all those roles in their head. At least one of those roles suffers a lot, usually more of them.
- vsareto 4y ago
  If someone's that skilled, you might be able to double up on slower remote jobs and collect two salaries instead of getting one position with the demands of two jobs but with the salary of 1x to 1.9x of a slower job. There seems to be diminishing returns for salary increases with responsibility increases.
ellen364 4y ago
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.
lliamander 4y ago
I don't see those responsibilities as being equally emphasized at a given point in a team's lifecycle. Early on, the tech lead will be primarily an engineer and hiring manager: there's not enough people to really need a process yet, and so the tech lead lays the technical foundation while building up the team with the right people. As the team grows, the tech lead will reduce their engineer responsibilities and start focusing on project management in order to deal with the complexities that come from a larger team. Once the team is at a steady state, both in terms of people and process, the tech lead can focus on people management, primarily by training people to take over the other responsibilities. I'm not saying there won't be periods where a tech lead is being stretched too far as the team transitions between these phases, but if the stretching persists for too long then something has gone wrong.
treis 4y ago
When I was a dev lead I split my time between (1) high level sizing business needs to develop a roadmap, (2) architecting solutions, and (3) enabling/QC on more junior devs. That felt pretty right to me. I agree adding on PM tasks to that is too much. Generally why we had something like a PM to do that. Last couple jobs had Engineering Managers to do (1) and generally manage the team. The problem is that EMs don't really know anything about anything. Maybe at one point they were a developer and knew stuff. But since they're not in the code every day they don't know the reality of the code base and their general programming skills decay. Effectively they become a relayer of messages between the dev team and the business with lots of information being lost along the way. I much preferred the previous way.

BFLpL0QNek 4y ago

Noticed this to and it’s not great. The person is spread to thin and there’s a lot of different skills to do each role well. The best project manager I had was a film producer moonlighting as a pm between films. The film producing experience, tight deadlines, tight budgets, scheduling, lots of cross functional teams, bringing them together at the right time etc really carried over well.

wembeley 4y ago

I don't believe this is strictly a cost-cutting measure. I think companies are realizing subconsciously that people who can do this are worth their weight in gold (although I might be biased as one of them) because they can put together the whole picture of software development. You can certainly achieve the same effect with a well-functioning team, but that's harder to manufacture than hiring one person who can put the whole thing together in their head. Of course the tradeoff is what you said: these people get burnt out if not carefully managed and they are probably less optimal than they could be performing any one of those roles in isolation. But the value of getting a synthesis across those functions and moving a project in the right direction is extremely valuable.

watwut 4y ago
The problem with that setup is that such one person is super rarely actually keeping all those roles in their head. At least one of those roles suffers a lot, usually more of them.
vsareto 4y ago
If someone's that skilled, you might be able to double up on slower remote jobs and collect two salaries instead of getting one position with the demands of two jobs but with the salary of 1x to 1.9x of a slower job. There seems to be diminishing returns for salary increases with responsibility increases.

ellen364 4y ago

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.

lliamander 4y ago

I don't see those responsibilities as being equally emphasized at a given point in a team's lifecycle. Early on, the tech lead will be primarily an engineer and hiring manager: there's not enough people to really need a process yet, and so the tech lead lays the technical foundation while building up the team with the right people. As the team grows, the tech lead will reduce their engineer responsibilities and start focusing on project management in order to deal with the complexities that come from a larger team. Once the team is at a steady state, both in terms of people and process, the tech lead can focus on people management, primarily by training people to take over the other responsibilities. I'm not saying there won't be periods where a tech lead is being stretched too far as the team transitions between these phases, but if the stretching persists for too long then something has gone wrong.

treis 4y ago

When I was a dev lead I split my time between (1) high level sizing business needs to develop a roadmap, (2) architecting solutions, and (3) enabling/QC on more junior devs. That felt pretty right to me. I agree adding on PM tasks to that is too much. Generally why we had something like a PM to do that. Last couple jobs had Engineering Managers to do (1) and generally manage the team. The problem is that EMs don't really know anything about anything. Maybe at one point they were a developer and knew stuff. But since they're not in the code every day they don't know the reality of the code base and their general programming skills decay. Effectively they become a relayer of messages between the dev team and the business with lots of information being lost along the way. I much preferred the previous way.