For non-engineering teams my playbook is: 1. Get in all their support or public slack channels, watch for acute moments of freak out or consistent schlep blind

For non-engineering teams my playbook is: 1. Get in all their support or public slack channels, watch for acute moments of freak out or consistent schlep blindness. 2. Meet with the head of the team once a month for 45 mins and get them to list out what just sucks. You can limit chit chat very well this way. You’re only going to be able to do so much so broadly picking the problem that is closest to the business’s immediate pains can be a win. Or maybe that’s already being swarmed on so you knock out a bunch of random stuff and get broad recognition. For technical teams, almost every single thing I ship: 1. cements a new pattern or contributes to a new one that my team can use 2. improves cicd speed or checks You can usually knock out the non technical team work and pick off 1 from technical team work along the way Everything I do (except specific bug fixes) force multiplies, otherwise I’m wasting my effort. I don’t feel like I need to talk too much to my teammates about their engineering problems. I’m doing the same work ultimately, so I have a solid understanding of what moves the needle Edit: convincing the organization that your work is important gets much much easier when you have metrics and charts that make the case for time well spent. It could be a buggy ass feature, or a meaty pipeline the business relies on. Prove that it’s hurting the customers and ultimately the bottom line. Battling over and convincing of scope becomes less important when you’re talking in the same language as non technicals