 Hi everyone! It's great to have so many of you here. My name is Marek Pyhajärvi and well, even though I say my name, I don't expect any of you to be able to say it after me. I'm kind of used to going around the world and having people look at me a little bit weirdly and like, oh please tell me how to say your name again and again and again and again. I think this is now my talk number 390 something, so I've done a couple of talks over the years, so I have a bit of empirical evidence on how things usually go. But you're being a bit of a special crowd for me in the sense that I do talk a lot about agile, I do talk a lot about testing, but I don't often get to talk to people who are particularly into this product design, product management space, and I was really delighted that I got a chance of presenting on this particular topic here today. We're going to be talking from a little bit of a different perspective than all the talks that I have heard today. I've been listening to different samples all day long and there's a couple of differences. One of the differences is that I am not a product owner, I am not a designer, I am not leading a design team, I am not leading a product owner team, so I'm none of those roles. I nowadays consider myself a developer. I'm a developer and a tester and I've been a tester for most of my career, 25 years so far, so that has given me a chance of working with lots of different people, but also a big part of my identity is that I work in a single development team, so I'm not trying to improve the whole organization, I am trying to have a great time with one single team and I'm trying to provide great results with that team of developers, product owners, whatever roles we end up having there. I'm working at a company called FCure and there's a couple of things about me and FCure that I should be mentioning before we dig into deeper into this topic. One of them is that I used to be a lead quality engineer, as the title says. Last June they decided in my team that they would move me into this senior manager, Windows endpoint development role, so I have now 12 people who report to me, but I approach this management position as in my goal is to get fired in a year, like I want to go back to being just a tester, just a developer in those teams, so kind of emphasizing this, you know, liberty, self-management, freedom, so living up to the values that we, a lot of times talk about in the agile field. Another thing that is good to remember is that a lot of times these sessions are about, you know, building something new and I'm actually not doing that, I'm not building something new and kind of like creating a whole new flow, but what I'm doing actually is that I have a product that has existed for about 30 years now. 30 years and it has seen many, many generations of different technologies and it has changed, the most recent change has been in the last two years. We're kind of just finalizing a huge technology change in the product that we're building so that we're getting all the millions of our customers into the latest technology so that whatever new cool stuff we end up building, they would even get it. So that's a very different setting for doing many of the things and also kind of it's good to remember that in the company that I work with, security software, end point protection, antivirus is the most common use case that you wouldn't know of and we have some millions of customers, each of them individually installing the thing that we're building on their own personal computers and that for example means that when we look at the stuff that team builds and all the teams, different teams building into this system build, we have a system of test automation that actually spawns 14,000 virtual machines just to test it inside the house on a daily basis. So the scale is kind of like sometimes it's a little bit fluffy and difficult to explain so I just wanted to kind of set the stage to give you some of these ideas on what kind of things we're doing. So I come to this whole experience from the background of being a tester of 25 years, I have had the privilege of programming in only 16 languages so far, you know that's what testers do you know that's completely possible and plausible thing for a tester to do but one of the things that I really found important in all of the 25 years with this tester identity is that I look at the stuff other people are building it might be the plans or the backlogs that the product owners are building or it might be the code that the developers are building I look at it and I kind of look at it as if like it might not be completely true there might be something here that we don't yet know it might be that there's bugs you know that's the simple part but there might be features that we have never developed because nobody was asking for them the customers might be asking for something but they actually mean something completely different and all these layers of kind of how people work together to solve the problems around software development they've been the big fascination for me for pretty much all of my career and this has transformed me into thinking of like you know I'm not just breaking illusions about the code the code is actually the end result like if we don't get our plans and designs and whatever into code the users won't be able to use them like they get to use prototypes paper prototypes or running prototypes but that's not the real thing we have to have the code involved but there's many kinds of things where we're breaking illusions overall so I'm often talking around these illusions with this idea that you know there's things on basic around product but also there's these ideas leading to code and specifically today the sample of having no product owner is in the process area of these illusions so as part of my work as anyone in my company could I can just you know decide that maybe we should do things differently maybe we should try something different and I can propose that within my team I can propose that within other teams and whatever we end up doing or selecting to do that's what gets done so here's a little bit of a list of things we are doing right now in my team so we're delivering continuously meaning that we have versions available all the time but since we have one million and something installations to do every time we deliver it's not one server or ten servers it's millions of individual computers we're installing every single time we deliver it actually has a financial impact like it means that someone has to download quite a relevant size of a package and pay for the transfer cost we have to pay for some of them the customers have to pay for some of them so doing that really really really continuously wouldn't be a nice mechanism so we build a way of throttling and delivering it in a bit slower pace so usually a new version is available once a week or every two weeks so that's the pace that we found that customers are now okay with we don't use JIRA much that's a whole story of its own but basically focusing on communication face to face or calling our offices in Poland so I'm in Finland some of our people are in Poland some of our people are in South Africa nowadays so again we have to do multi-site development but we rather often try to meet people face to face whatever mechanism the face to face is than work with JIRA and this is not true for any other teams in my whole organization this is just my team that emphasizes this we don't spend our time on estimating there's a whole other talk here on no estimates I suggest that you would go and talk to that it has been a transformational practice for my team so Wudizuil I think he's later in the day today so if you get a chance of having a chat with him that would be a good thing we have no product owner anymore we actually don't have projects anymore there's just continuous flow of features and we discover something new we figure out what we want to build and then we try to build that and deliver it to the customers rather sooner than later and also we used to do a lot of scrum basically two-week increments come from that side and now it's more like continuous flow Kanban style management so no scrum either so this is kind of the story but all of this kind of is related to the idea that we discovered or we found that within the development teams over the years of trying to build software the easiest way to get things wrong was to make sure that the developers didn't know why we were doing something or what we were trying to achieve with that so if the developers were well versed in the idea of what we wanted they often built on top of that idea and they made it better and when we made them kind of look at an idea that somebody else formulated and try to just deliver that they were not very joyous but also they made mistakes of kind of like I didn't know that nobody explained that to me like they weren't actively thinking around what they were building and the code, the product that ended up being delivered wasn't always the best possible one we also noticed this dynamic where a lot of times when things went wrong there was a big problem in production for example who do you call in our organization? Well, the developer I was the tester in the team I never got woken up 2am in the morning and none of my developers in the past would have lived through a life in the organization without a story of being woken up at some weird hour or being expected to do something at late hours or there's a concept of working 24-7 until the customer problem is solved that never hit me so what hit me as a tester and a teammate who cares about the persons that I work with is that I really don't want things to be so that the developers don't have the means but they have the responsibilities so I started off with this whole discussion around no product owners so for my organization I think we've done something we call Agile maybe 14-15 years now so it's been long enough I haven't been all the time in the company I'm now on my second term in the company so I came back 2.5 years ago and I was there earlier 12 years ago but we've been doing Agile style development for a really long time and we had done many changes over the years we had for example kicked out all of the Scrum Masters they actually ended up being fired in the organization so knowing that that was kind of like in the history or DNA like now of the organization that even that kind of things could happen I was a little uncomfortable with this idea of no product owner at first because I actually wasn't looking at getting them away but I was looking at getting the responsibility at the developers or the team with the immediate delivery responsibility so the idea started formulating basically from ideas around discussions like this customer obsessed teams don't have product owners and the idea with this particularly is that if you have someone who makes the choices for you a product owner who builds a backlog and maintains the priorities and then the developers are kind of actually just taking orders then you don't actually have the full potential of the team in place but you have people who kind of just obey orders and whatever learning happened by the product owner don't get fully transferred because learning is kind of a personal thing where everyone has to take a responsibility also I kind of formulated this idea out of all of these articles that I was reading that maybe if it is the most important thing that a product company is trying to do is to make money out of solving actual customers problems so that they're willing to pay for that maybe it doesn't make sense to specialize one person only into that problem, maybe it's everyone's problem, maybe we should all be thinking about this so I started talking about this in my organization and the first reaction from the current position holder the product owner was oh no no no no no not a good idea and we didn't have to actually talk very long until he was like okay sure we could experiment with this we could try something different maybe we'll figure out that whatever I'm doing is really critical and necessary but even if we would find out that this is the perfect excuse for developers to actually start taking ownership that would also be a valuable learning that we can take out of this so all of this kind of came from this idea of modern agile so we talked with the product owner and looked at kind of what they were doing as a part of their work and we realized that they had days full of work so when the team and the product owner had this discussion on taking over this product owner role we realized there's so much to do so if someone has full 40 hours every week and they're still overflowing with work like throwing that into the development team it must have some impact right so we had this discussion we are ready to take that risk and let's keep our eye on that and on how it ends up going and we talked around all the different areas that product owners often do this Hello, my name is William Gill and I really love the material that he started publishing on the complete product owner even that already gives a great idea of all kinds of tool sets that a product owner is supposed to have and just having this discussion of all the different areas that we're supposed to be following on was a really valuable experience for the development team like all these kind of things then mean so there's all kinds of things around well product definition and vision but also on just driving innovation and making things better so kind of safely talking around the product owner's role, what kind of things filled their days it gave us this place where we were felt a little bit more safe to get into the idea of let's first experiment with this we don't have to commit to anything time frame, we decided the three months sounds like a good time frame to get some results but it's not too long so that if we want to kind of revert back we are not yet completely anywhere else so we set up this three month experiment first one thing we did is kind of formulated the idea of what were we trying to do so what was the idea that we were trying to either prove or disprove and since I am a tester I want to disprove every hypothesis I am actively looking for evidence that things are not true because that's the only way to you know even getting closer to really proving or understanding anything looking at the positive signs is not enough you have to look for evidence against whatever you're trying to achieve so we believe that you know if every one of the team members every single developer every single tester in that 12 person team would actually feel ownership towards the client would have direct connections with the clients well some of the millions at least then we would probably we thought that we would probably actually be performing better and this whole concept of what does it mean to perform better we looked at six months before what had we delivered what kind of things had been happening and kind of created baseline baseline out of that and we also looked at the things we have done before so we realized we didn't have a manager so we already kind of like had given up on that idea that we needed a manager who would somehow manage all the teams work we had already figured out that we can talk to each other like we can share the work without Jira Jira and it's still a headache for some of the more process oriented people in our organization and one of the things particularly relevant for this experiment was that we used to have the product owner that we were now removing from the position we used to have them as part of the team they were in the same room with us when I joined the company they were in the same room with all the developers and when I came one of the things I did in the first few months is go to their manager and ask them to be removed from the room and the reason wasn't that they were being often anyway the reason was that the team had somehow probably culturally picked up this reporting structure where when there was no manager there was a manager and the product owner played that role really nicely in the team and I as a new member in the team I was for example struggling with getting information because it all flowed through the product owner who did not necessarily remember to tell the right parts to me as the team's tester so that I could do my work work properly so just a physical movement first had happened already so we had just moved him to another floor and from there they were having this kind of like still holding the very same role but the developers laziness already had changed the system so that they would now report to each other instead of reporting to the person where they had to walk one flight of stairs to get to so it's that little so the whole remote work and all that you know even in one bigger building one floor is enough to change the dynamic we were releasing frequently and I already talked about the no estimating part so what we did we kind of looked at the bigger picture of what the product owner does but then we created a very specific list of the duties that were being handed out and out of that list we found one thing that the person who used to be holding a product owner role was like a really really long list probably 20 30 different items that they were doing all of them kept coming to the team except one there was one item around requirements drawing fishing for requirements so basically when you have some thousands of partners and some millions of customers having 12 developers talk to a million people it doesn't really scale you don't get to do that so having someone who would be kind of the receiving end of emails and responsible for responding like thank you we heard this 1000 second time and we are keeping this on our list of things and considerations and kind of somehow fishing for the important information was an important part so we made the product owner or the past product owner we made them we call them a product management expert I tried to call them product management specialist but PMS made you know as a shortening they didn't really like it so expert sounded a lot lot better and the only responsibility we assigned out of that whole list of things the product owner was doing was be available in all the boring meetings that keep on happening because usually that's why their weeks were so full of stuff is that you know different customers different partners would come and visit us and they would always be representing us in those meetings so requirements trolling was left with them so three months passed and in the end we asked around the team and also outside the team on what kind of things happened and the first thing that the team reported is nothing changed you know removing one person product owner didn't change really anything like nothing is different from here but then we made a list of the past six months and the now three months and we compared what we had delivered and we realized that we had delivered a lot more a lot more we had also delivered things on higher quality as in we now cared a lot about we call it telemetry basically analytics information so developers now that they were responsible they refused to build features that nobody would be using so they introduced a lot of features around knowing what we were actually using so that we can turn them off or take them out if they were not used and having direct connections with the customers when they found a problem that was painful for someone the empathy that they felt was almost, you can almost grasp it and all of that like I've not felt so much joy in development then I felt when that kind of like you know we're now free and we can do the decisions ourselves when that started emerging so many kinds of things that I almost call magical happened like I don't know exactly how they're connected this change but people started taking responsibilities and participating in discussions that they had not volunteered to do before and one of the most difficult things for us to do was have the product owner in the room and not say I want it this way the priority should be this way and just you know watch the priorities unfold sometimes you know pitch in some information but still say that the final decision on what gets implemented right now kind of like into this this planning when you're making choices is on the development team so that was something that we really needed to practice the product owner themselves reported that they had now time for they called it strategic thinking I'm not sure what that means because I have not yet after a year seen a big impact on that strategic thinking so I know that I do a lot of strategic thinking all the time I feel guilty when I can't connect my awesome thoughts of what the world could look like into anything practical because actually we're paid to deliver results so again if this is a learning experience for all of us it is only positive so failing FAIL fail means first attempt in learning so doing something wrong is never a bad thing but anyway they said they had strategic thinking time the interesting part was that during the three months they didn't come back with all from all of the meetings because now we could measure the meetings input to the development teams they came up with nothing so three months of meetings and quite many of them you should really think about how efficient your meetings with your stakeholders are nothing that we didn't already know remember we have 30 years with this product and this specialty area already behind us computer security is not always the domain where the customer knows best viruses most of us haven't seen one in our lifetime so again it's a very specific area in that sense so this was something that really kind of piqued our interest on like how will that turn out to be a longer term and now that we've been doing this for a year we have now one thing that they have brought back to us in whole year but we also have a lot stronger relationship in having these discussions on the daily basis we don't necessarily notice what kind of things they're bringing but the competence, the knowledge is a bigger part of just having discussions nowadays so some aspects on this experiment that on day 21 was really funny being one of our demos where the developers basically in the team ran a demo and they showed a couple of new features that they had built in the last last couple of weeks so we had a cadence for showing things around in the company and they got really positive feedback from all around sales organization and it was a really good demo like it was one of the best demos that they had seen for a while and the funny part was that the developers were like oh you know we're supposed to be doing that you know that's what we do now and most of the demos ever since actually have had a lot more of a customer focus and they nowadays opt out of delivering a demo where there isn't a focus for that group so not just showing things for progress sake but actually showing the results and the impacts another interesting part during this experiment time was that on 65 days so that was closer to the end of the 90 days that we were running this we realized that hey we haven't actually seen the product management specialist or the product management expert in planning for a while like we had these sessions where they could show up and we would be together at a certain time and they were invited and all that but we hadn't seen them for a while and we hadn't really realized that we could even miss them at that point anymore because we were so active in designing and deciding on whatever the product backlog would look like ourselves and also we saw him kind of on the corridors like you know you would walk by and how is it like now going and you know any interesting things going on with the customers and like what kind of things is going on in your floor and you know just chatting up and then telling that back to the team that was more of the practice that we had but out of all of this kind of experimenting there were some impacts that I really kind of wanted to highlight the first thing that really happened is that anything and everything that was clear to the developers that they felt that somebody had told them not to prioritize but they felt it was wrong all of that stuff got implemented in the three months like they fixed all of the bugs that we had on our backlog that had been lying around probably for years because we didn't have time there was something more important so they got they got working on those and they fixed a lot of them also some of the fixing was really like a lot of it actually was very customer oriented so for example there was this one fix where a customer was asking us like can we have this fixed and then they were wondering like when is it actually available because sometimes the product is not the easiest one to understand when a particular change is available in production so many different moving parts so the team even kind of like you know went through and checked that the fix is available on a particular date and then communicate it back to that customer so it was really like many ways like gearing it up so that the fixing that was supposed to be happening already before really started happening but this didn't stop people from doing other things than just fixing so the crossing worship was about providing that kind of fix for other themes we're also talking more to the customers we realized that some of the pains they had were not about the software it was about not knowing how to use the software so we kind of geared up also the customer facing documentation so developers were the first to volunteer on you know writing community articles and health documentation things they usually would opt out on but now that they knew that someone really really needed them and wanted them they would actively go and and since all of the information was already in their head it wasn't much of work for them but it would have been actually much work for someone else to try to dig it out from their heads and then start delivering so again a really nice benefit there many of the solutions we needed to provide there was a lot faster delivery so again with the empathy feeling like knowing that this is needed and figuring out how to deliver it in the first valuable bit first and then more like the agile way of delivering we really got a lot better with that that and there was one particular feature around installations that we were supposed to be implementing and we had been already six months telling that it's a big project it's gonna take us forever like you know probably another six months before it's available and after we met the salesperson on that area and understood their problem it was delivered in a week the first version of that and later on we replaced it with a proper solution but they had it available basically almost six months earlier than what we had originally planned for when we felt disconnected with the real problem also the incremental delivery like we were already delivering incrementally but a lot of times there was a lot of process around kind of like taking something from the backlog and then refining it and understanding what it should be and having a discussion around it and making sure different participants developers, designers UX people, testers all of them like you know would have their say on it before it got built or while it got built and after it got built and a lot of times it was really difficult to do these minimal changes but whatever we considered viable tended to be a lot bigger than it turned out to be so when the team got the responsibility and felt like they were in the ownership they also figured out that they could do smaller changes and continuously deliver so it was more like a flow like again how do you get most water moved from one place to another is you know a drop at a time if you try using buckets and carrying them around it's probably slower than having a continuous flow where you deliver it so hiding things with feature flags keeping them under the hood for a while sometimes doing that showing it only to particular customers figuring out the right ways of doing it got a lot more active so we got nice feedback on that one then also we learned by talking to the real users and the real partners that they needed something that weren't you know came through so we really identified a big broken phone effect in the way we had worked before so sometimes you know keeping us safe from all the distractions meant that they wouldn't tell us about somebody's important problem because you know it's only 10% of our customers or only 2% of our customers or only half percent of our customers but again even those when you scale it into numbers that numbers are in millions that's actually quite many people who are annoyed or somehow inconvenienced and many of the features you really don't know what the feature is that you're supposed to be building unless you have that direct learning experience with the original source so the proxy way of working wasn't giving this all for us in the same way as it could also then the team like I already mentioned earlier as soon as they felt that they had the power they decided that they don't do any decisions anymore without having analytics data so we didn't only introduce analytics data on the positive cases on basically like does it work how many people are using it but we also introduced analytics around problems so when you have a scale of things you want to see how many people have a particular type of problem so that changed the way we implemented many of our features and we actually even learned at some point in the last six months so after the experiment time we learned that one of our features had never worked properly in production when we released it with telemetry we learned that 50% of the users could use it nobody was complaining so the negative telemetry was really really important and I'm really happy that last week we got to 95% so we have with the numbers visible seeing what is actually happening or that scale of computers we've been really able to take things forward a lot and still it's not that we haven't delivered any of the other stuff that people are expecting of us so it's just we get more through so out of all of this after the three months we had the retro we had those learnings and we talked around this idea that should we continue should we stop what did we learn and we decided that this experiment should turn into something that is permanent and we would continue in this mode so now it's been a little over a year I think a year and a half almost of working in this mode and I took for this talk I took the chance of reflecting a little bit on what were the core practices that actually over the year have taken a foothold so first of all I think that what is kind of like the cultural atmosphere that is really really important is that even though we kick out the product owner we don't really kick out the product owner like they are still as valuable a person as ever we still talk to them we don't isolate them we don't try to keep them away the only thing we're trying to say is that instead of having the power of decision on that one person gets to review whatever decisions were being made and they unfortunately sometimes need to accept that we might make a different decision that they would have made but they need to let us make our own mistakes and trust that we will be learning on them so the idea of never excluding a person was very strong in the way we worked so we really organized all of our work as in the kind of network of connections so every single person in the team has a network I talk to the product owner I talk to these teams this developer I talk to this tester in our Polish office I have my network and whatever I fish out of that network I bring back home to my team so that they can get the core of my learnings and every one of us is expected to work the same way in the 12 person team sometimes people say that you know we can do this because we are so seniors 25 years you know that gives you a lot of seniority but I have a colleague who is now 17 he was 16 when we started doing this he was 15 when he joined the team and he when he's the only one in the room who shows up when somebody shows up and asks something of the team he takes whatever for the team others are aware of it and make sure that the answers whatever was asked of the team go back to whoever was needing something from us so every single not every single person in this network in the team that we are working with is bringing stuff back to the team we don't have to have all the answers but we need to be responsible for helping working with the others and figuring out the answers another thing that became really really really important I can't stress this enough is bias to action a lot of times we would talk and talk and talk and talk and talk and then talk some more and then go home and sleep and then talk some more and we can easily use 2-3 weeks into just talking and nothing is delivered and bad stuff delivery isn't a bad thing because you can also take it out software is malleable you can put stuff in but you can also take stuff out so believing in this idea that you can make changes was a really profound one and instead of waiting to know the right thing to build building something and then making sure it was the right thing to build was much more important and I think this is the core practice for being more effective or efficient in output delivering right kind of things in general so we need to talk before we start but there is a point when it goes too much and we over analyze then with customers we have this rule of meeting them at least where some of them different ones every time usually at least once a month a real customer that's a smell so we go and meet them so we don't want to keep a distance and it also means that several people from the team are active in our open community forums and some of us get personal emails from customers I have many customers as LinkedIn friends and they keep on complaining to me about some of the problems and I just say thank you and I actually do solve their problems because I care so we don't try to keep them a distance but we try to make sure we solve the problems so that we don't have a problem of having to fend off the customers so that's what we try to do and then we realize that people don't mean to lie but they do lie because they just can't grasp the scale and data it lies to, it actually is a huge scale of lying but it lies a little less than people and you can always ask more questions and go and add that perspective from the data so this is what we learned after a year a little over a year of no product owner and the feedback right now is this was from my annual review as the team's manager you have the best team in corporate R&D and probably you did something to make this happen I actually think the team did a lot more more on that but you know anecdotal evidence, I have it in writing so if anyone wants to ever see it I can show it then I have as my this year's goal is to get other teams in FCQ trying something similar to take responsibility and learn these kind of design skills and dare to talk to the customers and do all of the fun stuff that designers and product owners get to do and that team when they considered, if they would now start doing that, this was their feedback well, you're one team, it's not sufficient proof that this approach is better also our team lacks the seniority that your team has and we don't have the communication skills that your team has so we can't attempt it and all I could say back to them is nothing changes if you don't start changing stuff like you can't complain about things being bad if you don't do something different you have to be responsible for your own team's happiness and your own results and again, experiments don't have to stick this one stuck but they don't have to one of the things I've learned over the years this is a picture from a mob programming session is that there's a very powerful idea called cognitive dissonance when I first time heard that there was a way of working where you would use one computer and you would have eight people working on the single computer I thought that was ridiculous it was so ridiculous I had to try it same way as no product owner is so ridiculous that I had to try it and I learned that when I was doing it it completely rewrote my history that's how the human mind works so when your belief system and your actions are in conflict one of them somehow changes and a lot of times doing something that you think is wrong is the best way to help you see that it actually might be right so out of all of this what we got is that developers really, really love solving problems and when they're taught to pull information so that whatever ideas they have are the best possible to provide the best possible code for solving these problems they do a brilliant job at it so pulling instead of pushing the information and that's what the no product owner experiment and the whole practice really gave us that's what I had to share today we have a moment for questions alright, couple of minutes of questions well we did that same thing as well again in about 15 years of agile we've done pretty much all of the things I was just talking with someone on the safe counter there there was a safe thing Dean Leffingwell was working at FCQ when he created SAFE he completely threw away every bit of that but we did try all of it so again trying things that you think are wrong is the best way of making progress in agile so first we removed the person from the room and then we removed the role completely so the person is still in the organization they're still doing other work you know completely different assignments they are just no longer acting actively with this team because they basically need only a few hours a week at most to work with us so we have a team of four or five product owners and they split work amongst different products in different way and I haven't followed up in detail on what is that work that he is particularly doing I've seen that they're doing some analysis related to customer retention so usually it looks to be more of these like understanding how our business numbers are changing type of work rather than working with the development team yep so again all the time when we have scale there are so many end users you can't have the real customer as the product owner you end up having proxies so my view is that it's better to have many proxies so everyone in the team is a proxy and it still doesn't necessarily hurt to have some really good proxy that specializes in that so I'm not against having those people I'm warning around the hierarchical idea that now this person's responsibility and the impact of that so again be careful of the language thing be careful saying I decide, I prioritize I get to say and make sure it's always the team who you empower to be around today and tomorrow so again you can have as much discussions as you like with me thank you very much