Less noise, more data. Get the biggest data report on software developer careers in South Africa.

Dev Report mobile

MERGE Panel Discussion: Building Tech Team Playbooks That Work

17 January 2020 , by Candice Grobler

Over time every tech team develops playbooks which help them build processes, teams and tech that succeeds. At MERGE Johannesburg, Phillip Barrett from OfferZen got to chat to Ashi Krishnan, Warren Foxley, Ridhwana Khan, and Dean Broadley about the teams they’ve been on. They discussed what didn’t work for their teams as well as how they overcame these challenges to build playbooks that help their teams win.

Panel discussion transcript

[00:10] Phillip Barrett: How's it going guys? Okay? Breathe. Awesome, okay. I just noticed a thing which I think is going to be really useful for us, which is all the hard questions came out right at the end there and they hit you, boom, boom, boom. Which was just amazing to behold. Now we can spread those hard questions around the panel and see if they can help.

[00:36] So there's some beauties that the audience has already given us. What we're going to do is do about 25 minutes of questions that I've got written down and that we've worked out and then it's back to you guys to see if you can use the collective brains that you have here to solve whatever problems you've got back in your teams. So this is a big chance for you guys. This is a big chance, pay attention.

[01:01] One of the things that always used to make me laugh when I used to be in consultancy and doing software and so on for clients was they'd say, "It's just a tiny little phone, how hard can it be to make it do the software thing that I want to do?"

[01:21] But everybody here today and everybody in the audience knows that organising your team to make that thing happen or your teams to make that thing happen is just insanely difficult, and that's what we're all really talking about. Cool. Okay, so just to get us started-

[01:41] Ashi Krishnan: Do people actually say, "Oh, this phone is so small, why can't it do more things?"

[01:46] Phillip: Sorry?

[01:46] Ashi: Do people actually say, "This phone is so small, why isn't it easier to make it do things"?

[01:50] Phillip: Yeah. So I had clients that said to me, "It's tiny, I mean look at it, it's so little. It can't be... there's not many pixels on it. It can't be that difficult to make it do what we want." And yet you get entire banks and entire mega organisations who cannot persuade that little tiny pane of glass to do the right thing.

[02:11] Ashi: There's an alternate world where making things smaller makes them faster and better and easier to work with.

[02:15] Phillip: Easier, yeah. I mean there's so little room to mess up, I guess was what they were saying. I don't know. Okay, anyway. We've already gone off topic, but we're allowed to do that, it's panel time.

[02:27] Okay, so I hope you're all thinking up questions that you're going to ask soon. Very quickly though, one more time, just to warm everybody up and remind everybody who we've got here. We're going to go round and say what's your name, what do you do and where do you do it, and what is your favourite breakfast? Okay, are you ready? And we'll start with Ridhwana.

[02:51] Ridhwana: Hi. So my name is Ridhwana, I'm a software engineer at Smile Identity, I'm also the co-founder of a nonprofit organisation, KasiMaths. What is my favourite breakfast? I skip breakfast usually.

[03:06] Phillip: You skip breakfast.

[03:07] Ridhwana: I don't have one. But if I had to go with something it's fruit.

[03:11] Phillip: Okay. Thank you very much. Ashi?

[03:15] Ashi: Hi. My name's Ashi. I am a senior software engineer at Apollo, I'm working on the server team right now, so I'm working on the next version of the GraphQL server. My favourite breakfast... So I usually have a protein smoothie because I'm feeling healthy but if I had to name my favourite one I really like small plates, I love waffles, so a little waffle, a little scrambled tofu, a little vegan breakfast sausage that's sweet and savoury. That's my mix.

[03:48] Phillip: This is already interesting. Nothing versus little plates. Warren?

[03:57] Warren Foxley: Well, my name's Warren. I am an iOS tech lead at Luno, and my favourite breakfast... that's another hard question, you're not helping me. If I had to choose, eggs benedict, yeah.

[04:16] Phillip: Okay. Sort of a solid, nutritious.

[04:20] Warren: Super healthy.

**[04:21] Phillip: **Is it super healthy? I'm not sure.

[04:28] Dean Broadley: Hello? Ah. My name's Dean, I am a full-time human and I teach organisations and teams to be more human, overall. And I do it on Earth. My favourite breakfast is success. Can't help myself.

[04:55] Ashi: Is that the title of your next book?

[04:56] Dean: But on a more real note, probably Taystee Wheat. I don't know if people know or remember Taystee Wheat.

**[05:06] Phillip: **As opposed to the tasteless kind of wheat, is that correct?

[05:08] Dean: Yeah. It was a thing, it was called Taystee Wheat, my grandmother made it for me and it was fantastic every time.

[05:16] Phillip: And there's diversity for you right there. Diversity of breakfasts. Fantastic. Okay, I've got two directions I could go in and I'm going to take a risky direction, which is to kind of drag us back to some of the questions and some of the things I heard this afternoon.

[05:37] So I'm going to try chucking this out for the panel and I hope that you all have a great time with it. The question we've had is what do you do if your jerks think everyone is oversensitive and your oversensitive people think everyone is a jerk?

[06:00] And Dean said, "Feedback given at the wrong time is an insult." And I think there's something going on there, there's something that joins these two together, and maybe the topic of culture is involved in this as well. The idea of how do you get people to communicate frankly and transparently and honestly when they are diverse and when they might either be oversensitive or a jerk and so on. What are the tricks?

[06:40] So I guess the question I'm chucking out for the panel is how do you get clear feedback and good communication when you also could risk hurting people's feelings? Okay, that's a question.

[06:57] Dean: Do we just go?

[07:00] Phillip: Just go. Just take it and run.

[07:05] Dean: You're going to hurt people's feelings regardless, it's planet Earth. But I do think that there's an element of, you just mentioned culture, et cetera. So what was hard for me when I started working in technology was this idea that I don't have to wait my turn to talk about the thing I care about and that my opinion matters. That took a really long time for me to get into a place where I go, "Oh, actually, I do know this thing and I can provide value."

[07:33] I think culturally people are, a lot of people are trained to wait their turn. So if you're a manager and you have a team and you're going well, these people aren't giving me feedback, so everything's hunky-dory, spending a little bit more time paying attention to whether or not people are just being forthcoming or whether or not the feedback you're giving is landing and changing your approach per individual, and I think that's the big thing. Is the thing that I found the most success with. And to then not assume that the way I'd like feedback is the way that that person would like feedback or the way what I enjoy doing even or the way I value things moving forward may not be relevant for the other person.

[08:13] So understanding the kind of unique needs of each person in the team and giving them some individual feedback in their way is a good basis.

[08:23] Yeah, I think so. Yeah. But also just you can't avoid hurting people's feelings, I think. As long as you've got the right intent, sometimes things are going to get misconstrued because we've been on this planet forever and the one thing we're bad at is communication.

[08:38] Ashi: I think it's also quite important to model receiving feedback and delivering it from leadership. So the managers and the higher order managers need to be not just... they're sort of the typical my door is open, no it's not. It's definitely not. Or, like oh we're seeking feedback on this but you get a form and you're like ah, this form is not going to go anywhere.

[09:06] But actually the more opportunities you have to actually demonstrate that... for leaders to demonstrate that, “Oh I'm getting this feedback, it's not pleasant for me right now, it's maybe very raw and I'm going to respond to it and take it in the moment,” that helps a lot, I think it helps open that degree of vulnerability for everyone.

[09:29] Phillip: So how does a leader get feedback and take feedback? What does it look like when that happens? Have you ever done it yourself or have you seen it happen?

[09:38] Ashi: I've done it myself, I've seen it happen, I've also seen it happen. Sometimes it's... you can synthesize it, so when I taught at bootcamp it would sometimes make a point of having somewhat contentious interactions between the two instructors at some point, to demonstrate how that's... and not in the context of a sketch, just like tensions come up.

[10:07] So when they come up, you model like... “Okay, here's how we both deliver the... I'm not having a good time right now and how I receive it, and setting up.” There are some things - like everyone responds differently - but I think there's some practices that can be helpful for basically everyone, like when you receive troubling feedback or when someone tells you something you don't want to hear, thank them. This is something I do and something I tell everyone to do, because it puts you in the right mindset. They probably weren't thrilled to tell you this thing that you probably weren't going to like to hear, so it helps build that relationship.

[10:52] Phillip: So when somebody gives you something you don't want to hear, thank them? Yeah.

[10:56] Ashi: I think as a general practice, yeah. But that alone can’t... Sure, if everyone did that I think it would help a lot, but that's not going to be a complete solution.

[11:10] Phillip: What else would you add? This is really good, I want to know more.

[11:16] Ashi: So that, modeling from leadership. There's all kinds of... For more serious disagreements there are all kinds of restorative justice models depending on what's going on. I've had classes that were just really, had a lot of social dynamics issues and we would have big meetings with everyone to be like, “Okay, here's how these things are making me feel, like me as an instructor, and how other people feel about that.”

[11:54] Ashi: That doesn't always work, people might not feel comfortable expressing themselves in that context but I think if you are in a position of authority, expressing that vulnerability yourself is a good way to help people feel more comfortable doing it.

[12:11] Phillip: Yeah. You looked like you were going to say something?

[12:17] Ridhwana: I was, but Ashi and Dean just went through it. But yeah, I think the most important thing about giving and receiving feedback is respect. I feel if you do it in a respectful manner and you are conscious of other people's feelings... Or not necessarily their feelings but you're conscious of what you're saying, you have facts to back it up. I think those things go a long way in order to be able to have a constructive conversation around the feedback.

[12:54] Phillip: Good advice. Cool. Okay, still doing okay for time? Halfway. We've got time for a bit more. Okay. I was also interested in the idea of mistakes, and how mistakes pan out in the teams you've worked in.

[13:27] So, mistakes can be another moment when life gets difficult, when things haven't gone the way you wanted them to, somebody's done something stupid or your whole product idea has turned out to be not so good or whatever it is.

[13:44] So mistakes vary from this little thing to huge, great thing. So I was wondering, if you've got any good advice about how to handle mistakes, and perhaps what I'm really looking for is what kind of mistake have you seen and how have you seen it well-handled in the past, or I guess, really badly handled? So can you think of a time when you encountered a mistake and it was either dealt with well or badly?

[14:16] Ridhwana: So, I have a really good example. It happened to me, I started my job Smile Identity about a year ago. They have a lot of complicated systems that work together. Within the first, say, three months or so, I was doing a deployment and I thought I was being really clever in deploying at about 5:00 AM in the morning, so Nigeria wouldn't have started their day and that's where our market is.

[14:46] And I deployed and it wasn't going through and I kept on trying and then eventually the entire system crashed and it was just at the start of their work day and so a lot of traffic was going to be going through.

[15:01] And of course, being someone new in the company, I was like really nervous, like crap are they going to fire me? The other portion is that I was the first South African engineer that was brought on the team, so the rest of the team is based in the US and as you know there's a 9 hour difference, time zone difference.

[15:20] So, I was really nervous, I Slacked a couple of people, and went like, "The system is down." And the way that the team pulled together was just amazing. So I sent my CTO a message and I was like, "The system is down and this is the steps that happened." And I don't actually know what caused it to go down. It may or may not have been my fault.

[15:42] Phillip: Mistakes were made.

[15:46] Ridhwana: It was three o'clock or 2:00 AM in the morning for him, he got up, we brought another couple of team members on, two or three, we all sat for four hours in a call trying to debug the issue and trying to fix it.

[16:00] There was no blame attached to it, nobody went like, "Oh you crashed the entire system." They just pulled together really nicely, we tried to work through the problem and find solutions for it, and at the end of the day it was just having that support system to know that if you make mistakes or if there's any failures that people around you aren't going to blame you. There's just psychological safety in what you're doing as a person. So that was my example of how embarrassed I was at the start of this year.

[16:37] Phillip: Thanks. I think we can all relate to this. Who's next?

[16:43] Warren: Yeah, I've also got a very similar experience. It was when I started at Luno the beginning of the year and we take it in turns to run the release cycles for the apps and as part of my onboarding I got the wonderful role of doing the next release cycle.

[17:03] When released to prod, I accidentally sent a debug build into production, which in Luno we've got a bunch of debug options which allow you to switch to an isolating environment and a lot of other interesting switches.

[17:19] Yeah, I realised this once I downloaded the updated app from the app store, and yeah. I went to my boss and I said, "Well, I messed up." And he just turned around and he was like, "That's fine. Just fix it." And this is why we can deploy again and again and I just went and I fixed it, I mean pretty boring story actually, but yeah, just the nonchalant attitude. It was like, "Yeah you made a mistake, just go fix it."

[17:50] I think that's a great attitude to have and in other situations where we've had crises, the attitude's remained the same at Luno, it's just okay, there's a mistake, let's go and let's fix it. No brain... Ah, brain. No blame, and just get together as a team and go sort it out.

[18:19] Dean: I have an example that was handled badly, which is kind of in direct opposition to the way your situations were handled. And maybe it's because of these situations that now it's handled some other way. But basically, it's kind of two examples.

[18:37] One was a client who launched a website that looked like another website. So the design, the flow, the illustrations, all looked like another website that was live. So they posted it online and were like oh, we're very proud of our new website, and I just kind of said, "Hey, you may want to check this out."

[18:57] So then the CEO kind of privately messaged me and they were like, "Oh yeah, we're very sorry, our designer got carried away." It was such an incredibly bad way to handle a situation like that because of two reasons. One, you're blaming somebody who isn't there to defend themself. Two, are you telling me that the junior designer sat there, designed the website, wrote the code, deployed it all by himself or herself and the entire organisation just wasn't involved?

[19:24] So that lack of accountability I think or shared accountability in any way, shape, or form is just a sign of a very, in my opinion, ill organisation culturally. And isn't an organisation that's going to build meaningful or sustainable products and experiences.

[19:42] Then, the second example involves me, is when back when I used to work in advertising. There had a bunch of web banners that needed to go live and I was the web banner guy, I was a banner boy, used to design and make flash banners by the hundreds, I was like a factory.

[20:03] I had to do something like 240 web banners in 24 hours or 48 hours and so I didn't sleep for like two or three days straight, and the buttons, the call to actions were supposed to say, "Get the full story." And when I get tired I get quite cynical, and so I was alone in the office, nobody else was there to support me. I changed it from, "Get the full story," to, "Get the fool's story." And then I just deployed all of those because I was too tired to care.

[20:31] So that wasn't so much a mistake as a very... I think a sleep deprived delusion, but the way the organisation handled it wasn't great initially, they kind of like, "Well, how can you do this," and they all started shouting at me. I was still too tired to care so I just said to them, "Well, this is what happens when you give people this workload," and went... and I left.

[20:52] So I didn't handle it very well, either. But when I came back the next day I think they had a bit of an internal conversation and they went, well, I think at the end of the day they still made millions of rands off of that banner and so they weren't really too worried, and it was an easy fix, right? Because I'd actually developed a system to change the copy outside of the banner.

[21:14] Afterwards they were like, "Okay, cool, we will change the way we do these things." I think yeah, sometimes you have to go through a bit of pain to learn a thing but if you can try and prevent something like that happening is good, and I learnt a lot from the experience around saying no. It was very early in my career. But yeah. So that's my thing around mistakes.

[21:37] Ashi: At Google we got stickers, for breaking s***.

[21:44] Phillip: You got what?

[21:45] Ashi: Stickers. Like stickers on your profile page. I got the sticker that said I'd broken Gmail for a lot of people, because I broke Gmail for a lot of people in North Carolina, specifically.

[22:03] Phillip: And why were they giving out stickers for people who had broke Gmail in North Carolina, and others?

[22:08] Ashi: It's quite an accomplishment, no? Could you break Gmail for everyone in North Carolina? No.

[22:16] Phillip: No.

[22:20] Ashi: I mean more generally it's a general acknowledgement that like... Especially if you're in reliability engineering, you're definitely going to break something at some point, you're constantly pushing things to prod. It's mostly not... it's very hard to damn right impossible to just take down all of Google, right? So you're probably not going to break anything. You might at most cost the company a few hundred thousand dollars per minute or something.

[22:49] Phillip: So this leads us on to the question of what do you do to make sure you don't make the same mistakes again? But that could be the wrong question. It might just be what do you do about mistakes? Because I guess Google says mistakes are going to happen. It's like mistakes are going to happen and it's actually a good thing because it means the engineers are trying stuff and they're not afraid to move fast, so we're going to reward mistakes.

[23:13] But at the same time, Dean said they changed their work process to avoid completely crushing their junior banner designers. So what are the tactics for dealing with mistakes? From a... if you're running your team.

[23:31] Ashi: Well, again if you have stickers you want to get different stickers and there by make... you only do that if you're making different mistakes.

**[23:41] Phillip: **If you get the same sticker twice are you in trouble?

**[23:43] Ashi: **No.

[23:43] Phillip: Okay. Can you get the same sticker twice?

[23:47] Ashi: Also no. I mean just the system doesn't let you have multiple badges. Like multiple badges of the same kind. I think the more serious answer is maybe you do post mortems and kind of dissect what happened. Mostly what happened when and what the causes of those things were and you're like, “Oh, okay, this SRE released all of the frontend machines in this cluster and why was that so easy to do? Maybe it shouldn't have just been a command, and why it was... it was a typo, why was it possible to make a typo, oh we're just typing these commands out over and over and over again like we're robots. Maybe we could have a robot do it. What are the blockers there.” And you can maybe actually fix your processes.

[24:42] Ridhwana: I think not keeping these mistakes a secret is really important, like actually acknowledging it as a company and using the opportunity for the individual to learn from his or her mistake, but also for the entire team to be able to learn from these mistakes because when you acknowledge these mistakes openly it provides learning opportunities.

[25:07] So, like Ashi was saying, being able to do post mortems on these mistakes that happen really lead to better processes, better technology, it just leads to innovation.

[25:23] Phillip: And while doing the postmortems, you mustn't be a jerk but you mustn't be oversensitive. So mistakes are... they're not about... it's not about blame, the word blame came flying out as well. It's not about blame, about well, you did this thing, John, that friend John of yours, yeah. A load of trouble.

[25:44] It's you, you're a bad person. It's about here's a thing that happened, how do we prevent the thing from happening again.

[25:52] Ashi: Right. They're in fact called blameless postmortems.

[25:55] Phillip: Sorry?

[25:56] Ashi: They're in fact called blameless postmortems. Like you account for what happened, including who did what, but if an operating engineer could break something, then the assumption is this person was the operating engineer who did break that thing, but someone else was going to do it at some point, right?

[26:20] It's a very, very safe assumption, as you scale. Every mistake that can be made will be made and whoever is unlucky enough to be sitting in that role is the person who's sitting in that role today.

[26:35] Phillip: Cool. I like that.

[26:36] Ashi: The breaker, the breaker of chains.

[26:40] Phillip: The breaker of chains?

[26:41] Ashi: Sorry. The unborn something, I don't know the whole thing. Has no one here seen Game of Thrones? Khaleesi, the breaker of chains?

[26:51] Warren: The only one I know is, "I drink and know things."

**[26:54] Ashi: **Okay.

[26:56] Phillip: That will be ours soon. You know things, soon you will drink. But first we're going to go to the audience for some extra difficult questions. Because we've seen what they're capable of, right? Yeah. They can be brutal. But maybe they'll be kind. We don't know, do we? We will see. Audience? Are you ready? Yes. Somebody is ready in the audience. Sort of towards the back left. They're going in.

[27:25] Audience member: Hi guys. So a common theme that we've heard about today concerns diversity and then we also hear that developers find that the environment that they work in is extremely important to them, especially here. I find that these seem to be divergent goals, as are many things in life. You're trying to optimise multiple dimensions at once and it can be very difficult to weight them.

[27:53] But what I'm really interested in is trying to address the different personality types that you encounter in the workplace. So if people value different things for various reasons, and the real question that I'm trying to get at I guess, is how can we objectively measure whether we are doing the right thing or moving in the correct direction, like oftentimes you'll make a decision, or you'll respond to a concern in a certain way, you'll solve a problem, but there's no way for me to know why is this the correct decision?

[28:27] You could even look back over a year from now, you can't really tell if that particular decision was the good one or not. Do you guys have any tactics, strategies for trying to objectify away one's decisions, rather than just being like it felt like a good idea at the time?

[28:48] Phillip: Did everybody get that? So it's like how do you know if you made a good decision when you're in management and you've got no control? It's like how much more messed up would my team be if I had done X instead of Y is kind of how I'm interpreting that. So how do you know if your decisions are good?

[29:04] Warren: Well, at Luno we're pretty obsessed with data and metrics, so always reflecting back after projects, et cetera, looking at the data and seeing the effect and if it's a good effect or a bad effect.

[29:16] If it's good, cool, move on to the next thing, let's make it even better. And if we see a dip we go back, we reanalyze what our assumptions were and try another thing, fix it, iterate and improve, watch the metrics and keep on repeating.

[29:41] Ashi: You will quickly fall into the situation where you will optimise for what you can measure, which is fine, you can only systematically optimise for the things you can measure, but I think you do need to, like prior to doing all that measuring and optimising, articulate what your values are and figure out how you can attach metrics to, if not those, the actual incarnation of those values in the world, then at least some proxy to them.

[30:16] Warren: A north star, something we can all work towards at the company.

[30:23] Ashi: Yeah. Something you want.

[30:24] Dean: Yeah. I think the metrics matter. Earlier I spoke about using time and information as a metric. So if you've made a decision and you're trying to figure out if it was the right decision, there are no right or wrong decisions, there only things that are most or least fit for purpose based on context.

[30:43] So you've got to really kind of maybe, in some ways, let go of the need for certainty to go, "Well, was that or is this the right decision?" And that helps because it means you get a bit more fluidity in being to change that decision and not go, "Oh well, John, this guy is messing up, made this bad decision and he's the manager, so it's all his fault."

[31:04] For example, I once hired somebody into my team, to a design team that had zero design experience and obviously everybody looked at me like what are you doing, Dean? But I hired that person for a very particular reason and that could have gone one of two ways. It could have never gelled and the effectiveness of the team could have gone down in terms of what we were trying to achieve. So if we didn't start achieving things because... I would have to have a different... change the decision by either giving the person a different job or figuring something else out.

[31:32] But the reverse happened where a new perspective, really good challenge, different quality of conversation, completely different lens to look at the same problems and all of a sudden you start to design new things.

[31:44] So, net net it seems like a good decision. Maybe not the right decision but an effective one. And I think that's the difference, for me at least, when I'm looking at different things, is to look at effectiveness rather than the right or wrong because I don't think there is, I can even ever know that.

[32:03] And I make the assumption that I will make the mistake. I don't know when, I don't know how, but I know it's coming, so that lets me start because I know it's coming, I know it's on the route. So that really, really helps from a... especially from a, if you're trying to weigh up the diversity thing because I think the conversation's also been around where do you, the juice and the squeeze, we've got to get a diverse team but sometimes it takes longer because your biases will let you go, "Well, I know predictable outcomes." So if I hire away, use this tool, I know what's going to happen.

[32:35] The problem with that predictable outcome is it means, by definition, it can't change, which means it can't get better - it only can stay the same or get worse. So then there, you kind of drift into failure. So yeah. That's my story, I'm sticking to it.

[32:54] Phillip: Okay. So, how do you know... I think what we're saying is, if things got better then it was a good decision, at the simplest level, but you can't know whether things are as good as they could be. You can only know that they're better than they were.

[33:16] And I think we kind of got two angles there. One is about the product, if I've got a product and I've got metrics and I've got analytics I can look at on that product, and I can see okay, I changed this feature, now more members of my audience are doing X. Well, that's an improvement, and if you believe in the power of continuous improvement, like Toyota, then hey, things are going to get better.

[33:39] For a team, your metrics are much less visible. It's more about how happy is my team or how productive is my team.

[33:52] Dean: Yeah, I think productivity, effectiveness, retention. How many people have conversations over cigarettes that don't smoke. Those kinds of things, you can kind of...

[34:04] So people tend to form when things are going badly in your team, they tend to form what I call therapy groups. So we find the people that agree with our point of view, so that they can validate it, and then the more factions you have then, the more unhealthy the team is.

[34:15] So it's part of the, there's a scale of dysfunctions in team, so you've got lack of trust, lack of accountability, so you can measure those things by looking at the occurrences of contributions to team meetings, how many people actually speak up about certain things, or how many people sit there, wait for the meeting to be over, or go have a fake cigarette, talk about how stupid that was, and come back.

[34:36] So you can measure those things if you're paying attention, right? And I think that's the thing, is to really, if you're in any leadership or team lead role, your role is to pay attention to the humans. Because if you're not doing that then you're going to end up with bad product, actually, in my opinion, because it's a symptom of what the people do, and I think...

[34:57] So those metrics change, so you're looking for trust, accountability, people going first to solve a problem. So do people sit and go, "Oh, well that's Dean's responsibility or John," let's use John again. So we don't touch that thing, right? And so you don't have that shared accountability because he does that part of the process. Then you've probably got... that's a metric, to see the occurrences of that. So I would use those, definitely.

[35:20] Warren: What he said, yeah.

[35:21] Phillip: It's pretty good, yeah.

[35:24] Ashi: Yeah I mean you can take surveys, those obviously have problems. You can do your own observations, which is also you have to correct for your biases.

[35:34] Probably the most reliable way is for the company, I don't really like companies providing alcohol, but many do, so you observe the alcohol consumption. You're like, “Oh, we're buying more whisky than we were before per capita, so something is not right.”

[35:54] Everyone's like, “No, that's a bad idea,” but look: You're going to buy the alcohol anyway, you may as well track it, right? Then you have to normalise for the season.

[36:03] Warren: If we use that use that as a measurement in the Cape Town office at Luno, we clearly have a major people problem.

[36:09] Ashi: It's the delta, right? It's like, “Oh people are drinking more than they were.”

[36:14] Phillip: So you've got a baseline high whisky consumption but if the delta is positive then you have a problem.

[36:19] Dean: It's the change you measure, you've got to measure the change.

[36:21] Ashi: So I also want to challenge something you said earlier, which is you said that you know if a decision was good. You never know that. You never know that a given decision was the right one or the wrong one.

[36:31] What you know is that over some period of time in aggregate some metric has gotten better or worse, which... what it tells you is not that you... it tells you that overall your decisions were leading to better or worse results, and so the guidance you can take from that is not oh, all of these particular decisions were bad or all of these were good, but something is wrong in our decision making process during this time, or something is very... There's some... you look at how you are or are not meeting your metrics, and then you can try and decide what needs to change in our process.

[37:12] Phillip: And what sort of time period do you think is associated with that? Because I've now got this idea of a glide path of something changing as I make a series of many decisions over time. What sort of time period are we looking at? Are we looking at a quarter or a year? Or how quickly can you aggregate your decisions to come up with an analysis of your decision making capability?

[37:36] Ashi: It depends on what it is, right? On the elasticity of the system. So if you're talking about... I taught at a bootcamp or a number of bootcamps, and if you're talking about how does a curriculum change impact the quality of our education where we decide that quality means our graduates can get hired because they want to get hired, and that's kind of the point.

[38:01] Then that's... It's going to take a while. It's at least 180 days before they can go through the program and then be trying to get jobs for a while and then that's one cohort, really. So it's not a... Because cohorts have variants, so you need... It's going to take probably a year before you really, really know okay, this was a good decision.

[38:25] Which makes it hard because in a year you probably want to change the curriculum again, and so, well, should we? I don't know. Should we exercise a different process?

[38:34] And then if you're talking about processes for... that's one decision, right? One decision for changing the curriculum once. So if you want to... What you actually want to do is figure out what the process for changing a curriculum should be. And that will take probably more, like more time than bootcamps have really been around right now, which is why I think nobody really knows that the model works. They know that... we know that it worked for this little flash in the pan, but will it adapt? I don't know that we know how it will adapt.

[39:11] On the other hand, if you're talking about the social dynamics of the team, I feel like we can come up with metrics and take surveys and all that, but you know pretty fast, you know within weeks, probably, if the new hire was a bad idea.

[39:30] Ridhwana: I also think that there's different types of metrics you can use to determine things, so you can have the long-term metrics that are going to inform your next decisions, but then there's also the shorter metrics that you can start implementing to actually, in the example of a bootcamp, instead of waiting up until the time the curriculum is implemented for, say, a year. You can use other measure of impact on a weekly basis.

[39:58] Perhaps it may be things like attendance traits or it could be engagement levels, things like that on a shorter term. So you'd use a combination of long-term metrics and short-term metrics to give you the best effect.

[40:14] Phillip: Awesome. I think you got a pretty thorough answer there. I hope you're satisfied because you should be, it was good. All right, anymore? Have we got another one? Oh, yes.

[40:27] Audience member: Hi. I've been enabling people to ask questions all day but I haven't asked mine. So I have two, actually. One is about mistakes. So the situations or the examples that you mentioned, they all had somewhat happy endings. So, I had a situation that was on the other end of the spectrum once.

[40:52] I also made a mistake where I deployed to production a debugging environment and then it was pretty quick where we picked it up, and as soon as we picked it up I went ahead and fixed it without having anybody tell me, "You have to fix it."

[41:08] But then at the end of the day I was still getting blamed and the situation wasn't well-handled. So I think that the question is more around what do you recommend people that get in that situation to do or how to handle it to just make the business improve or try to kickstart that process, or if not possible, then what are the options? And then I'll ask the other one after.

[41:37] Ridhwana: So I personally feel like there's two options. The one is you go ahead and you try and change things. So you actually approach the people around you and you have a discussion about it and take on the approach where you actually convey how you think it should have been dealt with.

[41:59] Then the other option is if you're not willing to put in the effort, find a place that treats you better. Those are the two options available, personally.

[42:11] Ashi: So something you can, you're always empowered to do, is you can, even if the process at your company, maybe it's not to do a blameless post mortem, it's to have someone yell at you for 15 minutes. You can still do the blameless postmortem and publish it and use that both as a model of, “Here's how, like subtly or not so subtly, here's how I think we should deal with these things in the future.”

[42:40] It also looks very good, it just, like, looks good to everyone that like oh, you're clearly defining what went wrong and you're taking responsibility for your part of it.

[42:52] You will probably also identify structural issues that do need to be changed. It probably shouldn't... none of these cases should really... it should not be easy to push the debug version into prod, right? There's some if statement that needed to be written somewhere.

**[43:11] **So that, and identifying that, it both looks good from a career standpoint. For me, like when I've gotten awful feedback it's very psychologically helpful to do that, and then I think you can fix things at your company, at least regarding that part of the process. If not the actual feedback process.

[43:36] Phillip: Cool. I'm not sure you get to ask your last question because I think we have to wrap up. No, we have time for your last question.

[43:43] Audience member: Okay, so this one, it touches on the principle of charity that Warren mentioned. So I like the idea of the principle of charity because it removes a lot of situations that don't really lead anywhere and they just become blockers.

[44:03] But if you think about it, it could be actually a response to a preceding problem which is like telling people how to deal with people that are being snarky or cracking jokes in an unpleasant manner. So how do you prevent the principle of charity to become an excuse for people to actually be that type of snarky or like the jokester, because there's the principle of charity as an excuse for that?

[44:34] Warren: Okay, so one of the things that I was unable to talk about in my talk was that the flip side of the principle of charity, where... and maybe I touched on it a little bit, but just have general respect.

[44:50] So when you're talking to someone, yeah, humor's good, I'm a big advocate for being a clown, but there's a limit, and you need to understand where that line is personally and show respect to your peers and your bosses, obviously. And how that happens, that's I would hope a lot of people understand that, but also going back to the one-on-ones, these kinds of things can get addressed and worked on with the managers and yeah.

[45:30] Just have respect, that's the flip side of principle of charity, because principle of charity is there to be your last line of defense if that respect fails. It's just to take that emotion, that perceived emotion away from the conversation.

[45:50] But if everyone's talking respectfully, then there may be very little need to be applying the principle of charity.

[46:00] Ashi: Is the principle of charity like you interpret what the other person is saying in the most charitable light possible?

**[46:08] Warren: **Exactly.

**[46:11] Ashi: **Even if that is not genuinely your interpretation?

[46:17] Warren: Well, yeah, I would try and assume best even if the person was being snarky. There's social cues to pick up when someone is being a jerk.

[46:27] Ashi: I don't like that. I don't like it. No, I think if someone is... if I believe that someone is adding charge to a situation, it's dishonest for me not to respond to that in some way.

[46:46] If I have a reaction to it, I think you should share that otherwise you're having this weird slant interaction. I can see it being good for diffusing interactions where you are seeing something that is legitimately not there, but I think you can also...

[47:03] So, I used to have a lot of trouble actually whenever I would have an interaction that felt uncomfortable for me or they were giving me something or I felt like I just didn't like what they were saying but I couldn't put my finger on it, I would really lock up, and what helped me get over that was actually reading Nonviolent Communication - very helpful book, highly recommend it - where Marshall Rosenberg recommends basically asking questions in that context.

[47:37] So is this what you mean? Someone tells an off-colour joke, like “Oh, what do you mean by that? Or is this the implication? Do you have this belief that I'm ascribing to you? Just so we can be on the same page about that.”

[47:59] I think phrasing those as questions, by putting yourself in the interrogative mode makes it, at least for me it makes it much easier to present without judgment, to navigate that without judgment. It's not that I won't later judge them, it's like, “Yes I think we have gone on this journey of exploration and I think we've decided that your values are very different from mine.”

[48:24] But even that, it's like you end up coming to a model of the person that is more holistic by deciding, okay, I'm going to be curious, I'm going to constantly be asking, and that's how I'll deal with a challenging situation.

[48:43] It doesn't always work, in particular it doesn't really provide resistance. It does help foster connection. But sometimes afterwards I do feel like okay, it was great that I navigated that situation, I feel like I was very in my integrity in doing it, I don't feel like I blew up, I felt like my emotional responses were in check, but I do feel that someone needs to call that person out and I didn't really necessarily do that.

[49:12] Dean: Yeah, I think just on the... Like when you say respect, respect's different for different people. And that's where it gets really hard because you may think you're being respectful from your background or whatever, but for somebody else they receive it as a really disrespectful thing. So that's where sometimes the mismatch happens, right?

[49:30] So I fully agree with the first approach should be to be curious and interested around why that would be the case. So if you're seeing in the other person that it's not received well, so if you're making the snarky joke or your response is that person's being oversensitive then you probably don't have a piece of information that you need, because I don't think people are just oversensitive. There's a rooting thing that's happening there.

[50:01] I mean, I've had that several times, people, like managers that have made jokes that are just not okay, and you've got to really kind of go, "Listen, do you even know this thing that you're doing is really bad?" And then you've got one or two things that happens. Either they go, "Oh, I didn't know that." Or, they get defensive and go, "Oh, you're being oversensitive." Then you've got to do a bit of a ‘juice’ and a ‘squeeze’ thing.

[50:23] Well, hmm, is this a******? Okay, I don't want to work there or not. At the end of the day it depends on what your role is in that team and whatever. If it's not your business and you work for... you can get to that point, you go, “Okay, there's not a fit here,” and you've got to move on, otherwise you're spending willpower just to do your day job and that's just not worth it long-term.

[50:42] Yeah, so I think measuring respect is always interesting for me because you can't assume that your version of respect is the same for everybody and I think that's really important.

[50:52] Phillip: I've got to stop it there, guys. I reckon things were just getting started, actually. This was amazing. So presumably things will carry on over beers upstairs. They're pointing upstairs, they're like, "Upstairs..."

[51:06] So if you want to take issue with this or explore it further, you can. We're going to head upstairs, and thank you very much for bringing the energy, listening, giving us great questions, and thank you very much to these four amazing people for sharing yet more of their knowledge. Cool.

Recent posts

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.