HRTech
(this iPhone pro takes awesome pics)
Dave Kellogg and I have been doing a Clubhouse Show for a couple of weeks. It has been a lot of fun so far.
So, after a couple of failed attempts to record via the iPhone, I splashed out on some proper podcasting kit. All the gear, no idea. A Røde Podcaster Pro, a Røde XLR microphone, and various software tools (Podbean, Hiddenberg, Otter.ai) Thanks Dave for your patience, and sorry to our earlier guests, Anshu and Mark, we will make it up to you. I also need to thank my friend, Heidelberg's top DJ, Bülent, for the loan of his microphone, and the retired king of the enterprise podcast now model tank builder, Dennis, for his advice on software.
It will take a few days for the podcast to appear on Apple, Spotify and Amazon.
Update: you can subscribe on apple podcasts here.
I'm applying an agile process here, in other words, figuring it out as I go along. You can listen here in the meantime. I will also post a transcript shortly. I'll use Otter.AI for that, it is a really nifty product not just the because of the name.
Scott Beechuk is an interesting guy, he was a product leader at Salesforce, and is now a successful VC. He has a lot of interesting things to say, and Dave does an excellent job of interviewing him. Here is a lightly edited snippet.
I think there's two different interactions that happen. One is healthy and one's not so healthy. I think the not so healthy one is where you've got a culture where product and engineering and perhaps a third group UX, are all at odds with one another, and they don't trust one another. And that's that is a that is a very caustic, very dangerous situation to be in. Because what you end up with now is every time you want to create a set of new capabilities in your product, or your product line, now, your product is naturally going to push as hard as they can to get as many features in there, engineering is going to naturally sandbag. Because that's that's how they protect themselves against this onslaught of feature requests, and there's going now all of a sudden, you've created this adversarial relationship, because product will never get really what they asked for engineering knows that if they're held to that standard, meaning, you know, I've got look across my Scrum teams, I've got 100 story points for this release. And you're asking me for 350, it's just not going to happen. But product will sometimes get more aggressive because there becomes this adversarial, like, engineering is always saying we can't do it. So you know what, let's just push really hard to just force them to do things. And then, you know, in an extreme example, one of those two sides wins. And that's when things get really gnarly, because now all of a sudden, if let's just say product wins, well, now, engineering will be forced to do things that are not healthy, they'll be forced to hard code, when they should have architected for extensibility, they're going to be forced to cut corners on quality engineering, quality assurance, which is obviously never good. They're going to be forced to cut corners, possibly on the CI CD pipeline, and something's going to break when you release it into into production.
There is this other side, though, where you've got a very productive version of this. And the productive version is if product teams can communicate with engineering teams, and there is this sort of copacetic you know, mutual trust and respect between the two. Now what we can do is we can get into a room between product and engineering. And we can we can have a healthy and friendly debate about, Hey, I think we need to build this new capability that that integrates with these seven different systems engineering, we'll come back and say, Well, the problem is that three of those systems don't have rest API's. And what we're going to have to do is do some crazy data dips, it's going to be really nasty, we're probably gonna have to, you know, build a new data store. And well, that's going to bloat the, you know, it just goes on and on. But as long as product has enough technical background to at least appreciate the realities of what engineering is communicating, I think now, that's when you can reach what is the, you know, we're always compromising. There's never a perfect scenario, and we never have enough resources. We never have enough smart people in the room to solve every problem perfectly every time right. So every single release involves a whole set of compromises. So in that, you know, idealistic scenario, everyone understands the limitations, and both sides will have to back off and make some compromises. Awesome.
Wise words from Scott. Next week, I'll do doing the interviewing, just in the process of finalizing my guest. News to come shortly.
