You’re still here! Welcome! At this point you know what you’re here for, so let’s dive right in to...
When we first went over the Engineering Values Handbook as a team, we ended up in a multi-day all-hands chat thread digging into this specific value. It turned out that we were all pretty aligned on "loosely held,” but we had many different interpretations of "strong ideas"! Was it about strong advocacy, ensuring ideas get fair hearings? Brave proposals that challenge conventional wisdom? Thoughtful proposals that avoid being hot takes? This section of the handbook gave us an opportunity to get into that kind of nuance.
We believe good ideas can come from anyone regardless of their title, seniority, or discipline.
- We strive for an egalitarian feel in all interactions.
- We seek to provide each other psychological safety. We recognize the near-universality of imposter syndrome and try to build each other up, freely showing respect and admiration while taking great care with the tone and context of criticism.
- We try to visibly show respect to everyone by default, even and especially when we haven’t worked with them yet. This is particularly critical to provide psychological safety to new hires who haven’t yet established institutional credibility.
- During debate and decision making, we try to separate ideas from who proposed them.
| “About a year ago, I moved from gameplay engineering to graphics, and soon after got to work on my first significant feature planning work. As I talked through the problem space with my mentor, Mark Davis, a principal graphics engineer with over twenty years of experience, I was struck by how much it was just two graphics engineers problem-solving together. It was completely clear I had equal footing in the discussion as we went back and forth on potential solutions and complications, and never felt afraid to challenge ideas or put them forth. I've continuously felt like I'm a full-fledged member of any discussion and my input is valued and meaningful, whether it's with Mark, the Graphics team, other engineers, or Bungie as a whole. As an early-in-career engineer in a new discipline, I've grown into my new role and learned so much from being empowered like this, and it's made for a deeply fulfilling and fun experience.” Abby Welsh, 2020- |
We're brave enough to be seen being wrong.
- Being seen being wrong can be scary, but it’s critical to our success. If we let our fear discourage us, we sacrifice opportunities for creativity and growth.
- Being seen being wrong should never be a traumatic experience. You should feel welcomed and supported by the team. Our work to maintain psychological safety is critical here (see section above)—we’re creating a place where you don’t have to "toughen up” to feel safe being wrong.
- We're brave enough to make proposals to help move a plan forward even when our chances of being wrong are high—we don't hang back waiting to be 100% certain that we will look smart with our suggestion.
- We're brave enough to see our ideas challenged without feeling personally attacked—we try to remember that we are respected regardless.
- We're brave enough to raise concerns or ideas even when we aren’t an expert or we’re raising them to someone more senior.
- We're brave enough to share our ideas early, seeking upgrades from others and avoiding polishing our ideas alone for grand reveals that take others unawares.
| “In the development of the new engine model, the Activity Scripting team was revamping how and where activity scripts executed within the server ecosystem. Distributing them amongst various agents within the ecosystem allowed for more expressiveness, but it also created a synchronization beartrap for writing scripts that might deadlock or have unexpected behavior due to race conditions. To mitigate this possibility, I proposed a process of code-reviews for designer authored scripts similar to engineer code-reviews. This was not a practice that designers were experienced at and most folks who heard my pitch thought that we wouldn’t get broad buy-in. So instead, we pivoted the technical design to mitigate the risk with minimal loss of script expressiveness and didn’t adopt designer script-reviews at that time. Talking this over as a team helped us quickly identify that solving this challenge with ongoing human diligence wasn’t the right answer, even though it would have enabled an exciting technical solution.” Ed Kaiser, 2010- |
We believe that success is helping a group get to the best answer and leaving with stronger relationships.
- If you came up with the best answer but people aren't excited to work with you again, that's a failure.
- If you made a meeting or project 25% more efficient but people aren't excited to work with you again, that's a failure.
- If everyone is excited to work with you again but you didn't speak up about a major flaw or opportunity, that's a failure
| “For a while the Engineering org held regular leads meetings where managers and others in leadership positions would gather to talk about Important Stuff™. When I finally leveled up enough to be invited, it felt like I had made the big time. It was a great feeling of validation but also intimidating. I wasn’t sure if I had anything worthy to contribute in this room with Bungie’s best and brightest. When I eventually did gather up the nerve to chime in, I was pleasantly surprised that everyone took my comments as seriously as anyone else’s. I came to realize that this held true with everyone that joined the group. There was never one dominant opinion that overshadowed all others. All voices mattered all the time.” James Haywood, 2007- |
-Bungie Engineering
