good developer advocacy is bidirectional. it’s a cycle:
- you learn from the team how to use something, and teach that to users
- you learn from users what sucks about it, and teach that to the team
a good DA is essentially a product owner. they’re involved in the design.
it’s interesting some people read “advocate” as “advocate for the product” and some as “advocate for the users’ needs”. it’s really both. sometimes you need to convince the people, sometimes you need to convince the team. the job is to make sure the story makes sense.
this is why you won’t have effective developer advocacy until your developer advocates are actually part of the design process. they need to have a seat at the table, to be able to question decisions, direct the team’s attention to pain points, look for compromises.
it also goes the other way around. a good DA doesn’t overindex on the user feedback (“our users say we should add X!”) but focuses on the problems (“here’s what our users are running into”). they equally respect the users’ concerns and the team’s philosophy and help align them