“Okay, so when you compile this, don’t forget to flip this switch, check if that config exists, and then make sure you have permission to build in that pipeline.”
“When running that test, keep mind you need to account for the mock stubs and the data might not line up as expected.”
“If you’re digging into that code branch, grab Jeff, he knows why he wrote it that way and issues there were with the API.”
“Yeah for those requirements you’re going to want to talk with the PM, there is a reason we can’t do that work for that customer, but we never wrote it down, so they keep asking for it.”
All that?
That’s “isms” and what we might define as our “culture” that exists within our collective heads and gets processed every time a new requirement comes in the door or a request to change some piece of an existing product.
That’s Headspace, and that’s taking up valuable energy of your team as they have to keep it straight in their mind and not forget it otherwise — “the world falls down”, “builds break”, “teams die”, etc, etc. The larger the amount of Headspace taken up by the issue, the bigger it gets in your team members' heads and the more “prolific” it becomes when discussing with others.
