0:00:00Welcome to Under the Radar, a show about independent iOS app development.
0:00:04I'm Mark Orment.
0:00:05And I'm David Smith.
0:00:06Under the Radar is never longer than 30 minutes, so let's get started.
0:00:09So today I wanted to talk about, kind of related to a recent discussion about trying to get,
0:00:14you know, watch podcast playback, and I did a blog post this week basically saying, like,
0:00:18here's what we need to do this.
0:00:21And I kind of wanted to talk about the process of trying to affect change with Apple and
0:00:27their products and their stores and everything else.
0:00:30And this takes a lot of different forms.
0:00:32I think the first thing I wanted to talk about is how to know what you can and can't change.
0:00:40If you're going to try to get something done at Apple or try to get a bug fixed or try
0:00:44to get a feature done or try to get something, some policy changed, it helps to know the
0:00:49company well enough to know basically what fights aren't worth fighting and, you know,
0:00:54what's not worth your effort and what is.
0:00:57If you want to, like, get bugs fixed or, like, get API changes to some degree, that stuff
0:01:03is usually possible.
0:01:04Those are fights worth fighting.
0:01:06A lot of people try to get unfair or arguable App Store rejections overturned.
0:01:13I think it is worth challenging unfair or arguable App Store rejections sometimes.
0:01:20Unfair, to me, means that the rules were not applied correctly or maybe consistently with
0:01:26other apps.
0:01:27Unfair does not mean you disagree with the rules.
0:01:30That's a different situation.
0:01:32So if you've been rejected for some way that you think is actually unfair, like the
0:01:35rules were not applied correctly, that is usually worth, you know, filing the appeal.
0:01:40And if that doesn't work, then maybe going public with it.
0:01:43As for arguable App Store rejections, that's very broad.
0:01:48That could be a lot of things.
0:01:49If you keep hitting rules that are arguable, maybe you should rethink what kind of apps
0:01:55you're trying to make because generally I recommend that you don't build a business
0:02:00or attempt to build a business on living on the edge of a rule.
0:02:04You know, if you stay away from the edges of the rules or the vagaries or the exact
0:02:08interpretations of certain rules, you're generally going to be happier and it's going
0:02:11to be easier to do business both, you know, immediately and going forward.
0:02:15So, those are generally, the things that generally you can affect, bugs, APIs, and, you know,
0:02:23bad App Store rejections.
0:02:25And, you know, what you can change can take a number of different forms.
0:02:28You know, you can obviously, you know, with App Store rejections you can do the private
0:02:31appeal which I definitely recommend you do first.
0:02:34Those appeals often work.
0:02:37I've heard a lot of stories from friends and other developers who have appealed things
0:02:42and they do get overturned.
0:02:43What's your experience with that?
0:02:44I have many experiences with that and in general I would say that is, I've had, usually
0:02:50we can come to some understanding.
0:02:53Like often the sort of, A, I think that Apple appreciates the working it through with them
0:03:02first in that sense of, I've dealt with all kinds, a variety of rejections for a variety
0:03:07of reasons and work, you know, I think the impression I've gotten is that you get farther
0:03:13by not running to the press, not trying to make a big fuss.
0:03:17Like maybe that is the final straw like that you do down the road but that initially you
0:03:23work with them and you work with them patiently and, you know, with politeness and respect
0:03:28and you work through it because typically they're coming at, you know, it's like
0:03:32the issue, unless you're just doing something wild and off the reservation, like usually
0:03:37there is some sticking point that they're stuck on that you have to work out a way to
0:03:41work around.
0:03:43There may be a small change that you can make to your app that will affect that change and
0:03:48if you handle that in a respectful way, in my experience, the appeal process and working
0:03:54those channels directly will often get you somewhere.
0:03:58Sometimes it may not be exactly where you would like to be, sometimes you'll end up
0:04:02having to make changes to your app that may limit its functionality or make you feel like
0:04:07you've lost a competitive edge or something but by and large that process does work and
0:04:15while it can be frustrating in the moment and I've certainly been very emotional in
0:04:20the moment, you know, when I work on something for months and you submit it and then it gets
0:04:27rejected for a reason that you don't agree with, like that's a very emotional thing
0:04:30but it does ultimately work through and just being respectful, making sure you're out
0:04:36of control, making sure you're understanding the subtext around what they're saying I
0:04:41think is something that I've found to also be helpful that often they're saying one
0:04:45thing which is correct but it's because of something else, like there's an underlying
0:04:50reason that you're trying to find and the better you can try to understand that or ask
0:04:55probing questions around that, the better you're able to make a change because usually
0:04:59what I've ended up happening is it's unlikely that they'll be like, "Oh, actually
0:05:04we made a mistake, you're fine now." Maybe they will, maybe they won't. In my experience
0:05:08usually it's a more likely scenario is, you know, here's this small change that I can
0:05:15say, like, if I did this, would it be okay then? And they often say, "Well, we can't
0:05:19pre-approve it but that's heading in the right direction." And then I make a change,
0:05:23I resubmit and everything's fine. But it does work. Like, I've gone through that
0:05:27process enough times and gotten apps that were rejected, ultimately approved, often
0:05:33with relatively minor changes. So it does work and it's something that I would encourage
0:05:37you to do and it's definitely the place to start. Thankfully, I've very rarely, if
0:05:42ever, had to try to make a big fuss to get something to happen because you're going
0:05:48all in at that point. It's either going to work or it doesn't. And even if it does
0:05:53work, you're putting your app in kind of an awkward situation for its future going
0:05:57forward. If it was ultimately accepted but not under the best circumstances, what does
0:06:04that mean in six months when you submit a big update and you're kind of doubling down
0:06:08on the features that were questionable to start with? So that's certainly my experience.
0:06:13And it works and it's an encouraging process that's gotten a lot better than back, whatever,
0:06:19eight years ago when things were a much more—like, I don't think on Apple's side they had
0:06:26quite dialed in their process there to the degree they have now.
0:06:30That's generous.
0:06:31Yeah, it works better now.
0:06:33Yeah, it's way better now. All right, so those are kind of the things that you can
0:06:38affect change with. There's also a lot of things that you can't really affect change
0:06:43and that your effort is probably wasted and that might even annoy Apple if you do it.
0:06:47And this includes things like trying to get major app store policies or business rules
0:06:54changed or get exceptions for yourself. This is things like getting around the 30% cut
0:06:58for in-app purchases or subscriptions or things like that. This also includes campaigning
0:07:04for major technical changes that are very unlikely to do, so things like allowing all
0:07:09iOS apps to run in the background indefinitely. If you just want to have a persistent daemon
0:07:13running on iOS, that's never going to happen. They're never going to allow that.
0:07:16Also, things that combine both of these, like both app store policy and major technical
0:07:21things like allowing sideloading of iOS apps, that's probably never going to happen either.
0:07:27I respect people who try to make that case to Apple, but I think it's futile. I don't
0:07:32think it's ever going to happen. And also, kind of obvious things like anything that
0:07:37could be potentially abused, like even if you have good intentions on something you
0:07:42want to be able to do, you have to think about what could a bad actor do with that same ability.
0:07:48So anything that could be abused for privacy violations is a big one. So things like access
0:07:52to restricted hardware, things like face ID, touch ID, secure enclave stuff, access to
0:08:00the restricted privacy sensitive APIs like location or microphone without prompting the
0:08:05user, stuff like that. If you need those things, you're going to have a hard time. That's
0:08:10probably not a great way to spend any amount of effort trying to affect change at Apple.
0:08:16And also, there's a big one that's kind of sad, but it's reality. And that is if
0:08:22you're trying to get bug fixes or API changes for either very old or very low priority APIs
0:08:31or platforms. And so this would include low priority platforms in general. I would say
0:08:37things like TDOS is pretty low priority. I would say unfortunately most of Mac OS is
0:08:41pretty low priority. So if you want some API enhanced on a low priority platform, you're
0:08:48going to have a hard time doing it. Even a bug fix. If it's not a really critical bug,
0:08:53you might have a hard time even getting anybody to care about that or to have time to work
0:08:57on it. Because even if you make a great case for some kind of change like this, if nobody's
0:09:03working on that thing, there's no one to fix it. It's not going to happen. A lot
0:09:08of Apple projects will go either completely unstaffed or staffed by one person who also
0:09:16worked on 17 other things for years. Who maintains a dress book? It's probably one person who
0:09:24also maintains six other frameworks. And even when you have a small staff on a project,
0:09:30they might not have time to do your bug or your enhancement. Because every year when
0:09:35Apple does big new headlining features that they market to customers or they have new
0:09:41hardware that things need to take advantage of or be adopted for, all those one person
0:09:47or small teams that are working on old apps or less high priority things, they have to
0:09:56adopt those marketing features first. Those will always take priority over old enhancements
0:10:01or bug fixes they also want to do. So for a lot of projects at Apple, there's literally
0:10:07not time for much of anything else. So if you file some bug with iWork, iWork is a great
0:10:14example because it has a staff. iWork is staffed. But iWork is involved in so many marketing
0:10:22features every year that it has to adopt or that it has to make sure it works with. So
0:10:27any changes to iOS, changes to the multitasking, the file picking, document handling, changes
0:10:32to iCloud, collaboration, sharing. iWork is involved in all sorts of crazy stuff. And
0:10:38so if you have a feature request or some kind of minor bug in iWork, that's going to take
0:10:45way lower priority than all the crazy marketing stuff they have to do every year just to keep
0:10:50up with Apple's own stuff. So there's a lot of projects at Apple for which you can file
0:10:55bugs or you can write a nice blog post saying that you wish this obscure bug would be fixed
0:11:01or that you wish this API was different. But if it's a low priority or old API or project
0:11:07or if its staff is way too busy doing other stuff, you're going to have a really hard
0:11:11time with that.
0:11:12>> And to that end, I think also it's hard for us to have a sense of what the future
0:11:19is going to hold. We're at a disadvantage to Apple in the regard that they know what
0:11:27next year's release is going to look like and have a good idea probably of what the
0:11:31next release after that is going to look like. And so if you're filing bugs against frameworks
0:11:35or things that Apple knows they have different plans for in the future, then it's going
0:11:42to become even harder likely for your bug or your issue to be addressed. And maybe in
0:11:48the best case it will be rolled into the changes they're making or if they're replacing the
0:11:51framework with something better. Those types of things may come into play, but it's the
0:11:56awkward thing too. All we see is the end results and we can't know what's coming in nine
0:12:03months whereas Apple does. And so it's entirely possible that a bug comes in for a framework
0:12:07and they're like, "Yeah, we're not going to fix that because in ten months that framework
0:12:13is going away or it's going to be replaced with something better. They're rather going
0:12:16to put their engineering effort into that." And so that can often, if we file a bug, we
0:12:22can do all the right things. If you have an example project, show how to reproduce it,
0:12:27it may never get fixed. And the reason why it may never get fixed could be any of the
0:12:31things you were just talking about in terms of staffing. It could just be a question of
0:12:34priorities or the future. It's impossible to know exactly why it happened and that can
0:12:39sometimes be frustrating, but that's just the reality I think.
0:12:42We are sponsored this week by Blue Apron, the number one recipe delivery service with
0:12:46the freshest ingredients. Blue Apron's mission is to make incredible home cooking accessible
0:12:51to everyone and support a more sustainable food system. They set the highest standards
0:12:55for ingredients and they're building a community of home chefs. For less than ten dollars per
0:12:59meal, Blue Apron delivers seasonal recipes along with fresh, high quality ingredients
0:13:04to make delicious home cooked meals in forty minutes or less. See, our show's a little
0:13:08bit shorter than that. It's pretty good.
0:13:09Yeah.
0:13:10Each meal comes with a step by step, easy to follow recipe card and pre-portioned ingredients
0:13:15and they ship the exact amount of each ingredient that the recipe requires. So they are reducing
0:13:20food waste in the process. And Blue Apron's freshness guarantee promises that every ingredient
0:13:25arrives ready to cook or they will make it right. I personally have been a Blue Apron
0:13:29customer with our family for, oh geez, I don't know, maybe two years now? It's been a while
0:13:34now, even before they were sponsoring any of our shows. And we just love Blue Apron.
0:13:39Their recipes are fantastic. We have really become better chefs as a result of having
0:13:45Blue Apron. It is awesome. We've tried so many new foods, new cuisines, things we would
0:13:50never even order in a restaurant that all of a sudden we're cooking. And then they're
0:13:54delicious and now we go out and order those things in restaurants. It expands your horizons
0:13:59for food and also it really does make you a better cook by just having so much more
0:14:03experience. And on nights that we don't have Blue Apron, we make better things now.
0:14:08So you can choose from a variety of new recipes each week or you can just let their team choose
0:14:12for you and surprise you. You can cook meals like soy glazed pork and rice cakes with bok
0:14:17choy and marinated green beans, skillet vegetable chili with cornmeal and cheddar drop biscuits
0:14:21or garlic butter shrimp and corn with green bean salad and roasted purple tomatoes. There
0:14:26is no weekly commitment so you only get deliveries when you want them. You can cancel them at
0:14:30any time. You can skip some if you're going to be out of town or whatever. It doesn't
0:14:33matter. So check out this week's menu and get three free meals with your first purchase
0:14:38including free shipping by going to BlueApron.com/Radar. You will love how great it feels and tastes
0:14:46to create incredible home cooked meals with Blue Apron. So get started today by going
0:14:49to BlueApron.com/Radar. Thank you to Blue Apron for supporting this show. Blue Apron,
0:14:54a better way to cook. After all the discussion before of what you can change and what you
0:15:00can't change at Apple. Now I want to talk about how you actually, the best ways to affect
0:15:05change at Apple. If you're going to be doing something that's actually changeable, how
0:15:09do you do it? So first as we talked about a little bit earlier, you should start with
0:15:15private methods first. So very first thing with any bug or enhancement is file a radar.
0:15:22And this is a hard thing to do because the radar system is, it's almost punitive. Like
0:15:28it really is almost abusive. Like in how much effort they want you to invest into filing
0:15:35bug reports even down to things like making sample projects which they will almost always
0:15:39request for almost anything even if it doesn't seem to need it to the point where I almost
0:15:43think it's a delay tactic so they can just close more bugs and people don't do it. But
0:15:47actually I don't almost think that. I do think that. But anyway, so file a radar first.
0:15:52And the reason why is because radar is, it's Apple's bug reporting system and radar is
0:15:59how Apple passes things around and prioritizes things internally. So if you later want to
0:16:06write a blog post or email somebody in the company or bother somebody on Twitter who
0:16:11works there or something, if you want to like escalate things further, it really helps to
0:16:16have a radar number or series of numbers to point them to, to say look, this is what I'm
0:16:21talking about. Because then if they actually take up your case and if they want to prioritize
0:16:28something in the company or forward it to somebody else or get it to the right department
0:16:31or try to convince somebody that they should be prioritized, they are going to do that
0:16:36by passing around radar numbers to people. And so it really helps a lot if you have a
0:16:42radar filed. I'm not always the best at this and usually when they ask for a sample
0:16:45project I just get mad and just abandon it because I'm like I'm not going to waste
0:16:48my time doing this. You know, you should fix this bug. But that is the most effective way
0:16:52to do it. And that, you know, and so generally radar first and then keep things private first
0:17:00if you can. So obviously with App Store appeals, you know, do the private appeal first before
0:17:04you go public because most of the time you won't need to go public and that'll be nice.
0:17:08When you have, when you do need to go public, it makes your case a little more defensible
0:17:13to them internally if you can say, like if you basically tried to do it privately first.
0:17:19You know, similar thing with like when you're reporting security vulnerabilities. I feel
0:17:22like, I mean, I don't know much about that community, but I think it works in a similar
0:17:25way where it's like you try the private method first and then if it doesn't work, then
0:17:30you consider going public. Do you file radars and stuff for all your stuff or do you just
0:17:36work it out yourself? How do you do that?
0:17:38So I have a lot of I've found a great many radars over the years and they I think radars
0:17:44tend to take different forms. Like some of my radars are just straight up bug reports.
0:17:50Like I'm just saying I use this API in a way that it is documented that it should work
0:17:55and it doesn't. And like those ones are relatively straightforward. And you know, like that's
0:18:00I've that that's sort of the one side and the other side of the radars that I file tend
0:18:05to be and I write them this way actually now I write them. They're almost just letters
0:18:10like they're like like open letters to Apple saying or like guys closed letters to Apple
0:18:15saying I believe it was called letters. Yeah, it's like here's this thing that you know,
0:18:20like, hi, I'm I make these apps these are the and you know, this is something that I'd
0:18:25like to be able to do with them at a current API can't do and I try and give as much
0:18:29context and to sort of a try to flesh out the not just like what I want like not just
0:18:36the like the technical like I wish this API would do XYZ but I try and provide like real
0:18:42world situations and examples as to why you know, sometimes it's like in you know, he
0:18:47even like here's a link to my app like here you can go see where this would fit in like
0:18:52to try and build a case because as best I can understand and as you have I've several
0:18:57and for several friends who work at Apple like I know a lot of people that the impression
0:19:00I get is that like radar is this funny thing because we see this very kind of sort of terse
0:19:08opaque thing on the outside where we put things in and then we'll either get you know flagged
0:19:12as duplicate or nothing will happen at all for a long period of time but internally with
0:19:17Apple you know, they have a whole other sort of discussions and threads and things that
0:19:25are going on around you know, the radar that I filed that is happening internally and that
0:19:31is the part that I'm trying to you know, provide as much information as I can to make
0:19:36engineers within Apple's case or lives easy because the reality is with almost any change
0:19:41that we want you know, there's like there's gonna probably gonna be someone at Apple who
0:19:45thinks yeah, this is a good idea that might be other people who think this is not that's
0:19:49not such a great idea and they're going to be having you know, it with any engineering
0:19:53choice, there's usually you know, there's benefits and and you know, disadvantages and
0:19:58you know, it can they may be thinking even in a broader sense because they have to not
0:20:02just think of your specific case, but they need to think of the worst case of someone
0:20:06else using this API. But they're having this discussion internally and like all I'm
0:20:11really trying to do is if there is somebody who is going to be advocating for you know,
0:20:16for the change that I want, I want to provide that person with all of the as much as I can
0:20:22in terms of, you know, support and evidence to make that change happen. And so I just
0:20:27write it right as much of these this as I can. And it can feel a bit funny in the sense
0:20:31that, you know, the radar system is all about, you know, like, what was the expected result
0:20:36and what did happen and like it gets used, obviously structured for technical reports.
0:20:41But I find if I'm in filing an enhancement request, like that's what I do. I mean,
0:20:46it's so hard to know how the degree to which like that is actually effective, but it's
0:20:50just what I've over the years, what I've sort of gotten comfortable with doing, and
0:20:55I've never heard anything bad about it, in terms of like, I've never had them closed
0:21:00as like irrelevant or poorly or, you know, incomplete or written or something like that
0:21:04does like, it seems like it's just a mechanism by which you can have private communication
0:21:09with Apple, that someone inside of engineering will actually look at. And especially also,
0:21:17I think in communication, like, if functionally the way you know, the developer relations
0:21:22system works is, you know, we can file a radar, and then there's a collection of evangelists,
0:21:27I mean, like all the essentially developer relations team is there to interact with developers
0:21:33personally. So usually what I will end up doing is I'll file a radar, sort of put that
0:21:38out there. And then depending on what the nature of the situation of the, you know,
0:21:43enhancement request is, if I know the evangelist who would most closely fit that, I'll reach
0:21:48out to them and I'll say, "Hey, here's this thing that I filed, you know, here's
0:21:52the reason why I'm asking it, if you have any questions or things, you know, please
0:21:55let me know." And, you know, sort of like in the same way that you may, you know, it's
0:21:59like you submit your resume on the system, and then you also may follow up with an email
0:22:03to a recruiter or something like, you know, you kind of you hit it in both ways, just
0:22:07to make it that much more likely that someone's going to look at it. And they may disagree
0:22:10with it, they may ignore it, they may not end up being effective, but at least someone
0:22:14has looked at it and they've made an active decision to, you know, to not do it.
0:22:19Also, the timing of when you file bugs or when you go public with things matters a lot
0:22:26with Apple because, you know, Apple is a company full of human beings, and they're on a tight
0:22:30schedule, and they all have, you know, more things on their plate than they have time
0:22:34to do. But the good thing is we know their schedule. Their schedule matches the release
0:22:38schedule of their products and their operating systems, so we know the schedule so we can
0:22:42use it to our advantage. So, generally, like, if you file a bug or you, you know, bring
0:22:48up a public thing at a time when they're really busy doing other stuff, it's going
0:22:52to get lost in the shuffle, or it's more likely to get lost in the shuffle. So the
0:22:56best time to file bugs is when they are actively looking for bugs ravenously, and that is early
0:23:02betas. Like, right after WWDC, when you get those betas and you're trying out the new
0:23:09stuff, they are looking very closely at bugs people are filing. So if you want things to
0:23:14happen, that's the time to do it. Like, it's like the code is, like, open, it's,
0:23:17like, being worked on. That's the time when they can allocate lots of their own time to
0:23:22looking at your bugs and considering them. The worst time to file bugs or to make requests
0:23:29public is probably right before WWDC, because that is, like, they are in a massive crunch
0:23:37time every year trying to get stuff done for those first betas, like, for those first builds,
0:23:42and anything you try to have them do during that time that they don't have to do is
0:23:46going to get dropped on the floor, because they're just, they're way too busy. Also,
0:23:49similarly, when it's right before the GMs come out in the fall, when there's about
0:23:54to be new hardware released, they have no time to consider your enhancement request
0:23:58then. Like, the OS is basically done at that point. Like, that's a terrible time to do
0:24:01it. A good time to do it also, besides the early betas, is, I would say, the very beginning
0:24:07of the year, January through March, maybe, because, like, usually they're doing, like,
0:24:11a kind of an intermediary release cycle, like, the .2s or .3s of the OSs. It's kind of
0:24:16a quieter time. It's a time when they might have more time to allocate towards improvements
0:24:20rather than just, you know, core features. I just want to spend a quick moment talking
0:24:26about tone and framing when you go public. So, if you're going to write a blog post,
0:24:32or you're going to have, you know, any kind of public, you know, outing of what Apple
0:24:36is doing or not doing or what you want them to do.
0:24:38>>Steve - If you're going to become the elephant in the room.
0:24:40>>Joe - Yes. It helps to, the way you frame it, and this actually should also probably
0:24:47apply to the way you write bug reports too, the framing is very important. You want to,
0:24:51instead of just saying, like, I want this to be fixed, well, that's, you know, you need
0:24:56to frame it as, here's why it helps Apple, users, and developers, and they care about
0:25:03them in that order. Developers are really last in that trio, like, you need to tell
0:25:09them why Apple needs to do this and why that will benefit Apple's customers or the users
0:25:14of your software. Like, that's what you need to tell them. And what you, what you as a
0:25:18developer need is really low on the list. Because if you tell them something that will
0:25:22benefit Apple, your chances are better. And the tone that you use in the wording and just
0:25:28everything, headlines, titles, the best way to do, you know, Apple is, again, this is
0:25:34a company full of people. I have found that culturally, many of the people there are pretty
0:25:40sensitive to the tone with which requests and especially complaints are made. The best
0:25:46thing you can do is to basically remain factual, you know, state the facts as neutrally as
0:25:54you can. Any request or, you know, criticism that you're making of them, be civil and
0:26:01be constructive as much as possible. Because what you don't want to do is you don't want
0:26:07to give them a reason to disregard you as just being mean or just being a jerk or being
0:26:13unreasonable. You want to give, you want to say, here's the facts, here's what we need
0:26:18or here's what I need or here's what happened and, you know, here's what I think should
0:26:22happen. And it's also important not to, they're very sensitive about this, not to put words
0:26:29in their mouth or not to ascribe motivations to Apple. You know, there was a kerfuffle
0:26:35last year with a developer where, like, he recorded a conversation with Apple on the
0:26:41phone, like, without their permission, like that, you know, that's something you shouldn't,
0:26:45you know, don't do that and don't ascribe motivations to Apple. Like, Apple did this
0:26:49because they hate me or because they're being mean or because they don't want this
0:26:54kind of app, you know, like, unless they told you that in some kind of public way, like,
0:26:59you know, don't ascribe motivations or malice to Apple. Just keep it factual, keep it neutral
0:27:06and, I mean, obviously this goes for a lot of communication in the adult world, like,
0:27:11this is what you should do in general, but, yeah, like, if you keep it factual, neutral
0:27:17and constructive, it increases your chances that you're going to be taken seriously
0:27:23and that will improve your chances of getting done what you actually want to get done.
0:27:27>>
0:27:35I think that you should be able to think of Apple as a faceless entity, right, that it's
0:27:41like, that doesn't have feelings, that doesn't have emotions, that is just this cold machine
0:27:47that, you know, takes in code and outputs money, like, that's not the reality. Like,
0:27:53it is, you are ultimately trying to, if you have a change that you'd like to affect,
0:27:58you are trying to convince people to do that and the best way to affect people is to, you
0:28:04know, be respectful of them and to be presenting your arguments in ways that is hopefully going
0:28:10to ultimately make them look good, that is going to, you know, make their life better
0:28:15in some way and you're going to have way more luck with that than just yelling and
0:28:19screaming and throwing a fit because that's not going to help anything. Like, that doesn't
0:28:23help if you're a two-year-old and it's definitely not going to help in trying to
0:28:26affect change into a massive, you know, billion dollar company.
0:28:30Exactly, because anything you are arguing, you know, as you said earlier, you are providing
0:28:35ammo for an internal discussion. You want your side of the argument to win internally
0:28:40and so if you make a really good case, people inside can use that to win arguments, to affect
0:28:47change, to do what you want. So it really helps a lot that you make the best case possible
0:28:52and that you, you know, choose things wisely to even argue about in the first place and
0:28:56when you do, do it right. Play by their system, play by their rules and play by general adult
0:29:01civility rules and you will have much better chances of succeeding.
0:29:05Well, that's all the time we have for this week. Best of luck with everybody with your
0:29:08Affecting Changes efforts and we'll talk to you next week.
0:29:11Bye.
0:29:12Bye.
0:29:13[BLANK_AUDIO]