Because of course it does. That said, here's some research you can show your boss.
Not sure where I found this (LMK if you shared it recently so I can credit you!), but Microsoft published a paper back in 2008 where they studied the launch of the Vista operating system and checked to see how "traditional" predictors of code quality compared to organizational metrics.
Code churn: code that changes a lot is more likely to be buggy
Code complexity: code that is more complex is more likely to be buggy
Pre-release bugs: bugs before launch predict bugs after launch
Dependencies: code that relies on other code is more likely to be buggy
Code coverage: code that is untested is more likely to be buggy
Organizational measures
Number of engineers: How many people people touched the code?
Number of ex-engineers: How many people who touched the code, and then left the company?
Edit frequency: What was the total number of times the code was edited? (seems pretty similar to code churn)
Depth of master ownership: How far down the organization is the owner of the code?
Number of orgs contributing: How many different (internal) organizations touched the code?
Percent of all engineers that contribute: How many engineers, out of the total number of engineers in the company, touched the code?
Percent of owning org that contributes: How much did the engineers in the "owning org" contribute to the code, compared to everyone else?
Turns out the organizational measures were better predictors of code quality than the traditional ones.
Which makes sense, especially if you've read the Team Diagnostics research by Ruth Wageman, J. Richard Hackman, and Erin Lehman.
They studied thousands of teams, and determined that there is a predictive relationship between six teaming conditions and the outcomes that the team is able to create. Better conditions, better outcomes.
Research says that you don't need to work harder. You don't need to create a new process. Improvements in these areas don't predict improvements in outcomes.
Instead, you just need to work on creating a real team, with the right people, and a compelling purpose. If you add good surrounding structure, supportive organizational context, and give the team coaching...that's even better, but not a requirement.
And if we overlay Microsoft's Organizational measures with the six team conditions...it makes sense why team stuff beats approach stuff when it comes to predicting team outcomes.
This development tool is designed to give change-agents inside organizations clarity into their path forward, help them define and deepen strengths, and maybe give us some shared language about what we do.
Challenges facing creativity; owning ideas from beginning to end; opinionated palettes; are we doing zines again?; randomness that didn’t fit in the first four categories
4 ways to use Pace Layers in strategy and OD work: 🚀 As a career planning tool; 🎓 As a strategy tool; 🔬 As a diagnostic or sense-making tool; 🎨 As a design tool for value-adding layers.
Not sure where I found this (LMK if you shared it recently so I can credit you!), but Microsoft published a paper back in 2008 where they studied the launch of the Vista operating system and checked to see how "traditional" predictors of code quality compared to organizational metrics.
Traditional measures
Organizational measures
Turns out the organizational measures were better predictors of code quality than the traditional ones.
Which makes sense, especially if you've read the Team Diagnostics research by Ruth Wageman, J. Richard Hackman, and Erin Lehman.
They studied thousands of teams, and determined that there is a predictive relationship between six teaming conditions and the outcomes that the team is able to create. Better conditions, better outcomes.
Research says that you don't need to work harder. You don't need to create a new process. Improvements in these areas don't predict improvements in outcomes.
Instead, you just need to work on creating a real team, with the right people, and a compelling purpose. If you add good surrounding structure, supportive organizational context, and give the team coaching...that's even better, but not a requirement.
And if we overlay Microsoft's Organizational measures with the six team conditions...it makes sense why team stuff beats approach stuff when it comes to predicting team outcomes.
Read Next
The Changemaker's Skills Maturity Matrix
This development tool is designed to give change-agents inside organizations clarity into their path forward, help them define and deepen strengths, and maybe give us some shared language about what we do.
Five Org Design Things N° 10
Pattern languages and org analysis; RTO is bad, even if offices are good; old maps made 3D; diverging values worldwide; exit interviews
Five Creativity Things
Challenges facing creativity; owning ideas from beginning to end; opinionated palettes; are we doing zines again?; randomness that didn’t fit in the first four categories
How to Combine Pace Layers, Org Design, and Strategy
4 ways to use Pace Layers in strategy and OD work: 🚀 As a career planning tool; 🎓 As a strategy tool; 🔬 As a diagnostic or sense-making tool; 🎨 As a design tool for value-adding layers.