Stakeholder Example: Improving an API

[00:00:00]
>> Here's another one that might hit close to home for many technical folks here. Let's say you are the Google Maps PM and you're like, hey, we have a janky API that, you call this method with this object shape and you call this one and it's actually just a post and there's no body that goes with it.

[00:00:16]
And we've duct taped this together over a decade. None of this sounds familiar to anybody I know, right? So let's go and let's unify this and let's make a v2 of our API. And let's make it all consistent and beautiful and lovely. And it's gonna have a swagger spec and it's gonna use GRPC.

[00:00:37]
That's I think those are mutually exclusive things but I don't care and blah, blah, blah, right? Aka what GitHub did when they went to GraphQL is their public API, right? That seems like a slam dunk, right? It's like, all right, we got space. Let's go make things better for everybody, right?

[00:00:57]
It might be. But let's go back and think about this as stakeholders. You have a bunch of people that have already built a bunch of stuff on your API. Right there, are millions of apps potentially that are based on the Google Maps API. If you break it, you are breaking a lot of people's apps.

[00:01:16]
Or let's say you even keep it around, now you either are trading off the stakeholder internally, we have to now support two versions of our API. Or we're basically saying, okay, we'll try not to break this other one but we're not gonna fix it, right? All sudden you're in this kind of mode of stakeholder management, you have to think about not just this potentially golden future you also have to think about what am I doing to all the people that care about this.

[00:01:44]
This is also extremely real to me because this is basically Stripe's perpetual problem. If you build something on Stripe in 2015, it still works today, because they never have broken their API. That means the Stripe API in some ways is pretty janky, right? Because they have had a lot of ideas since 2015.

[00:02:04]
And basically what they do, they do have a modern API that is actually much better. And if you make a call to an old API, it goes through a translation layer that goes back to those old APIs and things like that. But every team has to maintain every API that they have ever put out.

[00:02:21]
It makes Stripe move a little bit slower, right? But people don't wanna upgrade their apps. Particularly think about like money apps, right? So you have the Stripe integration, and if you have this Stripe integration and it works exactly the way that you want it to, and it's been tested and used over for like a decade, you don't wanna change it.

[00:02:42]
Why would you wanna change it? Money is scary, right? And so if you introduce a new bug or Stripe introduces a new bug, you are literally affecting people's bottom line. Which is why I think Stripe somewhat wisely, has basically said, if you build something in 2015, we're gonna do everything we can to make sure that it's continues to work the way that you expect it to.

[00:03:03]
Stakeholders, right? You have to frame it in the sense of, who is holding the back here at the end of this,right? And a lot of companies like GitHub in that particular case, when they went for v3, they went to Graph QL. They basically said, hey, everybody, you now have to learn Graph QL to even integrate with GitHub now.

[00:03:22]
At the time, GitHub was, or sorry, GraphQL was so hot, and everyone was like, this is the best, this is the future, and some years later everyone's like, maybe it's not, maybe it's not the future. Maybe we shouldn't build things like this anymore, right? And v4 of their API, surprise, surprise, not GraphQL anymore, right?

[00:03:40]
So that kind of churn is exhausting as a developer, right? And you'll find things that you don't have to churn as much. Why do you think WordPress is still so popular, right? It's a reliable partner that you can build things on. It's awesome. I will never disparage WordPress except when I have to work on it, and then I will disparage it a lot.

[00:04:00]
God, if I have to think about the loop one more time, I swear I'm just gonna pull my hair out. So every time that you go to approach, what am I gonna build and why am I gonna build it, please think about who you're building it for and who is not gonna like what you're gonna build, cuz it's always someone.

[00:04:15]
And if you cannot think of someone that is adversely affected by what you're building, at the very least is your own team maintaining it, then you're not thinking about it thoroughly enough, I would say. Yeah, Mark.
>> Do you ever anticipate that developers are gonna go over time and just kind of change the deadline?

[00:04:40]
Communicate the deadline as something further out to the business versus the developer. I know this is more of a project management.
>> Sure, no, but I mean, it applies to product managers, cuz we're equally beholden to the timeline and to delivering things on time. So, I mean, I think that to rephrase that question is, do I trust my developers?

[00:05:05]
I've had the good fortune of working with awesome developers that I don't ever question that this person is intentionally gonna try and slack off. I don't know what to do about that. I'm not a taskmaster, right? I'm not gonna go in there and sit on them and watch what they do.

[00:05:26]
Not my style. And it's honestly, it's not my particular issue, that would be an engineering manager's issue to deal with. I do push back sometimes when a developer will say, this is gonna take me X amount of months, and I'll ask, are you intentionally is that an overestimation?

[00:05:42]
Because you're anticipating something like what? What's built into your estimation? And you'll kinda figure out developer by developer, including myself as, I'm padding it for these reasons. And sometimes, I'm padding this because I don't know how the dependency org is gonna react, that's valid. I accept that, or I'm padding this because I'm worried that I can't deliver on time.

[00:06:04]
Well, let's try and give it the real estimation and we'll adjust, right? There's mechanisms to modify timelines when we run into issues. Don't give me the padded one, give me closer to what you actually think this is going to take. Acknowledging that software estimation is an impossible science.

[00:06:22]
Or an impossible art, if we're being really honest about it, right?