This is part 3 of a series of blog posts based on a talk I prepared called Successfully Derailed Product. It’s about the ways in which we define and talk about “success” influence what – and how – we build. See part 1, part 2.
Taking a step back from individual success, I wanted to understand was an industry we talk about building teams. What is the team working towards? What motivates them? What bonds them? What makes them proud?
I turned to a resource called Software Leads Weekly. It’s a newsletter that was one of the first things I was pointed towards when I became a manager, and it’s read by around ~18K people a week. I figured it would be a reasonable example of how we talk about technical leadership. I went through every issue this year, 13 issues with 130 articles and categorized every article in a spreadsheet. Blog posts made a bit over 50%, and tweets a bit under 40% (I shouldn’t tell my boss this, he’s pretty into blogging), with the rest a mix of media articles, video etc.
To try and quantify the bias here, whilst I was at it checked the gender breakdown of things included. 15.4% of included articles where by women. Now, gender is not binary, and not the only measure of diversity. BUT – it’s easiest to quantify, and necessary but not sufficient. I.e. if something is genuinely diverse, it will have good representation of women. If something is representative of women, it can still be poor at representing other axes of diversity like race or ability. Now for those of you who think 15% is OK, because it’s about tech, note that not all the articles are from tech, and so there’s plenty of possibility to do better than the poor standards of this industry. But that is not taken.
I read a good amount about management, and running teams, and sometimes I wonder if an alien was studying this, like the way the alien in Hitchhiker’s Guide called himself Ford (because he thought cars ruled the earth), what would they think development teams do?
So finally, I have my answer. And it’s pretty much: they might reasonably think we run teams to run teams, as some kind of cultural ritual.
The most popular categories are team operations – which was a broad category included things like process, job roles etc, and individual effectiveness which was narrower – personal productivity strategies – time management, decision making, etc. Less than 30% of articles had the word “user” or “customer” in them, but only 2 could really be defined as being about users and what the software we build is for.
I rounded out this biased research with some more biased research on Twitter.
Follow up from yesterdays question, what does a successful dev/product team look like? How do you demonstrate that and on what timeframe? Does your team have goals? What are they?
Would value managers and IC perspective – please say which 🙂
(RT for reach? 💕)
— cate // @hachyderm.io (@catehstn) March 18, 2018
I got some interesting responses. But I’d also love to know what you think. (Leave your answer in the comments or tweet at me).
Note – much less popular, and far fewer responses. I wonder why that is? Do people have less clarity there? Are they less willing to share it?
There are two themes worth highlighting here. One is clarity, the other is psychological safety. Clarity around what the team is doing, and needs to do. Psychological safety is about the team feeling good about getting there together.
I like the idea that “a successful team cares”. One thing I would highlight here is how quickly “what does a successful team look like” becomes “things managers should and should not do”.
Like… optimizing for playing video games. I have some feelings about this…
I’m not sure what to take from this research. It’s hard to see the relationship between what individuals are seeking out and what teams are. At best, we’re talking about teams as an environment for individual work, rather than the way in which we work together on something bigger.
Maybe that we’re more comfortable talking about video games and individual effectiveness than the bigger differentials of effective teams? Are these the things that we just don’t want to talk about in public? I run a slack for engineering managers and the topic discussed there are very different.
I wonder if part of this is the challenge of generalising when teams are made different not just by the people in them, but in the circumstances they operate in, and the harder things get the more personal things become. When we distill to a blogpost, by necessity we leave much of the complexity out of it. So it’s a lot safer to write about how to bring in Kanban, than is it to talk about how to manage up. It’s much easier to talk about how to hire than how to fire – and hopefully we do more of the former, anyway. It’s more enticing to talk about the CI stack than the slow grind and many failures towards achieving product market fit.
But ultimately I think any experienced manager will tell you the harder topics make the biggest difference to the a team that executes on meaningful work, than a disconnected non-team that does not execute at all.
What’s next? How users think about success.