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.
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.
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.
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.
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.
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:
```
```
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
(Looking back on that company, their normal development process was full of accidental Reasonable Accommodations for my ADHD)