4 ms·
Talking about team communication in the abstract is difficult. I wrote a book about it. [1] The problem is that you are looking for the maximum amount of valua
by DanielBMarkham 8y ago
Talking about team communication in the abstract is difficult. I wrote a book about it. [1]
The problem is that you are looking for the maximum amount of valuable communication with the minimum amount of overhead. That is almost impossible to reliably quantify, however, because each team develops their own communication and language style. This is the tension we face: outside folks who mean well want to standardize things so that teams have a better chance of succeeding. But the only thing they accomplish by doing this is creating a lot of friction, waste, and overhead. It does not matter if your TPS report has a cover sheet or whether your standup is at noon or not. Nor does it matter whether you're using Trello or crayons. You're focusing on the wrong thing.
If we limit our discussion to teams located in one place using a physical board, I have noticed that standups that focus on the board, the work, happen with better teams. (They don't make teams better. Good teams tend to do it that way). A few useful tokens of testable work on the wall that people can point at and talk about how those goals are going tends to focus the conversation around value.
On the other end of the spectrum, large spreadsheets or online tools where each person reports on what they're doing usually show a completely waste of time and a death march. I worked with a VP once of a major corporation that kept a 100-300 line spreadsheet with "promises" he received from all his teams. We spent every Monday morning for hours reviewing each promise and talking about how we had failed the clan and dishonored ourselves. Oof. It was horrible.
1. https://leanpub.com/info-ops https://leanpub.com/info-ops
- Benjammer 8y agoDo you have any advice for someone in a senior IC role to actually get people setting the processes to shift their thinking from optimizing general metrics and making everything more homogenous, into a model where everything is contextualized (like your examples) and then we draw out higher-level patterns by analyzing the common traits that organically arise as a result of contextual solutions?
- DanielBMarkham 8y agoPing me. I'm happy to provide any free advice I can over the phone as long as it has a chance of helping developers. HN isn't the place for this, however, as whatever I say is just going to open up a religious war. (Disclaimer: I am currently looking for new clients) You hire a guy like me because they have a broad and long record of seeing various things work and fail. The first thing you learn is that it takes a lot of examples to start seeing patterns. The worse folks you can deal with are the enthusiasts who have only seen things rock-and-roll a few times. Skeptics are great. Let's go see what works or not. True believers are another thing entirely. Humility is critical here. There are some things I've seen that work. There are also some things I've read from others that I trust. I've always been a huge believer in success by failure avoidance: it might not matter what you do as much as it matters that you're actively trying to avoid screwing up. No matter what your mix of strategies, it's a personal call that involves risk and not a kind of conversation you want to have in a room with ten thousand people in it. It's something to think about for a while.