6 ms·
I used to manage engineers at another large tech company and this was a big problem. There was nowhere near enough big projects to get everyone the evidence the
by leros 4y ago
I used to manage engineers at another large tech company and this was a big problem. There was nowhere near enough big projects to get everyone the evidence they needed for promotions.
As a result we ended up doing two things a lot:
1) over-engineering a feature that should be simple into something with architectural significance (e.g. a new set of services that could have just been a feature in an existing service)
2) de-prioritizing important things that were small in order to ensure everyone had a big project every quarter.
We ended up having to hire contractors to work on the small stuff because it was piling up and causing problems.
- UncleMeat 4y ago> 1) over-engineering a feature that should be simple into something with architectural significance (e.g. a new set of services that could have just been a feature in an existing service) Ideally this gets people fired, not promoted. Google explicitly calls out "solutions to hard problems are easy to maintain" on its ladder, for example. People can fail to identify these cases, but the intention is to promote based on hard problems rather than complex solutions.
- meowtimemania 4y agoI think there just aren’t enough reasonably solvable hard problems. All the low hanging fruit is taken, and the result is artificially complex solutions as a way for engineers to demonstrate craftsmanship.
- bluGill 4y agoDo they consider fixing easy bugs are hard problem? Should someone ignore a bug report "The is not spelled teh?" until it has bounced around unsolved for months on end, then spend 2 weeks "investigating" to show that it is a hard bug? I've seen real bugs that bounce around for months, each time to someone who looks decides it isn't in their code and points to someone else: eventually we tell one engineer to solve it an a few weeks latter she traces it down through many different layers to figure it out. I've seen other cases where a great engineer spent weeks fixing bugs only slightly more complex a misspelling. In the end what counts it the quality of the product not the effort put into it.
- joshuamorton 4y agoNo, this wouldn't get someone promoted, because it doesn't actually solve the problem. The problem here is that the triage process is a mess. Fixing that, so that bugs don't bounce around for months, would probably get someone promoted, or at least be a significant factor.
- xmprt 4y agoWhat if the solution to that hard problem is improving the incentive structure and paying/promoting people for fixing bugs? That's something only ELT or SVPs can do and they aren't getting promoted for that.
- joshuamorton 4y agoIf you think the problem can only be solved by management attention, and you cannot demonstrate to your management that the problem is impactful enough that it deserves their attention, either you are incapable of making a clear enough argument to focus on the right problem, or the problem isn't actually as dire as you think it is (or management is bad and wrong, or at the very least mismatches your values). Two of these are a signal that perhaps you shouldn't be promoted. The third is a signal that you should leave. In a less generic sense, I think that there are almost always ways to improve incentive structures and encourage people to focus on specific problems that don't directly involve SVPs. Your manager has some control over your rating. If you can argue that "customer happiness" should be a priority and as part of that, end to end bug triage time will impact ratings, you have successfully created an incentive structure that will reward that, without involving anyone who can modify compensation structure.
- bluGill 4y agoMany outsiders have noted that googles incentive structure is not around customer happiness in general. Thus articles and discussions like this one.
- 4y ago
- xmprt 4y agoIt's all about how you twist it. If you say "I built 2 new services that could have just been a feature in an existing service" then you'll probably get a bad review. However, if you give a reason for building the 2 new services (eg. more extensibility, enables a new flow, easier to use for other teams) then all of a sudden the complexity is justified and you'll appear to have solved a hard problem. No one is going to look super deeply and ask if those reasons are valid and if you even need the extra extensibility or if other teams will use the service.
- jstanley 4y ago> There was nowhere near enough big projects to get everyone the evidence they needed for promotions. Would the goal be to promote everyone? Who's going to do the work they all used to do?
- leros 4y agoIt's a retention issue. If people don't level up fast enough and get raises they'll leave for another company.
- _j5l3 4y agoAt Google at least, if you stay low level for too long, you get fired. If your team is full of low level people maintaining a project that's stable, you need to invent work to justify your existence.
- ceras 4y agoYou only need one promotion, L3 (entry level) to L4 (mid level), to not get fired at Google. And the company is quite generous with how long it gives you to get there. L3 to L4 is basically about writing good code on your own, and isn't really affected by promo culture -- doesn't really need shiny work. Several years back, you had to also eventually get to L5. This was more affected by promo culture, but was also largely unenforced, which is why they get rid of the formal requirement to get to L5.
- 4y ago
- riku_iki 4y agoIt sounds you had bottleneck in product management pipeline. Product managers should generate enough creative and significant features to justify stream of large projects.