The other perverse incentive is that you will end up with engineers trying to extract as much value from other engineers as possible, because it becomes part of leveling up: how much you make other people deliver. Even as an IC.
The other problem is that it becomes this game where nobody dares giving bad feedback to one another, because you know they could retaliate which could damage your chances to get a promotion. Everybody becomes "fake friend".
The "nobody dares giving bad feedback" thing isn't about retaliation (though I suppose that could happen). It's because perf is actually the worst place to provide "honest" feedback to a person about their performance.
It's complaining to managers/directors instead of talking to the person themselves (the recipient wont get to read your feedback for a couple months after). Even if you want to talk to a manager about some performance concerns, you should do that directly, instead of putting it in a record that sticks around for a persons whole employment
It's a bureaucracy game, and people who give bad feedback don't know how to play.
(I'm not endorsing the system at all, just rejecting the idea of it being retaliation-based. Anybody giving bad feedback doesn't understand what is going on)
I worked at a place that did perf reviews every 6 months. 360 degree style, where you got manager feedback and a bunch of peers that you nominated. None of the feedback I received was ever actionable or useful. None of the feedback I gave was ever really useful, either! People rated you on a bunch of silly, vaguely described sliding scales from 1 to 5, then answered a couple of equally vague questions. It probably distracted people for 3 or 4 days, every 6 months.
All I ever got was stuff like "Joe writes excellent design documents! His code is always well tested. I always want Joe on my projects!" I'd write stuff like "Amy is extremely effective at solving problems with <blah> API's, and is a great communicator. She should do a brown bag session about her experience with <blah>." The reviews were all fluff. Some people wouldn't put in any effort at all, and write one liners. Seriously, one of my reviews was "Just keep on being Joe!" Thanks, but why bother?
The review process at most companies is a big waste of time and money.
It really depends on the corporate culture. The last review heavy place would put an overly positive spin on everything. In one review I wrote, I could've said "Jack's project has been taking an excessively long time to complete. He needs to work on delivering changes incrementally", instead I spin it as "I'm really looking forward to the delivery of Jack's work on X! He's been working on <initiative> since the last review cycle. It will be exciting when it is finally completed."
Leave it up to the manager to interpret and read between the lines. At the end of the day, the better managers know it's all bullshit anyway.
It seems that just about anything else devolves into an ontological mess of Byzantine proportions. At one stage in my career I was reporting to 4 different bosses in this weird interleaved hypercube topology. I spent most of my time giving status updates
I do think more democratic, less hierarchical systems can work well if they're implemented in the right way. I saw a shift from that, where it was functioning well, to something more hierarchical and everything play out as this blog post is criticizing. It became really clear very quickly how aims shifted from more institutional mission-statement-type goals to promotion criteria and personal power agendas.
There's a limit I guess, but sometimes having multiple people to report to can lead to checks and balances.
I once had a similar situation and seriously contemplated building an application to manage my status updates so I could enter the raw data once and have all N people who needed to be updated sent the right information in the right way at the right time....
At least for performance reviews it's so much easier. If your boss hates you for some reason, that sucks, but you can just move on. It's a lot simpler than trying to please a dozen different people simultaneously though.
I have a scrum master, a product owner, a tech lead, and a team manager. All four of those are management relationships, but only 1.5 are hierarchal (the manager and sort of the tech lead). The most effective and efficient relationships we have, IMO, are with the scrum master and product owner, who aren't above us in a hierarchy.
There's no inherent reason for management to be hierarchically superior. If you want productive relationships, you have to level the power dynamic more.
Seems like if your boss is a receptacle for status updates, the company is doing management wrong. Sure, it works less bad with one, but that doesn't mean it's good.
Phwewww... this blog post and all these comments ring so true to me way outside of contexts resembling software development or business that it seems to me it's getting at something very fundamental.
A corollary to this in my opinion is that if promotion is expected at some point, I think the business/organization/institution has a responsibility to try to facilitate people moving toward that through mentoring or at least clear expectations. If nothing else, it makes the expectations clear, which clarifies how those might be at odds with other goals such as what the blog poster is articulating.
> The other perverse incentive is that you will end up with engineers trying to extract as much value from other engineers as possible, because it becomes part of leveling up: how much you make other people deliver. Even as an IC.
Raising up and increasing the productivity of your peers sounds like a good thing. I think I'm missing how this is a bad outcome due to a perverse incentive. Are you saying the value extracted from peers is not real value or that the focus on your raising your peers detracts from more important business goals?
> the focus on your raising your peers detracts from more important business goals?
It's this. Actually doing work is seen as simple and unworthy of a higher-level engineer.
Good engineers focused on problems (fixing complex bugs in distributed systems, adding fallbacks and failovers, improving the UI or performance of internal tools, etc) can add significant value to the company...but they won't be rewarded for it, because the perf process considers those to be simple, the domain of lower-level employees.
What the process _does_ reward is whitepapers, tech talks, daily updates, and delegation. It sometimes felt like the goal was to make every little change as noisy as possible: if you just fix something yourself, you get no points. If you plan it out, generate whitepapers, announce it, convince other people to work on it, send daily updates to every possible stakeholder and then a triumphant announcement, and then do a round of tech talks on every piece of it, you're a shoo-in for promo--whether on not the 'it' was actually important or valuable to the company.
Of course, people with those planning and communication skills are really valuable to a company. But somebody also has to do the work. Forcing _everybody_ to follow the one path to progress means a lot of noise. A lot of tech talks from people who have no real interest or talent for giving them, on topics that nobody is particularly interested in, just for the sake of a line on their promo packet. And a lot of effective engineers getting frustrated and quitting because they don't want to spend their days working on slide shows.
It feels to me like the people in charge of the perf process just tend to overemphasize their own strengths and skills. Kinda by definition, the people designing the system are going to be senior people who are interested in communication and process, so that's what they look for in others. If they were the kinds of people who were interested in identifying and solving particularly devious or consequential issues on their own (or as part of one of their peer's projects), they wouldn't be working on the promo process in the first place.
> What the process _does_ reward is whitepapers, tech talks, daily updates, and delegation. It sometimes felt like the goal was to make every little change as noisy as possible: if you just fix something yourself, you get no points. If you plan it out, generate whitepapers, announce it, convince other people to work on it, send daily updates to every possible stakeholder and then a triumphant announcement, and then do a round of tech talks on every piece of it, you're a shoo-in for promo--whether on not the 'it' was actually important or valuable to the company.
This is absolutely my experience at Google. If you want to move up quickly you have to write docs to convince people to work on your ideas.
> Forcing _everybody_ to follow the one path to progress means a lot of noise. A lot of tech talks from people who have no real interest or talent for giving them, on topics that nobody is particularly interested in, just for the sake of a line on their promo packet.
This doesn't really align with my experience. Most people I interact with at Google do not try to do this. They are happy being ICs at L4 or L5 doing their own thing. There is plenty of room to be an L5 or even L6 IC without constantly self promoting, it will just take you much longer to get there and you will never move past L6.
Well TBF, I was an SRE while at Google, so I worked with a whole bunch of other teams. And tech talks were considered a good way for SREs to familiarize themselves with partner teams' various systems. So my calendar had several weekly meetings for tech talks and other presentations...and they were usually pretty yawn-inducing. And at the same time, I felt a fair bit of pressure to prepare talks about my various projects and present them: it would help to spread my knowledge and (ahem) raise my visibility. But they weren't interesting projects, and I was not interested in making presentations about them (or in general).
You described many of reasons I left a previous company. As one of the higher level engineers, I was constantly writing "tech specs", reviewing tech specs, doing code reviews (one week I had 12), and forced to present slide decks full of fluff against my will. Usually I'd push the slide shows off for a few weeks, but eventually I'd run out of excuses. Occasionally, I'd get to do some real work, but it mostly involved refactoring an almost decade old smoldering dumpster fire, so I left.
Yep. The truth is, most of the work we do isn't that important, interesting, or useful, so the pomp and circumstance is necessary to raise its "visibility." Truly sad.
Your peers are rewarded for accomplishing their goals. In the best-case scenario, the incentive is to find ways to synergize your goals so you are all benefitting.
In the common-case scenario, you figure out how to bribe / cajole / coerce them into putting time in on your project and don't really care about how things are going on their project, because we're all responsible engineers who can time-manage ourselves, right? So you get your promotion and they get screwed because the work they did to deliver on something valuable to the company isn't reflected in their OKRs.
It degenerates what should be a collective goal of accomplishing the company's objectives the best way possible into a slotting game of making sure you're always listed on paper as being on the right project, because your work won't have value if you applied it outside your bullpen.
> The other problem is that it becomes this game where nobody dares giving bad feedback to one another, because you know they could retaliate which could damage your chances to get a promotion.
It's good to have people who understand the difference between the prisoners' dilemma and the iterated prisoners' dilemma.
The whole point of a tech company is to pay engineers $X and find a way for them to create some over-unity multiple of $X in value.
If the problem is “this incentivizes engineers to make each other deliver more value”, that sounds like not a problem (and opens everyone up for increasing $X).
It’s a problem when you start to see your fellow employees as the competition instead of your actual competitors being the competition.
It's a problem for people who value working on things that actually get used for more than a few years and aren't duplicate efforts to make some line on some graph go up somewhere.
These are of course people, after all. Not robots.
The other problem is that it becomes this game where nobody dares giving bad feedback to one another, because you know they could retaliate which could damage your chances to get a promotion. Everybody becomes "fake friend".