When I was managing engineers, I would insist that the engineer talk 1:1 to the engineer on the client (or customer) side when doing fixes or feature enhancements that happened to be requested from outside the company. This always caused consternation among scrummasters and product managers, and there always had to be a discussion about it. But it sped things up tremendously, because the engineer could do things like say "well, what if we did this other thing instead, which would give you what you need, and also solve another problem we have". In almost all cases the other engineer was happy to talk to our engineer, and very easy to work with.
This needed to be a private conversation as well, so that both parties not need to worry about optics. Preferably phone.
Once a scrum-master tried to insist that these conversations take place on a public slack channel so that we could "capture" it! And yes I understand why, but it would have skewed the process into something less effective.
This kind of works fine until you have many customers.
If you have < 5 customers, then this works fine.
If you have > 10,000 customers, then this works fine, because you can rely on analytics.
If you have 100 - 500 customers, then it kind of breaks. You can't rely on analytics because those customers are too important, and you can't rely on 1-1 interaction with engineers because there are too many customers to consult on each change.
I've been the client engineer before, trying to get through the opaque 'solution support' folks to the actual engineers of the product. No dice. We could never get the problem solved and we ended up ditching the product.
When I eventually got an NPS e-mail from them, I gave them a 1, and explained that I couldn't get through to actual engineers so we gave up, and then a solution engineer
followed up and apologized and informed me that if there was anything they could do, to let them know.
I never wanted to bang my head against the monitor harder than in that moment.
NPS stands for Net Promoter Score. It's supposed to get a sense of % favorable - % unfavorable and leaving out the middle.
I've seen this at many companies and its one of my biggest pet peeves. Almost nobody uses it correctly. They don't net anything. They take the average. It's not clear at all why it's any different from any other score. I think most people think its some sort of collection or measurement thing rather than a calculation on the data. I hate it. Reeks of innumeracy.
Not that it really matters if you use average vs. nps...
or you could offer - optional non compulsory - support for recording and transcription to the engineers and pay them overtime to jointly produce a final copy / summary (destroying the materials unless required for compliance) as we used to do.
There’s some value in capturing these conversations for the record. If eg the engineer engaged in these conversations decided to leave, it would preserve the record for the person replacing them.
I do agree that if this process is used to score political points though, then it loses all value. Maybe a compromise is to capture the summary of these conversations somewhere. But honestly if an org has become this political.... I would start looking elsewhere.
I was referring primarily to slack conversations. Usually when searching for a unfamiliar service or tool, I first do a slack search, then look at a KB/Wiki, then at code etc.
Public slack threads are pretty great since you can follow the decision making process when solving problems. Great slack threads may even include data on what the author tried/didn’t try etc.
I agree with you that video recordings are for the most part useless. Until we find a way to get high quality automatic transcription of videos and add them to a good search index, they will have limited use.
There's a big difference between internal work and external work, where that discussion can matter a lot in antagonistic disputes (in court or outside of it) over whether a particular change (and its consequences) was requested or not, and if so, by whom and when.
In a perfect world yes. But the majority of JIRA stories that I’ve come across often don’t contain complete information. The best, well disciplined folks recognize that they will inevitably forget details and write careful summaries, most people write a few bullet point to satisfy the acceptance criteria for the story.
Slack conversations often contain more data. It’s also easier for me to follow a human conversation than a poorly written summary with many missing details.
