Letter to a PO
Azer is one the most interesting people I've met at Outfittery. His smooth voice and calm manners always make it a pleasure to talk to him. The way he talks about where he came from and his family… You never leave a conversation with him feeling the same way you entered it.
As we were having cake and champagne to celebrate Outfittery's brand re-enlivenment, he asked me to write about what I find important in my relationship with PO's, what are my expectations both as a developer and a tech lead, my do's & dont's. I couldn't say no to the big smile coming out of that well kept goatee :)
These are my top 5 expectations from a PO as an engineer.
It's not only about writing tickets
Preparing a work item to be worked on by the team is the very basics. As a developer, I don’t necessarily expect a Jira ticket; I can work with a dirty napkin, as long as it answers the crucial questions: what needs to be done? who’s gonna use it? to what purpose? and how do i make sure it works as expected?
I honestly don't need requirements to be written in a user story format. And I can live just fine without the Given-When-Then triad. Well written bullet points do the job just as well.
I don't care about the syntax, I care about the information underneath it, because that's what makes me tick. Knowing that I'm doing something useful to someone is what makes me wake up in a February morning in Berlin, look out at the grey sky and the white sidewalk and say "what a great day to be alive!".
And oh, by the way. We all know things change, including requirements. I hate to break this to you, but you're the one responsible for keeping it up to date. You own the backlog, and that includes the work items that make part of it.
It's about owning your product
I once asked a colleague PO: "how do I test this feature?". She looked at me with terror in her eyes and answered "I don't know, all I know is that I'm supposed to click this button and everything should work!!". Dear PO, please don't be that person.
Do you want to earn respect from your team? Then do the simple things: own your product. Get involved with it. Understand who uses it and why. Understand how the data is stored.
I don't expect you to write a RESTful API from scratch. But I'd have a lot of respect for you if you'd write SQL queries every once in a while. Triple bonus if you join high level technical discussions. Then everybody in the team will love you.
And no, I honestly don't think that's expecting too much. If I can talk KPI's, I don't think talking database tables structure is any harder.
Sign off on your product
It’s fine (and nice) to trust the team to assert the quality of our product. It makes them feel valued and increases their ownership.
But don't forget that you’re the one responsible for it. You’re the one person the team expects to know how everything should connect at a high level. You must get involved in testing and making sure we’re delivering the right thing.
If everything falls apart, the team will be there to support you bringing it back, but you have to be 110% sure we’re putting the right thing live.
Maintenance is part of the job…
A tech team is not a feature factory. Cheesy as it may sound, we see ourselves as craftspeople. We care about what we do, and we want to do it well.
Yes, we want to deliver what matters to business and we’ll commit to cut corners to get something important out of the door whenever necessary. But commitment is a 2 way street, you also have to compromise on sometimes shutting your ears to what business is pushing and help us prioritising the maintenance work.
No maintenance means taking longer to deliver easy features. No maintenance means spaghetti code, and there's nothing that developers avoid more than spaghetti code. If you keep skipping maintenance, soon enough no good developer will want to work in your team.
… as well as connections
As your fellow tech lead, I’ll help you finding the right people to talk to, but you also need to know who are the people that will give straight answers to the questions the team has.
It’s fine if you don’t know it sometimes, but sending us thru a loophole of people that just tell us to ask the next person every single time is not ok.
And when you send us on that quest, make sure you learn from it too, so that next time we can figure things out ourselves. Developers don't have that much fun having to look out for answers by themselves every single time.
And don't forget we love you!
A team is made of people with different skills and responsibilities. It's fine not to know the job in the beginning. But let's be honest… If you don’t know what and why is to be done, nor how to ensure it’s working properly, if we need to figure things out on our own every single time, then what are you good for?
To answer Azer's question, I expect you, my dearest PO, to do your best, to mingle with the team, to learn and to grow. If you do your best on your end every single day, if you care about others and what they value, odds are we're going to be the best team in the world.
This is dedicated to the best PO's I've ever had the pleasure to work with: Debs, Fabi, Gisele, Lyns and Funky Hair Russell. Thanks for everything you've taught me. I'm a better tech lead because of y'all.
