Dev + Friends
I was introduced to a new concept a while ago: Dev + Friends
Apparently it works like this: the only truly productive people in an organization are developers. They are the only people who actually put hands on code. Everyone else in the org is just overhead…ahem, friends. Managers, release engineers, Admins, QA, Project managers, in short anyone who doesn’t write code. Full stop.
I’d like to pause for just a second to express my utter horror at this concept. I think I get where it comes from. Organizations, especially large organizations, can become bloated. Executives looking at the composition of teams see that some teams are less than 50% developers and…Oh jesus I can’t even begin to paraphrase this bullshit. It hurts just repeating it. Well, I’m going to grit my teeth and try anyway.
I was part of an organization where the CTO introduced this concept. I suspect he felt that the developers didn’t have enough voice in the organization, so his answer was to make them the most important role in the organization. Everyone serves the developer. There is a certain justice in this. Teams had indeed become bloated with required roles that increased expense without necessarily increasing productivity. One particularly suspect role was the scrum master. To some degree this was a backlash against introducing agile to teams that wanted nothing to do with it (and were given no choice). Then there were product owners, who were often new, and had no domain knowledge. In fact the teams often knew more about the domain than the product owners. On a team with 7 people you just introduced 20-30% overhead without writing a single new line of code. And those scrum masters and product owners don’t come cheap.
So, apparently to combat those issues the CTO told everyone in the organization that the only valuable people are developers. Everyone else only exists in service to development. He called it Developers+Friends. Coders are the only people who are valuable to the organization. I remember feeling like a third class citizen almost immediately when this was announced. It was the most demeaning thing I’d heard in my professional life. Apparently, the work I did wasn’t important because I didn’t write code.
Just in case you’ve missed it, the fallacy lies here: developers aren’t the only people in the organization who contribute value. Part of the problem lies in the explosion of job types in larger organizations. This rarely comes up in small organizations for the simple reason that in a small organization, everyone contributes no matter what their job description is. In fact, their job descriptions in small organizations are almost irrelevant. Everyone is scrambling to help out so frantically, that the question of strict role responsibility never even comes up.
For the record, there are constructive ways to deal with these issues that don’t involve demeaning everyone who isn’t a developer. Involving the teams in the selection of their roles and processes. Insuring adequate training for people filling key roles. Focusing on flexible roles that don’t map directly to job descriptions. It’s really not that hard. You just have to treat people with respect.
Want More?
I provide innovative agile coaching, training, and facilitation to help organizations transform to deliver breakthrough products and performance. I do this by achieving a deep understanding of the business and by enabling the emergence of self-organizing teams and unleashing individual passion.
To learn more about the services that I offer or to arrange for an initial consultation, please see thomasperryllc.com