
Ask HN: What was the best project management style you have been a part of? - MPiccinato
What tools did you use? Any particular methodology? Why did it work for your team or company?
======
rbthrowaway
Throw away time.

I work for a company in slow decline. We’ve been churning like 5-10% of our
customers for a few years now. Old VP in tech was pushed out and a new one was
brought in.

This guy (1) fires all the project managers (2) flattens the tech org such
that he has over 50 direct reports and (3) institutes a mandate that all
developers are now accountable directly to their business stakeholders. Anyone
who doesn’t like this plan was told to GTFO.

We have never been more productive. However he alienated many people who’s
skills I respected and they left the company. Also there’s a fine line between
accountability and leading via fear, especially during times like these.
Sometimes he crosses that line I feel.

That said, flattening the organization and pushing accountability directly to
developers did improve output. You can’t hide any more as a dev. Everyone has
visibility into what you’re delivering. I don’t meet with project managers any
more, instead I meet directly with people in business units. He also does a
good job of recognizing individuals when they step up and deliver.

~~~
rawgabbit
Agreed. Best projects I worked on were led by the business stakeholder. No
project managers. No scrum master. No QA folks. The tech leads translated
business speak into tech requirements and educated the business on the art of
the possible. Because the business drove it they learned very quickly and took
ownership. The entire project was managed by word documents stored on a file
share.

~~~
2rsf
as a test person I can see an organization without a dedicated QA organization
or even dedicated people, this is even somewhat of a recent trend, but someone
still needs to test and take care of the test infrastructure and this is not a
small nor easy task for someone who is also in charge of developing the
feature.

~~~
pm90
The problem with this approach is similar to the problem of having a dedicated
org for ops: the qa/testing org is disjointed from any sense of delivering
business value and its goals are somewhat arbitrary. This team usually does
not have a good understanding of what devs workflow looks like and instead it
mandates some things that look good on paper but end up being quite useless in
practice. Eg “have functional tests for every application” becomes a mandate
that devs pay lip service to. It becomes another annoying box that devs need
to check rather than something that actually improves the reliability of their
applications.

A better approach is to discuss the reliability goals with the dev team and
let them employ/buy any testing tools they need and hold the team responsible
for the result. Developers want to build reliable apps. They know how their
applications work. They want what they build to not break.

~~~
afarrell
Or to have the infra team learn how to do UX design.

No I do not mean Photoshop/InDesign/Balsamiq/Dribble etc. I mean user
experience design. Like [https://fishshell.com/](https://fishshell.com/) or
[https://www.digitalocean.com/docs/databases/postgresql/quick...](https://www.digitalocean.com/docs/databases/postgresql/quickstart/)

------
AlexanderNull
I work in a predominantly Scrum division with rigidly set iteration lengths
(technically not scrum as this should be decided by each team, I know). It is
horrible, so much wasted time trying to play by the book on this.

Every once and a while we have to break out special teams for a cross group
project, a special POC, or something super important with a tight deadline. In
those cases the team becomes much more engineer led than management led and in
most cases we revert immediately to Kanban style. Not surprisingly for me, we
always get more done in a faster manner with Kanban.

Things get done when they're done, not when an arbitrary sprint end day has
occurred. Kanban allows you to move work along as needed and instead of
focusing on meeting that arbitrary end day, we all get to focus on
continuously getting stories closed out. All we needed for this was a kanban
board in whatever tracking system we were using at that time along with a
reliable form of communication between team members.

------
ericbarrett
In 2012 I was an infrastructure engineer at Facebook. Up to that point I had
the typical IC's view of project managers as worthless, typical bureaucracy,
etc. All the stereotypes. In fact we were proud of working without PMs in our
group at that point.

Word came of a significant new feature for the site, one which would require a
lot of extra data to be backed up, and at such quantities we couldn't use our
existing system. So it required significant changes to our backup architecture
as well as coordination with several product teams to ensure we got it right
and that it was ready for launch—as you can imagine, not having functional,
tested backups was a blocker. To ensure a timely finish, management brought in
a recently acqui-hired project manager. There were literal groans when it was
announced (I was probably one of them).

What a revelation! It turns out all those stereotypes were actually true, and
the PMs I'd worked with in the past were actually as indecisive, unnecessary,
and hobbled as I thought. Here, by contrast, was somebody who brought
competence and execution to the table. Among the delightful things she did:

\- First things first, she _managed the project._ (So many project managers
don't actually do this!) By this I mean she talked to all the teams involved,
got a sense of what everybody thought had to happen, summarized it, collated
all the teams' takes, and presented it back to us, and got buy-in or
objection. Repeatedly.

\- All meeting organization was handled by her. Not as a secretary—excuse me,
_administrative assistant_ —but in the sense of cajoling insular and disparate
teams to agree that they should talk, and what the topic would be; as well as
scoping the topics ahead of time so we had some common ground to start
talking.

\- While she wasn't an engineer, she had some technical experience, enough to
understand the shape and implications of architecture decisions. And the price
tag.

\- A perfectly blasé attitude (cheerful and uncaring). Why is this good? Many
of the team leads involved were that toxic combination of sexist and
dismissive of "non-techies." (This was 2012, so "bro culture" was in full
swing.) I personally witnessed her get smacked in the face with this attitude
day after day. Rather than withdrawing or complaining, her response was a
shrug and, "Your funeral." She was able to do this both because of her amazing
personal attitude and because she actually did have the confidence of higher-
ups, and knew if she reported "We're blocked because team X won't cooperate"
it would be taken seriously and wrath directed appropriately. I think this
attitude would serve anybody well in the same role, be they man, woman, or
anything between or aside.

What didn't she do? She didn't use named business school techniques. Agile was
a weird and mostly-forgotten nerd rant published eight years before and not
yet rediscovered. No Waterfall, no points, no scheduling, no Cycle Analysis,
no JIRA, none of that. What made her so effective was that every day, she
asked, "What can I do as a coordinator to make this project successful?" And
then she did it.

The project launched on time with functional backups.

~~~
vanusa
_This was 2012, so "bro culture" was in full swing._

Thank you very much for revealing this tidbit about what it meant in 2012 --
and presumably still means, to this very day to some extent -- to be a
"culture fit" at Facebook.

~~~
ericbarrett
This culture was absolutely pervasive throughout Silicon Valley, likely since
the first ground was broken for the first office park. I remember being taken
to a strip club lunch by a field team, years before Zuckerberg graduated high
school. In this regard, in 2012, Facebook was nothing special. In fact, there
was probably less of that kind of bullshit than elsewhere.

------
kleer001
Please excuse my "You're asking the wrong question." answer. That said I do
want you to succeed. Of course, a grain of salt is reccommended.

I wouldn't point towards relying solely on methodologies. People are weird and
complex, crazy even, especially the talented ones. Maybe eccentric is a more
politic term. Be that as it may, I don't think that trying to use recipes for
this landscape is going to help, at least in the day to day problem solving
way. Instead I think you'll want a particular person.

Excellent soft skills like you need require high trait contentiousness and
high trait extroversion, someone that loves to talk with people all day and
that has all their ducks in a row. Test for those two things.

They're going to be expensive. But, with a established track record they're
going to be worth it.

------
afarrell
I used to work for a company that used a process mostly like the following:

1\. Hit 'copy' on a Dropbox Paper template of usually-important questions.

2 Write the name of the project at the top.

3\. Collaboratively write whom (we think) it matters to, what systems (we
think) it touches, and why (we think) it matters.

4\. Go talk to the people in ops/support/api support/sales/legal/etc, whom it
mattered to and ask them. Collaboratively edit the Dropbox Paper document with
the updated understanding.

5\. Think some more about the systems it touched. Read code. Maybe write a
1-day spike. Maybe write psuedocode. Maybe draw diagrams. Ask questions.
Update the Dropbox Paper document. Delete irrelevant questions or sections.

6\. Come up with a few design options, starting with some crappy ideas. Maybe
talk with other teams. Maybe go back and talk with stakeholders. Eavaluate
trade-offs. Pick the option[s] that made the most sense. Put the others at the
end underneath an <hr>.

7\. Meet with the stakeholders again to double-check that everyone's on the
same page and they'll have capacity for us to ask Qs when we run into the
unexpected. Send out a concise project-kickoff email so people know what we're
doing.

8\. Break work into trello cards. Sequence them to try to deliver incremental
wins along the way.

9\. Write tests. Write code. Ask Questions. Write queries. Get stuck. Get
clarity. Make changes easy, then make the easy change. Do hallway usability
tests. Update the Dropbox Paper document as you learn important things, so it
stays an organized source of project truth.

10\. Succeed.

11\. Have a project retro among engineers and stakeholders to collect
learnings, usually scheduled by the PM.

12\. Send around project complete email with a link to the Dropbox Paper
document, which now becomes a historical reference.

Projects were generally 2-4ish weeks. Longer effort would be broken up into
conceptually-coherent phases of that size.

\--------

Causes of success:

1\. Insist on written clarity -- We put a lot of thought into the Dropbox
Paper document because it was actually our means of communicating with each
other (and our post-vacation selves) about the results of our a conversations.
It is _astounding_ how much faster you can work when you're on the same page
and know what you're doing.

2\. Start With Why -- We strove to always keep in mind the actual impact we
were trying to have

Sometimes we would get to step 4.5ish and realize that the project had
insufficient "why". This observation enabled us to deliver (earlier than
expected!) the most high-performance snippet of code that any company can
deploy:

    
    
       ```
       
       ```
    

3\. "Take what is useful, discard what is useless, add what is specifically
your own." \-- either Bruce Lee or a weird guy from Mostar

The template was a useful reminder, but we cut any section that didn't serve
to create clarity.

4\. Being able to talk to stakeholders, to know what their goals are, and talk
through what UX matters to them....sure that probably helps the business...
but the real reason it is great is that it is just so damn personally
rewarding.

5\. Technical Investment -- Our PM wanted us to keep the codebase clean and
well-tested so that we'd be able to deliver with more speed and sureness.

6\. Do not 'be Agile'. Move _with agility_ --
[https://www.youtube.com/watch?v=a-BOSpxYJ9M](https://www.youtube.com/watch?v=a-BOSpxYJ9M)

(Looking back on that company, their normal development process was full of
accidental Reasonable Accommodations for my ADHD)

