
Leading Projects – As a Software Engineer - gregdoesit
https://blog.pragmaticengineer.com/how-to-lead-a-project-in-software-development/
======
hitekker
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.

~~~
mnowicki
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
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/art...](https://sci-
hub.se/https://www.sciencedirect.com/science/article/abs/pii/S0749597815300108)

[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.h...](https://www.nytimes.com/2019/10/14/technology/uber-layoffs.html)

------
wolco
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
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
> 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?

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

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

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

~~~
singron
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
Dedicated admin/clerical support for software projects sounds like a great
idea, actually.

