4 ms·

Leading Projects – As a Software Engineer

83 points by gregdoesit 7y ago

cpeterso 7y ago
Good information, but why not hire a dedicated project manager instead?
- gregdoesit 7y ago
  I'm the OP. Good question. I had this come up with many people and I wrote a longer response[1]. The short of it is, for small (2-5 person projects) this is a valuable skill to have. And a project manager would probably add _more_ work on top of it. If you think of a small team, let's say a tech startup with 5 people. How many of them are project managers versus developers? And would you rather a project manager with little context on your work "nag" you multiple times a day, or would you rather have control how you and the team do minimum effort project management? These are exactly the type of teams a typical project is run by. Also, most of the engineers are product-minded engineers[2]. In highly autonomous tech companies I see a small ratio of project managers - likely 1:50-1:30 with engineers. In companies where devs have little autonomy, this ratio goes up. I know a large, well-known consumer bank, where there are almost as many project managers, scrum masters, agile coaches and the managers of these people, as there are developers. Developers are not allowed to make any decisions - that's why all these other people are there! In all fairness, this company is spending loads of money with a consultancy to figure out how they can speed up software delivery, which is... slow. Who thought? [1] https://blog.pragmaticengineer.com/a-team-where-everyone-is-a-leader#tensions-and-challenges https://blog.pragmaticengineer.com/a-team-where-everyone-is-... [2] https://blog.pragmaticengineer.com/the-product-minded-engineer/ https://blog.pragmaticengineer.com/the-product-minded-engine...
- singron 7y ago
  I think management is too eager to hire a new role to fix a specific problem. E.g. if your product has bugs, you dont hire new people just to fix bugs. You should get your existing developers to fix bugs. Dedicated bug fixers won't have enough familiarity with the code or organizational clout to really be effective. QA teams run into this all the time. Similarly, not every project should have a dedicated project manager. They won't be familiar with the problems and they don't hold power in the organization. They might end up being little more than a clerical assistant to the tech lead or whoever actually has familiarity and power. Maybe I just haven't worked on the right projects.
  - closeparen 7y ago
    Dedicated admin/clerical support for software projects sounds like a great idea, actually.
- JMTQp8lwXL 7y ago
  When management won't fill the role, someone has to play the role of acting product manager. This will inevitably happen, and it will be the lead engineer's responsibility to interface with external stakeholders.
wolco 7y ago
Most of the responsibilities on the checklist are usually done by a pm. I noticed there were listed as an upflow resource. What do the pms do at this company?
- gregdoesit 7y ago
  At Uber, we have Product Managers, who define priorities, strategy, and the "what" to build. Engineering managers and engineers decide on the "how" and manage their projects. Some EMs run the projects themselves, some PMs do the same. I've found that delegating this responsiblity - and setting up clear expectations - really helps engineers on my team grow, stay motivated and become leaders. Engineers who lead projects also often get promoted faster than those who don't and just become much better rounded than those who have the mentality of "That's not my job. Why should I manage any project?" We have Technical Project Managers - TPMs - who manage massive projects. Think 5-10 teams, 50+ engineers, 3+ locations/timezones. The type of projects that take more than an hour per day to keep in sync with. The ratio of TPMs is around 1:50 for engineers. This is similar to all highly autonomous tech companies work - Google, Facebook, PAULS (Pinterest, Airbnb, Uber, Lyft, Slack) as far as I know. For small projects that engineers can manage just as good, why add an extra layer? Also, often project management decisions and arcitecture decisions are often connected (clean architecture, clean boundaries means less cross-team project management). Engineers managing the projects means a push for cleaner architecture. Having full-time project managers might mean working across messy architectures, project managers picking up the additional work that unclear boundaries mean. So for every 100 engineers at fast-moving companies like Facebook, Google, Uber, you'd have about 10 EMs, 10PMs and 2 TPMs. That's it!
  - erik_seaberg 7y ago
    > Engineers who lead projects also often get promoted faster Architecture is one thing, but I'm never going to be better at management than a good full-time manager who's also growing in role. I want to be recognized for writing better code solving harder technical problems, and shouldn't we be making the most use of this skillset when there's a shortage in the industry?
hitekker 7y ago
Project management is the responsibility of a manager. Project “leadership” is the abdication of that responsibility to individual contributors. This antipattern typically begins with the engineer being "volun-told". The manager will frame leading a project as a growth opportunity, a chance to learn about people, the power to push the envelope in their org. Once the engineer submits, the manager will take a back-seat. They adopt the mindset of a passive referee: sitting on the sidelines as the engineer wrestles with the complexities of aligning people with technology. They're here to "guarantee the success of the project", they can't get caught up in the little details! Sure, the engineer will question why she or he is responsible for reading, writing, communicating, coding, and basically doing the manager's job. But the manager will link to a litany of excuses, they'll offer vague assurances, they'll encourage the engineer to exercise more leadership! Eventually, the engineer encounters an insurmountable obstacle: the structure of the organization. No amount of "influence" on behalf of the engineer will make this project succeed: the engineer needs authority to make substantive changes. The engineer dutifully raises this blocker to the manager, at which point, the manager says that the engineer need to be accountable for their own actions. The manager once claimed the engineer could “delegate upwards” but now the manager doesn’t sound happy. At this point, the engineer realizes that they were "empowered" without power. That "accountability", as the Dutch say, is responsibility minus authority. The engineer finds a way for the project to "succeed" without the manager doing their job. The project achieves its objectives, the engineer (may) rise, and the org takes one step away from its goals. After a few hundred cycles across a few years, these unmanaged projects have created a product disassociated from reality, and therefore unusable. The cycle ends with the engineer exiting: hopefully with a firmer understanding of power, and some useful technical skills for his or her next job. The manager, on the other hand, has let their technical and managerial skills atrophy. They are now semi-obligated to disseminate their rationalizations in books and blogs, in a bid to maintain their current position within the org. All in all, an unfortunate but natural pattern in the lifecycle of an organization.
- gregdoesit 7y ago
  We're looking at two very different sides of the coin and likely working in different environments. Thoughtfully delegating project leadership helps engineers grow their leadership skills. They learn how to make things happen and it sets them on the path of driving impact, even without authority. It also helps the engineering manager - myself! - with potential succession planning. In fast-growth tech companies, it's not uncommon for third-half the engineering managers to be promoted from within. I'm at four engineers who transitioned into engineering management in the company, as a lateral move, after gaining much-needed lead experience with projects like these. I'm also certain that these skills will help some of the other engineers take on lead roles in the current, or future companies. >The cycle ends with the engineer exiting Odd enough, all engineers who I've supported on taking lead roles in 3.5 years (about 20 of them) are all still with the company, and have moved upwards in responsibility/scope/level/pay in no small part thanks to hands-on leadership they keep demonstrating. >the manager will link to a litany of excuses, they'll offer vague assurances, they'll encourage the engineer to exercise more leadership! In practice - as well as in the guidance document[1], I specifically ask engineers to delegate upwards to their manager when they see a need: "Delegate where it makes sense. You can both delegate upwards (e.g. to your manager or PM) as well as to team members.". I often step in to help with things that are outside the scope of an engineer or where they struggle. Why on earth would I not help the project succeed? All in all, it feels like you've not had good experience with managers or leading projects. [1] https://docs.google.com/document/d/1kngKHUCS0DHNvZAO8PfkcsTD4Mq7b11L09RIaVpQnwI/edit# https://docs.google.com/document/d/1kngKHUCS0DHNvZAO8PfkcsTD...
aprdm 7y ago
Great article! I've been in this sort of role for around four years now across two different companies. A very big problem I see is balancing out my time to learn technical skills vs leadership/mgmt skills. I feel like the software engineer is not being kept as up to date as I want. An issue I see w/ this is that companies rarely hire for lead software engineer and if I were to change companies I would have to exercise the software engineer side of knowledge for interviews / first couple of months.

83 points by gregdoesit 7y ago

cpeterso 7y ago

Good information, but why not hire a dedicated project manager instead?

gregdoesit 7y ago
I'm the OP. Good question. I had this come up with many people and I wrote a longer response[1]. The short of it is, for small (2-5 person projects) this is a valuable skill to have. And a project manager would probably add _more_ work on top of it. If you think of a small team, let's say a tech startup with 5 people. How many of them are project managers versus developers? And would you rather a project manager with little context on your work "nag" you multiple times a day, or would you rather have control how you and the team do minimum effort project management? These are exactly the type of teams a typical project is run by. Also, most of the engineers are product-minded engineers[2]. In highly autonomous tech companies I see a small ratio of project managers - likely 1:50-1:30 with engineers. In companies where devs have little autonomy, this ratio goes up. I know a large, well-known consumer bank, where there are almost as many project managers, scrum masters, agile coaches and the managers of these people, as there are developers. Developers are not allowed to make any decisions - that's why all these other people are there! In all fairness, this company is spending loads of money with a consultancy to figure out how they can speed up software delivery, which is... slow. Who thought? [1] https://blog.pragmaticengineer.com/a-team-where-everyone-is-a-leader#tensions-and-challenges https://blog.pragmaticengineer.com/a-team-where-everyone-is-... [2] https://blog.pragmaticengineer.com/the-product-minded-engineer/ https://blog.pragmaticengineer.com/the-product-minded-engine...
singron 7y ago
I think management is too eager to hire a new role to fix a specific problem. E.g. if your product has bugs, you dont hire new people just to fix bugs. You should get your existing developers to fix bugs. Dedicated bug fixers won't have enough familiarity with the code or organizational clout to really be effective. QA teams run into this all the time. Similarly, not every project should have a dedicated project manager. They won't be familiar with the problems and they don't hold power in the organization. They might end up being little more than a clerical assistant to the tech lead or whoever actually has familiarity and power. Maybe I just haven't worked on the right projects.
- closeparen 7y ago
  Dedicated admin/clerical support for software projects sounds like a great idea, actually.
JMTQp8lwXL 7y ago
When management won't fill the role, someone has to play the role of acting product manager. This will inevitably happen, and it will be the lead engineer's responsibility to interface with external stakeholders.

wolco 7y ago

Most of the responsibilities on the checklist are usually done by a pm. I noticed there were listed as an upflow resource. What do the pms do at this company?

gregdoesit 7y ago
At Uber, we have Product Managers, who define priorities, strategy, and the "what" to build. Engineering managers and engineers decide on the "how" and manage their projects. Some EMs run the projects themselves, some PMs do the same. I've found that delegating this responsiblity - and setting up clear expectations - really helps engineers on my team grow, stay motivated and become leaders. Engineers who lead projects also often get promoted faster than those who don't and just become much better rounded than those who have the mentality of "That's not my job. Why should I manage any project?" We have Technical Project Managers - TPMs - who manage massive projects. Think 5-10 teams, 50+ engineers, 3+ locations/timezones. The type of projects that take more than an hour per day to keep in sync with. The ratio of TPMs is around 1:50 for engineers. This is similar to all highly autonomous tech companies work - Google, Facebook, PAULS (Pinterest, Airbnb, Uber, Lyft, Slack) as far as I know. For small projects that engineers can manage just as good, why add an extra layer? Also, often project management decisions and arcitecture decisions are often connected (clean architecture, clean boundaries means less cross-team project management). Engineers managing the projects means a push for cleaner architecture. Having full-time project managers might mean working across messy architectures, project managers picking up the additional work that unclear boundaries mean. So for every 100 engineers at fast-moving companies like Facebook, Google, Uber, you'd have about 10 EMs, 10PMs and 2 TPMs. That's it!
- erik_seaberg 7y ago
  > Engineers who lead projects also often get promoted faster Architecture is one thing, but I'm never going to be better at management than a good full-time manager who's also growing in role. I want to be recognized for writing better code solving harder technical problems, and shouldn't we be making the most use of this skillset when there's a shortage in the industry?

hitekker 7y ago

Project management is the responsibility of a manager. Project “leadership” is the abdication of that responsibility to individual contributors. This antipattern typically begins with the engineer being "volun-told". The manager will frame leading a project as a growth opportunity, a chance to learn about people, the power to push the envelope in their org. Once the engineer submits, the manager will take a back-seat. They adopt the mindset of a passive referee: sitting on the sidelines as the engineer wrestles with the complexities of aligning people with technology. They're here to "guarantee the success of the project", they can't get caught up in the little details! Sure, the engineer will question why she or he is responsible for reading, writing, communicating, coding, and basically doing the manager's job. But the manager will link to a litany of excuses, they'll offer vague assurances, they'll encourage the engineer to exercise more leadership! Eventually, the engineer encounters an insurmountable obstacle: the structure of the organization. No amount of "influence" on behalf of the engineer will make this project succeed: the engineer needs authority to make substantive changes. The engineer dutifully raises this blocker to the manager, at which point, the manager says that the engineer need to be accountable for their own actions. The manager once claimed the engineer could “delegate upwards” but now the manager doesn’t sound happy. At this point, the engineer realizes that they were "empowered" without power. That "accountability", as the Dutch say, is responsibility minus authority. The engineer finds a way for the project to "succeed" without the manager doing their job. The project achieves its objectives, the engineer (may) rise, and the org takes one step away from its goals. After a few hundred cycles across a few years, these unmanaged projects have created a product disassociated from reality, and therefore unusable. The cycle ends with the engineer exiting: hopefully with a firmer understanding of power, and some useful technical skills for his or her next job. The manager, on the other hand, has let their technical and managerial skills atrophy. They are now semi-obligated to disseminate their rationalizations in books and blogs, in a bid to maintain their current position within the org. All in all, an unfortunate but natural pattern in the lifecycle of an organization.

gregdoesit 7y ago
We're looking at two very different sides of the coin and likely working in different environments. Thoughtfully delegating project leadership helps engineers grow their leadership skills. They learn how to make things happen and it sets them on the path of driving impact, even without authority. It also helps the engineering manager - myself! - with potential succession planning. In fast-growth tech companies, it's not uncommon for third-half the engineering managers to be promoted from within. I'm at four engineers who transitioned into engineering management in the company, as a lateral move, after gaining much-needed lead experience with projects like these. I'm also certain that these skills will help some of the other engineers take on lead roles in the current, or future companies. >The cycle ends with the engineer exiting Odd enough, all engineers who I've supported on taking lead roles in 3.5 years (about 20 of them) are all still with the company, and have moved upwards in responsibility/scope/level/pay in no small part thanks to hands-on leadership they keep demonstrating. >the manager will link to a litany of excuses, they'll offer vague assurances, they'll encourage the engineer to exercise more leadership! In practice - as well as in the guidance document[1], I specifically ask engineers to delegate upwards to their manager when they see a need: "Delegate where it makes sense. You can both delegate upwards (e.g. to your manager or PM) as well as to team members.". I often step in to help with things that are outside the scope of an engineer or where they struggle. Why on earth would I not help the project succeed? All in all, it feels like you've not had good experience with managers or leading projects. [1] https://docs.google.com/document/d/1kngKHUCS0DHNvZAO8PfkcsTD4Mq7b11L09RIaVpQnwI/edit# https://docs.google.com/document/d/1kngKHUCS0DHNvZAO8PfkcsTD...

aprdm 7y ago

Great article! I've been in this sort of role for around four years now across two different companies. A very big problem I see is balancing out my time to learn technical skills vs leadership/mgmt skills. I feel like the software engineer is not being kept as up to date as I want. An issue I see w/ this is that companies rarely hire for lead software engineer and if I were to change companies I would have to exercise the software engineer side of knowledge for interviews / first couple of months.