As we were gearing up for the launch of Google One, we had a set of 40 bugs which we called "paper cuts". It was an animation firing off the wrong way, a formatting error in the email, things like that. Nothing that would be a [[Jason's razor|launch blocker]] by its own, but altogether left the user a little bit jarred - not screaming [[Quality]], which is what we wanted to project. In the weeks leading to the launch, we were juggling the paper cuts together with bigger scopes that actually were launch blockers (e.g. GDPR compliance). Eng and program management were pushing me (the PM) to just "let go" and accept the paper cuts. I felt like I had accountability for the ultimate outcome. At some point, this discussion became abstract. We talked about "the 40 bugs", I was asked to stack rank them, and we were negotiating, in abstract, on how many of them is reasonable to get to. And we were going absolutely nowhere (except for a "throw down" meeting with our VP). ![[Throwdown.png]] *The throw down meeting we were able to avoid. Credit: Google AI Studio* In preparation for our "throw down" meeting, we were sitting down with an engineering leader whom we'll call Ron, who was out of the loop until that point. Much to my (and the program manager's) shock, Ron said: "wait, can someone project the bug list". He then proceeded to go one-by-one over the bugs: * Some were already fixed * Some were going to be fixed by another change we were about to do days into the launch * Some were trivial to fix * Some would be hit for a small fraction of users He *knew* all of this off the top of his head. By the end of Ron's culling, we were down to 5-10 bugs. And those were things we could easily negotiate. We cancelled the throw down meeting. --- ### Whiteboxing In software testing, you can do a "black box test", where you don't care about the internals of the component at all, just the surface behavior, or a "white box test", where you know about the internals and test internal components. ![[Blackbox and Whitebox.png]] The rest of us were Blackbox'ing the 40 bugs and running around in loops. We thought it would be too time consuming to go through them one by one. Ron mercifully Whitebox'ed the situation. ### Walking the floor The managerial instinct of when to Whitebox is critical: * If you only whitebox, you waste your time micromanaging or [heroing](https://builtin.com/software-engineering-perspectives/engineering-team-heroing). * If you [[ZIRP Management is what preceded Founder Mode|ZIRP manage]] and only blackbox, you reach situations like this. The same concept was familiar to factory managers. Toyota Lean Manufacturing had the concept of "genchi gonbutsu", or managers generally talk about "walking the floor" or MBWA (management by walking around). Giving up on whiteboxing due to time hurts both your craft and your ability to supervise and make good decisions. Walk the floor. #published 2025-01-12