3 ms·

High pay is great, but doesn't make better software. Do Googlers get time to fix things?

saalweachter 7y ago
I would say that Googlers can make time to fix things. In the parts of Google I've seen, engineers are largely given projects with a timeline of weeks or months and left to structure their time themselves. You're usually given more projects than can feasibly be accomplished in the time allotted, and learning which are high priority and which to let slide a quarter is a bit of an art, but as long as your projects are moving forward you can usually structure some time for paying down tech debt or a side project, either an official 20% or just experimenting with your area of responsibility outside any roadmaps. I tend to structure my weeks with Tuesday as the designated day to fix anything that's broken or, if everything is running smoothly, to pay down tech debt more for the opposite reason, so that I don't get caught in a rabbit-hole of fixing things that aren't broken and neglect to make progress on the new work.
jacques_chester 7y ago
According to the first of the SRE books, engineers working under the SRE banner are expected to devote approximately 50% to operational activities and 50% to engineering intended to make the other 50% easier. Given that the usual ration is 100% : -100%, 50:50 is going to be helpful in escaping capability traps.
- smueller1234 7y ago
  It's actually "at most 50% on toil". But of course it's also hard to measure exactly. It's more of a barrier that if we exceed it, the team probably needs serious help! Ultimately, Google engineers can move between teams pretty freely, so if we allow a team to descend into an operational or a deadline-induced death march, and we don't address that quickly, chances are the engineers will move to another team. It's sometimes frustrating not to have more control as a manager, but it's a very nicely self correcting mechanism and fixes various incentives for us managers. (I'm a manager in Google SRE. Not speaking for Google.)
  - jacques_chester 7y ago
    I like the idea of at least targeting a high fraction of total bandwidth for "making stuff better". My reference to "capability traps" wasn't accidental, it's a serious risk to any business where maintenance and improvement has low observability vs production outputs[0]. In that situation economists rightly predict that effort is skewed towards what can be observed more easily ("equal compensation principle")[1]. Under those conditions it's easier to fix a time-spent target and observe time allocated, even if only approximately. [0] https://web.mit.edu/nelsonr/www/Repenning%3DSterman_CMR_su01_.pdf https://web.mit.edu/nelsonr/www/Repenning%3DSterman_CMR_su01... [1] https://en.wikipedia.org/wiki/Principal%E2%80%93agent_problem#Contract_design https://en.wikipedia.org/wiki/Principal%E2%80%93agent_proble...

I would say that Googlers can make time to fix things. In the parts of Google I've seen, engineers are largely given projects with a timeline of weeks or months and left to structure their time themselves. You're usually given more projects than can feasibly be accomplished in the time allotted, and learning which are high priority and which to let slide a quarter is a bit of an art, but as long as your projects are moving forward you can usually structure some time for paying down tech debt or a side project, either an official 20% or just experimenting with your area of responsibility outside any roadmaps. I tend to structure my weeks with Tuesday as the designated day to fix anything that's broken or, if everything is running smoothly, to pay down tech debt more for the opposite reason, so that I don't get caught in a rabbit-hole of fixing things that aren't broken and neglect to make progress on the new work.

jacques_chester 7y ago

According to the first of the SRE books, engineers working under the SRE banner are expected to devote approximately 50% to operational activities and 50% to engineering intended to make the other 50% easier. Given that the usual ration is 100% : -100%, 50:50 is going to be helpful in escaping capability traps.

smueller1234 7y ago
It's actually "at most 50% on toil". But of course it's also hard to measure exactly. It's more of a barrier that if we exceed it, the team probably needs serious help! Ultimately, Google engineers can move between teams pretty freely, so if we allow a team to descend into an operational or a deadline-induced death march, and we don't address that quickly, chances are the engineers will move to another team. It's sometimes frustrating not to have more control as a manager, but it's a very nicely self correcting mechanism and fixes various incentives for us managers. (I'm a manager in Google SRE. Not speaking for Google.)
- jacques_chester 7y ago
  I like the idea of at least targeting a high fraction of total bandwidth for "making stuff better". My reference to "capability traps" wasn't accidental, it's a serious risk to any business where maintenance and improvement has low observability vs production outputs[0]. In that situation economists rightly predict that effort is skewed towards what can be observed more easily ("equal compensation principle")[1]. Under those conditions it's easier to fix a time-spent target and observe time allocated, even if only approximately. [0] https://web.mit.edu/nelsonr/www/Repenning%3DSterman_CMR_su01_.pdf https://web.mit.edu/nelsonr/www/Repenning%3DSterman_CMR_su01... [1] https://en.wikipedia.org/wiki/Principal%E2%80%93agent_problem#Contract_design https://en.wikipedia.org/wiki/Principal%E2%80%93agent_proble...