Leading Projects – As a Software Engineer
blog.pragmaticengineer.com
blog.pragmaticengineer.com
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.
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/1kngKHUCS0DHNvZAO8PfkcsTD...
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.
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/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
[3] https://www.nytimes.com/2019/10/14/technology/uber-layoffs.h...
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.
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!
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?
Except there really isn't, no one cares how nice your code is or how hard the problem is. They want you to solve a business problem for them. That is what you're really being judged on and paid for. Even Google's promotion boards take into account the success of your project as far as I know.
Leading a project helps engineers gain insight and training in the skill that they're really being measured on.
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.
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-...
[2] https://blog.pragmaticengineer.com/the-product-minded-engine...
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.