4 ms·

My sole experience in Big Tech consists of Facebook and the post more or less matches what I saw there. It seems to me, though, that the author views "no proces

My sole experience in Big Tech consists of Facebook and the post more or less matches what I saw there. It seems to me, though, that the author views "no process" from a very positive lens, with no discussion of negatives. Like how at FB so many teams use spreadsheets to track their work (sometimes multiple spreadsheets per team, sometimes no tracking at all). There is some internal tooling, which is quite basic and at the time I was there it got deprecated without the replacement being finished yet. Whatever you say about JIRA, it can handle complex projects way better than a spreadsheet. My biggest issue with the whole thing, however, boiled down to the set of incentives that centered around individual performance. You see, the teams weren't _teams_ per se, but a collection of individuals working on their own projects, sometimes related to those of other teammates, sometimes not. A team-oriented process like Scrum or Kanban cannot survive in an environment where every person is optimizing every decision for their advancement/bonus/whatever. There's some exaggeration here, but I definitely saw a lot of this at FB. Having come from a company with high-functioning Scrum and Kanban teams that worked together to achieve a common goal, I'd choose that any day, JIRA or not. This is obviously a single example and many of the issues were Facebook-specific. But I bet there are other, not so positive, sides to the "no process" story at the rest of the companies. Note I'm not claiming that the Agile processes are by definition good. I've seen plenty of bad implementations as well. At the end of the day, every group of humans is different and may require a different process (or no process at all) to maximize their success. What I'm suspicious of is the "every team picks their own process" claim, having seen company-set norms exerting enough force to make deviations from the common pattern rather painful and counter-cultural.

paxys 5y ago
Funny that you mention spreadsheets. When I worked at Microsoft my entire business unit (multiple thousands of engineers, managers, PMs) exclusively used Excel for project management. Clean UI, filters, data rules, conditional formatting, validations, pivot tables..it was the absolute best. And with Excel data tools it was all hooked up to a central database (TFS) for live sync/updates. Now I use Jira and hate every second of it.
fredliu 5y ago
Very interesting, do you have any examples of how FB manages long term (2+ years out) project that involves 100+ Engineers? Are those 100+ engineers all "individuals working on their own project"?
- simplyaccont 5y ago
  I worked at FB for a while, and the problem with long term projects were that they were long term. In FB you need twice a year to make self review that shows what kind of impact you created during last 6 months (and based on this you are rated, raises, refreshers, etc). In long term projects impact might be only at the end of project, which leaves you "impactless" for a long-long time. Because of this people didn't really want to join any long term projects. While I was there management was trying to resolve this situation and transmit message that long term projects are impactfull and important (and strategic to company), yet they couldn't answer question of how impact should be calculated every 6 months. Maybe by now they came up with some formula or something
- romanhn 5y ago
  +1 to everything simplyaccont said. Long term projects were a tough beast to manage given the short-term incentives. Usually those got done by breaking them up into milestones and hitting those. That said, my general impression (as a first-level manager who sat in on calibrations) was that unless you move some serious metrics in those milestones, it would be difficult to exceed expectations and much of the upper management encouragement for long-term projects was mostly empty air due to the 6-month performance cycle. That said, large cross-org projects certainly do exist. To answer your specific question, there would normally be some sort of a lead on the whole project, tech lead or PM lead or, often, a pair of those. They would meet regularly with leads of various sub-areas, organized similarly, and ensure things line up properly. Now repeat recursively until you get down to team level, where there might be a tech lead, or perhaps just a senior engineer working with a few non-seniors on their portion of the larger initiative. At this point this would get broken down into individual projects that each person owns and is accountable for. Tech lead may or may not contribute code to this project, they (and their team at large) might be involved in a bunch of parallel initiatives that often don't have much to do with each other, other than the product scope the team owns. Things like daily stand-ups don't work when everybody has their own work stream (and often multiple streams at that). Hope this clarifies. The setup works for certain types of personalities, but I found it to be a very individualistic culture that I didn't particularly enjoy.
underdeserver 5y ago
This matches my experience at Google. Scrum/Agile tells you to split up a project into well defined tasks to be done simultaneously by multiple people. That's counterproductive if, come perf, you need to show that you completed the project, and distinguish your contribution from others'.
vinay_ys 5y ago
Biggest difference between big tech companies and smaller companies is the sense of urgency to ship something to market and the time scale for that urgency. Bigger companies have lesser pressure to ship things too early and have slower (larger) time scales for product release cycles. Both in enterprise space or in consumer space, smaller companies are on a much more rushed timeline, for varied reasons including but not limited to financial situation of the company. Bigger companies can afford to build more slowly. This affects how the company plans and executes as well as rewards performance. In a smaller company, when a complex thing has to be shipped on a shorter time scale, a lot of divide and conquer and quick coordination across large number of contributors is required. This is a necessity. In a larger company, deep complex things are built by very small teams or just individuals over a relatively prolonged time. Individual engineers prefer to keep chiseling away at a particular problem until they can showcase a significant impact with high difficulty/complexity of the problem/solution. That's the consequence of individualistic performance measurement culture. Both cultures have pros/cons and there are rotten extremes in both.
shepherdjerred 5y ago
I had the same experience at AWS. A team of siloed engineers working on projects for the same product, with very little collaboration. Projects were tracked in spreadsheets. Time estimates were created out of thin air to meet the desired (impossible) deadline.
- dboreham 5y ago
  This kind of mass delusion has been pretty much de rigueur my entire career (decades): Software is typically quite hard and mostly unknown at the beginning of a project. Most of the hard work is figuring out the things that weren't known. It's a learning/discovery experience. It's essentially impossible to predict how long that activity will take. The further out in time you consider, the less likely you'll have much of any clue about the subtasks to be done. And of course in the meantime the participants likely aren't even working close to 50% of their time on the new project -- instead they're fixing the bugs and technical debt in the last project. And yet, the "stakeholders" simply wouldn't accept any narrative like the real one (we kind of have an idea how to do this but we're going to figure it out as we go and it'll be difficult and unpredictable). They'd go hire another bunch of folks who are willing to salute the flag. So instead we pretend that what we're doing is predicable and plannable, like building a bridge that's a bit longer or shorter than the last 10 bridges that we built. The stakeholders probably have a pretty good idea that the developers are making it up as they go. But everyone behaves as if the reactor isn't on fire.
  - kragen 5y ago
    Have you spent the decades of your career working at companies that blew their competition out of the water with better software, like Google, Apple, WhatsApp, and Facebook, or at companies whose software was unremarkable or inferior? If it's been some of both, did you note a difference in the degree to which stakeholders grappled with the kind of uncertainty you're talking about?
modeless 5y ago
> Whatever you say about JIRA, it can handle complex projects way better than a spreadsheet. Frankly I have had a much better experience on teams that tracked work in spreadsheets than teams that tracked work in JIRA. Like it's not even close.

paxys 5y ago

Funny that you mention spreadsheets. When I worked at Microsoft my entire business unit (multiple thousands of engineers, managers, PMs) exclusively used Excel for project management. Clean UI, filters, data rules, conditional formatting, validations, pivot tables..it was the absolute best. And with Excel data tools it was all hooked up to a central database (TFS) for live sync/updates. Now I use Jira and hate every second of it.

fredliu 5y ago

Very interesting, do you have any examples of how FB manages long term (2+ years out) project that involves 100+ Engineers? Are those 100+ engineers all "individuals working on their own project"?

simplyaccont 5y ago
I worked at FB for a while, and the problem with long term projects were that they were long term. In FB you need twice a year to make self review that shows what kind of impact you created during last 6 months (and based on this you are rated, raises, refreshers, etc). In long term projects impact might be only at the end of project, which leaves you "impactless" for a long-long time. Because of this people didn't really want to join any long term projects. While I was there management was trying to resolve this situation and transmit message that long term projects are impactfull and important (and strategic to company), yet they couldn't answer question of how impact should be calculated every 6 months. Maybe by now they came up with some formula or something
romanhn 5y ago
+1 to everything simplyaccont said. Long term projects were a tough beast to manage given the short-term incentives. Usually those got done by breaking them up into milestones and hitting those. That said, my general impression (as a first-level manager who sat in on calibrations) was that unless you move some serious metrics in those milestones, it would be difficult to exceed expectations and much of the upper management encouragement for long-term projects was mostly empty air due to the 6-month performance cycle. That said, large cross-org projects certainly do exist. To answer your specific question, there would normally be some sort of a lead on the whole project, tech lead or PM lead or, often, a pair of those. They would meet regularly with leads of various sub-areas, organized similarly, and ensure things line up properly. Now repeat recursively until you get down to team level, where there might be a tech lead, or perhaps just a senior engineer working with a few non-seniors on their portion of the larger initiative. At this point this would get broken down into individual projects that each person owns and is accountable for. Tech lead may or may not contribute code to this project, they (and their team at large) might be involved in a bunch of parallel initiatives that often don't have much to do with each other, other than the product scope the team owns. Things like daily stand-ups don't work when everybody has their own work stream (and often multiple streams at that). Hope this clarifies. The setup works for certain types of personalities, but I found it to be a very individualistic culture that I didn't particularly enjoy.

underdeserver 5y ago

This matches my experience at Google. Scrum/Agile tells you to split up a project into well defined tasks to be done simultaneously by multiple people. That's counterproductive if, come perf, you need to show that you completed the project, and distinguish your contribution from others'.

vinay_ys 5y ago

Biggest difference between big tech companies and smaller companies is the sense of urgency to ship something to market and the time scale for that urgency. Bigger companies have lesser pressure to ship things too early and have slower (larger) time scales for product release cycles. Both in enterprise space or in consumer space, smaller companies are on a much more rushed timeline, for varied reasons including but not limited to financial situation of the company. Bigger companies can afford to build more slowly. This affects how the company plans and executes as well as rewards performance. In a smaller company, when a complex thing has to be shipped on a shorter time scale, a lot of divide and conquer and quick coordination across large number of contributors is required. This is a necessity. In a larger company, deep complex things are built by very small teams or just individuals over a relatively prolonged time. Individual engineers prefer to keep chiseling away at a particular problem until they can showcase a significant impact with high difficulty/complexity of the problem/solution. That's the consequence of individualistic performance measurement culture. Both cultures have pros/cons and there are rotten extremes in both.

shepherdjerred 5y ago

I had the same experience at AWS. A team of siloed engineers working on projects for the same product, with very little collaboration. Projects were tracked in spreadsheets. Time estimates were created out of thin air to meet the desired (impossible) deadline.

dboreham 5y ago
This kind of mass delusion has been pretty much de rigueur my entire career (decades): Software is typically quite hard and mostly unknown at the beginning of a project. Most of the hard work is figuring out the things that weren't known. It's a learning/discovery experience. It's essentially impossible to predict how long that activity will take. The further out in time you consider, the less likely you'll have much of any clue about the subtasks to be done. And of course in the meantime the participants likely aren't even working close to 50% of their time on the new project -- instead they're fixing the bugs and technical debt in the last project. And yet, the "stakeholders" simply wouldn't accept any narrative like the real one (we kind of have an idea how to do this but we're going to figure it out as we go and it'll be difficult and unpredictable). They'd go hire another bunch of folks who are willing to salute the flag. So instead we pretend that what we're doing is predicable and plannable, like building a bridge that's a bit longer or shorter than the last 10 bridges that we built. The stakeholders probably have a pretty good idea that the developers are making it up as they go. But everyone behaves as if the reactor isn't on fire.
- kragen 5y ago
  Have you spent the decades of your career working at companies that blew their competition out of the water with better software, like Google, Apple, WhatsApp, and Facebook, or at companies whose software was unremarkable or inferior? If it's been some of both, did you note a difference in the degree to which stakeholders grappled with the kind of uncertainty you're talking about?

modeless 5y ago

> Whatever you say about JIRA, it can handle complex projects way better than a spreadsheet. Frankly I have had a much better experience on teams that tracked work in spreadsheets than teams that tracked work in JIRA. Like it's not even close.