Data behind high-functioning engineering organizations [pdf]

&quot;Most organizations have shifted to organize their engineering teams by product&quot;<p>We have done the same. The great thing about it is locating decision makers and customer insight close to developers. The bad thing is that what is perceived to be a &quot;product&quot; can be very different from the natural division of technical work to be done.<p>I sometimes joke that our Head of Product ended up involuntarily being our Chief Architect. The master plan of the tech has to be divided along these fault lines between Product A and Product B.<p>In Sales these may be sold as separate products. But the reality is that 80% of functio ality is shared between them, and these 80% do not get a good organization developed around it, since the A vs B split is at the core of the company chart.

Perhaps its my disdain for metrics and &quot;efficiency process&quot; in general, but skimming through these slides made me want to run for the hills. A high functioning team, in my experience, is one that has clear direction, autonomy, communicates well, and has enough trust to operate as efficiently as possible to meet the company&#x27;s needs.

&gt; Developer productivity can be compared to a sales funnel, with key metrics that can be tracked at each stage<p>I dont like the idea of ruthless efficiency by tracking metrics similar to a sales funnel. It gives me the mental image of everyone competing and inflating numbers or gaming the system.<p><a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Goodhart%27s_law" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Goodhart%27s_law</a>

&gt; More engineering organizations are starting to track developer productivity, with the top metrics reported on being number of bugs, %of committed software, working software, and PR to release time<p>Sounds like an absolute dystopia.

What aspect of the surveyed companies suggests that they are &quot;high functioning&quot;?

This doesn’t seem like they figured out anything about “high functioning teams”, they just performed a survey.<p>Like, do these companies actually ship faster, have lower rates of issues, better MTTR, etc? This just says things like “there are more full stack engineers”.<p>At least the Puppet state of DevOps report gives you a “low, medium, high” categorization. This doesn’t seem to be describing much other than some trends they saw this year.

Shameless plug: In case you want to get similar data for your company and you are using github for issues management, please give my product <a href="https:&#x2F;&#x2F;app.gitimprove.com" rel="nofollow">https:&#x2F;&#x2F;app.gitimprove.com</a> a try its in alpha right now. Website is <a href="https:&#x2F;&#x2F;gitimprove.com" rel="nofollow">https:&#x2F;&#x2F;gitimprove.com</a>.

wow 89% use Atlassian tools..

<a href="https:&#x2F;&#x2F;www.iconiqcapital.com&#x2F;growth&#x2F;insights&#x2F;2022-engineering-report" rel="nofollow">https:&#x2F;&#x2F;www.iconiqcapital.com&#x2F;growth&#x2F;insights&#x2F;2022-engineeri...</a>

Browsed through the slides but didn’t encounter any lightbulb moments or any specific enlightenment.<p>What are the key takeaways or lessons here?

Does anyone have experience working within a matrix team? It seems like an interesting idea.