 Just a couple of bits of news. The main piece of which is last month, Marge and I were voted onto along with Julia Toplas to the Drupal South Steering Committee. So if you voted for that, regardless of who you voted for, thank you very much for participating. You don't know that Drupal South Committee is not part of the Drupal Association. It kind of sits underneath Linux Australia in a very hands-off relationship. So it is very much a community run by the Australian and NZ community and serving that community directly. So thank you if you voted for taking a part in that and helping to see that come through. We're all really looking forward to the Wellington event. I hope we'll have dates we can share with you and I hope we'll be able to see you there. I'd also like to call for speakers for his meetup for next year. We're going to have the December meetup, which will be at Reload Bar on December 8th. You are all more than welcome to come to that, but you do need to RSVP for that one. If you're the sort of person who doesn't usually RSVP for things, we have a very specific head count for that that we have to stick to. So first come, first served. The other thing that I wanted to mention, yeah, we need speakers for this event. So we're experimenting a little bit tonight with this panel arrangement. I haven't seen a panel done at a Drupal meetup yet. We're taking a little bit of a risk. That's the theme of the panel. So that's perfectly fine. If you think of something that you think we should try next year, we're going to try and get into this monthly from February. Or if you want to present something on your own, then please let me know and we'd love to have you involved. So without further ado, I'm going to hand over to Carl, who is going to introduce our panels and kick off the main event. So thank you, Carl. Thank you. This is also new to me. So I'll be reading from the script occasionally. We're here tonight to discuss risk and how that impacts innovation in the place. And we've got a representative from some major categories. So Senior Public Servant, there's a private sector in leadership, the developers and a project manager, a public sector team. So on the far right, we have Howard. You want to introduce yourself? I'm Helen Delfanti. I'm currently contracting at the Civil Aviation Safety Authority as a digital project manager. I rebuilt the CASA website, which went live in December last year. And I've been doing continuous recruitment work for the medicines. And Alastair? Hi, Alastair Anil, technical product donor at GovCMS. Government face of things. Government for a long time. We have 15 years of luck overall. Haven't done a lot of product stuff in a very long time. Next we have Lee. Hi, everyone. I'm Lee Guidoz, I'm the managing director of Anex. I've been doing dribble stuff probably for, I was just trying to calculate real quickly my head, probably about eight years now. So you're involved as a developer and also as a, like a scrum master and delivery lead for tons of dribble stuff. And Brian? Hi, Brian. I work with, I work for Lee. So I'm a big risk sitting next to him today. I'm a developer. Yeah, but we manage risks. I'm a senior job and we work on dribble projects a lot of the various things. Okay, and I'm Carl Hepworth. I'm the moderator for tonight's panel and I work with previous next, managing and developing the skipper, what for? So operations folks. I will be just keeping this conversation going and I might chime in occasionally. Did we want to start by defining what we all think risk is? Because this can be very different depending on your background, your history. Ooh, Palestine. Yeah, sure, sure. Sorry, we're not there. No, risk for me is resourcing, capacity, capability. I think are the big ones for me. When I think of that, people always need more resources. People usually don't have a lot of capability and capacity is always an interesting one across bodies, resources, people, technology. Sorry. Just one moment. We're getting a low battery. Okay, one second. That's risk. We've got a mitigation in progress. Excellent. Yeah, they're the ones, yeah, that's how I define those sorts of things. They're very umbrella terms, but of course... Moving on, Bryn, follow up. So for me, I guess risk at work would be whether the project is to live it on time and sort of to budget in a general sense. I guess I don't really... We will take more care about those bigger things. For me, it's, yeah, right down in the roots of a project. Does these tickets get completed in the right time frames or are we missing the mark in certain areas and how can we adjust to those things? So for me, risk is a bit more specific to a project, I guess, in this sense of what risk is. Yep. Hello? Risk for me as a project manager is anything that will prevent me from delivery. So whether that's lack of resources, lack of capacity, or trying to do something that's creating a risk for the end users on a website or in a system, so anything like that that may prevent me from trying to get the job done, that for me is what I define as risk. And like, yeah, I definitely agree with everything everyone's already said. I think the other bits I always think about, like to me, everything has some level of risk, which we probably don't even think about, but we're always doing some kind of mitigation that to me even like the risk of not doing something or not even like necessarily delivering the outcome, but also the risk of like not getting what am I trying to say, the maybe that's part of where we're going with the innovation part, which is like, yeah, the risk of not fulfilling the potential of what you could possibly get or not exploring something as part of the product delivery. So for tonight's context, we have unmanaged risk, which is a uncollaborative effort where an individual or one or two individuals take lead and sort of go into the space where a decision could impact customers, clients or workflows. And you got managed risk, which is a more collaborative effort. Everyone's aware of the risks. Everyone gets involved in testing and it's a bit more structured. Now, first question would be, do you feel that within the workplace that risk-taking is encouraged? And if it is, do you feel it's accompanied by an acceptance portfolio? We all have war stories. So take that, how you will. Did you want to go first, Bren? Sure. Your glasses are right next to you. I think, honestly, I think like at work, we do a pretty good job at assessing and sort of mitigating risk where we can. And I would say that risks aren't that bad if we kind of are open and honest about what we think those risks might be. So let's say we wanna, we're starting a new project and I wanted to build with a new framework, for instance, that isn't inherently risky because or we don't know anything about it usually. But if we like estimate properly and sort of, we're just upfront about those things that kind of go wrong or that kind of stuff, like I don't think there's any real reason why we can't take that risk. And at work, I think we do a pretty good job at allowing people to sort of be a bit more flexible when it comes to that kind of level of deciding, are we gonna be able to use view or react or a few crazy angular? Like there's these things where it doesn't seem like it's that risky if we just manage them. So I think at work, we are encouraged to take risks and like in this case, try new technologies and things like that, but it doesn't seem inherently risky when you take all the steps to make sure that you've covered yourself. And so do you know where the flag points are of like, this isn't gonna work for me to go back to what we know. Yeah, so you can say it's a whole bunch of manage risk. Have you had to deal with a manager's in the same way? What's just working with me is somewhat unmanageable. Unmanageable. Pat and Lee will probably both tell you that, but usually at the end of the day, I come to my senses and I'm more of a... A collaborative approach and you basically reach a point collaboratively besides when it's time to step back. Yeah, like, so Pat's in the audience and no one can see him but he's there. He's my boss and like I will say to him like, I wanna try this. And he'll say, yep, or not. Based on our time frames and stuff, but hardly ever know. And usually if it's a no, it's because it's not needed. But like, we work at it together and we sort of just make a decision together that yeah, this is a fine thing to try out or like, let's save that for a different project where we have a bit more scope for like why we wanna use this. So I have to make a bit of a justification sometimes why I've wanted to use these things, but I don't think it'll work at least in this job, there's much unmanaged risk. Any more? Yeah, any more. Like we have lots of things in place to make sure that any risk is like caught early and we're like communicating often. So those risks are brought up in just like daily standoffs and like backlog refinement and all these kinds of things where we think of there's like a possibility that something could go right here. We've sort of got all these other frameworks around them to sort of like manage the risk and make sure that we're still innovating and things like that. Fantastic. Helen, would you like to hear the question? Yes, please. Do you feel that within your workplace that risk taking is encouraged and is there a feeling that you're, you're gonna be accepted for failing and how is that handled? So I think, I don't know that risk is encouraged, just accepted as being part of a project in, and I haven't really worked with unmanaged risks because part of being a project manager is identifying the risks and understanding the potential outcomes and putting the mitigations in place so that hopefully that doesn't happen. So I usually work with a managed risk environment. Accepting failure is a bit of a juggle because the environment I've been working in for the last couple of years is I'm working for a regulator. So there are lots of legislative and regulatory things that have to be done and there's no room for failure in that environment. And previous roles, similarly, you worked for someone, I worked for the digital health agency building the My Health Record website and we had to put into place the mechanisms on the website to manage the opt-out period. And there was such a high public focus on that and so much publicity that, and the census had just failed like six months before. So there was no room for failure. Like, so that was kind of a really scary place to be in because there was a real potential for failure. But we just, everyone kept walking around going, you can't be another census. And it's like, so it's always that juggle but risk is just a part of being project manager. You just live with it and mitigate it to the best of your ability. And while failures, I'd like to say failure is not an option. It's always a possibility, but you just work your hardest to not make it happen. Yep. Also, I'd like to hear the question from the other person. No, okay, all right. A couple of my things reflect Helen's experience there. It's probably yes or no to the actual question. Yes, in the sense I think we've got some pretty good controls where I work at the moment. We go through camp process, we think about change in that sort of space. We have a lot of meetings talking about a lot of things in that sort of space. And we think about risk, obviously, the security level and functionality level. And of course, obviously, well, what happens if all of this blows up? So of course, a lot of that is that sort of front of mind, very similar to that. When I think about some of our customers, similar again to Helen's experience is there is an expectation that things cannot fail. There isn't that room in their space or they've been burned for or something. And that's reflected in the previous jobs of mine as well when I got the last job I had before. GovCMS was running a corporate team finance, same building, different sort of lens, but same thing again. People just expect it to work. I can't have it fail over or there's a legislative requirement in that sort of space. So there's an expectation that you can just deal with that regardless of whether it's actually manageable or not, or even if it's a real risk. I think a lot of people worry about some of these things that aren't necessarily founded. Yes, you should have some capacity built in to be able to address those things if they pop up. But I think with a lot of stakeholders and customers because they don't have an understanding of the technology being used or redundancies built in or even some of those things such as our process. And even today, this week's been a bit of a challenge we have so much for doing a release. That's, it's a managed risk because we have resources. We're doing it during operational hours where we have capacity to do things. It isn't necessarily great, but we've also got rollbacks in place. Whether people perceive that's a good thing or whether that's potentially mitigation, not sure. That's for someone else to decide when they look at us and when they think of us as a product. And Leigh, do you have any other question? No, I think I'm all right. Yeah, no, I think, yeah, I was thinking about this one as well. I don't know that we encourage risks as much as we maybe should, but we try to build safety into every day, how we work to mitigate all those risks and create space for all of our people to do the thing that they love to do. So the last thing we want is have a list of scope and just only do that. And you kind of just work like a robot, which is often a lot how projects come to us. What we try to do is create enough space in there where you get a chance to think, like, yes, there's features and there's scope and that's what people want, but we want to provide enough time in there for the experts to think about the problem, maybe come up with a few extra solutions because often your scope is just the somebody's idea of the solution to our problem. So yeah, I guess we try to provide that safety so that there is time or opportunities for people to come up with ideas. And sometimes it's just like, no, sorry, whoever it is, our client absolutely wants this thing that's how it is. Or it might just be that's a great idea for like the next phase of a project potentially, like, because there's back to all those constraints with budget or resources or whatever. So yeah, we just try to provide that safety. We kind of, yeah, it's like, and I guess I'll slightly put a slight twist on the fail part, which is we definitely want stuff to go down, but we try to make it safe enough for you to like learn a lesson and like fail inside of a sprint or on a test or like I've tried to build this thing but it didn't quite work out, but it was worth the experiment. Or we build a prototype. We thought this would solve a problem, but there we've done user testing doesn't solve these problems. That's not failure that like, we try to find that more around like, we've learned something, we've saved a bunch of time for like, we'd have to build that thing now we know it doesn't quite work or at least it needs to be tweaked and known, like a known usable function or PDF piece functionality. So yeah, that's how we kind of try to provide that space and maybe we should be like, like all those safeguards, maybe it's not as overt, which is like, we have all this in place so you guys can do what you think to take some risks and promote it like that, but maybe we should. Yeah. Can I just throw in one other comment, something brings in about, can I try that? Yes, but in a test environment. Yeah. Don't go near the one with the red banner at the top. Just going into the broad dark base, yeah. So you can do whatever you like, you can take. So yeah, so that's a cry that I have every day in a test environment. Sounds like we're all very familiar with Managers these days, which is a good thing to see. Is there any differentiating language that you have at work? Or are there both between manager and unmanagers? Do you know you can handle different socially? Or are they just, how do we define unmanagers again? Uncollaborative work, right. One or more individuals working to achieve a certain goal, it might be due to a necessity. Yeah. Our boys. Our boys. Yeah. It could be a month for you, yeah? Okay. No, it's just, I say you can't a lot. Like a collaborative, like a collaboration is our definition. Yeah, gotcha. I mean, my environment that is doesn't go well. Like, because I'm reporting to people who have very definite ideas about what they want to accomplish. And like with scope and requirements and if someone goes off on a tangent and does something weird, then it usually doesn't go down well. Do you find that the terms used to speak with them are a lot more formal than that happens? Yes. That's what I'm trying to build down with. Yeah. For the, you know, in my head, the buck stops on my desk on the project. They'll do on the one that's organising the resources and trying to get the job done, organising the sprint, trying to get all the requirements done. And if something does go off the rails, then I take responsibility for that because I've even not been paying attention. I haven't asked the right questions or someone hasn't come to me and spoken to me about what they're doing. But either way, it's my responsibility to keep track of all of that. And if I haven't done that, then I've fallen my sword. Have you found the same thing? Well, yes. Probably not so much in the current job. I like to think we're a bit better about discovery and having visibility of things that come up. And of course, obviously, there's a whole lot of security requirements that go with that job and make sure that we have to be on top of things. When I think about previous, it probably aligns very much to how one's there, where, yeah, you find out that someone's been doing something or you find out that something's been connected to one of your systems, and then you find out because someone turned something off or blew up or they've registered it in a company's name and you don't have a contact over there anymore or they closed down because they had a certain video get published and released publicly and then you'd have to rebuild their site. Three days later, as they do the next round of graduates, I only have been on a break if anyone's unfamiliar with what I'm talking about there or just a public graduate there. So that was one of those low-end effects that landed into my team at the time. And of course, for those sorts of things, it was a whole bunch of process that happened that jumped through all the right groups that you do for procurement and things in government doing all these sorts of things. They didn't actually tell the team who would then own the right any of the information of how to get to it, how to maintain it, how to pay a bill for it. So when that subspace, yeah, everyone but the people holding the bag were involved. When you look at that specific instance, everything feels like it's on my board except for the fact that you were roped in as you became the BAU owner after built. But that's otherwise pretty reflective of that sort of cowboy mentality if someone goes off, build something and then he's hoping it doesn't break because that left her a year ago. Language in that case would be very consistent from start to finish the project, wouldn't it? Yeah. Yeah. Lee? Yeah, I think I'll answer this from like a high-performing teams kind of perspective because, yeah, like I think a lack of collaboration causes I think a lot of problems in our teams. So as soon as we, yeah, you have people, I guess cowboys or whatever you want to call it, like off doing their own thing, not collaborating or not checking in with teams and just doing their own thing. You destroy trust like really quickly. And so that has huge effects more than just like, can we get this project done on time? Of course, that all becomes part of a major risk. But yeah, as soon as you have people not collaborating, then the team's second guessing themselves about what's next and what was discussed and where are we up to? So yeah, we try to back to those systems and things, we try to make it as nice a space inside of that team to be able to collaborate. And some of that's just being around when your teammates are around and checking in on whether you're on Slack or on Teams and just what I'm up to is use the ticket on that. And then I think the other part would just be that like blameless kind of culture of, we try to blame system or process problems rather than individuals. Everyone's heard of those classic stories where someone's first day where they walked to the prod database, but are they at fault or is it the fact that they had access to that on their first day? And so like we try to think about things like that where no one really has malicious intent and is deliberately trying to break stuff. No one wants to ruin a project or have something come down. So we try to have systems in place back to creating that safety. And then again, look at it as a, issues always happen, things happen, but try and look at it as a process. Well, what can we change? Maybe someone hasn't had enough training or maybe the meetings are on at the wrong time and you can't get to them. So therefore you're not collaborating as much as you need to be. So we try to look there. Yeah. I think just to touch on that, Leo, I'd agree because I think a lot of people are worried about getting yelled at for something. And of course that malicious intent one is a big one. You're not doing this sort of stuff because you have a huge, theoretically like what you're doing in this space, right? There's a level of creativity that comes with this, it's a level of creativity that works at a risk space as well. There's a whole bunch of really cool things that you want to do with you. They're trying to solve problems. Hopefully have a bit of fun while you do it. Absolutely. So yeah, I mean, the average owner isn't usually trying to do those sort of things. They're just trying to do their job. That's right. There's nothing like getting yelled at to then be like, cool, I'm not going to get creative anymore. I'm going to do exactly what I'm told and I've basically been discouraged, especially if you talk publicly, like if you just like, you did something wrong in front of everybody, you're never going to get anything like that. Why would you speak up again? Or why would you, yeah, you'd be, can I, should I do this? You'd be, yeah, it's not good for culture for sure. Yeah. Can someone push those changes for them? Yeah, review everything I've done because I'm nervous as hell. I don't want to be embarrassed in front of everybody. Yeah. Exactly. Yeah. Do you want to take three? My answer's not the same as Lee's. Maybe we've worked in the same place so it kind of makes sense. But I think in terms of the language, as people get spoken to or communicated with differently, it doesn't happen often, but sometimes you have people that do that in your team and it becomes the case that they become sort of like the black sheep of the team in some ways and then I guess people, every single thing that that person does from then on is sort of like viewed from this, like they're trying to go against us sort of a lot and I guess the communication between like me and that other person or even if I'm that person, it's probably not like everything's a bit more, like you said, formal and a bit more like, it's like, this is the thing you need to do, so that like by communicating like that, you're trying to mitigate the risk that that person does something wild again, right? But is that like you describing like a breakdown of trust again or something comes down to that, right? Like if I'm working with someone and they're constantly just sort of strained from that ticket a little bit and sort of like doing their own thing or like we as a team, let's say there's five members and four of us have all decided that we're all on the same page about how we're gonna build a site, right? And then there's this one other guy who's just doing it their own way. It becomes really challenging to work with that person because now the site's just like two sites in one and it becomes really difficult and that trust is broken down but you feel like you can't even give them a ticket in some ways because you just don't know what's gonna come out the other end. And like Lee said, in high-performing teams the trust is paramount. I think it just doesn't happen. Like you can't have a good team if the other people don't trust each other, right? Like basically human being in the next guy at the bottom decides to just build circles just fucking everyone falls down. Have you in your career found that pattern can be reversed where a breakdown in trust can eventually be maintained, upheld or informed upon? Do you feel it's something that can be turned around? I think it depends on the person. I think it can. Like I don't think there's ever the possibility that it's just 100% no. It really depends on the motivation of the person and the way that they're being dealt with within the team. Like we said, if they're being yelled at in front of everyone, there's a really low chance that that person's ever gonna want to change because you've kind of just put them in front of the village and called them media, right? And that's not a nice position to be in. But I think if you nurture the person and like everyone just wants to come to work and do their job like Al said, right? Like no one, I don't think anyone ever does things maliciously and like maybe that one person thought that that was the best way to do it and they've just done things that way forever because that's the way it used to work in the past, right? Maybe they used to work in Drupal 6 and now they've moved straight to Drupal 8 and it's a completely different paradigm, right? So maybe there's that kind of issue and it's just a training thing. But I don't think it's impossible. I think sometimes it can be hard to teach an old dog new tricks though. I think I ask them to be rebuilt through process. So going back to what they said, if you stick to the process that everybody knows what's expected and what you have to do and so if someone breaks the process and you just bring everybody back in or if there's no process there or the process is broken and sit everybody down and say, how do we fix the process? Like what step is it that's broken? Where is this going off the rails? Okay, everyone agrees, this is what we're now doing. Here it is, everybody follows this and if everyone there does that that's how trust gets rebuilt because the person that lost the trust or the people that don't trust whoever they can see that everyone's now following the rules. To me that requires both parties to want to change. Absolutely, absolutely. Can we add a project manager and run for the office together? I mean, I had two developers a while back who were committing stuff different and using a different process and one was doing it one way and he thought he was right and the other one was doing it a different way and he thought he was right and they kept losing work. The second one was overriding work that the other one had done and they were kept going, like, ah! Like coming in the morning and the sky was falling and so I sat them down and I said, okay, I need you guys to agree on the process. Like whatever it is that you wanted, however you want to do the commits you both need to agree on the same steps so that that doesn't happen and eventually they came to a consensus and did it. And while I don't think they ever got to 100% of trust, they probably got to about 95% and that was fine. That's a good outcome. I've been on that side of it where it didn't work out for the other party. Just a question. There you go. I'll be fine. I'll be fine. I'll be fine. I'll be fine. I'll be fine. I'll be fine. I'll be fine. It's just a process and communication, obviously. Now, moving on, do you feel that it's necessary to take risks or to innovate to the workplace? Yes. It's nice thinking. I'll do yes and no again as I did earlier. Yes, you should be taking risks. Yes, you should be trying your things. It's a good stimulants. Again, it goes back to that my step in creativity earlier, nor going back to, well, don't do it in one. Don't do it in prod. Don't push it up. Do it in a safe space where it can be trialed. It can be erred. It can be validated. It doesn't work. What else needs to be done to it? Do we have to trouble? But, yes, don't do it out in the wild, you're not. So, the answer would be yes, but in a safe space. Yes. I think that's better. Isn't that? Yes. Does everyone agree? We'll have different feedback? Yes. I don't know exactly how to answer it. Like, like, or why? If I just, I guess I just see everything is there's some risk in everything at some point. So, that's fine. Yeah, it's how much, again, space can you create to, like, where are the parts? Where are the spaces for innovation? Where can we build that in? And then, again, still contain it and mitigate those risks? Like, I think, again, for us, we've got different clients with different needs and different budgets and different appetites for risk-taking. And sometimes they, you know, some people see doing lots of research and understanding of the problem of discovery as, like, risky and spending of money. And I just want my website or my app or whatever it is. Whereas, and others will see that as a necessary process to not build the wrong thing and take, and, you know, like, that can be a risk on its own to, like, go live with something that doesn't actually help a user or will solve the problem that you're there for in the first place. I think the things that are key in my world are preparation. The requirements, scope requirements, you know, writing it all down, understanding what is needed. But then, there's that whole, I love that, there's an old project management little cartoon where they're trying to, you know, the requirement is, this is what the client wants. You know, this is what, yeah, the engineer builds this and the developer builds this and then someone, this is what you end up with, but this is actually what they wanted. And that's a communication thing. But it's also about, you know, if you do all your preparation and your communication right up front and get, you know, then, and keep that communication going. But it's not just with your stakeholders internally, it's also with your audience. Like, you know, the website we've just built, we thought we communicated a lot. And then we found out that it wasn't enough, you know. So it's like, I don't think you can ever do too much talking about what you're doing and telling people what's coming and this is going to change because, but it's always a risk. Everything, like we said, everything is a risk. It's just about trying to keep people prepared and get them to a place where they know that there's a change coming. I agree with the sentiment that everything is risky. Everything's a risk. I don't, like, waking up in the morning, stepping out of your house, doesn't matter. There's like a risk that there's a crazy person who's now there with the chainsaw or like a car hits you or anything. Everything is risky. A comfortable baby and baby. There's a risk that you've betrayed Carl, which is out for you. There's no risk of that. You think the wrong guy. But I think the answer is yes. I think you have to take risks to innovate. They should be managed in some way. Like, we should flag when this is probably like, let's say I choose a piece of technology. A good experiment was we used white on a Drupal project. I think we decided we may not do that again. Well, that was a lesson learned. Yeah, that's a lesson learned, but it was a risk in doing it. Like, it worked and for that project it was fine. But the benefits didn't outweigh the problems that it caused. And that was okay. Like, it was just a thing that we tried. So we took a risk and we tried to innovate with newer technologies. But maybe there's a more simpler way to do the same or similar things. Not to say that we wouldn't use white in a project that required it, like a headless front end or something. That makes sense. But trying to get it to work with Drupal, you've got to have weird stuff in the theme and stuff like that. You had to do a lot of retrofitting to get it to work. The risk was low because I have confidence that we can get it to work. But maybe the reward would have been high if we got it to work and it didn't take that much. We could do away with a lot of older things. So in that way, I think risk really is important to innovate. And we've got to try things. Otherwise, you just stick with the old stuff. Yeah, no one should try. Yeah, we're still on Drupal 7 to the end of life. Coming back to something you said before, do you think there's a place in the workplace for administrators in any capacity? It could be when a customer critically needs attention or develops these things. Or an outage in a social overload. It's something all might feel. But are there cases for it? Are there cases for doing wild countless things? After the young man's risk is through. That's a bit of collaboration. I think that's the important bit. In some ways, it is okay to have a little bit of unmanaged risk if you are committed to mitigating that risk after the fact. Sometimes you have a client and their website needs to go live critically right. We had some sites during COVID that needed to go live real quick. And then as we put them in the dev environment, some things failed in IE 10 or IE 11 or something. So we'll create a block in Drupal and then put JavaScript in the head that will work in IE 11. Ideally, you put a ticket in the backlog to fix it. That's like unmanaged risk because now we have a block with JavaScript in it. We manage it after the fact. Is it okay? Again, I would say they came down to the problem in a process like we said before. There should have been a process in place to make sure that that worked beforehand. Now, there was a lot of other factors that impacted that thing. It was stress, tired, panicking, whatever. But still, in the end, it's unmanaged risk and it was mitigated after the fact. Also, I preferred on a whiteboard or a local computer. I think there is a time of the space for it when it's on some really good examples there. Yeah, but being able to find it and then actually turning it into something that can be managed, yeah, it's key. If you kind of get to that point, we probably shouldn't be doing it. Or we should be reviewing what we're doing to spot those things there. Yeah, I was seeing on this one too. It feels, yeah, it doesn't sound right to agree that I think that unmanaged risk is fine. To me, it just feels like we've got to manage it however, in whatever way, somehow. Especially in project management, you're trying to bring stuff in on time with certain level of expectations. Whatever the problem might be, there has to be some kind of control somewhere there which could be just, do we need some of the work or not? But I need controls on that. You can't just have someone working definitely. At what point is a problem, too much of a problem that more people need to get involved? There has to be some kind of a plan in there. For us, it's for a client, they might be demanding something. It has to go live at this time. If it's just not ready or it's just not right, that becomes their risk as well. And so all I want to do is provide as much information and controls again as possible, which could just be we'll work our asses off for the next three hours to your deadline. We think we can get it done, but man, we're not sure. But here's what we're going to do to do that. In the meantime, you should come up with a plan that's not going live or just in case. I feel like I just would like to know what the constraints might be on the just let's just go for something and we'll pick up a piece as later. But that's the position I'm in, I suppose. I like 100% agree with that. My baseline is talk to the developer, whatever the problem is, what do you want to do, how are we going to fix this? And then he gives me one or two solutions. It's like you can do this or this and I go and talk to my manager and we make a decision. That's my minimal consultation. So I suppose it is still managed, even if it's only verbally. And then afterwards I write it all down. We go, okay, this is what we're going to go and do. And I write it down, put it in a card, whatever it is. I put it in an email, but at least it's managed to the point where I've spoken to the developer and I've spoken to my manager. But it's, yeah, it's, you can't, I've been in that situation where you're sprinting, okay, give us this much time or see if we can fix it. But the caveat is, okay, if we hit this point and we haven't done it then this is what we do. Or we roll back. Sometimes that solution, let's just all dogfile on is half the problem as well. Because we can't see the forest for the trees or under pressure. Sometimes you don't know until you get into it. It's like, well, give us two hours. We'll see what we can do if we don't get it done, we stop. And then it doesn't go into production. So we'll finish it properly tomorrow and we'll roll it out properly. So, you know, but there's always a degree of management there. So. For public service panelists, do you think the federal government generally encourages or discourages risk taking? And what context is risk law accepted if it's control? Yeah, I'm thinking no. You know, many different jobs and activities tell me it's probably no. Not even in the creative space? Yes, I think on a creative space generally, however, it really comes back to how your customers will say, what that creativity is. Most people don't see that when you're going. You're doing it from a code perspective. They're worried about how it usually presents on the screen or what's in the content model. Now, again, they're very important aspects when we think about web development and a lot of the stuff that we do most people are sitting in this room focused on. But they do still sort of draw the sort of almost the line of what is communications versus what is almost ICT. Now, to a degree, they are very closely aligned to ICT, but at the same time as well, they're all their own disciplines now but still, I don't think it's still that traditional model of ICT for a lot of things. I think that's where a lot of it comes from because everyone still feels like it's a bit of a too ICT when we don't know technical sorts of things. Within the constraints of a acceptance criteria, how do you delineate the activity from technically this is exactly what we want. That's a great question and I wish I had an answer for it. I haven't found the magic bullet for that one. From my time being able to once again, it's that open line of communication. It's having a customer or some stakeholders who could simply talk to the problems. I want, you know, what can we move on? What can't we move on? Things like that. If you've got people who just want those sort of I want this, I don't care. I just want it delivered. You're not going to get any movement against that. You're not going to get any different sort of series of acceptance. They're not fast. If you've otherwise got more communication lines and you can talk through those things and explain to them how stuff works, you usually get more flexible. It's not always the way. It's usually got a time pressure or not enough reasons. Yeah. Hello. It's difficult when you have senior stakeholders that are inflexible about the outcome. So if you're just building a website, you're trying to design a website. It's usually where you start. You know, you get the requirements about what they're trying to accomplish. But I want this bit to do that or look like this. And all of a sudden you're locked into something that you've got to then work around because, and you go to them and you say, okay, in my experience that's actually not the best solution. My recommendation would be that you do it this way or we've got here a couple of others. No, no, no. I want that. You know, so it makes it really hard then because if that's going to then cause problems elsewhere but they're completely immovable, then it presents a risk across the entire project then. And that's hard to manage. I have taught people around. I can be quite persuasive when I want to be. It's a lot of energy though. It is a lot of energy. And you have to pick your battles. Again, using Digital Health as an example, we had to do penetration and load testing on the website for, because we knew that when the opt-out period hit, we were going to get millions of people on the website at the same time. And we had some design questions that were going on and some other things and I sat down with my manager one day and I said, right, here are the things I want to achieve. This is the thing that the penetration testing and the load testing was the most important that we had to get right. And we needed the infrastructure in place and we had to spend the money on the infrastructure with these guys to make sure that we didn't have another census. So that was our point of fail. So I came to a compromise on most of the other things because that was the thing I wanted to fight for and win, which I did. And at that point it was the website I had the most traffic that I've seen at that point in time. It was pretty great. And the website didn't follow up. But it's, I had to, like I had management saying, no, I want this bit to be this way. And so I went, okay, but I want that. Yeah, it's an intership. It's an interesting series of lenses. I do a lot of initial sort of conversations with people who are considering coming to GodCMS. Because one I've been on that customer side. I sat in that sort of seat for five or so years. Sometimes Toby responded. Appreciate that. Jesus. Yeah. I'm sorry to throw it out there. So from that side I've been there, I've done it. I've gone from scratch, all of that sort of stuff. And then when they come in and they ask it really depends on who's in the room, what sort of capability and capacity they put in the team. Some of their customers come in with that security uptime focus. And that's the only goal that they're after. Others come in and go, oh, we really want to do something really fun and creative. And that's usually then down by how government executive go, oh, we can't be that maybe we can't be that creative or maybe we're worried we're going a bit too far with these sort of things versus we're trying to be talk to a serious topic. There's always a balance and that stuff too. But it's really interesting because you have that security folks who other people go, well, what's the goal of that? And that's the only thing on phone and stuff. We'll make sure that this gets delivered and other people go, well, how restrictive is your rock? What can we do? How far can we push it? It's just interesting gamut of all of these audiences. I mean, it's government and sometimes it comes across really boring and I would totally agree with that a bit around it and so on. But again, it's it's still dealing with all of these customers that have their own desires, wants, needs and interests or focus. Sorry. It brings me to a decision making model I have was doing a while back the can should must that you are you familiar with as if it's useful to you? Sounds familiar for a country that we're talking about in a positive light at the moment. I've used the Moscow model in a couple of things. I've got this. Yeah, exactly. So we use that on a couple of things internally in romance. We do that without reputation backlog, which just gives me more work. We use it on our website backlog, which usually also gives me more work. And I think we've trialled with a couple of other spaces in sort of small projects. Lots of much other ongoing things behind the scenes. It certainly is eye-opening. I think people who haven't gone through that process or say that their thing is very important when in the scheme of things it's not or maybe it's really easy to tip off. Brett, that was called the Moscow model. Yep. As far as I understand, that's what Yeah, the other way can something something I haven't heard that That's what you said wasn't it yet. So I'm not going to deal with what's another thing. You've got three layers. Nice to have smart tabs and everything else falls in the middle. Yep, cool. Moving on to the next question with the private sector. Do you feel that your clients encourage you to take this and are willing to bet on risk by paying for your failed experiments? Is there a difference between public and private clients in their attitude towards experimentation earlier? I've got a wild opinion on that one which is I don't think the private sector is way more gunk than it sounds in terms of the safety or whatever the perception of public sector. It's just that they care about different things. In my experience the public sector they care about they care about user outcomes and they're protective of that so they're less likely to want to push something or do something that might upset users and things like that. Plus as we mentioned earlier about the regulatory issues and there's lots of content that matters whereas private sector care more about the dollars that they're spending so they might get more creative in that but they are mostly watching the money part of it and they care about their bottom line of work. So I find it kind of similar but they care about different things. There was a second part of that question the difference between public and private attitudes towards experimentation. So I guess maybe it's back to the negotiating and stuff. It's like we'll never frame anything as like a failed experiment but we'll definitely I don't know it's back to that it's everything's a lesson and you've learned something so it wouldn't necessarily be a failure like we'll come up with an idea we think it's all to use a problem rather than just deploy it to thousands of people let's use a test it turns out it didn't work like to that in a way that would be a failure like we had an idea it turns out it doesn't work that's the failure part but actually we learned something it's not really a failure we've saved we've saved on the back end by not building it or causing confusion to use this on a wide product or something like that so I guess I don't know when you've got a client whether it's public or private who's willing to think like that and be ready to care about whatever that MVP looks like which is debatable but yeah whatever that looks like or wherever they're trying to get back to the outcomes like if they're actually thinking bigger picture about this is actually what we need it's the big picture thing we're trying to solve all the other stuff is a bit of detail so we get there it doesn't really matter but as long as we solve the big problem then they're good people to work with and partner with to solve the problems and get caught in the weeds it's a form that has to have 17 fields and should just be right here acceptance criteria when we talk about acceptance criteria should just be we need a form that captures the acceptance criteria should be that we have a form that can capture enough data so that we can perform some action it shouldn't be have you got acceptance criteria have you got 17 fields does this one need validation that one needs validation you know what I mean I'm trying to leave that as a space for the team to figure out like we would expect our team to go find out what's the minimum information need on that form what do we think is that what which means need validation or don't need validation and can work it out as part of the ticket we've been all over there anything else to add to your boss I guess for me personally I'm a bit more in the weeds with stuff so it seemingly things are a bit more up for grubs when it comes to like on a per ticket basis opposed to like a per project basis like Lee's looking at like the grand scale of this we hope we deliver X by this point whereas for me it's more about like in this sprint I want to deliver X so my time frame is a lot a lot shorter and I still have like the grand vision inside of like this is what it needs to be at the end but I guess my my things are more micro yeah my world is much smaller and I can have a bit of a different relationship with the client for instance than Lee does so I'm in stand-ups with them or I'm you know I'm at least seeing them at least once a week every every week and I'm maintaining a relationship on a personal level I guess so I get a they get a better understanding and a feel for me where I can say like hey we we did this and it was alright how about we try or like we succeeded in this area where we kind of had a little risk now we have this other piece of functionality that you want and there's this other way that we could go about doing it and we think it'll be beneficial for you because it'll yield these better things in the end better experience for you as the content manager or the front end will be lighter or removing tech debt or whatever it might be I guess when it comes down to like it's easier for me to negotiate those things because like I can go on like a per day basis so on this project we have to achieve X the difference between like government and private it's I don't know much of a muchness for me I mean I think we can probably all to some degree agree that government clients have a bit more restriction around the things that they're going to do or the things that they need to provide and user where like I mean some private company might come in and say I don't care about anyone that uses Firefox or anything right I just wanted to work in Chrome okay cool that's great for me as the developer because I'm just like awesome I get to do like almost all the new cool things where the government has a bit more it's got to work for everyone actually and you got to make accessibility lots of different rules like we would endeavor to always meet accessibility standards no matter what the project is and we would always be trying to do best practice but if a client comes to us with like some crazy thing that they want to build and they're like it's only only needs to work in Chrome and it makes sense to only build for Chrome like this is more work right so in that regard I guess there's a little difference but I don't actually see that there's that much difference like I I find that there's room for creativity working on government projects as well if not more than regular projects because you have to solve things in different ways and it's nice to be able to like I'm stuck inside this box how can I operate whereas like if I'm working on a private client that only needs Chrome helpful leather right helpful leather like just do whatever you want like lots of people like it's an adage in our sort of sphere that like working within GovCMS can be a bit difficult because like we know what Drupal is outside of GovCMS there's no restriction all that kind of thing but if we like think about it a little bit differently like there's a bit more creativity that goes into a GovCMS site than there is a regular site because I'll just install a module sick but maybe in GovCMS I need to think of like these few ways to do this problem or solve this and like I guess the creativity comes from a different part and like different things are up for grabs and different types of projects and I'd go along with that with the CASA website we're on a SAS platform that the developers that help build or build the site they got really creative in a couple of instances working within that SAS platform but coming up with some really great solutions for things that we needed to accomplish because we didn't have CASA but they just worked with what they had and figured it out and that was pretty amazing so it's good when you can It feels good let me tell you If one yourself has problems like you've had on many other sites before and you just now I have like this tool that I can take to the next site or like anytime someone says I need this on my site and we kind of go again we can't we I'm like well I've done that before over here we did it this way like maybe we could tweak it a little bit every time When you work within a restricted framework and you come up with something creative that does think outside that box and still works it's pretty good What do you think can be done to encourage clients both internal and external to back experimentation with either financial investment or personal investment I think I'll go on this one it's easy to me I think from my perspective it really helps if you have that trust built already like we've already delivered this many things we did it all right now we're telling you that there's this other thing that you could have but like you have this backlog of stuff to say like we did this bit and now we just needed it like trust us a little bit you trusted us with this let us do this a little bit more that that did just like it extends projects they clients might come back to you in the future and say like you did a really good job on this we know that we had this difficult piece of technology we had to work with that you guys did a really good job so let's bring these people back in or you're halfway through the project and you kind of you've established that bit of trust with the client and they they say oh we've just we've just got this person my boss above me said I need this bit now we go well maybe we need to change this and that and they they kind of have that inherent trust with you already and once that trust is built like anyone will tell you it's easy to break trust but if you're delivering and being transparent and honest all the time people are people and they're reasonable and I think that that is the easiest way to make sure that like people are like backing your need to take risks or to innovate is by just delivering it seems simple but I think that's great relationship being authentic with people so if you've got your can that you can yeah I think are you a human you've got your can yeah and owning the mistakes as well like we tried this and it wasn't right like I'll wear that and I'll do this to fix it or look we did this wrong or we did this this thing that we this project we built might not have been right for the situation or whatever but we own that and like I think some of that just to your last bit bring is framing around that you know this library that we thought was going to solve this problem doesn't work or doesn't work yeah exactly for example for some of those things it's not necessarily a failure it's like okay we'll pull another one down it doesn't mean everything has fallen over it's a different story if you're servers on fire and you're on prem room and you're back up sitting underneath it and it's never on fire so that's more of a failure on my mind whereas okay we tried this thing now we're hiding anything or whatever cool words we use these days to talk about this sort of stuff part of that's just that journey and I think people go oh well I did the work first time and therefore I work if I change this time it's it's just a bit of an evolution around those sorts of things and okay that didn't work let's try this we don't have to start again it's still working on the problem people invest in people right? not technology staff I think that's amazing I think experimentation is fantastic as long as you've got the time to do it and in my experience I usually don't have the time so I mean you're three pillars of project management of time resources but it's more money so and you're usually short of one or maybe two so but if you've got the time and the space to be able to have a play in a test environment then absolutely go for it and that's fun when you can do that and then show the client or your stakeholders this is what we can accomplish but it's you don't always have the capacity to do that yeah I think I agree with everything there I've definitely built trust is a major one because then then you listen to and again we always find I would say this but I think we've got fantastic people with a lot of expertise and you've got fantastic people in the room looking to solve problems for you and you don't want to tell them what to do you want to ask them how to solve a problem so the quicker you can build that trust and people want to listen to you then they can help you create that space to innovate but yeah the time is definitely tricky and I think on that point we just try to pick like good guesses if he shows people that if you do spend a little bit of time here and you get something from it you can hopefully create a little bit of a culture where we want to do more of that it's definitely tricky but yeah we just pick we try to pick one where we think there's a high level of success and back to managing a risk at the risk here we're going to say we're going to experiment on something but we think it can win and we think that whatever the worst case scenario it's still a good thing so therefore maybe in the next spring maybe in the next month or whatever we'll be able to do that again to create some extra value and I try and link it to something else so you can't always but sometimes it's like if you give us the time and space to do this bit it's actually going to help us here because it's going to make that easier and it will make that work better which will then lead on to a better outcome for your end users so if you can give them that kind of like they can see the flow and where it's going and that helps Okay lastly do you believe the people in diverse backgrounds or minorities have a difficult time dealing with failure of how people perceive or present feedback and what can be done within both private and public to help support this sort of innovation I think having a diverse team is a really great thing because every well and it's just people every different person looks at something in a different way and there was a great advertising campaign in the UK a few years ago by HSBC where they said a different perspective is just for where you're standing so if you move from where I'm sitting it's different from where you're sitting and it really stuck with me because that's all it takes sometimes is just saying to someone just come and sit next to me and look at it from this side and having a diverse group of people their backgrounds will feed into their experience and the way that they look at the world and whether they're from a minority group or from just a different country or they spoke a different language is their first language everybody brings that life experience and that's all worth having I'm in quite a hurry with Helen I think it's important we have everyone's voice available visible and can be heard and can share those sorts of things it's very hard for me to say yes otherwise because I'm not in my shoes or maybe in the circles I won't but not so much but super important I don't think we have enough of it yes absolutely we want as many different opinions as possible and I think for me it fits in the same framework of the providing safety so it's like communication and provide safety for everyone so whatever your background is if everyone's coming at it from a like everyone's trying to look at every option in the most generous way then that's the safety so there's no problem coming in with different ideas and debating and healthily some ideas we're not over other ideas but you want to encourage that debate because again you don't want five people in a team all with the same idea you're not really going to innovate too much there you want people questioning things and questioning approaches and trialling stuff out but yeah creating that safety for all of those different voices I think is important just again you want the safety part being that you're not shredded for coming up with an idea that three other people didn't agree everyone's taking the most generous breeding of your argument because we're all trying to solve the same problem but Dick is giving everyone a voice so when you're in a room it's like if someone's not talking if I'm running the meeting I'll say okay what's your opinion you haven't spoken up yet what do you think about what's going on so it's pulling that person that might be a bit shy or a little bit less forceful than everybody else pulling them into a conversation so they can be heard probably a bit of a thought in some of them it's maybe more comfortable I know there's quite of the group of us sitting up here, quite of us are quite loud in general so I'm an expert who's the whispers over there yeah and also usually being the tallest person in the room I find that people do gravitate to me do want to talk to me and that's not the same experience for everyone else and that's not necessarily a good thing we need experiences we need people and we need diversity because we need people who are going to use these products probably reflect the teams that are working so I don't think there's anything I can add that hasn't been said can you speak up a bit sorry I don't think there's anything I can say that hasn't already been said well fantastic that brings us to the end of the curated questions we now have time for questions for the audience final job I'd like to go back to the concept of unmanaged risk and quote-unquote cowboys and the general idea that if we take risk we can fail and if we fail our organizations that we work for or that pay us we can regard that value as a negative do you think that there's a relationship between how much risk you take and how much innovation you might succeed in pulling off is there is there more value in going to a client or a partner or a customer and saying right sorry client and customer the same thing but going the same look we want to try something bold we want to try something big and if we fail this is the ramification of that do we aim higher and risk more in order to achieve greater innovation I think the word value doesn't sit right that's a very good point if we take a risk and like you said if we take a bigger risk of course there's higher chance of a high reward high risk high reward they kind of go together but what you're saying is like these values I don't think they're values that they just learned ways of not to achieve that thing and that gives us like greater confidence going forward on if that client came back to us and said like we know last time we learned these things but we still want to give it another go we now have this giant subset of stuff that we know we shouldn't touch with the barge pole maybe but I think value is not the right thing but I think you're right in the fact that greater risk comes with greater reward usually I mean sometimes people take crazy risks and they're not texting and driving actually not good rewards I believe all knowledge is worth having to quote one of my favourite books and I don't I agree that I don't think of things as failures I think of it as okay we took a risk but look at what we've learned look at what we've done we now know this let's do it this way instead and I just think regardless of the outcome you've learned and therefore that's worth it so it's not a fail knowledge above all else for me yeah yeah I don't have a problem with someone going in and let's say let's be bold but you know what's our contingency you know you can't necessarily throw a hundred thousand dollars or a million dollars at something you've not come out with anything you've not come out with the most experience I mean you can you can you should like the people you can actually build up from where you are and something like that so it certainly feels a bit marketing when we say that sort of bold sort of statement the one that I used for a fair bit of a while which I stole from Chief Economist in RP Australia when I was still working over there was the gold silver bronze sort of set up where if we can aim for gold we should start with gold we should hit all of these things having a couple things against it as to what's the measure what's the outcome, what's the deliverable and then having some lower grades of those to go okay well if we can't hit gold because we've run out of time we've run out of budget or whatever happens to be we can step down so we're still delivering something I mean they still have an idea of where you're going so whether or not you can achieve it is a different story but it's something you could then appear to exactly Any more questions I have one we defined what risk was at the start of the conversation but we didn't define what failure was what is your opinion what do you define as failure of such thing from a project management perspective I suppose if I had to define failure having just said I don't believe that anything is necessarily a failure but if you're looking at it from I've got a set of requirements that I have to deliver against if I don't meet those things therefore the project has failed but then it's like have I met some of those or have I missed all of them or you know where where do you say at what point does something fail and it's like when you look at requirements you always set a minimum deliverable so it's like if you meet that then you've achieved it so therefore it's not a failure it's the minimum deliverable of what you actually want so which could be vastly different yeah you work in that like past failure where are you working in so it's your gold silver bronze there again you know you aim for bronze you're actually aiming for gold but if you get a bronze then you're okay we'll do it one of the difficulties of an organization pushing for risk taking is pushing for risk taking on a bed of a culture of bread in a success so if I work other service departments who should not be named that the very top is preaching risk take risks be bold the bottom layer is saying we want to take risks and be bold you've got an entirely fat middle layer that's saying whoa whoa whoa like I'm I'm measured on my success unless you can convince executive to view the learning journey as success you're really up against being able to implement any kind of risk taking behavior or embracing a non binary success failure outcome exactly I think that's the hardest thing to do and using a very very small example it's a 4.0 page on a website I like more 4.0 pages that are really fun they should be topical they should be something that gets the users attention so that they know you haven't found what you're looking for there are organizations out there in the world that have created some amazing 4.0 pages that are really cool and every federal department I go into I say let's have a bit of fun with this now the government is trying to be more human you're trying to be more plain English you're trying to bring the people in and join the party no we just want it to say 4.0 but it doesn't matter it's a 4.0 page wait I don't understand oh sorry 4.0 is the page that you hit when you can't find the content oh right just says 4.0 then they don't understand you're absolutely right so you need to put words wrong maybe put a fun picture or cartoon or a little graphic or something we did that once with the industry and consolidation project and our biggest gripe was just whoops have an H in it I'm like yeah well I did at the time I was doing it wrong but every department I've worked for they've come back to a really conservative 4.0 page I don't know why it's a page that actually doesn't matter from a style perspective it's like just have a bit of fun with no official government we have to be seen as serious anyway it's just a very small thing but it's just what Tony is saying yes we want to take a whisper no we don't that sort of thing also should be experienced to use it I'd say just try it thanks Tony just do it I managed this video you've managed it it's on the 4.0 page it should be in the first place that's right all the links work just try it well that concludes our panel if there are any more questions thank you for coming thank you now let's all see you real quickly are there any questions are there any online questions there were no online questions there may be some awesome thanks no but this tends to comment a few times thank you Brett, thank you Chanel thank you very much for joining in just really quickly just reiterating December 8th we've got the end of year drinks if you can make it please come along be sure to RSVP and if you'd like to present or if you have another idea for something we can try with future meetups then please let Marge or I know and finally and most importantly the credit for this idea that we executed tonight goes to Marge thank you very much Marge thank you very much yes we took a risk thank you very much the panelists for coming along thank you Karl for being the moderator you all did a fantastic job so thank you and good night