"if you are constantly pushing your engineers for increased productivity, the really important innovations around automation, experiments, and research won’t ever happen. Or said more plainly, your team will never automate the boring stuff."
I had the same discussion with my cofounder CTO regarding the last part. It was almost a decision to have a team structure like Google Brain team and Google production team.
I also feel some people like to be bored - these are explorers , the researchers. Who can get you 100x step changes - the macro people
Others need constant action. Something to write, deploy- these are super important when dealing with live clients and solving their problems.
Also, just to add I have huge respect for people who can get bored and still keep pushing. For me, Many ways that is the definition of commitment.
Thanks for the comment! And great thoughts. It's definitely a balancing act which is why I like the 80/20 rule for it: only 20% boredom is not actually alot and leaves plenty of room to still get all the normal stuff done.
And I guess, like with any other esoteric "principle", there's alot of room for flexibility in that model. Some people, like you said, may need more structure. Or less structure. It really depends on the person. But the ideal stands strong: teams that are pushed to 100% at all times will burn out and will find themselves in a cycle of never creating flexibility in their automation, research, and innovation.
I'd call that 20% 'boredom' time 'slack'. You need to have slack in any system. If it's a slow week your engineers will improve the CI pipeline, increase test coverage, or maybe if they're 10x ninjas, write the first lines of a successful spinoff. If shit hits the fan, there's capacity to clean it up while still not falling significantly behind on the normal stuff. And some weeks the engineer will spend Friday rollerskating with their daughter, so fucking what, better than to burn him out.
I just got sick of doing the same error-prone thing over and over again. I'd work hours and well into the night automating something I could do in about a half hour or so. Now, after creating a program, the task was done in under a minute with no "oops"-like errors in the process. I created enough free time doing these things that I was able to spend most of my time on innovations or explorations of other ideas rather than normal work. I never saw boredom result in innovation. Rather, the innovation came from deciding to solve a repeating problem.
My secret to helping my teams innovate was simply to give them the time they needed to complete a project, not just an arbitrary deadline because someone thought they could get it all done in that time. The secret to getting the right amount of time was looking at how long similar projects took in the past and using the average time to completion. This worked well in organizations that consistently delivered software-intensive systems that were late and buggy (so, this is an intervention technique I later used as a consultant).
I knew I had a doable amount of time when everyone howled about why it would now take so much time to do a project, and the time I had chosen was nothing more than how long it had always taken (think about that—they didn't actually know how long things took to get done even though they lived through it for years).
The real surprise was not that we delivered on time, often for the first time in anyone's memory, but that the quality of the delivery was dramatically better (I'll point to Benson's Bylaw; look it up on pmtoolsthatwork dot com). Getting to that dramatic increase in quality was usually in large part because the engineers had time to innovate and be more productive.
Good article, and thanks for allowing me to reminisce.
Great article and great timing for me read this
"if you are constantly pushing your engineers for increased productivity, the really important innovations around automation, experiments, and research won’t ever happen. Or said more plainly, your team will never automate the boring stuff."
I had the same discussion with my cofounder CTO regarding the last part. It was almost a decision to have a team structure like Google Brain team and Google production team.
I also feel some people like to be bored - these are explorers , the researchers. Who can get you 100x step changes - the macro people
Others need constant action. Something to write, deploy- these are super important when dealing with live clients and solving their problems.
Also, just to add I have huge respect for people who can get bored and still keep pushing. For me, Many ways that is the definition of commitment.
Would love your thoughts?
Thanks
Thanks for the comment! And great thoughts. It's definitely a balancing act which is why I like the 80/20 rule for it: only 20% boredom is not actually alot and leaves plenty of room to still get all the normal stuff done.
And I guess, like with any other esoteric "principle", there's alot of room for flexibility in that model. Some people, like you said, may need more structure. Or less structure. It really depends on the person. But the ideal stands strong: teams that are pushed to 100% at all times will burn out and will find themselves in a cycle of never creating flexibility in their automation, research, and innovation.
I'd call that 20% 'boredom' time 'slack'. You need to have slack in any system. If it's a slow week your engineers will improve the CI pipeline, increase test coverage, or maybe if they're 10x ninjas, write the first lines of a successful spinoff. If shit hits the fan, there's capacity to clean it up while still not falling significantly behind on the normal stuff. And some weeks the engineer will spend Friday rollerskating with their daughter, so fucking what, better than to burn him out.
I just got sick of doing the same error-prone thing over and over again. I'd work hours and well into the night automating something I could do in about a half hour or so. Now, after creating a program, the task was done in under a minute with no "oops"-like errors in the process. I created enough free time doing these things that I was able to spend most of my time on innovations or explorations of other ideas rather than normal work. I never saw boredom result in innovation. Rather, the innovation came from deciding to solve a repeating problem.
My secret to helping my teams innovate was simply to give them the time they needed to complete a project, not just an arbitrary deadline because someone thought they could get it all done in that time. The secret to getting the right amount of time was looking at how long similar projects took in the past and using the average time to completion. This worked well in organizations that consistently delivered software-intensive systems that were late and buggy (so, this is an intervention technique I later used as a consultant).
I knew I had a doable amount of time when everyone howled about why it would now take so much time to do a project, and the time I had chosen was nothing more than how long it had always taken (think about that—they didn't actually know how long things took to get done even though they lived through it for years).
The real surprise was not that we delivered on time, often for the first time in anyone's memory, but that the quality of the delivery was dramatically better (I'll point to Benson's Bylaw; look it up on pmtoolsthatwork dot com). Getting to that dramatic increase in quality was usually in large part because the engineers had time to innovate and be more productive.
Good article, and thanks for allowing me to reminisce.