Product Hero: Benjamin Ho, Senior Engineering Manager at Everbridge

Product Hero is our bi-weekly series that highlights outstanding members of the product management community. These industry leaders share tips on processes, team building, how to be a better product manager, and who they are outside of their careers. This week our product hero is Ben Ho, Senior Engineering Manager, Mobile at Everbridge. Ben and I covered a lot of ground in our discussion, so we’ve split the interview into two parts.
In Part 1, Ben and I focus on everyone’s favorite topic – Agile. Agile’s not new – a lot of people and teams know what it is and have moved in that direction. But many are finding it harder to fully embrace. Typically when we talk to teams, there are still some lingering habits of the old waterfall method or whatever used to be the way of life. Everyone defines agile differently, so Ben and I talked about his definition of Agile and how, if at all, it differs at Everbridge. Ultimately, Agile is an evolution that affects your product organization’s culture. It’s about shared responsibility,collaboration, and empowerment. Ben and his team subscribe to a “very practical form of agile” that he describes in our discussion.
In Part 2, we dove into Ben’s past as a chef and how that informs everything he does as an engineering leader today. Ben started in tech but eventually became disheartened with it. So he just decided to leave the industry behind to become a chef working in some of the best restaurants in the country for almost a decade! Ben rediscovered his passion for technology when the first mobile OS was released. Although it’s been awhile since he’s “done the chef thing,” Ben feels it’s something that never really leaves you, and he feels that chef perspective pervades everything he does, every single day. It’s still about passion, craftsmanship, and figuring out how to build and deliver something really cool.
I hope you enjoy the podcast.
Listen to Part 1 of the Show: http://traffic.libsyn.com/thedirt/Product_Hero_Ben_Ho_Part_1.mp3 Download the MP3 for Part 1
Listen to Part 2 of the Show: http://traffic.libsyn.com/thedirt/Product_Hero_Ben_Ho_Part_2.mp3 Download the MP3 for Part 2
Subscribe through RSS
Subscribe on iTunes
Subscribe on SoundCloud
Subscribe by E-mail
Show notes: Connect with Ben on LinkedIn.
Get to know Ben at Everbridge.
Follow Everbridge on Twitter.
Podcast Transcript, Part 1: Jill: Check one, check two, this is Jill.
Ben: Check one, check two, this is Ben.
Jill: I have with me today Ben from Everbridge. Ben, thank you so much for coming today.
Ben: No problem, Jill.
Jill: We’re gonna talk a little bit about Agile, all things Agile but first Ben, would you be able to introduce yourself and talk a little bit about what you do and how you got there.
Ben: Oh Geez, well I’m an engineering leader, and I have a passion for all things mobile. I’ve been doing mobile since the very beginning of iOS when things got really started. Right now I’m at Everbridge, it’s an organization that basically helps organizations manage critical communications. Something goes wrong like there’s a critical event, there’s emergency or an issue around safety, we help organizations or governments keep in touch with people and help them do something actionable.
Jill: Great.
Ben: As for the journey, I got a weird, long, convoluted history that you know a little bit about.
Jill: I know about it’s exciting, which is why I asked the question.
Ben: Touché. I started in tech in Canada and got disheartened with it and chose to be a chef. I actually just left the industry and I actually cooked for almost a decade. I had the privilege to work in some of the best restaurants in the country. Ironically, I’m gonna fast forward a little, mobile came out and that other passion for technology had never really gone away and I had realized, that hey this is something I really want to be a part of and so I decided to come back. So nowadays it’s funny because it’s been awhile since I’ve done the chef thing but it never really leaves you, and I find that, that chef perspective pervades everything that I do, every single day even though it’s completely different because you’re doing mobile stuff but it’s still that passion, that craftsmanship, that let’s figure out how to build something and deliver something really cool.
Jill: Yeah, well I might dig into that a little bit more later, but one question I always like to ask the people that come on this is, what’s one product … and I’m gonna ask you for a mobile product since you are the mobile guy today, what is one mobile product that you are crushing on right now that’s not something that you’ve worked on?
Ben: Oh Geez, in terms of like apps and stuff like that?
Jill: Yeah.
Ben: See so, this is what’s weird, so I will admit I am not the guy to go out there and stay abreast every single week of what’s new and what’s cool simply because you can’t, it’s constantly changing.
Jill: There’s so much.
Ben: There’s so much out there.
Jill: Yeah.
Ben: What is cool though and this is part of the reason why I got back into tech, right?  It’s you have this ecosystem that has these capabilities.
Jill: Mm-hmm (affirmative).
Ben: You got a camera, you got this sensor, you’ve got sensors for the orientation of the phone, whether you’re walking or whatever else and these really easy API’s that you can glue things together and do cool stuff with, so what does that mean? It means things like, the Amazon app right?
Jill: Yeah.
Ben: Lots of people buy stuff from Amazon all the time. They have this cool new feature where you can take a photo of something, like this Dasani water bottle.
Jill: Mm-hmm (affirmative).
Ben:And you can hold it up in front of the water bottle and then the app will try to figure out what it is that you’re looking at and say, Hey, do you want to buy this thing? So it’s that cool integration of technologies to make things really delightful and frictionless that I find cool. And I see this all over the place, right, it might be something as mundane as a password manager, right, everyone hates passwords.
Jill: Yep.
Ben: Well the fact that you happen to have something that can secure your stuff or the fact that you can use your fingerprint to authenticate all that stuff. So really what I’m looking for are experiences and leveraging these different technologies and ways to make life easier in a lot of ways.
Jill: Yeah. It’s spoken like a true mobile person. You didn’t list off one solution, you were kind of like the fusion of different solutions coming together to create one really great experience.
Ben: Right, so let me give you an even better example when we talk about the light. I was traveling to San Francisco, like a lot of people will do and I was trying to hail a cab, right, rush hour, trying to get to dinner, impossible to get a cab and expensive too. They had surge pricing at the time. I was like whoa 20 bucks to go a few block, okay, and so it turns out that the phone actually was actually in a really bad, poor network area and so I got this sort of spinner thing and it became clear that the … basically hung, so I gave up. I closed the app and then decide to, okay I’m gonna walk the six blocks. Turns out, three minutes later my phone rings and the Uber’s here. I’m like, what the heck just happened. Now, it turns out that the app had basically, when I put it in the background mode, I had made the assumption as a developer, that oh the calling Uber didn’t work and so I’ll just walk instead, right, didn’t work at all.
Jill: Yeah.
Ben: But some Uber engineer somewhere had realized, Okay, let’s make this thing work more resiliently and they really want to call an Uber and so I’m gonna do whatever I can to call the Uber. And so it just sort of happened frictionlessly. That’s not by accident, someone had to spend a fair chunk of time thinking about how that worked and what are all the edge cases and how do you want to accomplish the goal that the user really wants to accomplish.
Jill: Yeah.
Ben: That’s cool.
Jill: That is cool.
Ben: That takes effort and time and when you hit the formula right it’s sort of that magical thing that Steve Jobs used to talk about.
Jill: That’s awesome, yeah that kind of, exceeding expectations.
Ben: Mm-hmm (affirmative).
Jill: Really, really cool.
Ben: Right, it’s hard. It’s the same thing with food by the way. There is a lot of hard work, blood, sweat and tears that goes into making an experience really great.
Jill: Yeah. Very cool, all right. Well I think we’re here today to talk about Agile, it’s something that we hear a lot about at Fresh Tilled Soil from clients and from prospects and there’s been … Agile’s nothing new, a lot of people know what Agile is and have moved in that direction but are finding it harder to really embrace it 100% fully. Typically when we talk to teams, there’s still some lingering habits of the old waterfall method or whatever used to be the way of life, that still permeate in the new Agile world, and so kind of managing that transition and managing those teams. Everyone defines agile differently and so I wanted to get your definition Ben, of what do you define as Agile at Everbridge?
Ben: Oh wow, that’s … so there’s Agile in general and then there’s Agile at Everbridge as well.
Jill: Okay.
Ben: For me, I’m one of the big champions of, let’s learn into this.
Jill: Okay.
Ben: Right, so Agile at Everbridge, at least in my perspective, my teams are one of the teams that have a little bit more freedom because we’re mobile.
Jill: Mm-hmm (affirmative).
Ben: We’re not tied to like this big platform. We have a completely different CICD system, release cadence, we have more freedom basically. And so because of that we can explore, we’re a little bit more independent and we can explore more and so for us this means, Hey, let’s try different things within Agile. So I have an offshore and I have a team in the United States, and ironically the Agile interpretation’s for each one is a little different.
Jill: Interesting.
Ben: And now the reason why is because it’s an evolution. We’re trying out different things right. We are trying to figure out, okay if we have a goal of be more agile what does that mean?  Maybe more flexible, maybe we can deliver more quickly, maybe we’re learning more quickly, maybe we can iterate more quickly and it’s just there’s less overall friction in terms of delivering stuff. Either way, the whole point here is to figure out what tools work for each team.
Jill: Mm-hmm (affirmative).
Ben: Now I had said that one team’s remote.
Jill: Yeah.
Ben: Right, their physically … it’s a 12 hour time zone difference.
Jill: Wow.
Ben: So, if you happen to have leaders here, like the PO’s in the United States, and I’m here and we’re trying to give Agile guidance or hey, this what the customers looking for, well someone’s gotta be engaging with those folks over there and it’s very difficult just to be doing that via writing an email for instance, so there’s some overlap, the flip side, the other team I happen to have is in the U.S. they’re all remote, it’s a little hard to get everyone physically in the same room using a bunch of sticky notes, etc, etc, right.
Jill: Exactly.
Ben: And so, if you’re talking about using Agile tools, I’ve worked with you before.
Jill: Yep.
Ben: And the sticky note thing is something that’s wonderful, there’s something unique about being able to touch this thing and talk about this thing. It’s hard to do that when everyone’s remote.
Jill: Exactly.
Ben: And so, it’s easier to do that with folks who are in the same place, like Beijing, where all of our teams are, if they’re all in the same place they can do that, the U.S. folks can’t do that.
Jill: Yeah.
Ben: And so, this is where we’ll experiment with different tools and try to evolve and learn into it. Over time, it’s good because of the fact that both teams are iterating more quickly and they’re able to sort of embrace that mechanism of empowerment. You actually see this in different ways-
Jill: That’s awesome.
Ben: … but you can see that progress over time.
Jill: Yeah, so give me an example of how some of these teams, like you’ve seen it, empowerment come through on the team and seen them progress kind of to a new level.
Ben: Oh wow, sure, let me give you an example of an Agile team I worked with once that, they were starting out on an Agile transformation. The previous model was much more centralized decision making. Where a lot of organizations you’ll have engineering leaders, managers, VP’s whoever sort of saying, Hey, this is the direction we should take. And they’ll push that to the teams. This is not unconventional, in this scenario the team had started with the particular … there was a particular feature and that particular feature from a development standpoint, everything looked fine. It seemed like it was working, they never really had any problems with it but in terms of reports from the customers, there were a couple of customers that were very loudly saying this thing wasn’t working the way they were expecting. It just outright would fail and so you have this disconnect.
And so in the spirit of empowerment, one of the questions I had posed to some of the senior engineering members on the team was, Hey, there’s this disconnect here, why do you think that might be the case? And they’re like, Oh, it could be that, it could be that. Okay, well here’s some room, rather than pack the schedule full of stuff around like, Thou shalt do this or that. it was, can you verify whether that’s the case or not? Turns out, these engineers got together within an hour or two, they had talked, they had figured out there’s a couple of quickie things we can do to check, turns out the issue by the way was around bad networks. The tools that we were using, the frameworks, for this feature worked just fine on WiFi, when you go onto cellular or 3G or a connection that takes a long time to connect to come back, it just falls over.
Jill: Wow, okay.
Ben: And so within two weeks, that engineer went off on his own, because he knew the goal was figure out what the … if there’s a problem here but recommend a solution. He was empowered to basically, go figure this out and provide a recommendation. And within two weeks he came back with not only, Hey, there’s a problem here. This is specifically where the issue is. Here’s a couple of solutions we can provide and oh by the way I actually did the POC and proved out that if we decide to do this, we know that this will work better.
Jill: That’s awesome.
Ben: In two weeks, rather than two quarters of sitting there scratching our head over is there really a problem here or not.
Jill: Yeah. Yeah, I love that, letting people dig into the problems and get a little messy and come up with some ideas and do that proof of concept that’s … A lot of times we think oh that’s for an innovation team or that’s for higher level management to figure out or a research team and they’ll come back to us with the answer, but that’s certainly something that anyone can do and I’m sure it’s very fulfilling for your engineers to be able to do that.
Ben: Oh absolutely and they want right?
Jill: Right.
Ben: In some ways it’s actually better having the people with the boots on the ground providing that context because what you’re doing is basically saying, Hey, here’s the goal that we’re trying to accomplish or some unknowns.
Jill: Right.
Ben: Some questions, assumptions, and they’re the ones who know where we currently are, and can also sort of bridge the gap to where we want to be, they just need enough transparency, enough visibility to go, oh am I aligned with … Cuz it’s very easy for them to go off in one direction and it’s totally the wrong direction.
Jill: Yeah.
Ben: And so that’s a very strong thing that if you leverage just right, really helps you get to a more ideal place faster.
Jill: Yeah. So I wanna follow up on something you just said, and you talked about how it’s easy for people to go down rabbit holes and get disconnected from the team, so how do you both empower your team but also make sure that they’re not straying too far from the greater purpose that you’re moving towards?
Ben: Agile’s a really powerful thing, it’s around this collaboration mechanism, it’s around this, Hey if we get your collaboration and shared context, teams can build great things. Well, most organizations don’t come from an environment where they start from scratch, they often time are doing waterfall, some other mechanism, top down management, whatever have you.
Jill: Yep.
Ben: And you’re trying to sort of transition from that form to this empowerment model. The challenge is that … especially when you start getting outside of a tiny start up where there’s like three people or 10. If you’re talking about a larger start up like 20 or 50 or heaven forbid a company, or heaven forbid an enterprise with 500 or 5000 people. How do you keep all those people aligned? And so the tricky part here is that there simply is not as engineering leader, there simply is not enough time for me to ramp up about what the business needs and then for me to communicate all that volume of information to the team and keep working. Now the tricky part is you want to be able to take that information and distill it into it’s essence and share enough of that context to get that alignment piece that we’re looking for. Now, if you can provide enough alignment, okay we’re focusing on this particular type of customer, here’s a user persona. They have this particular problem, we have a theory that if we deliver this feature that they’re gonna like the feature and they’re gonna want to use it and they’re gonna ultimately pay us to be able to use that.
And so you want to give them enough context of the why, not just the, thou shalt build, blah, blah, blah, blah and then have a conversation. And what often ends up happening, I find, when you get product in UX, DEV’s and if you happen to have QA or if you happen to have full ownership doesn’t matter, but get those people in a room thinking about the reason that you’re building it, great things come out the other side.
Jill: That’s awesome.
Ben: Now to your point around alignment and waste, this is the inefficiency of things. This is where having strong strum masters or someone in that role really helps. I myself, very easy to get off in tangent, and part of the reason is cuz I have a lot of context on everything beyond just that one particular topic. Someone’s gotta be able to help shape that conversation, to nudge the team to say, Hey, is this … what we’re talking about right now, that’s a great point, is this really relevant right now or maybe we need to dig a little bit deeper into a particular area. So, that alignment piece is an important one that transparency and more information can really help with.
Jill: Yeah, yeah and it’s … I mean I think that’s crucial if you’re going to empower people, you have to give them the right information to make the decisions, to let them go down that hole. You talked about user persona’s and that’s something that we develop here at Fresh Tilled Soil all the time and a lot of time they get used by a product team for a little bit and then kind of sent off to the marketing team. Like, okay we figured out enough, now go send that over, but I like that if you guys are faced with an unknown or an uncertainty you’re digging into, okay who is this customer and what exactly is their problem and trying to think about it from their perspective.
Ben: Right. The challenge with engineers is engineers are really smart. They’ll fill in the gaps, and they won’t let an assumption block them. They’ll be like, Oh, well they must be using this blah, blah, blah, blah, blah. When in reality if you go out and actually measure or ask you might find that no, that’s not what one particular or a group of people might use it for. It might something completely different, and that’s important.
Jill: And what I found too is a lot of the engineers that I’ve worked with are very logically minded. While they might put two pieces of information together that makes total sense logically, that’s not always how customers or users connect the dots and so you have to go again back to the source and figure out okay how do the customers or users think about it and if that doesn’t make sense logically you’ve gotta unpack the why behind it.
Ben: Right, totally right to your point in most forms of Agile there’s a reason why the product owner basically represents the customer, they’re basically responsible for understanding the use cases and the why are we building this thing and those personas and understanding, who’s gonna care about this thing and how are they gonna use this thing. Because to your point, whether you be a DEV, a QA, a UX person, you might not have that full breadth of understanding of why we might be building this thing and so someone is gonna be representing that and really helping align everyone else.
Jill: How have you been able to bring … Agile … I kind of joked earlier that getting to 100% Agile but you never actually get there right? It’s a continual improvement process, how does being more Agile affect your culture, either for better or for worse?
Ben: You’ll notice that earlier on I said that Agile’s an evolution, right?
Jill: Yeah.
Ben: Often time, because of the fact that you’ll think that you’ll … okay we’ll do it this way and maybe you’ll end up finding that it goes in a completely different direction. So with respect to … we’ve talked about empowerment a little bit, we’ve talked about shared responsibility and understanding, right?
Jill: Mm-hmm (affirmative).
Ben: What I find is when people within an organization start to adopt Agile, you’ll know you’re getting traction because it sort of takes a life of its own. This is simply because people have their own understanding of things. There’s lots of people out there who’ve been doing Agile in its various forms, usually with a caveat but put air quotation marks, we’re doing Agile.
Jill: Yes, I’ve also heard Agile-ish as a phrase that’s thrown around a little bit.
Ben: Well we use these terms to represent Agile as a whole, Scrum, Con Bon, Lean, XP, all these different practices, but they’re basically just lighter weight ways of trying to collaborate. Now when we talk about collaboration we’re talking about people, at least two, right?
Jill: Yeah.
Ben: Or maybe more and so each of those individuals once they realize that they have this empowerment, once they realize that we’re talking about Agile and I’m doing the air quotation marks. Meaning that they’re individual interpretations matter. They bring that to the table and now certainly at the team level you have this evolution where you might go to a more pure-ish Agile form. Where people like, Oh no, the manifesto says we should do this or that or it might be a more practical form to say we’re doing Agile but we have his regression and we don’t have enough test coverage to be able to get out of the regression okay so for now how do we do Agile with quotation marks assumed as a regression.
Jill: I gotta get a sound effect for all these air quotes that you’re doing.
Ben: I personally, I subscribe to a very practical form of Agile.
Jill: Yeah, all right so tell us more about that.
Ben: Which is, okay we have these concepts and really they’re philosophies and let’s explore, on an Agile team. Somewhere ideally between five to 10 people and the reason is from a practical standpoint, more than 10 people is a lot of voices in a room, too many voices, and let’s explore what the understanding is of everybody in the room and if we present them a goal or a shared vision how do we rally towards that? And you may find that there are people who want to be very, very pure and there are people who are more reluctant. And so the practical Agile form is irrespective of whatever you were preaching, teaching, advocating for, it’s the okay, okay, we don’t necessarily have to agree but let’s align on what are we doing next. And so pulling people into that process and making them a part of it is a really big part of that.
Jill: Yeah and I think it’s important too to acknowledge that people don’t have to be exactly the same, you don’t have to come out of that, those meetings with complete agreement on the approach or what everyone thinks is the best way forward. All right I’m gonna try and say this again, I think there’s value in having those different perspectives in the room. I think when you’ve got the people who are more pragmatic and have that more purist approach, they’re driving one voice but when you have kind of the outliers and the people who are coming with maybe a more unconventional approach. Those creative work arounds that they bring to the table while they might slow things down a little bit, they also, they’re bringing in this creative aspect that is helping with the problem solving activity, and so balancing each other out I think is a valuable thing.
Ben: To your point, different perspectives is huge, especially for engineering groups because engineers, we tend to think oh engineers very different. Well, we’re within the overall public, we are very slight, small chunk. We all think sort of alike, the reality is and you’re not gonna find someone who thinks diversity could be a greater strength. I personally given my chef background I see process and tooling and collaboration and standards, all these things as key elements and that diversity that people bring to the table, is huge to help people with that.
Jill: Yeah.
Ben: I actually often time find that it’s the dissenting voices where those are the real nuggets. If you’re a project manager and you’re worried about a risk for delivery, it’s gonna take us four months or six months to deliver on something, it’s the people who are raising their hands saying, Hey, wait a second have we thought about blah, blah, blah. Those are the things that are gonna blow up your plan, if you’re talking about a design, it might be the one person who’s a little bit quieter and then they happen to raise their hand and chime in and ask a question that maybe you should look at this thing and talk about it a little bit more. I don’t know why we expect, in Agile, why would get agreement. If I decide to drive from here to Montreal, there’s five different routes we can take, and if I throw five different people in the car I can almost guarantee you we’re gonna have differing opinions on how to go about doing that. So why would we have the assumption that in an Agile conversation that we’re gonna align around something?
What’s important and I think people fail to realize this and realize the importance of learning the tools, is how to move forward. Okay, we’ve discussed this particular topic, we think we want to build this feature, there’s three different ways of doing it, we can schedule another … we’ve now run out of time, we can schedule another meeting and continue to discuss this or perhaps we can come to an agreement and say, Okay, let’s try doing this. And then try that over the next couple of days or the next sprint for instance. I’m a big believer in this I propose methodology, I think you and I have practiced this before when we-
Jill: I think a little bit yeah.
Ben: Where you raise your hand … someone … you’re having a vigorous debate with something and someone raises their hand and says, I propose, blah, blah, blah and it’s just their opinion and then you vote. And the reason is the vote basically forces an evaluation of where you’re currently at and what I often time find is you probably, without a vote, you’ll probably debate til you’re blue in the face.
Jill: Yeah, you fall down this black hole of theory.
Ben: Right and you’ll debate for a whole hour.
Jill: Yes.
Ben: Whereas you could have just got to a place where you got to alignment around how to move forward within 10 minutes and then tackled the next problem.
Jill: Yeah and I think that speaks to the nature of Agile too, cuz going back to your analogy about driving from Boston to Montreal. You could spend an hour debating what that route is all the way there, between those two or you could start out and say, Okay, well let’s at least drive to this point and then figure out the next step from the there and maybe circumstances have changed.
Ben: Right, I’m hungry.
Jill: Yes.
Ben: So maybe, let’s take a vote who wants to stop at McDonald’s?
Jill: Exactly.
Ben: Three people vote out of five, okay we’re stopping at McDonald’s absolutely.
Jill: And any engineer will tell you circumstances change every single day between design changes that come through, customer needs that come through, that kind of stuff and so you could invest the hour and be committed to this plan but you know that’s gonna change before you’re gonna be able to finish it.
Ben: So this is something people don’t usually talk about but I think that it’s critical, Agile basically gives us an ability to adjust more quickly for the things that we don’t know. And the reason why you have a two week cadence is because A, it’s not that long. B, it gives you a regularity to be able to evaluate to say, Oh, two weeks ago we didn’t know something, now we know a little bit more, does that change what we were planning? And if it doesn’t you continue and if does you tweak. You can sort of think about this in terms of, going back to the Montreal example again, maybe it wasn’t, I want to go to Montreal maybe it was I want to go on a vacation to somewhere different. And so we make the assumption as a group, okay we’re gonna go to Montreal and we’re gonna have fun and go experience something different and as we get closer, we’re talking to people or someone’s on the internet, and then realize and we’re learning into it that maybe two people have been to Montreal before so it’s not really different for them and maybe we end up deciding we want to go to Quebec City. Which, is a totally different direction and that’s actually okay.
It allows you the ability to end up in the ideal place sooner without wasting a lot of time and I think that’s one of the things that businesses don’t realize, that it doesn’t take you necessarily a whole year of investing three million dollars to say, Hey, we have a theory and we’re gonna test this out and the proof of the pudding in whether that theory was right is customers will pay us money and we can make money off this. It’s we’re gonna learn into this and then a year and a half down the road we end up in a very different place but that’s actually way better because that’s where we wanted to be in the first place.
Jill: And that’s maybe one of the harder aspects of Agile is you don’t get to tell that person, Okay, yes, we will be there in six months, we will have this released. It’s we’re learning into this, we’re working towards this but there are a lot of unknowns yet. And so it’s kind of that, having the leash to go do what you want to do and do what you need to do and do the exploratory work without necessarily committing to some of those harder deadlines.
Ben: Right and so what you described earlier as, going back to the Agile-ish thing, and a lot of organizations struggling with this. I’ve been giving this a lot of thought, this is not uncommon, this is by far in large the majority of what you see, which is why Agile is hard as an adoption and also why you hear this feedback from all over the place. The reality is that organizations, they’re businesses and from a business standpoint whether you’re talking about sales and marketing or how you run a business, how you have a finance group where you have bills to pay, you do yearly planning. Sales, they’re all driven by sales forecast and quotas and are we on track or not and did that sales methodology work or did that salesperson do a great job and if they don’t, we continue to invest in the areas where we get traction and if we don’t then we invest elsewhere.
Well the problem is, is that businesses as a whole don’t adjust. Often times you’ll see Agile being led from the engineering side but then the business side doesn’t really make that large of an adjustment, now if you have to be into a work that happened to be literally top down, CEO, we’re going Agile everyone whole hog, that’s a really powerful thing but that’s the tiny, tiny, tiny minority. And so one of the challenges that I’m looking at right now is, okay now that Agile within engineering, and certainly my engineering teams, are pushing forward hard in terms of exploring these new capabilities, and this flexibility, how does that adjust how the business operates?
Jill: Yeah. I even wanted to ask how do you communicate that out and teach other teams really what maybe they’ve heard about going Agile, but they don’t truly know what that means and how that’s going to affect how you interact with that business unit? I just finished talking with an organization that’s having this challenge. Their DEV team is trying to go Agile, but the other business teams that they work with just really are having a challenge understanding what that means, and wait a minute I can’t get everything that I used to get from you before, because there’s more ambiguity in the process now.
Ben: Right.
Jill: So, how do you manage that?
Ben: An example of that would be sales, we need to know what’s coming out next quarter and the quarter after, so tell me what you’re gonna build. As an engineer way down on the totem pole, I don’t know. I only have to deliver two weeks out, I’ll let you know at the beginning of the spring. The business can’t operate like that. This has been challenging, I’ve done this a couple of times where we’ve done an Agile introduction, and unless people on the other side have actually done Agile before and know sort of what we’re talking about, and the role that they can play or help, it makes it really tough. On a personal level often time this ends up translating to me going out and reaching out to other leaders on those other teams, whether it be support or knowledge, the implementation teams, sales to say, Hey, we’re doing this Agile thing. Oh yeah, I’ve heard about that. That means you can get a beta, that means you don’t have to wait until we release this thing. At the end of every two weeks I can give you what’s coming down the pipeline. I can send you an email saying, This is what we’ve worked on and you can tell me whether you like this thing or not.
Heck, if we wanted we could expose our customers to that, do you think a couple of them might find that useful? Ooh, that’s something I hadn’t thought about before. Now, the challenge is that takes a lot of work and time.
Jill: It does, it’s a lot of coordination there, because you’ve gotta get feedback from those people too.
Ben: What you can do is you can build these capabilities and then publicize them, make it available. I’m actually finding that there’s actually a lot of openness when you start talking about capabilities like that.
Jill: That’s fantastic.
Ben: The challenge is around the alignment piece. Now we’re all of a sudden starting to talk about scaled Agile. In the purest form like SAFE for instance is a particular framework that’s getting a lot of traction usually meant for huge organizations, like organizations of 10 thousand, 20 thousand people, 50, a 150 SCRUM teams. How in the world do you keep all those folks aligned? This would be a company like Boeing or AT&T for instance. We think of it in terms of engineering, but it’s broader than that. If we’re really talking about customer delivery, you’re talking about everyone who engages with the customer. Internally I have customers who are the people who engage with our customers. Externally it’s the customers themselves. Those people are all stakeholders that feed into the Agile input. That means that they need to be part of the process beginning all the way to the very end, it’s this whole cycle when we’re creating this feedback group.
One of the things I’ve actually been experimenting with lately … You’re starting to see more organizations try out our skill mechanisms. So for instance a few weeks ago we actually ran a summit. We actually flew a cross functional set of people to headquarters, and we sat down and talked about what are the personas, what are the challenges they’re facing, why are you building these things? We did a retrospective on what we had delivered before. Let’s make sure we don’t make the same mistakes, and Let’s make sure that we cover some of these gaps that we have. The most important piece was a planning exercise. We did it as a more yearly planning exercise, but you certainly can do this from a release planning exercise where you’re looking at a period, let’s say three to four months. What are we going to deliver in the next four months, and what are the roles that each person has to play in their prospective area?
For instance if we’re going to do a beta … Well the sales folks or the support folks gotta be able to reach out to our customers and figure out who is the beta going to. How do we manage that data? How do we run that program? These are program level, which lead into portfolio level Agile tools that when we talk about Agile people don’t really think about. In my opinion for any medium size organization or larger it’s critical to think about how an Agile transformation includes the business as well.
Jill: Yeah. No, I think that’s huge, and I think that if you’re trying to do Agile in one group … Other people may have rejected the idea, tried it in the past, didn’t like it, or have modified their own Agile-ish version of Agile then … I did the air quotes too, I need sound effects. Then it doesn’t work in a vacuum. You’re gonna need input, you’re gonna need some buy in or at least some acceptance of a changed process from the other business units that you work with.
Ben: You know when you’re hitting that sweet spot in Agile when two things basically start happening. A, you start noticing change happening quicker, and B, where you end up isn’t actually where you thought you’d end up when you started. That’s a good thing, not a bad thing. It means that you learned into it and realized oh, we need to make some adjustments here and there.
Podcast Transcript, Part 2: Jill: Alright, so I want to draw upon your wisdom as a chef. What parts about being a chef and working on a team in a kitchen parallel over to working with your development teams and being agile?
Ben: Sure. For me?
Jill: Yeah.
Ben: Everything.
Jill: Alright. Tell us a little bit more about that.
Ben: Being a chef, it’s not a title, it’s just who you are. It’s a perspective that is pervasive through and through.
Jill: Okay.
Ben: So let’s break it down in terms of at the highest level, what does being a chef mean? Being a chef basically means you’re delivering a great experience. Now, great … There’s a couple words that are important, right? Delivery, meaning there is some expectation around timing, around cost, around what you’re going to get on the other side. Great is highly subjective. Great is a term that’s highly contextual. It depends on whether I’m eating Indian food or fancy French food, or Chinese food. My Chinese food, I expect to be cheap. The bathroom would probably be sort of dirty, and it would be really tasty. Very different experiences.
With respect to agile, and as an agile leader, what you’re really doing is the same thing. You’re trying to think about a particular problem or a customer, and you’re trying to help them have a great experience, solve a problem, do things cheaper, easier, quicker, faster. Now, where things are very aligned are with the nature of the role. A chef is someone who’s spent years, decades, learning the craft, learning the craft of building an ecosystem to be able to have this great delivery pipeline. You are learning the ingredients, learning the tools, whether it be a knife or the application of heat in its various forms. And how do you manipulate things to transform it, almost will it into this product that gets put on a plate?
And then you have a bunch standards and checks to say, Is that what I consider to be great? And if it’s not, maybe you go yell at the cook who screwed up. And then you go deliver that thing, and you do this every single day. You do this a thousand times per night. You play this game 360 days a year, and at the end of the night, what people don’t realize is the people who run the restaurants end up going back and thinking about, Okay, how that night go? Was it a good night? Was it a bad night? And oftentimes it’s actually a bad night. Why was it a bad night? What do we have to change?
Jill: So those are mostly the retros that engineering teams do after a sprint?
Ben: The difference is the time frames. On the engineering side you’re building something, you’ve got tools, you’ve got GitHub, you’ve got your IDE, you’re writing code, you’re building something, you’ve got QA doing validation, or maybe the devs are doing a sanity check on the thing that you’re getting out. You’re deploying and releasing this thing, and you’re putting in front of people and saying, What do you think? From a leader’s standpoint, it’s very, very, very similar. You are basically practicing and honing this craft around iterating and delivering that value.
Jill: Yeah, great. Well that’s always a fun analogy. I know we’ve had this conversation many times, but we like talking about the infusion of the techie side of your history with the food side of your history.
Ben: Right. I’ve worked in five-star restaurants, I’ve worked in restaurants that are ridiculous. I remember … I’m not gonna say the chef’s name, but there’s one French chef in New York. The chef had us, he was complaining that the plancha, it’s this flat, large, three foot, square, steel hotplate. He was complaining at the end of the day that it was dirty, okay? Now, you’re cooking on it with oil and grease, of course it’s gonna get dirty. And he wanted it to look like a mirror, none of us thought it was possible. And we watched him, 15 of us stood around and watched him, with the green scrubby, scrub and clean one square inch for 10 minutes. And at the end of the 10 minutes, that one square inch was polished like a mirror. And that he said, Go forth and do that. And then for the next hour and a half, all 15 of us scrubbed away to make this plancha shiny like a mirror, knowing full well that the next morning we would come back in, and turn it on, and pour oil on it, and it would look like a mess again.
What the heck? Why? Well, because for that chef, that was where the standard was. That was the highest end of cooking. And it translated to these meals, these dishes and plates that would be … they would look and be absolute perfection. Well, ironically on the mobile side, you could sort of do the same thing. I, as a mobile engineer, I’ve sat there on a map. I remember, there was an icon on a map, and I wanted to make it clear that you physically are here. Here’s a pin. And I spent an hour messing around with the timing of the pin to have it drop in from the top and have it bounce.
Jill: Yeah, those animations.
Ben: Right. And the point was I wanted it to feel organic. So you’re just sitting there, messing with the animation, trying to get it to this right spot. And when you finally hit the sweet spot, you knew where it was because it was sort of magical. It was sort of like, Ah yeah, that feels right.
Jill: Yeah.
Ben: And so that same level of focus, tenacity, insane standards-
Jill: Attention to detail.
Ben: Attention to detail, you can apply to almost anything.
Jill: Yeah, awesome. I think we’ve got time for a few more questions here. I think we’ve talked a lot about agile, and it’s been awesome to learn how Everbridge has approached it and really had some success with it. But out of curiosity, what’s one of the things about agile that still keeps you up at night as a manager?
Ben: Sure. This is a challenging one. One of the things in agile that I worry about is momentum. We talk about empowerment, and collaboration, and shared context, all the good things that come about from this. But we also talk about the practical aspect of things.
Jill: Right.
Ben: And whether people internally on the teams, or externally can get really frustrated is when there’s a mismatch in expectations. When you’re trying to accomplish something and it’s not really where you really want it to be. There clearly is an overhead for any kind of agile adoption. The practices you pick, there’s somewhere between a, I’d say, 10 to 25% level of overhead, for just the meetings, et cetera, et cetera. And the worry is, is that if you’re, in an extended period of time, if you’re not actually seeing the benefits of those things, you lose a little bit of momentum, you lose a little bit of that energy, of that excitement, of that engagement in some ways. You’ll notice this because of the fact that the retrospectives, it’s just a meeting to talk about what went well, what didn’t, and people are just sort of like, Eh. You lose that momentum of improvement.
Jill: Yeah.
Ben: So I worry-
Jill: And it sounds like there’s almost a loss of personal investment.
Ben: Oh, absolutely. If there’s an element to agile that people should pick up on, I know people talk about the ceremonies, they talk about what the benefits. It’s the empowerment piece, it’s that ownership piece.
Jill: Yeah.
Ben: And engineers are great, because oftentimes they want to deliver something, and they want to be part of it. They don’t just want to write code, they actually want to do something great. So, if you can create that environment … As an engineering [inaudible 00:08:20], this is what it’s all about, right? Creating that environment where people are engaged, people feel responsible for, people are willing to monitor what’s out there and iterate on that. That’s what you really want to do, and you want to keep that ball rolling, basically. And there’s so many things that can go wrong, that can stall the entire effort. So it’s really about nudging things forward, keeping a pipeline going, keeping people enthused and engaged and motivated.
Jill: But also trying to keep your finger on the pulse of that. Is the momentum up to par? Is there something that’s pulling it down or slowing it down?
Ben: Well what’s funny is that people who are even external, they get a feel for it. If you have any engagement with an agile team whatsoever, and you’re seeing the outputs. Let’s consider the agile team as a black box. You’re putting a bunch of stuff into the black box, and you’re seeing stuff come out. As leaders and managers in general, VPs, whatever, you get a feel for, Does that feel healthy or not? As an agile leader, there’s this in between where you actually have context, because you’re engaging with people. But how do you bridge that with the external folks?
I’ve actually been focusing a lot on metrics lately. How you measure that feeling of, Are we on track? Are we not? That empowerment piece. In some ways that’s a survey; in some ways you could even do things like look at your retrospect. Let’s say you take notes during the retrospective, you can see who are the ones, who are the people who are chiming in all the time. Those are probably the ones who, A: maybe by nature tend to be little more vocal, or B: if the quiet ones are chiming in, actually, that actually means that they’re sort of engaged. That’s a healthy thing.
Jill: And one thing I know that we talk about a lot, especially in our roadmapping processes, is this value behind shuttle diplomacy. And you can have the big meetings where you’re getting group feedback, but also, for the people who didn’t speak up you’re going to them one-on-one and getting their personal pulses, and you’re able to get into those deeper one-on-one conversations, where they might be a little bit more honest about how they see things going, as a team, and be willing to give you that feedback on a personal level, and be able to get all of those perspectives individually, and use that collective information that you gathered from all those one-on-one conversations to really see, okay, are there trends that are happening? Was there a flag was raised here that is something we need to pay attention to?
Ben: Right. Let me share with you two perspectives on this one.
Jill: Yeah.
Ben: The first one is really around the role of the scrum master, and how critical this is. Often time we’ll be like,Oh, we need a scrum master. We’ll just arbitrarily throw so-and-so at it. Well, it’s a set of skills that’s actually sort of tricky to learn. It doesn’t come naturally.
Jill: Right.
Ben: Even if you’re sociable, you gotta learn these tools. I’m talkative, as a scrum master I have to learn how to step back and create room for that conversation.
Jill: Yeah.
Ben: So having a good scrum master in that role, being very observant is helpful. Let me give a specific example. Having video is helpful. One of my teams right now doesn’t do video, they’re just uncomfortable with it. It’s just a cultural thing. However, as a scrum master, as you’re looking at people, if you’re in the same room you can pick up on who’s checked out, who’s on their phone, who’s rolling their eyes, who’s got their arms crossed, who’s really engaged with the conversation, all those kinds of subtleties. And you can use that to say, Hey, so-and-so looks like they’re not really cool with that idea, or their brow is furrowed. Hey, so-and-so, what are you thinking?
Jill: Yeah.
Ben: And pull them into the conversation. So that’s one thing that’s really important.
Jill: We advocate for that all the time when doing customer interviews, but it makes just as much sense when conducting internal team investigations.
Ben: Absolutely. That’s actually how you get to a healthier place. Dissent is not a bad thing.
Jill: It is not. If I don’t hear that dissent, whether I’m testing a new idea, or we’re talking about maybe a business change, or anything. If I’m not hearing that dissent, or at least question that might hint at it, then I know people aren’t thinking about it seriously. They’re not thinking about it deeply enough yet.
Ben: Right. Flip side, the second perspective I have. You had suggested a scenario where publicly you’re doing one thing, and then more privately you’re creating that trust, that safe place. What’s your honest opinion? What are your worries?
Jill: Yeah.
Ben: Oh, we’re about to tackle this really big thing. What are you concerned about? Is there something that you happen to know, that either from a personal standpoint, just a feeling, or maybe it’s that you happen to know a piece of information that you’re not as comfortable sharing more publicly. I’ve actually found more recently that I have a scenario where I have a scrum master who’s learning the ropes, natural at it. And he can carry forth that sort of more agile, the pure agile form, to say, Hey, we’re trying to challenge this and tackle it on this way, and that’s very powerful thing. And on the side, I’ll get feedback from various people, or I can individually have one-on-ones and get a feel for where the pulse of things are and where the concerns are.
Now the reason why this is useful is because the Agile Manifesto and all of the rest of that never talk about the role of the engineering manager. And there’s some people who believe that if you’ve done agile right, the role of engineering manager can go away. No, turns out that engineers, we still have careers, we external stuff to manage, dependencies. There’s a role there, but one of the key places were in engineering, I, as an engineering manager and leader can help is hearing that shared context, but digging down deep and hearing that individual, personal perspective. Now, that means one of two things, either, A: you’re taking those inputs into consideration and helping use that information to shape the overall roadmap, or the overall concerns, or B: we had talked about practical agile, and sometimes there being a couple holdouts. Sometimes you can use that as a mechanism to … Publicly we say one thing, individually we nudge, nudge. Help me understand why you feel the way you do and get them to that place faster. If you do it right your agile adoption happens way faster than it would if you just naturally let it happen.
Jill: Yeah, great. What is a piece of advice that you would offer to new product manager?
Ben: Oh wow. Your product managers have a tremendous responsibility. They own the backlog, they own the priorities, they’re supposed to represent the customers, and understand the personas, and the business reasons, and do the juggling act. And then they’re supposed to write all these stories that are supposed to feed these scrum teams? That’s tough, they’re juggling a lot. Well, if there’s a piece of advice I could give it would be … And I’ve had this experience twice now, and so I know it’s valuable. It’s that trust. Trust your engineering teams, trust the folks on the other side wholeheartedly. Feel out the areas that share context, and you’re gonna find that individuals bring their own interests and B: their own skill sets to the table that you can lean on.
When you actually can build things together as a group, this is the agile, getting away from documentation. Shared context, let’s talk about this and understand what we’re trying to build. What you can often time find is that your partners can actually champion and drive things on their own, and then as the product manager, that enables you with more ability to be able to have more flexibility to go, Okay, now that we’ve got these different areas covered, I can go focus on some of these other areas that we don’t have as much focus on. What I’m finding, in general, is that when a team and your PO can really figure out that sweet spot and that balancing act, great things happen. The evolution and the roadmap actually changes more quickly, and you learn into it much more quickly. There’s a lot less wasted time and effort.
Jill: Yeah. I think you hit the nail on the head with the trust component there, because when we were talking a couple months ago with Nate Walkingshaw about product leadership, and his big thing is, if you grant someone else your trust and offer that up on a silver platter, they are going to take that and hopefully offer their trust back to you. And that’s how you build that bridge, that’s how you build that relationship and get into a deeper level of collaboration.
Ben: Right. Collaboration means that there’s a shared goal, which means … And I get the more traditional engineering perspectives, where sometimes you get this healthy pull between quality, dev, product requirements, [inaudible 00:17:57], and the idea being that you land in the sweet spot. Well, true, but the thing is, is that it can be a little contentious. I find, and this is my personal style of working, but I find that it’s more effective to basically come to the table and say, Okay, what we want to accomplish for the year? And there’s different priorities, and that doesn’t mean that we have to do all priorities all at the same time, and let’s have some flex, let’s give and take.
When do we invest more in design? When do we invest more in addressing our customer complaints? When do we invest more in innovation and exploring new capabilities that are wild, and wacky, and way out there, and balancing that with the feature set. Maybe there’s a way that innovation can really inform and accelerate a better experience for the feature set that we’re talking about. So it’s that balancing act that has to happen, and it only really comes about when you have that trust.
Jill: And it’s important to ask that question, because there’s no one right answer all the time. There’s this back-and-forth, and it’s very situational, so you’ve got to really explore it for the circumstances that are in front of you.
Ben: Like I said, agile’s an evolution.
Jill: Yeah, cool. Well Ben, thank you so much for coming in today. I always enjoy talking with you. I feel like we could talk for another few hours. But appreciate this, and hopefully we can have you back sometime to talk some more.
Ben: Happy to drop by anytime and share some perspectives. It’s been a lot of fun, thanks.
Jill: Alright. Thank you very much for tuning into this week’s Product Hero, and we’ll catch you next week.
The post Product Hero: Benjamin Ho, Senior Engineering Manager at Everbridge appeared first on Fresh Tilled Soil.