Some personal thoughts here:

• I think having some kind of cycle is important, and would want to have one eventually. I was very frustrated in 2008 because there was no feedback cycle and my role had grown substantially after being hired without a corresponding growth in compensation. Although employees respond to things differently, I'd selfishly like to believe that I'm a desirable hire and we'd want to be able to capture and retain similar hires. Iain Proctor published a note recently which touched on some of this, but a point for me here is that responsibility is rewarding when you have none of it but punishing when you have too much of it, and you can't reward the upper end of employees by just giving them more responsibility. There is also probably little need for the organization to mete out responsibility explicitly -- at least at Facebook, I didn't have any issues grabbing more than I wanted (and I think the processes which lead to this are mostly desirable). Overall, I'd like compensation to be just, to generally reflect impact, and I think it's hurtful to downplay its importance relative to types of rewards (social/recognition/responsibility). These types rewards are often important for new hires but were not important at all to me after a few months. All else being equal, I'd rather the process cater to the most valuable employees than to the newest ones: I think a lot of the new-hire stuff can be dealt with far better with real mentoring/leadership, and Facebook just didn't really have these processes in place. If another process dealt with making new hires feel comfortable and confident and empowered, the review process could focus more on the long term.
• I think the feedback cycle should be as short as possible. Facebook's felt way way too long.
• I think it's important that the cycle be predictable. I had no clue what my rating was going to be most of the time, and my managers empirically did not either.
• If we do everything my way we'd probably end up with a nonsense process that chopped the legs off the organization so we shouldn't listen to me too much. A lot of this is really reactionary to the way Facebook did things; it's generally difficult for me to think about this unemotionally. My gut reaction on most of these issue is to just do it the opposite of Facebook.

An idea which came up off thread which I think might merit further exploration is the idea of targeting feedback at systems instead of individuals. That is, in many cases I think a piece of feedback is sort of fundamentally related to a system (I want to use X to block spam in my new product Y), but ends up targeted to an individual (when I asked Z for help with X, he was a total jerk). This feedback mostly has to be private or often isn't shared since it's laden with social weight. Additionally, it's not necessarily very good, since there could be plenty of good reasons that the experience wasn't good (e.g., the project could be understaffed or mismanaged or the root issue lies elsewhere or whatever else).

If we tried to reframe this feedback as feedback about systems instead of feedback about individuals, it might be more useful, easier to make public, easier to act on immediately, and less judgey/venty/blamey. Roughly, instead of sending feedback about "user Z", you'd be writing something more like a Yelp review of "system X". I could see this having a very short review cycle, like a weekly meeting where a group of managers look over all the system feedback for stuff they control and talk about how to deal with it.

This system could then tie back to individuals, but ideally that part would be handled by managers, whose function aligns more closely with this anyway and who ideally have a much better sense of the root cause of an issue. This would also tend to make managers accountable: if your systems are having a lot of issues and you aren't being effective in fixing them, that signal can be fairly public.

Formalizing "responsibility" could also help line up incentives: if you aren't claiming responsibility for any systems, it's more clear that you aren't doing work. If you're responsible for a lot of stuff, you deal with the feedback on it too (but it would also be more clear that you have wider exposure).

Broadly, the idea here is just to use "systems" as an indirection layer so we can get all of the benefits of public/transparent feedback without all the personal costs.

To work, this would have to effectively sever the "incident <-> system <-> individuals" connections -- i.e., if system feedback is just "Z was a jerk", that's not good. But I think soft hinting could deal with this pretty well. Real private issues would remain private anyway, this could just deal with the large middle ground of ultimately-system-level issues, and frame all of this feedback in terms of concrete things.

I could also imagine doing system feedback at an arbitrarily small company size. It would be pretty silly for Bob to have a 1-on-1 focal review with Chad, but we could easily leave system feedback on something like Celerity, "this is slow and I hate running it all the time" or whatever. I'm mostly responsible for this system, but this feedback is totally impersonal and would be really useful to me, since it would help me prioritize that system relative to other systems.

That idea seems more broadly inline with our goal of helping people build better software. Reviewing the project/launches seems useful/actionable than direct individual review.

As for individual review, I'd rather have some things built into reporting/fact that help managers make more informed decisions, like who is employee x working with, how many tasks did the close, what documentation did they write, which people should I ask for them to review, etc.

Yeah, I think framing things in terms of systems has a lot of alignment with the rest of the suite.

We can definitely do integration stuff with other tools too -- I think there's significant value there, we just need to balance it against going too far with something like Hall of Heroes.

I have lots of ideas here. :)

First, I would describe most existing performance review cycles as not doing enough in a timely fashion, then playing lots of catchup collecting feedback, then trying to normalize that feedback across the organization, then doling out changes in compensation and expectations. Instead, the feedback should be ongoing, the normalization should be ongoing, and changes in compensation and expectations should happen as soon as they make sense.

I'd love to see something like (this is a mix of tooling and process)

• cultural emphasis on direct feedback - something go well? say it. something could go better? say it. More practically, any onboarding process would just drill in this point and the first training the company ever offers would be on these skills.
• public levels - shared, company-wide expectations on what a given employee should be like in a given role. The "con" here is that high level folks may push around low level folks accidentally; I think that's addressable and needs to be addressed anyway given some people tend to push other people around regardless of level, and worth addressing given the gains of shared expectations
• weekly 1:1s - I think weekly 1:1s are the bare minimum management process that must occur. The tooling here would be minimally letting manager rate employee as "awesome", "okay", "needs improvement", and the employee would similar rate the manager, each and every week. Manager's and employees should be working to get reciprocal "awesome" to each other. Maximally, the tooling would include functionality to set weekly goals, linking directly to pertinent task and other objects.
• applications to be promoted - For an organization like Facebook, these applications can happen twice a year for every employee. For some unknown organization, when an employee and manager think the employee should be promoted, they "apply", which includes collecting some additional, written peer feedback directly on whether they should go from X-1 to X, a personal and manager essay addressing the same, and massaging their employee timeline a bit (see next item). A challenge in a business when changing compensation is you might not be able to actually pay people more. ergo, the company could have a model where they announce they have N slots of level X and level X-1 folks are encouraged to apply. The weekly 1:1 tool could prompt if the "awesome" thing is happening often that the person should be looking to apply to the next level. I think applying to be promoted is pretty important to prevent never-ending increases in responsibility. I think it also address a problem where you have great employees doing great work who aren't interested in the career crap anymore but are forced to do that anyway, eventually driving them to a company where they can "just work",
• employee timeline - sort of like Facebook timeline, but it should be of their "major work achievements", plus have the existing feed logs like we do today. managers should also be able to cultivate their employee's timelines. This should be the bulk of the promotion application.
• thanks tool - actually somewhat worthless data signal at scale, but great for motivation.
• system feedback - you need the concept of 'owners' for systems, as well as making sure legacy owners versus newer owners are getting the proper attribution of credit here. feedback is "awesome", "okay", "needs improvement" with a text box.
• regular switching of manager <--> employee relationships - this helps normalize all those "awesome", "okay", "needs improvement" data AND you get some very interesting data when / if people don't want to switch
• upper management has a huge emphasis on normalization - any manager of managers should be looking at all of the above for their people and making sure it makes sense. in particular, people getting "awesome" a bunch or "needs improvement" a bunch need to be understood as correctly scored relative to the expectations for their level, and people in the "normal" bucket repeatedly indicate the manager might need some help doing a better job.
• a compensation and expectation structure that rewards advancement more than being "awesome" at current level - I've seen bugs where level x-2 can get a bigger bonus than level x...
• project post mortems - when a team does something big, they should take a moment to give each other feedback and think about what went well and what could go better for next time. any systems produced or updated could also have their "system feedback" button glow green or whatever for a bit to get more input.
• performance improvement plans - if / when an employee isn't working out, a formal plan to improve that is about ~4+ weeks should be created (with the help of upper management). said plan should put the employee permanently on a path to succeed. This should basically just be using the full powers of the 1:1 tool above.

All of this is not particular immune to politics, really relies on upper management to have a large focus on this, and probably isn't complete since its such a big hairy beast ultimately. Thoughts?

That stuff pretty much all makes sense to me.

On post mortems, I think one particular failing that Facebook had was a culture which had a very hard time assessing both what went well and what went poorly with completed projects: there was a tendency to just celebrate everything, even if it hadn't been executed all that well and there (presumably) was a lot that could have been learned from it and avoided the next time. This runs into critical-feedback-about-individuals-is-mean a bit, but I think we can generally mitigate that through systematic reframing of feedback as against systems rather than individuals/teams, where possible.

I'm probably a little less sold on the value of the Thanks tool than you are, but I think we talked about that briefly elsewhere and your experience was that it was more valuable outside of engineering? Correct me if I'm misremembering.

Generally, on the "relies on upper management" issue, when designing tooling I think we have to assume that management is focused on this and highly competent, and let the tools degrade in other cases. If management isn't quite on the ball or doesn't think this is especially important (maybe with good reason), or just disagrees with us about how to do things, the tooling can just degrade to 6-month top-down reviews or whatever -- all we can do is try to make the tooling support more transparency, shorter feedback cycles, etc., and encourage these practices and explain why they're valuable and what the advantages are. 6-month top-down reviews in Phabricator are still probably slightly better than the same reviews in another tool, since they'll benefit from integration/consistency/cohesion if nothing else.

I think post mortems / feedback sessions can go pretty well with the right leader -- its hard but its possible to keep people focused on constructive feedback and influence the shared attitude towards one of learning / growth and not blaming / punishment. I agree our previous employer had a tendency to just celebrate everything, and I'd add that there was a positive outlook on many projects / teams I personally would have killed many moons prior. Oh well. :D

Yeah, that's about right on the Thanks tool.

The longer version is that it can be useful at a glance if you have regularly occurring events that are done by different people, thus allowing "apples to apples" comparisons, but otherwise suffers from easy political gaming and "democratization" of what's important / valuable.

For an example where it works well, suppose the team meeting is run by a different team member each week *and* you are supposed to thank the person if they did a good job. Management / the individual can at least get a comparative sense of how they perform this task relative to their peers. At Facebook, I saw quite a few teams / groups that incorporated thanks into their workflows like this such that you could get some reasonable signal without diving into the substance.

For an example where it works poorly, imagine the difference in thanks one could get simply by ending a presentation with a slide "if you liked this, give me thanks <here>" versus not doing that. As another example, consider the amounts of thanks you might get for adding dancing dinosaurs to the end of a work queue vs making static resources faster on the production site or the dancing dinosaurs on a widely-used, unimportant tool versus a business critical one used by few.

All that said, I think it is always motivating - everyone likes to be thanked for something they did by a peer, even if an individual thinks what they did is a wee bit trivial.