All right, welcome everyone. Thank you very much for attending this session. We're gonna have a very good panel discussion here with some experts from industry-leading companies that are gonna share insights about organizational best practices for cloud adoption. So I'd like to welcome on stage, first of all, Mark Williams, who before joining Redapt was the CTO of Infrastructure at Zynga and led their, basically, their public cloud and their private cloud build-outs. I'd like to introduce Mariano Cunetti, who is the CTO at ENTER, an Italian service provider that's built a three-data center open-stack public cloud. I'd like to introduce Ariel, who before joining ScaleVP as an investor, so he's our money guy, was a director of engineering at Netflix and built the very famous Netflix OSS tooling for that Netflix used to adopt cloud. And then I'd like to introduce Ian, who is the CEO and founder of CloudOps and let's give them a round of applause to welcome them. All right, so just to kick it off, I would like to ask the audience a couple of questions just to get a feel for what the breakdown is. If you're from IT, can you raise your hand right now? And if you consider yourself more of an application developer or non-IT, would you raise your hand? All right, so a little bit less, but mostly IT, awesome. So let's kick it off with a couple of kind of a nectodes, a couple of things to break the ice. So how about we, do you guys have any interesting stories of things that you've seen in CloudAdoption that were really not cloud, some fun stories to tell there? Mark or Ian? CloudAdoption, excuse me, CloudAdoption that hasn't been cloud, a lot of the customers that I'm helping out there, excuse me, I don't know what's wrong with my voice. That's better. A lot of the customers I've kind of helped engage and express their vision for their future of cloud have wanted to stick to so many proprietary technologies that might be on that list of what is considered supported by the orchestration software that they're taking a look at. But inevitably what happens is it becomes so unique and custom and un-upgradable over the long term that it ends up not being a cloud. So what I try to educate such customers on is really the value of having kind of a utilitarian version of cloud that is very simple. Just coming from an operations experience, getting that phone call in the middle of the night when something is broken, the value of keeping things very simple, eliminating potential points of failure is super valuable. So having all that custom complexity stuff is where I think you have a lot of risks in that form of it. Ian, any fun stories of Safi? Yeah, I guess I think what we've seen is, since the topic's barriers of cloud adoption, we're seeing a lot of cloud adoption, but we're seeing a lot of very, we're seeing a lot of cloud adoption sort of echo what Mark's point was that is fundamentally not changing the way people work or changing the processes people are using. So they're adopting the technology, but you don't have the cultural change. DevOps is a great example, sort of an aspirational way of working with cloud, but also on the process side, we see a ton of problems. When we go in with a lot of customers, they'll have very, very strange deployments on Amazon or even internally that are fundamentally explained by how they procure services and how they manage them.  They have some really slow, ITIL change management process with lots of approvals that are required. So obviously that's a really big problem. Then on the flip side, sort of in the enterprise data center, we see things like people trying to deploy open stack or Hadoop clusters on blade servers and IBM sands, which is just, I mean, aside from, in many cases, defeating the purpose also leads to all kinds of really awkward operational issues. So yeah, there's a lot of cloud adoption. I don't think there's a lot of barriers to cloud adoption, which is actually leading to the problem of people adopting cloud very poorly.  Let me add just one quick thing which is funny because I just heard this over lunch today when I was sitting down. And this was one company that we're all familiar with that I won't repeat the name of, but this person was telling me about how they went through this cloud adoption, cloud migration phase and it took a couple of years and they're very unhappy with it. They're very unhappy with the results and now they're thinking about alternatives and when I asked about the details, it turned out that basically what they did was they took their existing legacy applications, their existing architecture and forklifted that and just moved it into the cloud and never scaled up, never scaled down, always used those resources and then they were very unhappy because the cloud cost so much more than what they were paying for in-house. And I think that echoes a lot of the cost concerns and that you hear from people migrating to the cloud and in this particular case, it was a public cloud use case, but you hear this for private cloud as well where unless you're also marrying that migration with rethinking about how to re-architect your applications and your processes to be more cloud native then you're not really in the cloud. Yeah, there's a lot of cloud challenges and disillusion when you move to the cloud because of those processes that might have not changed. So on the topic of cultural change, in your opinion, what are the first things to tackle when you're trying to take a big organization that's using the traditional model and moving that to DevOps type? Well, Mariano. In my expertise, as far as I can see in the Italian market but I think it's the same everywhere, the cloud is a source of stress for organization. I think you laugh, so I think you agree. Every organization is stressed by the concept of cloud. You ask for a story before, I have the story of a guy that I call a nervous guy. He came up and showed up and asking for, okay, we run this large hospital and healthcare application and we want to run it on the cloud. We are building a startup, we want to move it to the cloud. Okay, let's see. Let's see how the application is done and let's see how architecture fits your needs. And then we started to dig into the application and we discovered during a meeting with the project manager, the lead developer and the CEO of the company, we discovered that a lot of stuff was done by, it was a Java and Oracle typical application. Was done inside Oracle and nobody knew what happened inside this Oracle with 700 tables inside. A lot of the application was delegated to the database. So we saw the CEO becoming very, very upset and the project manager becoming very, very uncomfortable. And so in the next meeting, he became always more and more nervous because he understood he had to take up the information and the process that was delegated to an external deposit like Oracle and the people working with Oracle and the consultant and he needed to take it back to the company. He understood he had lost the value of the company which was the process and he had to get it back into the company and in order to go to the cloud and to make an application scale, design a good architecture for databases, for front ends, for middleware, he had to understand how it worked really and so he understood the huge amount of work he had to do and he had to learn a new way to work. That work was an organizational change and increased collaboration, that sort of.  The second half is to reimplement it in a smart way. If you are running a startup, you are five people, one couple of developers and you want to just translate the legacy application to a new cloud-aware application. There's a lot of work to do once. You cannot afford to do it twice or three times or any time. So the guys are still nervous now. So, yeah, go ahead, Mark. I can kind of speak personally for what my transformation was kind of going through this at Zynga. So early on, before we had really done anything with cloud, I had a very stressful job to ensure that all of the infrastructure was up. I felt like that was my domain. It wasn't necessarily a control issue, but it was a confidence issue that I know how to make this work for my customer who I'm allocating infrastructure for. What became clear to me is as the needs of my customer outpaced my ability to really support them in a manner that was going to drive their business requirements, I found that I needed to be more transparent and in fact more collaborative and providing an education to my customer about what it is that are my pain points, right? So one specific example of this was our two biggest games were literally consuming all of the private data center space and server capacity I had. I was in the middle of doing our second data center. This is before we had done really anything in public cloud yet. And one of the CTOs of a game studio and his SVP wanted to come into my data center. And I'm like, I don't have time for that was my initial reaction, right? Like I know what I'm doing, I can just talk you out of this, right? I need to keep focusing on getting your hardware to you and moving you into this next data center. I had a rational epiphany to go ahead and do this. And what I realized is that their reaction to walking through this data center and seeing empty spaces in all the racks was a natural conclusion of well, why can't you just put more servers in there? Like that they don't really have an appreciation for what these challenges are in real infrastructure. And so it was great to educate them so that they really helped me think through, well, how can we do this differently? How can we make this easier for me? And so through that transparency and really collaborating, we were able to kind of take those next steps and accelerate how we did this in successive investments and later investments in how we did cloud. Ariel, were there any changes in relationships between application developers and IT and Netflix? Yeah, yeah, quite a bit. So I think there were really kind of two key things that we did at Netflix as part of the cloud migration that in hindsight made it successful. And I think are really two key ingredients for anyone doing it. And so kind of painting the picture of what it was like before we moved into the cloud, we were very traditional IT organization. We had an IT operations team that was responsible for managing and maintaining the site. And then we had a product team that was building all of the software. And every six weeks it would get on a train and a release train, or not six weeks, two weeks, it would get on a release train and get deployed by IT ops into the production environment. And then whenever someone checked in some bad code or there was a problem with the deployment, the whole train stopped. Everybody got on board, figured out what was wrong and then it got through again. So part of the cloud migration was really rethinking the application architecture and moving from this monolithic large job application into large scale distributed service oriented architecture that was all centered around this notion of microservices and very, very small units of logic that would be able to scale up and scale down on their own and have very relatively limited blast radius for failures. So that was one key of moving to the cloud. It wasn't simply, well, let's replace the infrastructure. It was let's rework the whole application and really take advantage of this new compute platform that we have, which is the cloud. That, by the way, is based on an unreliable set of resources. And even though you might think that you have a reliable set of resources in the data center, they're equally unreliable. So that was another really important design assumption that we had. The second part of that migration was really tearing apart that wall between IT operations and the product team. And in fact, we actually did away with the entire IT operations. I shouldn't say did away with, but we refocused their work on supporting all of the corporate systems and all of the customer facing systems were now moved into the product, the engineering group. And so every single engineer that was building code that was building software to be eventually deployed into the production environment was now responsible for deploying that code into the production environment and was now also responsible for getting that call at three o'clock in the morning on a Sunday night if their piece of code was somehow causing a problem. And so you'd be amazed at how quickly that aligns the incentives for making sure that your code is well tested and that you have kind of all the operational assumptions that you need in order to run your service effectively at the development phase and not found later by an IT operations team that feels like they've been handed this hot potato that they have to maintain. So I think those are really two of the really key factors for making that call migration successful. One was re-architecting the application to be in a cloud native. And the second one was eliminating that gap between IT operations and development and really collapsing that all into a single function. On the topic of that gap, what's the biggest reluctance? Like where did you see the most reluctance and the most difficulty in getting people to change as opposed to getting systems to change? Ian, if you wanna tackle that or Mark? Oh, I was just actually just gonna add, you know, there's certainly with a number of our customers a huge amount of reluctance that I suspect at Zynga Netflix was a little bit easier to resolve because Netflix and Zynga are, you know, both online business models where the profit center, basically the line of business is highly aligned with the technologists in the organization. A lot of the large enterprises even if they've got a significant investment in software development, we're working with one that has 260 applications that they're developing. They in fact do have aspects of the line of business that are completely online businesses but there's a massive battle being waged and it basically comes down to, you know, a CTO who's got a group of developers who are charged with sort of driving the innovation and ultimately contributing to the success of the business and are much more profit centric sort of aligned and then you've got a CIO and a very large IT group who ultimately, like right from the top are organized around managing a, you know, large budgets which are committed to significantly in advance and the CIO is compensated not based upon necessarily supporting sort of increased rates of change and innovation but in fact based upon, you know, cutting 5% off the budget. So there's, I think, so a lot of the larger organizations we're working with, the biggest barrier really starts at the top with how those executives are compensated and how they collaborate. And in this particular case, what's interesting is we're helping them with an OpenStack project right now but it's unfortunately what's happened is sort of the, and we've worked for both sides of the fence which is also rather interesting. Like we've done work for the IT guys, we sort of, you know, did a cloud strategy, did a cloud architecture for them but then they ran into sort of these procurement politics and like, all right, well, how do we take the cloud ops architecture and then make that real with our existing suppliers and our existing budget and just basically ground to a halt. And then we continue to work with the sort of more innovation side of the fence and to date they've really just been adopting Amazon but they basically got to a point where it's just too costly and they want to do a significant chunk of their development on in-house infrastructure and so we've been contracted to go in there and help them with an OpenStack cloud. But this is all happening, I'd characterize it as a bit of a sort of a Skunkworks project. So it doesn't really have the support of the executive level, they're aware of it but they're sort of like, well, let's see what the CTO and the developers are able to do over here with some, you know, on a shoestring budget. So it doesn't really have a, I'd argue the characteristics of constructive cloud adoption. Mark, you have a lovely experience as an integrator for very large organizations. Can I answer your first question? Because at first you stumped me because like, wow at Zynga we really didn't have a reluctance to do things in a more modern way but what I have actually seen being in the system integrator role. Spill it out. That I've seen it not only at the executive alignment level but in fact the first week on the job at Redapt I was participating in a cloud workshop where we're discovering well what is it that your workloads need to do to be cloud enabled and how do we help you do that? And the customer had initiated this plan from one individual in a leadership position but not really socialized it with his team that he was taking a new course to do this cloud natively. And his team was white knuckled on exactly the way they've been doing it. We're gonna stick with our blade servers.  We're gonna stick with VLANs. We're gonna, you know, and it was very awkward to be in this meeting educating them and trying to suss out detail about how to build a cloud for this team that did not wanna build a cloud. And I've since seen in some of our customer space there's some acquisition going on where we've built native clouds for them and then an acquiring company will come in and these white knuckled guys are coming in and they're kicking the cloud out. Like because they are so fixated on the traditional historical ways they've been doing it. So in the face of that reluctance what did you guys do? Well in a sense of an acquisition if the acquiring company is leading that we're not really being asked to impact that unfortunately. So what we are hoping and unfortunately the acquiring company has been losing the employees that have paved this new way trying all the while to educate above like this is the value of it. We are a smaller team kind of ratio to infrastructure wise than what the acquiring company is doing for the same effective capacity management and it's not resonating. So we're not in a great position because our relationship has been with the acquiree rather than the acquirer. Yeah. I wanna just make a comment about the previous comment that Ian made which I think is a very good one that centralized IT has been its policies I think have been one of the things that have driven a lot of public cloud adoption to date which is that you started to see this you know what's being termed shadow IT where all of the business users and the technical application developers are taking it on themselves to create the mechanisms that they need in order to innovate quickly and they're being successful at it and they're being rewarded at the business level and they're getting support from their executive teams for it and they're able to out compete their industry competitors. And so what you're seeing now is all of these different shadow IT springing up in different organizations and I think the CIOs are starting to realize that what they need to do is to start enabling that and to start being more of a service provider to the rest of the organization rather than the control and the gatekeepers. And so you know at least from what I've seen from the more innovative IT organizations they're shifting towards thinking about how they can enable their application users and their functional business units to take advantage of some of these new technologies in order to be more agile in order to be more innovative rather than trying to always play the cost argument or the security argument or the control argument. And I think that's a very positive thing for the overall industry. So it seems like the dot coms and the online businesses tend to have it a little bit easier with cloud than more regulated industries. What would be your recommendations if say a large healthcare provider wanted to make a big step or a bank wanted to make a big step into a cloud? What sort of change would need to happen there? So I think most of the web 2.0s, the gaming companies have had the luxury of no legacy, right? So that's why there was really no resistance to adopting a new method. But having worked with a lot of more enterprises and more risk averse companies, trying to boil the ocean with one massive overhaul is not an approach that is ever going to work. Getting whomever is in the company that is starting this skunkworks or hopefully a top down directive to go this direction always encourage them to start small, find your earliest, your best candidate as your internal customer that can be your early adopter and can co-avangilizing, co-develop what those requirements for that cloud are once you've successfully, and then here's another thing I actually really did experience. Once I built a private cloud and having a company that was 85% dependent on a public cloud at the time, nobody wanted to move in. Everybody was warm and fuzzy and they're a little, so how do you get your first customer in there, right? So this ties into the same thing I educate customers on is you need to find that willing participant, that early adopter who can help influence the design of the cloud and adoption of that cloud and then become your evangelist internally to spread the word of how much better it was. And in my case, I was fortunate to have built the right thing because we collaborated on it and it was a richer performance experience. It was a, it wasn't painless to move people but it was certainly kind of, in the end of the day, it was less expensive for them on a cost per unit basis. We were doing charge back so there was that increased the ability to encourage more adoption later. Having the internal adopter who was evangelizing, we had our own evangelist as well and educating. You need to educate as well. And then ultimately having that financial influencer to have a third of the cost per unit available on a private cloud charge back versus less performance and higher price per unit for a public cloud. Yeah. Generally the way we start with a large enterprise and usually pretty carefully because we're a small company is with an inventory of their application. So we'll, the company I was talking about before, they got about 260 applications. Only about 40 of them were cloud suitable. And then we further went and did an analysis on as to whether they're public cloud suitable or private cloud. So I think that's a very important step is that inventory of the workloads and taking a really hard and honest look about how, because there are folks out there, they're application product owners who are maybe a little bit over confident in the abilities of their application. So we typically with a large organization take a very conservative approach and sort of go for those early adopters, those, the lower hang fruit because you got to show those success stories. And then that sort of, those become the sort of business cases and proof points to drive the rest. And those tend to be like mobile development, like mobile applications, like the new wave of applications in the regulated industries that tend to be those early adopters for public and private cloud. Mariano? Yeah, but regarding the large enterprises I've been to, I have two examples for Italian companies. I've met Pirelli, which is a tire company, and Ducati, which is the motorbike company. And it's very strange how you look at large companies from outside. You would think that Ducati is a very red oriented and very passionate company, very innovative. And you would think that the tire company, typical tire company is tiring. And instead we found, I had this meeting with the media marketing manager in Ducati and I had this conversation. It was very informal and he had this poster behind him. I could not stop laughing because the poster was, I love milk and all the time, this thing. And it was unbelievable. And we understood that they approached the cloud very early with Amazon and there were already shrinking the domain of the private and I can say, I can say the valuable information, they were shrinking the domain within SAP inside the company and they were setting up some gateways to take this information out and in just to protect the valuable data to design such an anone around this internally and externally. So they were almost ready and open minded to go to the cloud. On the opposite, we went to Ducati and we discovered that since the main sponsor for Ducati is Telecom Italia, which is the main telecom operator in Italy. They were, they could not buy from any others from them, but Telecom Italia like any other tech companies very far from understand and just to build and to sell the cloud. And so they have this weird situation by which they had to order VMs via Fox and yes, they do. They send a Fox and they get the VM in at least 30 days. That's the Ducati. So you write your API call on the fax machine? Yeah, that's it, that's it. So we've been hearing a lot about when you take these like IT and application developers and you make these blended DevOps type teams, then making sure that accountability is still held somewhere, people are still responsible. And how would you manage blame when you've got these teams that are, go for it. Well, the first thought was, I know Ariel mentioned this earlier, like developers need pager duty. So once there's a mutual understanding of what that pain is, it changes behavior. The other one is, again, this is where I had initial resistance and as a part of my personal evolution into cloud two is I used to track availability, right? And I cared about what I could control. So I had an availability number on network infrastructure and server infrastructure, et cetera. So as we matured in purely mutual kind of collaboration around DevOps and application ops and infrastructure ops, there was a suggestion to essentially have one number for availability for the entire company that counted everything, including services we had nobody in the company had control over. So Zynga being very Facebook dependent, if the Facebook API went down, our games would generally go down. And there was a suggestion to our availability number should count everything. And what finally got me around is recognizing that the value of having that one number helps rally everybody around agreeing that that is what the number, that is the user experience for what we are providing to the world. So it is the most representative. Yes, certainly having that data is critical because if you can't measure it, you can't fix it. And so knowing why each outage mattered or contributed was valuable to help focus that. So did you put a dollar amount next to an every outage? Oh, yes. Definitely. But getting the culture kind of rallied around that. And also aligned very well to organizational MBOs.  As uncomfortable as that was, it drove all of the right behavior. Our collaboration with our peer group who did the outage, my team in terms of, hey, network guys, I don't care if you have five nines of network availability, but you need to be transparent with what your hardware is doing so that when the appop guys have a suspected problem and they don't know what it is that they know I can eliminate network or I need to focus on network. So getting that, the true transparency of all the different pieces of this infrastructure. So just doing that one very simple thing is really important. So everybody agreeing on the availability number drove a lot of alignment and collaboration. So I think that was a terrible question. And I'll tell you why, because I think the question is, the way you phrase the question is, well, one flawed and two also indicative of exactly how people within organizations ask that same question. And the reason is that you're looking for where to place blame. You're looking for where to place blame. And I think that's the wrong pursuit when you're trying to improve your availability. I think what you need to start with an assumption of trust, that everybody in the company is doing the right thing for the business. And when you have problems that come up, if your perspective is who is the person or team that needs to get blamed, then the way people are going to approach that investigation is how do I defer responsibility for me to the next guy? And that doesn't help you identify what the actual root causes and the actual reasons are for why you're having problems. Is that okay? At the Chef conference this year, we heard a lot of talk about blameless management. Is that what you were referring to? That's exactly, that's a great way of putting it. Ethnathics, for example, each one of our postmortems was really focused around identifying what the reason, and usually not reason, reasons for things not to go the way that we wanted them to go. And then deciding whether, what the reason for that was, and typically it was because it was just resource investment. We decided to invest into moving very quickly, into investing into innovation and not enough into the tooling that we needed in order to get code safely into production or into the right communication between teams or basically what is it that you can do so that something like this won't happen again next time and if your answer to that is, well, we have to be more careful then that's wrong, right? Because everybody's already being as careful as they can be. And so you're assuming that that's the steady state. So I think the way you approach outages, the way you approach your postmortems is gonna be very telling of the kinds of results that you get. And if you approach it from the perspective of which team is responsible for what and who carries the blame when something goes wrong, then you're gonna create a culture of trying to avoid blame because who wants to be blamed for things. But if you look at it from the perspective of we're all trying to improve our availability and the reason we're not where we want to be is because we might not be investing in the right levels in the right things, then it becomes much more of a collaborative exercise in order to how to raise the bar. On the standpoint of the vendor, we are the last step. Always blame the vendor. Always blame the vendor. But our approach is since we have nobody to put the blame on to. We are, we have this approach. We take the blame on us, but we explain what happened. So at the first time, the customer is happy because it has someone to put the blame on too. But answers are starting to coming up from below and they go all the way back to the exact responsible person. So during this time, you see that people start to consider you reliable, more than blamable, and they still put the blame on you, but they get answers, so they trust you. You build the trust by taking the blame and giving answers. Then in time you get less blame and more trust. Yeah, and do you have any experience? Lots of experience with blame. So a lot of the larger organizations we work with are very siloed and they play this blame game constantly. What we've been, where we've seen success with some of the larger organizations is taking, is sort of encouraging them to create sort of small teams that cross these silos, they're focused on very particular, like, identifiable service delivery and business results and having them as a team responsible for making sure that that result is achieved. It's hard to do because, depending on the culture of the organization, but that's where we're seeing results. And there's actually a bit of a movement in the enterprise world towards, I don't know if anybody's heard of intrapreneurship, but there's sort of a whole sort of, there's a bunch of folks running around sort of trying to bring kind of lean methodology and more sort of DevOps style approach to problems in large enterprise. And we're starting to see some success stories there. And I think GE actually hired, like they had their whole organization go through training around that. So, but I think it's still early days, at least for the large organizations. But where I think the small companies have an advantage in terms of adapting and obviously the ones who are already very sort of, already focused on sort of more next generation business models. I'm going to pause you for just a second. We're going to take questions shortly. So if you can line up behind the microphone, we'll take them there, go, sorry. But with the large companies, I mean they're like aircraft carriers that take a while to change direction. So where we're seeing results is if people can sort of carve out a very particular problem, bring together sort of a community of practice around it that hopefully spans a couple of those silos and then be sort of held responsible for achieving a particular business result instead of being responsible for just, making sure that, I don't know. One part stays available. Storage doesn't crash. So we have a couple minutes left. So if you have any questions, feel free to go up to the microphone. Otherwise I'll just continue on. So for cloud adoption, we've heard some cases where there was endorsements at the very highest levels for cloud adoption and there's in other cases where it's very much of a grassroots effort. What do you think is best for an organization to adopt cloud, whether it is best for it to come from below or from the top? Mark always takes the first question. As long as my voice works. So I've seen the Skunkworks grassroots where it can run into a major obstacle is if there isn't strong alignment at least with the technical leadership of a company. So the CTO or VPs of engineering to ensure that you have a customer who is going to be mandated because you can't control engineering from the operation side. You need to ensure that you have alignment and a mandate to ensure that you have customers at the end of the day. So I don't think it's exclusively either. More often than not, I do see kind of the executive leadership trying to influence this because they're the ones paying attention to the marketplace. But they may not have enough bandwidth within the technical organization to actually start educating themselves about what it is to start down this cloud path. That's where executives are ensuring that they have people who are resourced to be able to investigate these things and not just running around doing heroics to keep the existing production up as key. There's an easy road and a hard road. I think the easy road is when you have the top level executive realize that the key to them having greater business agility is to transform the organization into one that takes advantage of elastic compute resources and elastic platforms. And I've seen this firsthand in Netflix since that's very much kind of how it came down. Reid was himself a really big proponent of moving to the cloud. And that just saved us so much time of having to get buy-in, having to kind of have all of those political discussions around where a resource is gonna come from and what's the right approach. We know that this is a key in order for us to be more agile, in order for us to be more innovative, and the question is how and not if. Now, you can also do it with the Skunk Works way. I think it's harder because you're gonna end up coming up having to overcome a lot of impediments and having that high level sponsor, the CTO or a VP of engineering or someone who can at least give you air cover helps with that, but it's certainly a harder road to go down when you're trying to do this in a small individual level than as a broad organization with all the resources and kind of all of the alignment already behind you. Yeah, and of course it helps if you have grassroots that validates the CIO's vision or CTO's vision. All right, thanks everyone for sitting in on this session. We'll be around for the next couple of minutes. So if you have any questions to take to us privately, please feel free to do so. Otherwise, thank you very much and please let's thank the panelists.


Estonia is a very positively engaged European nation and its European country. And it doesn't matter how many of us are in union. Today 28, perhaps in couple of years 27, we are our core interest. Today is to keep strong unity and cohesion among European nations. In Estonia we understand strongly that we need very good allies and very good partners in this very turbulent world. And we understand that there is not really good alternatives for nations who have joined the European Union. EU 27 if we say so, rather than to stick together and work on those issues which are common interest of all of us. As internal challenges we have to commonly tackle to keep up union and citizens. We are offering them security and good opportunities to benefit from growth of the economy. But also issues like the challenges who are on our orders to the east and so on and so forth. But one of the highlights of Estonian presidency and this is not only for this six months or second half of this year. This is how we could use in Europe in better way modern technologies. Like in the governance questions about digital society, digital economy. And this is what we have carried today during this presidency, these topics. And have engaged in all kind of discussions about creating a single market for next year to the end of next year. But also to create possibility that we can benefit actually from these technologies. This is an interesting question. We have seen this topic popping up every so often. And actually we could ask do we have already a motive speed Europe perhaps because of not all countries are members of Eurozone. Not all countries are also belonging to one and another format of discussion in Europe. But as is Estonian position we would like to see stronger unity among European nations, European countries. And we cautiously look at possibilities that there could be some sort of too many internal groups or decision making areas within European Union. Europe is rather small if we compare with powers like China or number of hours. And here we benefit perhaps more if we could agree up and together on these major issues. What are both when we're talking about security, talking about issues like Eurozone or economy by and large. But also about defending our values and principles. Estonian policy priorities are very much connected to these core priorities and issues which are more or less important for all of us in Europe today. There are many discussions about how well we actually defend our way internationally. I mean how well Europe is, how competitive Europe is at the time. And there is a number of new centres of influence and challenges let's say in the world. So why Estonia has prioritised one area which is extremely important not only for us but hopefully for future of Europe as well. How to make Europe more innovative, more open for new ideas and also how to implement these new ideas. And this is why during our presidency the digital economy and digital society is highlighted as a way to go where are. Certain obstacles today we see that we should work together in order to create a digital single market. To also perhaps reach one day to agree up and on 5th freedom within the European Union which is a free movement of data. Because this is future anyway and we have witnessed in Estonia how our society has benefited from that. That these services are available for our people when they interact with the government for instance. And very important is of course to have the European Union as one of the leaders in the field of global fighting against global climate change issues and problems leading this process. We are witnessing almost daily nowadays the results of this huge change globally. And last but not least of course a question about Europe as one of the promoters today of a free trade. Estonia is a small nation and we are very much dependent on the export and how well we trade with other nations and countries. And European Union has done great job creating in terms of creating a new area of free trades. And recently our parliament ratified the free trade agreement between EU and Canada. And we hope that we will see in the near future similar to development with Japan. And perhaps one day we could also be back on track with a very same question in relations between EU and United States. For Estonia transatlantic relations are very essential. And we hope that the relations which were let's say in turbulent phase during elections period during last let's say 12 months is now over and we can focus on issues which are in interest on both sides of the pond. And one more question of course it's understandable in Ireland number one question is Brexit and we feel the same pain in many ways. UK has been and is our very good friend and our both in EU but also in NATO. There is very specific link today between UK and Estonia because of enhanced forward presence in NATO framework. UK troops are in Estonia and cooperation is going on really pretty well. We very much hope that the Brexit negotiations will lead to the solution which is in interest of both sides. I see that Estonian and Irish relations are excellent. And of course we share many issues and we're on a common same page let's say when we're talking about the very same question about solution on Brexit. Then it's a question about transatlantic relations are vital as vital that they are for Ireland they are also from Estonia perhaps in different reason but still. And we both are small nations and somehow very fair in Europe. This is something where we should work perhaps sometimes twice as hard as some other nations but in Estonia we are strong believers of Europe and the future of Europe. And I guess here we are very much vision and same way of our future but where we perhaps could use better the framework of European Union is enhance more in trade relations. The numbers today are not as big as we could be and this is where our embassy here works hard to engage more interest let's say of Irish business community as well to look at our region to Estonia and vice versa.


Well confidence is a big thing in football and belief and I always stress to my players that if you don't believe in yourself then you know we've got a problem because if the manager believes in you but the player doesn't then that's not going to work. You know the manager didn't believe in you then you wouldn't be at the football club. You know that's the first step I say to the players the second one is believe in yourself there's a difference between confidence and arrogance. You can be very confident but you also have to show that you know don't turn up late the professionalism aspect is very very important because I'm a firm believer of the small things the little details are the bigger things because if you're willing to turn up late or willing to do nine press-ups instead of ten you know for me that's a lack of humility and it will show out on games you know it might be in the last minute when you can seed off a corner because you don't want to do things right. Do things right every day you walk into this door enjoy being here smile be a good teammate be a good person and the rest takes care of itself. You know I believe that I'm a coach that gives young players opportunities and you know everyone can say it and I said this in my press conference saying and doing the two different things if you say one thing and then don't do it then you can be called out upon it what I've got a background of saying it and actually doing it so I believe in young players that's why I say I want them to believe themselves more I can't I can give them opportunities but I can't take the opportunities for them it's down to them to do it so it comes down to I when you're looking at players and what you see and the tendency I try to use is what can the player do how does he do it rather than what you can't do because I think people in general sometimes look at what players can't do rather than actually focusing on what they can do.


e to types of units uh I it suddenly occurred to me to ask that question I hope that's in order otherwise we can put it off until next time well I you've asked the question chris do you have it you know what's going on I haven't spoken with them about that project um in a long time I don't know if either of my colleagues has spoken with them no but I know they're busy you know it's trying to finish up spring street in 11 to 13 east pleasant so it might just be uh you know and other things there might be a you know order of priority and you know I haven't heard that it's not happening I just think it's delayed with their other projects good enough nothing to report on pvpc all right um I think that since our last meeting in december uh cpac did meet and approved uh most of the projects that were that applied for money this this time around um there was some trimming of budgets most of it proposed by dave zomek and other folks at the town on town projects um but it seemed like a pretty smooth process this this year caron is not here to talk to us about the design review board chris anything on crc I understand that there's still um well I should back up and say crc has been repopulated um it has I think four of the same members and one new member so jennifer taube pam rooney pat de angeles and who am I missing mandy joe mandy joe the most I shouldn't forget her no because she was the chair um then at friccate is uh also joining so um we haven't worked with them yet I think that they did have a meeting recently and they're picking up the I haven't worked with them yet but um they're picking up the rental registration project and trying to move that forward and is the solar bylaw with that committee as well the solar bylaw is also with that committee but again they haven't done any work on that one yet okay and is there any statutory deadline for them to move that out of committee yes june okay they were given a deadline of june yep great all right um I guess that's that's all our committee and liaison reports uh I as chair have no no report tonight chris pam any report from staff have you got a new staff member no um and I'm not sure I don't think that it's been advertised yet I did send it down to HR in December so we're gonna have to um give them a nudge shake them a bit yep right let's get you some help um okay all right well we didn't quite make 9 30 but the time is 9 32 uh unless anybody else has any uh anything to say we can adjourn I will say please do try to go and look at the drawings I think that would be I know I I haven't done that yet and I feel the need after tonight's conversation particularly all the good questions that Bruce noticed that I wouldn't have had a clue about but yeah and I have to say that we didn't give you the whole set of drawings we gave you about two-thirds of it because it was just too much of a monumental package so um there may be things that would be enlightening to you like I don't think I included the grading plans people who look online can look at the grading plans but I don't think I included them in the in the paper packets so looking at the drawings live and in full size is really a good uh good exercise yeah um I don't know I it's probably tell me if it's out of turn because we closed or continued the hearing but would the Wildwood site have required as many special permits and waivers I think probably in the end it would have um we didn't really scrutinize this project until fairly recently so when the site was being chosen you know they were asking us well what kind of permits do you need and the site hadn't been designed yet so we didn't know that it was going to be 43 feet and we didn't know you know necessarily that it was going to be in the FPC zoning district and you know so there were a number of things that only came to light once the thing was designed and so I think uh you know as I said we don't really scrutinize these projects until we get an application and then we really look at them closely but before that you know our our our review is a more cursory review right well it would have been uh it would have been uh equivalently challenging from a traffic management point of view the issues would have been different but uh they were similar uh in extent uh the site is much more compact so they would have been issues draw and of course it's a sloping site quite extreme there is a lot of fill on that site actually uh uncompacted fill that the building would have been going over I can imagine that I suppose that may not have manifested itself in in the permit related questions before us but the challenges of those as a wildwood sites were considerable the only way I'm going to say given the zoning district I think it would be the same in terms of height you know could be coverage step backs okay fill parking so you know I just think that to design both sites and present them to the planning department for thorough scrutiny in order to know what kinds of permits might have been required for wildwood okay well I guess I you know it's just sort of in the back of my mind like well what what choice do we have we have to approve this so okay so far as the field is concerned I think that's true um yeah otherwise we maybe be able to the sort of things that Janet was pushing for Rick push back I mean I have to say this is an extraordinary design team that they put together I had my doubts initially I challenged Kathy on one or two points but Denisco have demonstrated a just extraordinary commitment to this town and to this project including Donna Denisco who as the principal I thought well she'll be there for the first little while but Donna is at every meeting for two and a half years and doesn't look like stopping they chase down every ferrith they respond to public comments and so forth considerably and seriously carefully and so but they're just they're just a wonderful group of people and we're very fortunate to have them okay that's my view anyway well thank you for that endorsement all right well on that positive note we can adjourn time is 937 welcome back in 2024 thank you thank you all have a good night Chris can I ask you can I ask you a question sure um minute


My name is Adam Ford. I'm the Senior Vice President of Sales for Macquarie Futures here in North America. I get to interact with traders of commodities and traders of futures and options and other derivative products here in Canada and United States and Central and South America. When the opportunity to move to New York first presented itself, I was actually incredibly sort of apprehensive and frightened. But the minute I stepped foot in Manhattan, I realized that there was never going to be an opportunity like this. It's the most incredible city I've ever been to. I studied a bachelor's of economics at A&U. It's now been proven that some of the courses that I took were really, I think, vocationally oriented and something that I've been able to apply directly to my current role. So things like, you know, the core theory of economics and statistics and mathematical theory. When I think of A&U, I think of the Ivy League colleges in the United States. Schools like MIT or Harvard or Yale. If you interact with a lot of the alumni out of the A&U, they're often people who have come from those Ivy League type of establishments. A degree from A&U has far-reaching, I think, application. I would encourage people to sort of lift their heads and look up at the world. People back home at A&U need to know that their degree from the A&U is recognizable and applicable over here in New York. This is quite daunting when you're sitting in the lecture theatre in Canberra considering, you know, a career in New York or in London or in Tokyo perhaps. But there are people out there who have gone through that experience already and alumni have, I think, a real luxury of being able to tap that network. Being part of the Alumni Organization to use some of the language of my world is a free option. It's unknown at the time what it is you might gain from that. But I think at the very least you're going to meet incredibly interesting and accomplished people when the opportunity to volunteer for the Alumni Association here in the United States came up. You know, I sat back and thought about, you know, that option I had to participate or not. And for me it was an instant decision. I wanted to opt in, I wanted to participate and I wanted to see where it would take me. Already in a short period of time I've been incredibly surprised and impressed and I can't wait to see where it goes.