4 ms·

Project management is the responsibility of a manager. Project “leadership” is the abdication of that responsibility to individual contributors. This antipatte

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...
deanmoriarty 7y ago
This was so well stated and very much reflects my experience. I have seen many engineers in charge of leading projects who miserably failed because they weren’t able to “influence” other teams on which their project depended (“who are you again and why do I have to do this for you?”) while their manager still held them fully accountable without offering any help to step in and exercise power against the other team. The solution that always saved my ass was: build a network inside your organization, help the tech leads of other teams whenever you can even if it causes you some short term pain, and one day you’ll be able to successfully claim favors from them and influence a team towards your goal even if you have no formal authority over it. The amount of power managers have over engineers in certain organizations is truly horrific. They will always take all the credit and none of the blames, throwing engineers under the bus in front of their directors. It should be the other way around, most of the times. Great comment.
mnowicki 7y ago
Very well said. I have a question though, what is it that causes the 'manager' to push all of their responsibilities onto the developer lead? Just laziness, or is there some external pressure also being placed on the manager?
- hitekker 7y ago
  As the saying goes, "the fish rots from the head". Somewhere above the manager is an executive who has failed to perform leadership. Leadership, to be clear, is the process by which an individual influences a group towards a common cause; a process absolutely needed at the top of the hierarchy. If not performed at this critical stage, the need for leadership falls to the successive levels below until it is finally met, like a snowball turned avalanche. Take the average executive. Executives are obligated to make hard decisions and get their organization to follow them. Livelihoods are the line, the business at stake... yet executives are people. People do not like to make decisions for other people [1]. If this executive is like most people, they will unconsciously and naturally "delegate" to their subordinates who now "accountable" for a "task" well outside of their authority and above their pay grade [2]. The executive has the power to hide and now they have hidden. So, the middle managers are left holding the bag. For a time, these unlucky few will struggle to handle the weight of responsibilities-- they'll think for their "leader", feel for their "leader", lead for their "leader". Invariably, these do-gooders burn out and are replaced by those who share their rulers rhetoric: the same, safe, secure, separation from reality. These replacements may even perceive that executive not just enjoys the status of "leader", the executive believes they are a leader. The executive can't see that they do not lead. The blindspot becomes BS: we're leaders, you're leaders, we're a team of leaders! Compliance with this BS is necessary to advance upwards, and to push the pressure further downwards. This hollow BS is essential to abdication: it is how foul-smelling organizational problems can neatly be stuffed away. Those problems fester in the bag's darkness, passed downwards from hand to hand with nary a glance. The bag gets bigger and bigger, worn and weaker, until finally the bag hits the rank and file and rips open, consummating the phrase of "shit rolls downhill". The engineer and the manager now fight over the "leadership" of a nigh-pointless project, unaware that it started because Executive A was terrified to tell Executive B "no". Or that the latest cost-savings project to save .00001% of revenue exists because the CEO doesn't actually know which org is wasting money and "asked" his subordinates to figure it out for him [3]. Abdication, like other management pathologies, roots in the feeble minds and weak hearts of the powerful. They can't handle the burdens of their job, they don't want to deal with reality, so their first instinct is to use their power to make it all go away. They then mask their failed leadership with fake leadership, spreading it like a virus to the org beneath. This is a natural and also unfortunate. The simplest remedy and also the hardest one, is to remove the ones in power and replace them with ones who take responsibility for their organization. [1] https://sci-hub.se/https://www.sciencedirect.com/science/article/abs/pii/S0749597815300108 https://sci-hub.se/https://www.sciencedirect.com/science/art... [2] "the commander at the time of American forces in the Persian Gulf region, to issue orders that stated explicitly how he wanted the invasion conducted, and why. Instead, General Franks just passed on to General McKiernan the vague PowerPoint slides that he had already shown to Donald H. Rumsfeld, the defense secretary at the time." https://www.nytimes.com/2010/04/27/world/27powerpoint.html https://www.nytimes.com/2010/04/27/world/27powerpoint.html [3] https://www.nytimes.com/2019/10/14/technology/uber-layoffs.html https://www.nytimes.com/2019/10/14/technology/uber-layoffs.h...
eugenekolo2 7y ago
Amazingly well stated. I lived this exact life as the task-lead a few years ago on one of my projects. I was told to keep the project running, but had no power on hiring, firing, performance reviews, or anything. The project fulfilled the few requirements that we had, but failed to gain any real traction due to lack of feedback from the customer, for which the actual project lead was responsible for.

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...

deanmoriarty 7y ago

This was so well stated and very much reflects my experience. I have seen many engineers in charge of leading projects who miserably failed because they weren’t able to “influence” other teams on which their project depended (“who are you again and why do I have to do this for you?”) while their manager still held them fully accountable without offering any help to step in and exercise power against the other team. The solution that always saved my ass was: build a network inside your organization, help the tech leads of other teams whenever you can even if it causes you some short term pain, and one day you’ll be able to successfully claim favors from them and influence a team towards your goal even if you have no formal authority over it. The amount of power managers have over engineers in certain organizations is truly horrific. They will always take all the credit and none of the blames, throwing engineers under the bus in front of their directors. It should be the other way around, most of the times. Great comment.

mnowicki 7y ago

Very well said. I have a question though, what is it that causes the 'manager' to push all of their responsibilities onto the developer lead? Just laziness, or is there some external pressure also being placed on the manager?

hitekker 7y ago
As the saying goes, "the fish rots from the head". Somewhere above the manager is an executive who has failed to perform leadership. Leadership, to be clear, is the process by which an individual influences a group towards a common cause; a process absolutely needed at the top of the hierarchy. If not performed at this critical stage, the need for leadership falls to the successive levels below until it is finally met, like a snowball turned avalanche. Take the average executive. Executives are obligated to make hard decisions and get their organization to follow them. Livelihoods are the line, the business at stake... yet executives are people. People do not like to make decisions for other people [1]. If this executive is like most people, they will unconsciously and naturally "delegate" to their subordinates who now "accountable" for a "task" well outside of their authority and above their pay grade [2]. The executive has the power to hide and now they have hidden. So, the middle managers are left holding the bag. For a time, these unlucky few will struggle to handle the weight of responsibilities-- they'll think for their "leader", feel for their "leader", lead for their "leader". Invariably, these do-gooders burn out and are replaced by those who share their rulers rhetoric: the same, safe, secure, separation from reality. These replacements may even perceive that executive not just enjoys the status of "leader", the executive believes they are a leader. The executive can't see that they do not lead. The blindspot becomes BS: we're leaders, you're leaders, we're a team of leaders! Compliance with this BS is necessary to advance upwards, and to push the pressure further downwards. This hollow BS is essential to abdication: it is how foul-smelling organizational problems can neatly be stuffed away. Those problems fester in the bag's darkness, passed downwards from hand to hand with nary a glance. The bag gets bigger and bigger, worn and weaker, until finally the bag hits the rank and file and rips open, consummating the phrase of "shit rolls downhill". The engineer and the manager now fight over the "leadership" of a nigh-pointless project, unaware that it started because Executive A was terrified to tell Executive B "no". Or that the latest cost-savings project to save .00001% of revenue exists because the CEO doesn't actually know which org is wasting money and "asked" his subordinates to figure it out for him [3]. Abdication, like other management pathologies, roots in the feeble minds and weak hearts of the powerful. They can't handle the burdens of their job, they don't want to deal with reality, so their first instinct is to use their power to make it all go away. They then mask their failed leadership with fake leadership, spreading it like a virus to the org beneath. This is a natural and also unfortunate. The simplest remedy and also the hardest one, is to remove the ones in power and replace them with ones who take responsibility for their organization. [1] https://sci-hub.se/https://www.sciencedirect.com/science/article/abs/pii/S0749597815300108 https://sci-hub.se/https://www.sciencedirect.com/science/art... [2] "the commander at the time of American forces in the Persian Gulf region, to issue orders that stated explicitly how he wanted the invasion conducted, and why. Instead, General Franks just passed on to General McKiernan the vague PowerPoint slides that he had already shown to Donald H. Rumsfeld, the defense secretary at the time." https://www.nytimes.com/2010/04/27/world/27powerpoint.html https://www.nytimes.com/2010/04/27/world/27powerpoint.html [3] https://www.nytimes.com/2019/10/14/technology/uber-layoffs.html https://www.nytimes.com/2019/10/14/technology/uber-layoffs.h...

eugenekolo2 7y ago

Amazingly well stated. I lived this exact life as the task-lead a few years ago on one of my projects. I was told to keep the project running, but had no power on hiring, firing, performance reviews, or anything. The project fulfilled the few requirements that we had, but failed to gain any real traction due to lack of feedback from the customer, for which the actual project lead was responsible for.