I always try to think how product owners deal with this. I used to write a lot of code, so did my colleagues, but the product owner was the one driving the effort - they definitely didn’t know how to code, but they “shipped” results regardless - they develop relationships with individual engineers, make sure to understand their strengths and weaknesses, insist on automated testing and then hand verify results, whenever on assumption the engineer expressed but turned out to be not true they push to extract the uncertainties.
Slowly build understanding of what is possible, push back on engineers suggestions and don’t approve stuff blindly, but relying on results to guide them not the implementation.
It is very very similar feeling. -you need to know your models and harnesses (e.g. your … team). You don’t need to know the specifics of the code but doublecheck with different personalities if the assumptions are correct, test them.
And ultimately shipping bugs is a given , human engineers do it _constantly_ it’s the resilience systems you build around that which saves you, tests, canaries, rollbacks, feature flags, everything we already know how to do - just use that and imagine yourself the product owner.
Slowly build understanding of what is possible, push back on engineers suggestions and don’t approve stuff blindly, but relying on results to guide them not the implementation.
It is very very similar feeling. -you need to know your models and harnesses (e.g. your … team). You don’t need to know the specifics of the code but doublecheck with different personalities if the assumptions are correct, test them.
And ultimately shipping bugs is a given , human engineers do it _constantly_ it’s the resilience systems you build around that which saves you, tests, canaries, rollbacks, feature flags, everything we already know how to do - just use that and imagine yourself the product owner.