Great Expectations

October 31, 2019

Joshua and Kel talk about setting and maintaining expectations and the importance of building up this skill and how it plays into the role on a practical basis.

Be sure to check out our new Slack community to meet others who are facing the same things you are and share your journeys!

• 00:00 Joshua

  Hey folks, welcome to Getting Apps Done. A mostly non-technical podcast about building software. I am your host, Joshua Graham,

• 00:12 Kel

  And I'm your other host Kel Piffner.

• 00:14 Joshua

  And on the show, instead of talking about syntax and frameworks and algorithms and things like that, we like to talk about, you know, more practical things about being a software developer as an, you know, getting a job or keeping that job and doing it really well. So today what we want to talk about is setting expectations because it's important to set expectations and sometimes once you've set them, it's very hard to keep them and maintain them. So we wanted to go through some practical exercises and things that you need to keep an eye on when you're setting expectations with a client or boss or a coworker or your mother or whoever it may be. Because setting expectations is important outside of software development as well.

• 00:52 Kel

  And when we were talking about this episode, we started with the phrase scope creep, which is probably familiar to you if you've started your job already. But it's the same, same kind of concept of you set expectations and then they kinda got away from you and now you're doing something different. And that's not a particularly effective way of building software.

• 01:11 Joshua

  No, and it is probably the single most common thing I see for where expectation setting goes completely wrong because you say, yes, of course I can now have that done by Thursday. And you might actually think, yes, I can get it done by Thursday. And then you know, somebody shows up to your desk and says, well can you do this as well? Or could you add this into it and Oh, could you make that puke green? Or whatever it might be. It somehow starts to get bigger than you thought it was.

• 01:36 Kel

  And there's, there's a bit of a trade off with flexibility there too, especially when you're new. I remember when I was first starting as a developer, people would come to me with those types of requests and I would just add them in. Sure. Why not? It was one tiny little thing to go with the, you know, thousand other tiny little things I was working on. But as I kept on in the development industry and took on larger and larger projects, there was a lot less room for that sort of thing. Like the tiny changes started to get larger and the things I was working on were larger and just generally less flexible. And so that's part of why, why that's a problem.

• 02:11 Joshua

  Absolutely. And that is a very key item because a lot of these changes that people ask for, do sound like small things. Can you make this puke green? It's not a big deal. Yes, of course I can make a puke green. But then they ask you that 20 times over. And then for other things and before you know it, that one minute job has suddenly turned into 60 minutes of work. And you know when you've only got a couple of days before your deadline an hour adds up to a lot. Yeah, that's a big percentage of that time.

• 02:37 Kel

  And that's a lot of what, um, we've talked about agile before and agile processes and actually I kind of started that off right? Like when I first started as a developer, I was a lot more agile. I could do smaller chunks and smaller changes. And so like you'll see that as a pressure pushing down on teams to kind of force these conversations to happen earlier, of we can't be on month six and have this discussion that we can no longer fit your bright green button. We're still within like a sprint or a month or you know, an iteration of some sort where we can have these types of conversations and fight over them directly. And we do that by setting expectations.

• 03:12 Joshua

  Now obviously we've jumped right into how expectations can get derailed, but we should probably talk about how to set expectations in the first place because it's a skill and it takes some practice and you need to be aware of your audience because not everybody's the same. Not everybody takes news the same way. So sometimes you have to frame this in a way that's going to make sense for your particular audience. If I'm telling Kel how long something's gonna take, the way I say that is going to be very different than if I'm telling my boss because Kel and I have worked together for a long time. They know what to expect from me. What I mean when I say things, so if I say, yeah, I can probably have that done by Friday. If I don't get it done by Friday, it's probably not the end of the world because we will have, we have pre arranged expectations that those dates don't really mean too much other than I'm going to try to get it done by Friday. Exactly. If I tell the client I'm going to have done my Friday, I damn well better have it done by Friday.

• 04:09 Kel

  Yeah, it's a lot easier and that's kind of an example of communication of not necessarily meaning what you say too. It's like, I'm going to have that done by Friday, except we, we've already like prearrange this agreement that those words don't mean that. Those words mean I'll take it, I'll take a try at it by Friday while you're talking to your client, ah, they're probably gonna take you pretty literally. So it's usually best to start these conversations from as as literal as you can get, like mean exactly what you say. And that's what we mean by expectations. Be very exact about what they are. Use more words until you are certain that they have the exact same understanding and that understanding is probably by end of day on Friday.

• 04:48 Joshua

  Yeah. Now one way you can do this is by setting constraints and caveats. When you're telling them, because you honestly think you're going to have it done by Friday, you need to set some expectations that that might go wrong. If you think there's any chance at all that it's going to go wrong. So you can tell them flat out, you know, I believe this is going to be done by Friday, but I've never done this before. This is something new. There's some things I need to figure out so I'm going to try them out first and then I'll give you better update tomorrow once I know how bad that's going to be because there might be something that goes wrong or just you know, let them know that you know it's tech, stuff goes wrong. Most people understand that. Yes, I and odds are actually a really good way if you're a talking to a person who can understand that I have a lot of clients, if I tell them the odds of something going or not, they have no idea what I'm talking about so I don't use those with them. You have to learn who your target audience is. Who are you talking to? Is this an accountant? Yeah. Okay. They probably do understand odds. They're going to get statistics and understand the mathematical and they're going to be fine with numbers, but if you're talking to, you know, a florist or they might be okay with numbers, you never know. They might not be, they might be better than the accountant.

• 06:00 Kel

  in my experience, there's not actually a lot of overlap between using numbers in your day to day life and your ability to recognize odds of something happening.

• 06:08 Joshua

  We have said this in the past. Yeah. Um, but it's getting to know them. What are they expecting, what can you tell them? How can you explain things to them? Because learning how to communicate is, it's important. It takes practice with each individual person you're talking to me, it's not just something that you practice and then you've got it nailed down pat. Every audience is different. The more you practice, the more you get better at talking to different audiences. But everybody's different.

• 06:35 Kel

  Yeah. And that's a lot of the pressure behind, um, agile. That's why we have processes. This is the agreed upon language that we're working in. And so you might have things, um, like you were mentioning earlier of I don't, I have never done this before. How long is it going to take for me? I'll get back to you after I find out. And an agile workshop, you might call that a spike where you create a task specifically to go try something and you're like, eh, give me a day and you time box it to a specific amount of time. And then you update your estimates when you come back with more knowledge. And so a lot of these things are built into these processes and that's why they're there. Like this is why there's so many weird random things you can do in agile and they all have ridiculous names like spike.

• 07:14 Joshua

  yeah, I hate those terms. I never call it a spike, but I, I use exactly that. I tell the client, you know, I'm going to go spend a day doing some research on this to figure out exactly how big it's going to be and then I'll come back to you with a much better estimate. It might be a week, it might be another day, I don't know. I might have it done by the time I come back. But they know that there's a fairly high level of risk involved that way. And that's really what it is, is communicating the level of risk versus knowledge.

• 07:41 Kel

  And yeah, like I'm using the word spike, but when I actually talked to say a boss or a client or something, what I usually do is kind of, I work it in, I'll say I'm going to do a research spike and then I'll be doing this. And that kind of opens up, you can figure out what it means by context pretty quickly. And if you are still a little fuzzy on it, you can ask me, but you don't really miss anything by not knowing that word. It's kind of a slow educational way of teaching people at these words mean if they're going to be part of that process a lot. That's kind of an important thing to do. Like it is really helpful to have shorthand languages in a smaller group because it can make things faster, but it also means it's more room for something to go wrong if somebody doesn't know what that word means.

• 08:20 Kel

  So you have to be, like you said, very clear about who your audience is and who you're talking to. Is it okay to say spike, will they understand what that word means or are you just talking jargon like, I mean we could label these things with letters and pictures. Yeah, exactly. Like we we could have like pictures or colors or something that could be an elephant. Like it doesn't matter what the word means at that point. So it's important to realize that things that seem obvious, especially in process stuff that have names like scrum and spike and timeboxing that sort of kind of explain what it is but not really until you really dig into it. You really need to translate. Helps with setting expectations.

• 08:57 Joshua

  Agreed. And you actually mentioned something there that I like as well. From both sides. Ask questions. If you are getting to know a new client, you don't know exactly how to set expectations with them. Ask them some questions. There are some things that you can ask them that will help you get an idea of the type of person they are. Ask them how they would estimate something. Asked them about what things are valuable to them, how they relate to time. Some clients may think about things in week. Some clients may think about things in quarters because that's what's relevant to them or they might have a very specific set of times that are very important to them. And part of setting expectations is knowing what times are important to them. I've got a couple clients that have particular parts of the year that are very, very busy for them and I know that I had to work things around that. Again, setting expectations, I can't tell them yes I'm going to get all this stuff done in December only to find out that actually they don't have any availability to do any testing or anything like that in December. So part of setting that expectation is I need to ask questions so I know what my realistic expectations are.

• 10:01 Kel

  Exactly. My, my personal favorite question is asking when the deadlines are. Like what is the date this has to be done by, and this is kind of a challenge with clients cause they hate answering that cause they want it way before that day. They don't want to risk that. Like there's a lot of risk having it at the last second, right? Yeah. You want to make sure that you're, that's when it has to be correct and done not just not just done but done and correct. it has to be right that time and so, but that is, that is the actual cutoff date. That's where you start is all right, well what's the absolute deadline? All right, let's see where we can fit you before that. Where do we can fit into that? How much time do we need to test? How much time do we like? That's how I usually approach these conversations with clients who starting from the date and kind of working my way backwards. Just having it or something. Whenever I can manage to work out with them.

• 10:47 Joshua

  With that one in particular, I like to ask two questions. I like to ask them, when do you absolutely have this done by? I end working and out the door and everything else, but also when is the soonest you'd like to see this? Right. I quite often they will come back and say last week, but you can usually get them to be a little bit more realistic. Okay. We're talking about this size of work, at least at a ballpark. When is the soonest you think would be realistic for you to have time to take a look at it and actually us be in a position that you think we should be where we need to be. And that helps set my expectations for what they expect because both sides are important. If they are thinking, I'm going to have this in two weeks and you're thinking, Hey, I can get this to them next year. Those are very different things and first off, it might be a situation where your expectation needs to be, no, I can't at all do that, so maybe this isn't a good match or maybe it needs to just be that, okay, there's some work I need to do to help realign our expectations here because if they're thinking in two weeks, there's some misunderstanding of the amount of work involved or what sort of resources we have or whatever it might be.

• 12:00 Kel

  You'll find as a developer, especially you'll find this pretty quickly, is that a lot of people see us as magicians and as a junior developer, you've already crossed that threshold into magic for most people. If you, if you don't know how to develop, it looks like magic. Even the simple things you do and it's really difficult to determine what is really difficult magic and what was really easy magic when there are so many frameworks to make it help you make do so cool. Things like I can build a game in unity in about 15 minutes and it will have graphics and pretty things and if I had done that from scratch, it would have taken me a year. And so those expectations are really difficult to set at first. Like you really cannot just trust that people have a reasonable expectation of how long something takes to develop because it drastically is different in every scenario depending on what they need, what they ask, what they already have. You really do have to approach it kind of from scratch each time. And that can get faster as you work with a person longer and like the expectations build. But it's probably a good idea to start from zero and work your way up.

• 13:02 Joshua

  And it is amazing sometimes what people think. I actually had somebody, they came to me, they wanted to build something very similar to WhatsApp and we started to discuss what it would do or what would be involved and I started to get in my head, you know, a few months of work here and then I asked them the question, so when are you expecting this and how much, how big do you think it is? Because I wanted to get their baseline and I wanted to know what they were thinking about this and they came back with one week and I wasn't judging. Okay, so how are you basing that number? Where are you getting that from? They said, well I know what type is already out there and all of these things already exist so you can just use that and put it together and put my brand on it. Right. Okay. We've got some expectations setting to go through here. What it came down to it, they had about two weeks worth of budget and it was probably more like a two, three month project. Uh, so it wasn't gonna work out anyway, but that expectation that they had was completely unrealistic but they didn't know that, that it's not their job to know that it is our job to find out where they are right now so that we can help them get to where they need to be.

• 14:10 Kel

  And the kind of, the hardest part about this really isn't this the the part of going back and forth and coming up with a standard and there's like a shared context and being able to determine these things. The real problem is, is that just the normal human problem that you will tell them no and they will get angry. This is a really common thing in client software development and you will read loads of horror stories about it if you decided to become a freelancer. And it is a fact of life that there is a bit of just kind of managing people

• 14:39 Joshua

  Absolutely, I've run into a lot of IRA clients who, where I write for things that I wasn't in my control at all. It's an Apple takes how much of my money, 30%. what? I like.

• 14:54 Kel

  I agree, but feel free to yell at them.

• 14:57 Joshua

  I agree. Stop yelling at me please. Exactly.

• 15:00 Kel

  And that's, and that's part of like when we talk about bringing your whole self into a project and being yourself and forming real human connections and that's kind of what helps derail that sort of behavior, nut type of toxicity and that we're all here together trying to build a thing and we have different skills and one of those skills might just be, I have all the money. That's a great skill. We like that skill. Um, but like yeah, you build a thing as a team and that's kind of where you want to get when you're in these conversations and that can, that can take awhile. Like you have to build up trust.

• 15:31 Joshua

  Absolutely. And the Apple thing. That's another great example of setting expectations because if you told somebody on day one, okay, you want to build an app, you got to remember the app stores only lets you pay through the app stores and they take 30% of that, then they can freak out immediately, but you're not to blame at that stage. You're just the person telling them. Sometimes they will still blame you, but you're early enough in the relationship that either they'll get over it or you can run.

• 15:56 Kel

  It's like, I am sorry this is the truth of our relationship and I cannot help this one.

• 16:00 Joshua

  Yeah, but if you wait until you've already built the app, you've collected a bunch of money from them and then you tell them this, then suddenly you, I actually do have some responsibility there because you didn't set that expectation appropriately. That's why these things get to be so important. It's not just about setting deadlines and things like that, but if you don't manage those expectations of your clients, you can actually be negligent in these things and it's actually your fault when it comes down to it. Things that weren't your fault in the beginning because you didn't share, you didn't set those expectations suddenly become your fault.

• 16:32 Kel

  Exactly. So when you, when you first started talking to the client, you need to make sure that you both are on the exact same page as close as possible, that you have the same expectations, that you have an understanding of the same risks. They don't need to know how you're going to do it, but they do need to know what those risks actually look like and what the gambles will look like. And some of that, some of that requires them kind of accepting it. When you tell them, I, you know, there was a 75% chance that this will succeed and a 25% chance this will fail. And you come to them and go, well, it failed and that's going to happen. And that stinks. But that's why you have this conversation with these folks upfront and you know, that mutual trust of them accepting that it was, it was a quarter chance it could fail, this, this is a thing that could happen. The odds were better the other way, but it happened and I'm sorry and what do we want to do next?

• 17:19 Joshua

  And that is the big thing is what do we want to do next? But also that is this mutual thing and that's a huge expectation to set up front is what the different roles are. Because I've quite often had people who at the end of a project are absolutely shocked that they need to test the thing. Well, isn't it going to be perfect in an ideal world? Probably. Yes. Uh, but I learned very quickly, one of the first things I need to tell them is, okay, these are the things I'm going to do, but these are the things you still need to do to make this a success. And part of that is being involved, being engaged and owning this project because it's your project, when it comes down to it, not mine, I will probably help you make some decisions, but it's not my role to make those decisions for you. This is your product.

• 18:05 Joshua

  The other side of it is, yes, there's going to be some testing and I highly advise you do some testing, but you are probably gonna want some other people to help you out and things like that. I was just having that conversation at the beginning makes it much easier because you don't get to the end and then they're thinking, well, I've got all this work now that I didn't know about or I just had this expectation that, you know, you magic it up and it's perfect every time, right. Because you just pulled it off the shelf WhatsApp, you just put a new name on it and the logo and off.

• 18:33 Kel

  Yeah, you pulled a, you pull the transmission off the shelf and you had attached it to the car and now it's all perfect. Right? Like what? You just need to start it a couple of times and you'll know it works, right? It's difficult to describe these things to people who haven't programmed and like you don't have to actually program very long before really understanding all of this thing, which is why I'm really appreciative to managers I've had in the past to have at least tried. It saves a lot of early conversations if they have a better understanding of how these things at least assemble. But that's also not required. That's totally not all you have to do is listen to the people around you and you can learn these things well enough to make decisions and that's important.

• 19:13 Joshua

  But that is all about setting those expectations defining your roles and everybody else's roles so that everybody knows what page you're on. If you've, as a manager, don't want to be technical, but you surround yourself with technical people, give them some autonomy and ask them to help you with that. You've set that expectation. You can work as a team you, it's mutual and again, and there's absolutely nothing wrong with that. As long as you set that expectation and you manage it appropriately.

• 19:41 Kel

  It's kind of a expectation of trust. And then that particular example of I'm going to trust you to tell me when it fails and I'm just going to accept it and move on. Because I was the expectation we came up with. And maybe I'll ask for an explanation so I have a better understanding of the risk next time cause I, you know actually thought it was way better than 75% I find that happens a lot. You tell somebody it's going to be 50% failure and they still expect like 75% success.

• 20:06 Joshua

  Yeah. And that probably is another side of this is obviously managing expectations up front is best, but sometimes things do go wrong and even if you did manage that expectation, if you told them there's a 50% chance of this going wrong, do you still want to go ahead with it?

• 20:22 Joshua

  And then they goes wrong and they're saying, well I, I just, I thought it was going to go right. It's going to happen because some people just, that's the way it is. But there's some things you can do. And Kel mentioned it earlier and this is probably my number one. This is the one I go to every single time. I completely ignore them and I say, okay, what are we going to do next? How are we going to take care of this because it doesn't matter if things went wrong, it does, but when it comes down to it, the most important thing is how you react to the situation, what happens, how do you work to correct it or mitigate it or do whatever it is that you need to do to move forward. Because getting stuck, yelling and screaming and getting upset about it doesn't do a damn thing, but doing something about it can change things. It can change it from a failure to a success.

• 21:11 Kel

  That sounds a lot better than my first reaction of, Oh, let's get a quarter and do like best two out of three. Flip it a couple of times until they give up. Yeah, and I kind of want drawback though that this is a lot of the things we're talking about are common processes within agile. Like you're talking about early testing and feedback. Well that's part of the agile method, right? Like you give it to them and you ask for early feedback and then you iterate over and over and over again. And so a lot of these things are built into these processes, but this is why they're built into these processes, because this is a difficult thing to do. It's difficult to have these conversations with people. It's difficult to estimate correctly and even coming up with the odds is really challenging because you'll never really like how difficult is 50% on implementing a new react app. I don't know. Like I barely even seen the framework like that. Even that estimate is really rough and so all the processes and all of those have a lot of ways of helping you estimate, having a lot of ways of estimating risk and how long things will take and how to communicate those things to other people and that's why they are there as a process. They might not be the best at it. You might be able to come up with a better one within your group, but that is why,, you know it's a good starting point.

• 22:23 Joshua

  Absolutely. And I think that is the key thing and this is one of the things I've said about frameworks and processes like agile and everything else. There are a lot of decisions made for you because if Kel and I set out to go figure a new way of dealing with this ourselves, we probably could come up with something that's going to work better than anything else out there off the shelf. But when you're talking about a large organization, when you've got 10 20 40 50 people on a development team, suddenly not everybody's quite at the same level and you kind of need a baseline for everything and using a technical framework can provide a baseline on a technical side. Using something like scrum can provide a technical framework that everybody can work with on a non technical side, on management side,

• 23:08 Kel

  That mostly non technical side.

• 23:09 Joshua

  Mostly non technical side. Yes. That gives you that language, that way to communicate with each other and set those expectations. It's all built into that package and everybody's using the same package that way and that's a huge benefit. Even if the process itself isn't perfect, having the process in place is much, much better than trying to wing it.

• 23:30 Kel

  Exactly. And it's helpful to think, especially as a software developer, it's really helpful to think of your process as an application. This is also something that you can iterate on and make changes on and make even estimates on. Like you can manage your process within the process. Like it's a thing that can be iterative as well as the software. And so like when you adapt something like scrum, you don't have to keep all of the ridiculousness. You don't all have to stand up every morning. It's fine. Um, but it's a, it's a baseline. You can start there and you can iterate on it and decide what works better and what works worse. But to do that well, you really need to understand why those things are present. Like setting expectations. This is the goal. Can we do it better than this? Is this a problem? Like that's how you want to approach modifying these processes.

• 24:16 Joshua

  Yeah, absolutely. But taking one to start with is a really good way to get yourself set up in a position where you can start to see those things where if you're just trying to go invent it all yourself, it's the same as anything else. Yes, absolutely, you could skip react, you could skip angular, you could go build everything with, you could go build everything with assembly language if you really wanted to, but it's gonna be a lot harder.

• 24:43 Kel

  I feel attacked.

• 24:47 Joshua

  You have be doing that a lot lately. But as we said on an individual level or with a couple people, that can be absolutely fine. In fact, that can be much, much more efficient. But when you're talking about a bigger group, and particularly when you're talking about multiple clients or a large organization, you need some kind of a central language that everybody understands that helps manage those expectations at that level because otherwise you're all speaking different languages and nobody really knows what's going on.

• 25:12 Kel

  Exactly. It's a lot easier if everyone's working on a react app, then just everyone trying to build a web app using whatever technologies and yeah, like patterns they can dream up that week. It's the same thing. You'd want to be sort of on the same framework.

• 25:29 Joshua

  Exactly, and quite often when I do come into a new company who is in need of help, that's exactly what's happening. They've got angular, they've got react, they got some vanilla JS, they got some old Java applets that they're still using and they've got four different processes. One person's using waterfall, one person uses some Access thing they built in 1992 and, and everybody's got different things going on and none of them are talking to each other in any way whatsoever. And that's usually where all the problems start to come in is nobody's talking together, nobody's setting expectations. Nobody knows what expectations to set at all because there's nothing in there that's shared.

• 26:08 Kel

  I mean honestly, just from experience, it's pretty rare that it's a technical problem at the root, like there might be a technology problem in there, but it's never really the hard problem. Like the technology problems usually the easy thing to solve. It's the, the process and the people and the communication and getting everybody moving in one vaguely similar direction as a herd.

• 26:27 Joshua

  Yeah. I would almost say that it is almost always the root is communication or lack thereof.

• 26:33 Kel

  What you find is, yeah, what you're finding when there's a group that does communicate well as they're moving, they're there. They're wonderful clients. They pay you on time, they, they have reasonable deadlines. They take this off where they're happy and then they give you a paycheck and we all go home.

• 26:49 Joshua

  Even if their processes aren't perfect, the tech isn't perfect. If they're talking to, they're communicating, they are engaged and understanding. Usually things aren't gonna go all right. If those things aren't true, I don't care what tech stack you've got in there or what project management paradigm you're using, things are going to go wrong because communication is probably the single most important thing. And that's what setting expectations is all about is communicating with others.

• 27:16 Kel

  And just a random like kind of funny anecdote from time, I've noticed the companies that do the communication thing well often have just absolutely trashed software to run their processes and it's impossible to get them off of it, and I don't know why, and I'm sorry to all you junior developers who are going to learn this the hard way. People don't like to change what works. Even though you can make it faster and less painful. It's a challenge sometimes to iterate from something that's working.

• 27:46 Joshua

  They've got their expectations set, they don't want to unset them.

• 27:50 Kel

  Yeah, it's a challenge to rock the boat, right? Like sometimes things are working and working well enough and you just want to make it slightly less painful. I mean, it could be something like upgrading their, versioning system. I remember trying to upgrade somebody from Visual SourceSafe to SVN and that was painful, ridiculously painful for something that was an obvious upgrade, but it was working. They were communicating before they were more or less getting things done and they weren't noticing where those problems were. So just a little, you know, since we're being so friendly about all of the things you can do, kind of give you a heads up of the things that, well, some things are harder.

• 28:27 Joshua

  Most things are harder than you think. They are.

• 28:31 Kel

  Another reason why we were really terrible at those estimates.

• 28:34 Joshua

  Yeah. All right. I will put some transcripts up at https://gettingappsdone.com. Please be sure to check out my website at joshuagraham.info and Kel's website, piffner.com. If you have managed to change some processes for the better or are stuck in process quagmire or just want to know how to set expectations or have a rude client or anything else that you need to help or could do with some help communicating or setting expectations or dealing with expectations that went wrong or whatever it might be. Pop onto our Slack channel at gettingappsdone.com/slack and uh, we'd be happy to help out or at least listen to you and moan a little bit with you, or

• 29:19 Kel

  We can share some rants and some stories.

• 29:21 Joshua

  We can relate and set expectations for you.

• 29:26 Joshua

  All right. We post every Thursday, so we'll be back next week. Until then. Thanks for listening.

• 29:31 Kel

  Cheers.