Good afternoon again. My name is Vinod and I'm a product manager with Microsoft. I Work in a team called visual studio team services, which is basically our DevOps offering And today I'm here to talk about You know our journey towards DevOps. This is not just about VSTS But this is also about the 82,000 Microsoft employees actually moving to DevOps, right? So The journey includes three aspects. It talks about the culture the process and then tools And just to set the expectation right my presentation is not so much focused on tool right now because I Saw there are plenty of demos happening here The intent of this presentation is to talk about, you know, what we did right or wrong What are some of the learnings that you can take in your journey? What are some of the mistakes that you can avoid? right I Have worked here in Bangalore also previously and I love the opportunity to come, you know to this city. Just love this city Except for the fact that my in-laws also stay here. So And That's definitely not the reason I left the city, right And I hope this is not getting recorded right This that is certainly also not the topic of discussion. I know a lot of you I can see a lot of you smiling, right? The only thing I can say about that is, you know, there are some challenges in life. We cannot solve We'll look at DevOps. Okay. All right. So with that, let me give you a quick introduction of The team that I belong to right so Microsoft has a big Organization which is called developer division right which has about thirty two hundred employees and This is essentially all your visual studio You know vs for code vs Mac Visual studio mobile center and then obviously, you know visual studio team services as well So it's a large organization and we are a part of that organization So we're about 800 a team of 800 people Spread across the globe. Okay. So We have a team in Redmond. We have a team in North Carolina and then we have a team You know in Hyderabad as well, right? We have about 40 feature crews So the size, you know when I look at 800 it reminds me that my first company didn't have you know The total strength was in 800. It's a big team Spread across the globe 40 feature crews working on you know various features This is the only slide I have about the product Okay, and I'm not going to sell VSTS here because my intent is to talk about how we embraced DevOps, right? So visual studio team services has two offerings One is a TFS which is the on-prem solution and the other one is VSTS Which is you know the cloud solution, right? It provides you source control It provides you build release continuous integration continuous deployment package management Dashboard analytics, so it's kind of an end-to-end solution. You know if you're looking at onboarding to a DevOps offering So that's the only slide I have on the tool then I have this slide which actually talks about Our internal journey like as I said there are about 82,000 Microsoft employees Actually using VSTS as the DevOps tool This includes, you know, the largest, you know, the largest code base that we have on earth, which is windows basically includes windows office You know any team your name, I mean there are 50,000 engineers actually working on you know on a dedicated basis So when you what you look at when you look at this dedicated user that means people using it continuously for 11 days in a month Right when you look at occasional these are people who come in for two days at least right and then there are One-day users as well who may be experimenting with it, right? So our journey so far has been good You know the way we have moved to almost 50,000 dedicated employees and it's a challenge It's easier to sometimes move people outside the organization than inside and in Microsoft You have plenty of tools which have been you know kind of homegrown, right? So you really have to have a reason To be able to move these teams around So let's now get into a journey and this journey is about how we started how this team started so Once upon a time You know we used to have this as the cycle which is two-year release cycle so something That I that I'm working right now is actually going to get released in 2020 Right, it's going to be two years down the line. I know exactly what that feature is going to be, right? So to be able to do that we had a huge planning cycle like months of planning, right? And then we had few milestones, right where we would have some part of the product to be enabled for our customers The planning itself was a huge cycle. I'm a product manager. So this is my area I would be writing specs, right? So I'd be spending like months writing specs and those specs would be nothing but you know 500 page document that the team is expected to go through and develop a product, right? But as I said the assumption was whatever I'm doing right now is going to get released two years down the line So I have to know What the customer is expecting two years from now. It sounds funny right now, you know when we when we think about it in today's time, right? And we also knew it was right, right? We knew because we have spent so much time. We know this has to be right What happens to the development? We had an equally long Development cycle where people would write code and this code would be written months before it's actually going to be released, right? It's like The developer is writing it now and six months down the line We will actually have a release because there is a huge test and stabilize phase Think about the plight of this developer Where a tester comes at this stage and asks the developer. Hey, here is a bug in the code Can you tell me what is the problem with that code? The developer has almost forgotten the code that you know he has written It's almost like me asking you like, you know, what's your marriage anniversary? And then you're thinking, you know, I don't remember right so It's it was that kind of a challenge right and think about the plight of a developer who is new So the developer who actually coded has left the organization and there's a new developer poor guy He doesn't even know what the code is but he has to look at you know, what that bug is understand that code So it was a huge huge huge debt for us Then came the beautiful day right when we are going to release the the product So we had we used to have release candidates and then we would have released to market, right, which is the RTM and What happens? We have done the planning. We have done our first deliverable and now our beta is ready So we go out right we go out and we talk to the customers We're just waiting like I'm standing here and you're the customers and you know You're just looking at what this product is going to offer and I'm excited to know what's your feedback and then you come back and tell me That doesn't seem right, you know, what you've built doesn't seem right And we're like no, but we spoke to you. We took the requirements This can't be wrong, right? So what do we tell them we have to have an answer, right? So we tell them Fine, you know, it's a great feedback We'll implement in the next two years Because that's how a really cycle is right. So we tell our customers wait We are booked solidly come back after two years Right now think about if you were that customer We've had a lot of challenges We've not been able to give features that people have asked for we've not been able to prioritize So we realize that you know, there is a problem with this, right? Why did it work at the first place because at that point in time? That is how products were developed like windows for an example was a three years really cycle, right? And it was fine. It's almost like if I tell you 15th century if I were to tell you in we're all in 15th century and I tell you a Hey Cars are going to be the most common way to commute. You're probably going to laugh at me at that point in time, right? At the same time today if I tell you that horse is going to be the most common way to commute You're still going to laugh at me, right? So this fitted at that point in time and so it worked, right? But today it doesn't right This is anyways a statement. So I'll skip through this is basically to say that hey You know with with the amount of agility that we are expecting in the business You know, you can't work at the pace that you've been working with, right? So what's the solution? I'm assuming Everybody knows about this light, which is a standard sprint, you know the scrums You know diagram and I'm sure through the you know three days or four days you've been here You would have seen this right so this is the solution to the problem and that's also my last slide No This is just the beginning we thought we will adopt this we heard like all of you we heard, you know This is what we should do, right? So We said, okay, let's go to sprint model. So what do you do? You simply break the schedule Right and this has like even even though it will not be perfect But the first step is to simply break the schedule. We did so so we we decided we are going to break everything into Sprints, right and these prints are going to be three week cycle. Why three? Any guess You know you are smarter than us because we didn't start with three weeks Actually, we started with two weeks first and then four weeks. Okay, and in both the scenarios We realize that it's not working out, right? So you're smarter. You figured it out in the first place, right? A good one So we started off with two weeks and then we realize it's not working We were not able to deliver enough increment, right? So we moved to four weeks but the four week cycle was a problem because if there's something that slipped beyond four week That meant another four weeks, right? So we said, okay, we're gonna go get to a three week cycle which seems to be reasonable But we were scared of quality, right? We think about this like we had been doing this two-year releases and one fine morning You know, we wake up and we say, hey, we're gonna do three weeks sprint Like it's just gonna be a very smooth transition, right? Two years till yesterday. Let's switch to three weeks now, right? So that was the transition that we were going through. So definitely not smooth What we figured out is that we do we are not we are not confident we can deliver quality So we added a stabilization sprint like everybody does and these are by the way small waterfalls Within the sprint, which is where we also started, right? Nothing new everybody does that Now what happens? We have two teams and this is actually by the way a practical Like actual on-ground example that I'm saying obviously I can't name the people but there are two teams One of the team decides that they're going to build Features that just going to focus on features. So they'll add feature on feature on feature They're excited developers want to build feature, right? So they went overboard and they started building the features which is team B Team A decided that while they're going to build feature But they're also going to make sure that there is not in your more technical debt that is accruing because by the end of sprint five While there is a stabilization phase. It is still a sprint, right? You do not want to accrue the technical debt, right? So what happens? Team B is red Okay, because there is so much technical debt Team A is green, right? So what do we do to team A? We reward them No We actually punished them we told them go and fix their debt as well What do we do? We have a you know limited timeline So we punish them, right and you can imagine the level of motivation that team A would have, right? After knowing that they have to fix team B's debt By following all the process as it was expected, right? Definitely, I don't want to be part of team A for sure So today we are here Today we are at three weeks sprint We don't have that, you know Long two-year cycle and I'm going to talk about some aspect as to how we reached here, right? I'm sure this audience would have you know people from different background like you know program managers developers you know testers and I hope that there is something for everyone out here to take okay as I said at the start the large part of DevOps is about culture and people then the tools and that's why I'm not covering tools You know to the detail This is a pretty known statement So what did we do to change the culture? We did not give people Dan Pink's book By the way, I don't know how many of you have how many of you've read this book, but it basically talks about The importance of autonomy the importance of mastery and having a purpose behind it, right? So we didn't give this book But our thought process was kind of aligned to this to say that we need to give autonomy to the team because Creativity comes with autonomy. We need to give people a sense of mastery For us it was easy because I'm building a product which is VSTS, right? It's a product for DevOps and if I'm not going to master that product I cannot stand here and talk about it, right? So for us the purpose came naturally because we were building that product And obviously, you know mastery I'll talk about it, you know, how our teams do that But let's look at what does that mean? What does autonomy mean because autonomy can also be risky, right? So this is one example that all of you may know about which is you know in Kata and You know Wikipedia the way in Kata came in was that, you know huge business plan Well-funded hiring the right people, you know that they needed and then Wikipedia completely You know different model People who are interested to contribute in their free time not much of funding and we all know what happened, right? And by the way that was actually funded by Microsoft In Kata, so we all know what happened, right? So clearly it's not the money that's working, right? You have to have something beyond right so So this is what our guiding principles are We have an organization which is of the size of 800 people What that organization is going to look like? What are the rows that are going to be there in that organization? Which teams are going to be there like testing or CI CD or work items? What cadence we are going to release product, right? Is it three weeks? Is it four weeks? Is it five? Is all Alignment today today Any of those 800 people if you wake up any or any one of them middle of the night and ask them Which is the sprint that is going on right now? They'll be able to they'll be able to say s 132 dot 2 Anyone and that's it. That's a challenge, you know that I can take openly That's the taxonomy part of it How do we make sure that you know the entire organization is aligned on certain things, right? But Without risking the autonomy so where does the autonomy comes the autonomy comes in? How do you plan and how do you practice that which means as a product manager? I have full freedom To decide how that feature is going to be built What are we going to do in that feature and nobody can take that away from me, right? But am I going to run a four-week sprint? Am I going to run a two-week sprint? No That's aligned at an organization. Am I going to run a sprint starting next week to you know The next three weeks and the other team starting this week to the next three weeks. No You don't have a choice there, right? So you have to have alignment and you have to have autonomy This is from a tixonomy standpoint. So we do 18 months of Planning strategy planning and let me just get to the next slide actually So we define epics which are like at you know at the range of 18 months Something that we want to target for 18 months next 18 months, right for an example If I were to decide, you know, if we were to decide that we want to do something around functional testing, right? That's a large strategy, right? So we would probably take a call that this is what we want to invest in right in the next 18 months From there we decide what feature are going to be, you know part of that strategy, which is roughly around six months From there we come to feature chat feature chat is nothing But we do kind of a three sprint planning. We have a sprint for three three weeks We do a three sprint planning, which is what we call a feature chat, right? And then we have the sprint which is three weeks itself now What is interesting is we've also figured out What does it mean in terms of how accurate we will be on each of those? So if I were giving a strategy for 18 months, I know I'm somewhere at the ballpark of 60% It it would be only 60% that I'll be able to deliver if I am doing a feature which is six months Then I know it's probably around 80% Right, but when I come to feature chat when I come to a sprint, I have much more clarity I know that I can deliver 90% of that right and I'm not just saying it Let me just I have a few slides open a few pages open that I wanted to show you as well Yeah This is Feature chat for all the 40 crew crew members that we have right 40 crews that we have and this is only for the sprint That is going on right now, right? So everybody has to come with a feature come up with a feature chat and then we have a set of meetings where Every, you know GPM which is basically my boss, right? Who's going to talk about his feature chat about his three feature crews and then everyone else is going to talk about that And we do it over like three meetings which are each for about two to three hours It is important because teams are distributed and there are dependencies across team, right? So that's the you know the feature chat part Let me just quickly Okay So this is the feature chat part that I said This is our sprint Three weeks print. So we have three weeks print which starts at week one completes on week three week fourth is a deployment and our deployment Happens in rings. So we have a progressive deployment And I should probably show you you know what that really means so These are the rings that we have. Okay, so these are the environments you can assume, right? And this is ring one. This is ring, you know, this is ring zero one two three four We have seven rings, right? The idea here is that there are a lot of people who are sitting here in ring one This is kind of a canary kind of a deployment where you know, I have my MVPs Which are you know a community of people that we work closely with, right? This is us? Us itself like you know one of this ring holds our code the VSTS code itself like can't be like Being part of this team, you know, I feel so excited thinking that What I am developing is also actually getting deployed by VSTS Which means VSTS is being built using VSTS, right? So these are the rings where you know, you would basically pilot test And and you know get some of the early early feedbacks out, right? And then you do a progressive deployment. So when I said the fourth week is deployment in the five days we would go from here till ring seven right and we intentionally delay You know in that week because you get service health related information If there are issues you would get issues as well for an example We had an issue with with our service, right? And since I'm talking about culture Let me let me show you something that Am I only intend to show you this is because as I said a large part of it is actually culture, right? So we had an issue. This is this is from my CVP And he he is very active on the blog, right? And so we had an outage Just a few days back, right? And he blocked about it He blocked about and this is all available in public to view, right? So he blocked about How there was you know an incident that happened and how we did a post-mortem of that and how that was available publicly for everybody to view, right? And the same post-mortem, which he's talking about is actually here So we talk about what was the customer impact and it's all in public, right? We talk about what caused the initial failure Why didn't the system auto come automatically recover, right? And then what happened at the you know the application tier what happened at the back end All of this data is available for all of you to consume for our customers to consume So that's the kind of transparency that we're talking about. It's a very important part of DevOps, right? It's not just about the three weeks, right? This is where the culture part of it comes in, right? So let me just go back again Yeah, so the three-week sprint fourth week we deploy and then while that is happening We've already started on the next print right We spent sent sprint emails Every every feature crew has to send it by the end of the week third everybody has to send it and All of these print emails are actually read by rcbt, which is great Basically, but the idea here is to say that there is one this is alignment This is alignment to say that Everybody in the team has an opportunity to know what's happening across a you know different feature group, right?  What you want to highlight the sprint emails are usually about customer value and stuff But you have freedom how you want to do it, right? But you have to do it, right? The other thing that I want to highlight is anything that we do, right? This is A feature that I worked on. Okay, and this is actually a work item in the sts And this is my release notes of when that feature got completed, right? I have to document that right, but once it is there It is available for anyone else to see. So let me just go and see where Yeah What I've put in my release notes is actually what the customer is going to see So you saw this Which is the feature that I had added, you know the one that I had worked on basically it's on vsts Which is also available publicly, right? So after every sprint you can come here and see what we delivered Anybody in the world, right? Um So that's that's another cadence that you know, we follow as a team so um In terms of you know, how that is getting picked up and how that is getting posted is something that is internal to us But Here's what I would say. It's a very lightweight process that we have built and it's not even part of the product Okay Yeah, that's what I said like there's a lightweight process that we have built which is basically going to collect that And then publish to our, you know blog site. It's not part of vsts, but it's part of our process sure sure All right, um, let me just make sure So this is what I spoke about, right? We also made organizational changes because you Like it's not just about tooling, right? So what are the changes we made? We used to be a program management Uh development and a testing org, okay, and this might be a little sensitive But this is our journey, right? It doesn't have to resonate with you necessarily, right? So we used to be a program management Development test and each of them will be like a vertical reporting into you know the director Uh in each of these orgs, right? But what we realized was The challenge we had with that model was the accountability wasn't there I as a developer would write code throw off the wall and say, you know, it's testers responsibility Right test it is testers responsibility to test and provide the feedback And those three months I'm having fun time, right unless there is a bug And it's a tester who is basically testing it and once the tester is done He has thrown it back to the operations to say hey you go deploy. I have done my job, right? We wanted to break that we wanted to bring accountability So we got we we got rid of a test as a as a role or I would say, you know As a specialized skill instead we merged dev and test, right? And and that kind of became the you know, we used to have sdats sd is previously We don't have anymore, right as part of that transition We had to let go of people as well Because you know a lot of work was About manual testing and we had to let go of people as well And we also had opportunity for people to kind of free skill But we were clear we wanted to have you know automated testing, right A large part of it was You know manual and we wanted to drive accountability more important, right? It was about accountability what you write you own it, right?  This is how the team looks like this is This you know the standard we think 10 to 12 is what works for us Thanks to those guys, you know, they've tried to control their laugh While clicking that picture, but you know, that's a team that sits in Redmond Um So what happened when we made that change when we when we kind of you know merge the devint test We had a lot of tests which were manual functional tests and stuff, right? And we wanted to get that automated, right? So this is how a test look test scenario look like this is how the test landscape look like this is This is where we were previously This is where we are today now that l1 l2 l3 l4. I'll quickly tell you l1 is basically a unit test No dependency with anything no network. No storage. Nothing. It's just an independent unit test, right? We coined term for l1 as well because we had a huge dependency with databases. So we said We will have l1 tests which are basically just using a database, but we are going to run them very frequently Right. So that is what is l1 Then we have l2 which is more of an api kind of you know integration testing kind of scenario And then finally l3 which is more of you know functional functional testing ui and things like that Our belief is that we want to have as less l3s and l2s Compared to the l1s and l0 we want to be high on the you know l0s and l1, right? today we run about 70 000 tests every pr build so As a developer when I make a change when I send a pull request, they're going to be 70 000 tests running with that single pull request And it's includes both l0 and l1 tests, right? And there are you can imagine there are 150 200 runs happening In a day actually more than that Actually more than that, right? So that was a huge transition and you know Part of it is also because once we did that whole transition We wanted to basically have all of this automated, right? less debt in the system Yeah l1 is where back end comes in so we are a very heavy sequel, uh, you know dependent Service so that's where l1 comes in. So this is how the quality was before right where you would have these Stabilize and the debt has gone up. This is uh This is how it looks today, which is After every sprint You know, you got to make sure your debt is controlled. There is by the way a report I'll show you at the end of it If you have more than x amount of debt The the team cannot take a feature period. You cannot take a feature Right, so you got them put and that's again, um That's alignment autonomy What is that? Thank you Yeah, there's a lot of technical data It's a lot of productivity as well because what was happening is the code merging is also going to happen here If you look at the previous model, most of it is happening here Right, which means 40 different crews merging code here Is a You know, it's a pain, right now that is happening here The third week everybody merge Right and just to add to that. We have a very lightweight branching model So first of all, we don't use tf. We use get okay Internally and a lot of team use get and we accept it right get works for us. We use get right But What we do is we have a very lightweight branching model, which means there's only one master branch Everybody is going to take from master I'm not going to start my own branch And then work on it and then come back one fine day to say, hey, let's go and merge it, right Everybody has to work on master and everybody has to merge that small increment Right and once the master is ready to be taken for a release And we'll take a release right, so Yeah, when we do the release, it's a release branch action from where we are taking it, right? Yeah Yeah Right Sorry No, no because the deployment is You know, there are dris. Um, there are points of contacts for deployments as well So it's not that the entire team is basically involved in the deployment We have a small ops Operations team as well that works very closely Which is partly looking at the service health and everything else But you know, they do help around that as well. So it's During that one week. It's not that my feature crew is actually doing the deployment It's a dev response since you asked that Yeah, sure Um This is where we are getting queries from customers. This is today. Obviously. I've been here. They're 37 emails team is actually looking at it Uh And responding this is a developer He's actually responding. So the team is responding to the queries and then there is a di as well Okay, so I'm going to skip through this one because I already spoke about the you know, how people Uh, basically create branch and we have a light, you know branching model and then we basically merge Uh, the idea is also if you look at it, you know, the code is fresh in developers mind So if an issue comes I know what happened, you know, what I did two weeks back versus saying a six six months back I don't remember, right? I mean, we have hard time finding, you know, stuff that we place at home and stuff. So, you know Okay, so this is This is something that we do which is what we call feature Flag, right and this has helped us immensely because the next question that should come is What if I'm not able to complete a feature in three weeks, which is a common scenario? I I speak to ton of startups and One of the common problems that they face is that they say the timelines are driven by customer So if the customer says something has to be given in two months, we have a two month cycle The customer says three weeks. We have a three week cycle, right? The problem there is the size of the feature So we came up with something we call feature Sorry feature flag, right? What does that mean? Now assume this is my code, right? Which is today and it goes through a Like when I when I go to a particular page and access a feature it goes through this path Okay Now I've decided that I want to enhance this feature So what I do I actually start working on it separately in the same code base under a feature flag Okay, so feature flag is nothing. I mean if I were to say simply it'll be an if condition where my code would basically branch out Right, obviously there are optimization behind in terms of how we handle it at application layer Or the database layer, but it's simply saying that I'm going to branch it up, right? Now. This is not visible to anybody This is still not complete, right? Then what I my feature flag is still off for most of the customers they can't see it They can't see this workflow. I am continuing to build on this and I might just test it within the team as well right I am now ready because I've completed this feature But I am still not ready to release it to the customer for everybody as a default, right? So then what I do is at account level I can enable that workflow So in vst as account is like, you know, I as a user if I want a particular, you know a subscription with five users I would go and Uh register myself and create an account and then I can set up a team of you know x number of people right so Now since the feature is complete. I can redirect few users here Who can start testing it and providing us the feedback? It's still the same code base that is getting deployed, right? Now I am confident that this works for everyone Right and at that stage I might You know switch on the feature flag by default and now everybody is flowing through this Right, but my previous feature is still there It's still there. It's a dead also, right? And we don't let it Grow large, right? So what we do is we just get rid of the previous feature, right? And then this becomes the default workflow right and Trust me. This has helped us immensely because you can't complete a feature in three weeks. No, it doesn't matter. You would still have to check into master It would still have to be there in the in in the master It would still have to be deployed you come back in the next print start from there Right, it helps us in testing because you know, I can give you alternate flows and say you you know You are a certain set of customers who can go and basically test Uh, you know this new feature and give us your feedback, right? By the way, if you're using so this is just an example to say that I have enabled it for these two accounts For one I have enabled the feature the other one it is off So one would basically go through the flow and you know be able to see the new feature the other would It'll still be in the master No, so the the the point there is that unless that feature flag is enabled, right You don't go through that workflow and that feature. Yeah, that feature flag you could limit and say hey It's just going to be MVP. It's just going to be my team It's just going to be a few set of folks and if it breaks breaks because the whole expectation is that you know There is a new feature. You just want to have a look at it, right? Look as I said, we are moving towards L zeros I cannot move my code beyond pr Like I if I send a pull request it will get rejected if it doesn't have test Compliance so pr you can you can set the compliance And it will run all the tests if there are failures you need to go and fix it before you can you know move to ci so if So reviewers would not even look at it, right? The second thing is that When you look at our prs, we will have failures. It'll be around 70 75 percent So tests will fail there, right? When it comes to ci you will see suddenly that it is around 95 96 percent, right? Because you've reduced all your You know bugs within the pr itself, right? Which is your pull request, right? And by the time people reach to ci It's a much more mature You know service But we still have failures, right? We still have failures so In the interest of time. So this is also the last section Everything that we do we measure also right and measure on three parameters. We measure on operationally how it is doing we measure on business You know kpi is we measure on how that feature is basically being used, right? And every pm has a responsibility to basically look at that data, right? So instead of me showing you you know these slides which is basically our stats around the service and staff This is the root cause analysis again publicly available This is the dash, you know, this is this what software engineering uses so you can see number of large-scale incidents for every team number of You know the bugs that each developer has you can see red where we already know that you know people need to basically go and fix it Otherwise they can't move, you know proceed further. So these are some of the things that we track at operational level as well, right? um Few things that i want to show you before i get to the summary part which is This is our dashboard And it refreshed sorry, but those boxes that you saw there they are environments where all the code for master branch is going And it's basically testing for You know 10 to 20 these are all builds these are all the builds right and then we have You know, obviously some error. So this is the default for for an example an engineering manager to just have a look at How the quality is across all the environments, right? Since i spoke about Telemetry I mean this is just one of the features that i basically We enabled right and i can see actually how many people are actually coming and basically hitting that that kind of stuff So you need to know how the usage You know how your service is actually being used is it really valuable So there's a lot of focus on telemetry. I mean um This just to make sure that Everybody is basically telemetry is like a default Component of your specification. You got to know what you're building is something that you know will be used So every everybody has to do this so that is there from you know operational perspective business and other other You know aspects as well. I'm just thinking is there anything else? That I wanted to show you before cool so Yeah, perfect on time, right? Sorry, there's the deck. So we probably don't need the deck In summary We didn't do it in six months right We didn't do it right at the first place Right and we are not done yet, right? It's going to take time Right, it's a journey at every stage you have to figure out if there is waste Like we figured out, you know, we've been spending time on manual testing. Let's uh, you know invest in automation, right? You you got to like You know, keep it going because it's going to be a journey, right? And all I can say is all the best from microsoft for your journey And if there's anything that we can help with we would love to thank you so much


What advice do you have for early career professionals who want to get into publishing? Oh, okay. Great question. So I think if you're in your early career, I think one thing that's great to do is to get involved with professional associations like the International Society of Managing Technical Editors or the Council of Science Editors, Society for Scholarly Publishing, even Cope, you know, at ten meetings if you can. Sometimes these groups have webinars online. And then as part of the involvement, maybe join a committee. That way you really start to meet people in the field. You do a little networking and build relationships. And so that's one thing. Starting at the bottom some places where it really needs to be. And so you can survey the publishing landscape. If you're interested in books, you might move to New York City. If you're more association publishing, maybe D.C., Philadelphia areas. But then there's freelancing opportunities. And then education could be a component of it. If that's a field you're interested in, you could do something like a master's program like GW has just to get that much more experience and to get a real well-rounded view of publishing. But so yeah, I think it's just reaching out to people and getting involved in organizations. You know, finding people at meetings and talking to them. People who are a little more senior and, you know, talking to them about it. And then just starting someplace even at the bottom and just working your way up and see how it goes from there. So it can be intimidating that networking thing is always very intimidating and it's hard to do, especially when you're young and you're just starting out. But if you can find someone who is a mentor, that's a big help. And one last question. What do you think about this initiative of connecting scholarly publishing experts and researchers? I guess I would say I'm very interested in education and I like the publishing field a lot. I think it's very valuable. So anytime you have a chance to communicate that value, but also to shed a light on what you do because I think it is sort of a black box for people. It's intimidating and just to share with people that it doesn't have to be intimidating, that we're people like you. We're interested in this whole academic endeavor. We're interested in science and medicine and making life better for people in general. So having that opportunity to talk to you and to be involved in education is important because you're sort of ambassador for your field in a way and reaching out to people, making those connections. And then for authors, hopefully it's presented in a medium that's accessible and interesting to them and maybe you spark some ideas for them or gives them just that little bit of education that they need to make their paper better or to work better with their team of authors, to act ethically, all of that. So it really benefits both of us because then we know that we're getting good content from our authors because they're invested in it as well as we are. So I guess it's sort of conveying the fact that it is sort of a team endeavor, even though we're not at different areas, different places, coming from different places, we're both hoping for the same end products.


So, over the weekend this last weekend, I really had the hankering or inspiration to make some little custom doodle embellishments for my journal, our journal is going forward, not just for the My Year 2017 program. And I started out doing this little mason jar, isn't he cute? And I printed a whole sheet of them and then I sat in front of the TV the other night and I just cut a bunch of them out. Now, this was just plain white computer card stock. I got it wet, I put a couple drops of acrylic spray ink on it and that's the blue color that you see on there. Once it dried, I ran it through my printer and then I cut them out. I did some with the blue, I did some with the white. Then I was thinking about the videos for my year and I thought, well, I may or may not use some of these little mason jars, but holy cow, I have another idea. So I did another doodle. This time I did a thermometer. I did it, it actually was very large, I did it on my iPad and I reduced it down in size and I did a whole sheet of them and I sat and cut them out. So I have a whole bunch of them. So now I want to take one of them and I'm going to use, this tag is just a tag from clothing that I bought and you could use a store-bought tag, you could use a piece of card stock, use what you have. I like this gray side of this, so I'm going to use that side and I'm going to probably glue this down on here, but before I do, we're going to color our thermometer and I'm going to pull it up as high as I feel like right now at the moment. I'm feeling temperature-wise cold and flat or am I feeling warm and I'm going to think about not my actual temperature, but my mood. Am I in a cold mood and flat or am I hot and fiery and crazy and maybe annoyed or I could think about my artistic mood. Am I feeling flat with no inspiration or am I hot and fiery? Right now I feel like I'm sort of somewhere in the middle. Like, yeah, so not super hot on it, but not flat either. So I'm going to start by, I'm just using a light blue ink pad. This is one that I had and I just want to do this with a Q-tip because I want to kind of prove to you you don't need anything fancy. Use what you have, use a Q-tip or if you're in the UK you call these ear buds. Now this was printed on a just jet printer, so the black ink may run a little bit okay with that. If you're not okay with that, you may want to print these on a laser printer or you may want to, I'm going to zoom in so you can see because I just realized you can't really see what I'm doing, or you may want to cover the paper with a sealer. You could also probably do this with a crayon. And that actually, you can see that with the ink that ran a little bit. If you do it with a crayon or like I have the Jane Davenport watercolor markers, what are they called? Mermaid markers. I actually haven't used them yet. But use what you have, you could, I would do it with something that's not opaque because you don't want to completely cover up the thermometer doodle. I am going to sell these doodles in my Etsy shop, but if you're in the My Year 2017 Facebook group, you're going to get access to the doodles free in the group. So I got a little bit of that blue ink on here and then this is, I should really do this on a scratch piece of paper first. This is one of the markers. This is Byron Bay, I bet you have to take this spacer out. Yep.  Again, you want to use something that's transparent, not something that's opaque so you can still see the original clip art doodle through it. I do want to add a couple of little white highlights, except I need a pen that actually works because this one's not working. Grab a different one. There we go. The fatter one. OK, so that's cute already. So I have myself that at about 60 degrees in my artistic and creative mood. I think that's about right. So let's get this glued on here. This is Aileen's Turbo Tacky. I like it because it grabs quickly, but not too quickly.  I've got this box full of stuff that I never use. How many of you guys have that? I'm going to zoom out. There we go. No, I know I'm not the only one, but I want to put gems that reflect my mood. I want to just feel right. I don't know how to explain it otherwise. I'm thinking about my creative mood, what kind of creative mood am I in? I'm in a mood that I feel fairly creative, focused on getting my art business to make some money. The green stones kind of reflect that. I'm not super overflowing with ideas or inspiration, but I'm not completely lacking either. Mostly, that's because my world is kind of still topsy-turvy with the construction on my bathrooms continuing ongoing. It's hard to be creative when you have workmen constantly in your space, in your face all the time, but it's getting better. I think I like this. The same kind of gray background of the tag for me is representative of some of the blandness and frustration I'm feeling about the fact that the construction is taking so long. The colors on here really reflect the temperature of my mood, which is what I'm going for. Very much they do. I also have a box of brads, and I kind of want to stick a brad in the top. I have this one that has a little green on it that might be the one that needs to be the copper one. Yep. I'm going to just put that up there. My creative mood thermometer. I don't know if I want to throw that away, so we'll just put that up there. We're going to take the journal and we are going to put this probably right here in the front. The first thing I'm going to do is I'm going to clip all these open, because if I don't, it's going to slide like that while it's wet with the glue. Do that. I think we're going to put this, it'll cover up the owl a little bit, but that's okay. All right, so let's get that bunch of the turbo tacky on there. These are weights I used and I use them all the time in my room. You've probably seen them before if you've been watching my channel for very long at all. They are actually the ends from barbells, an old pair of barbells where the bar was threaded inside. You can see I took them off the barbells and I've been using them for craft weights ever since. I've had them a really long time, so I'm going to just put that on there so that it can dry and doesn't like go sliding around too much. Put one here. I'm going to take my pen, try to position the weights so that I can finish this part. Do my journaling here at the bottom. Okay, that's cute. I didn't know for sure what I was going to write until I was writing it. So it says, let me take the weights off really quick so you guys can see. So this month we're talking about hot and cold, that's our prompt, and what I've done is added a creative thermometer to my journal. And I did the journaling around it says, my creative temperature is mild right now, things will improve when the construction storm passes, that's true. And you know the quote at the top of the page also applies to this, if you believe you can you will. So so so so true, I definitely agree with that. I may write something right here too, let's see make sure our clips are, my creative temperature is never cold, but it's been hotter. That's also accurate. So I love that that's a great start I think to the month in my journal, I love it. So you guys think about downloading the temperature doodle and printing something out to use in your journal, you can print it whatever size will work in your journal, and if you would like a sheet of the downloads or of the mason jars, you can buy it over in my Etsy shop if you're not a member of the Facebook group. That's it for today, don't forget to check out the video description, there's a lot of stuff down there and the most important thing go out and have a great day, do something nice for yourself because you deserve it and I'll see you later, bye guys.


I'm Zeke and welcome to the Dream Green show. This episode is brought to you by Webull. Sign up now and deposit $100 and receive two free shares valued up to $1,400. It's free money, so why not try it out? In this video, we're going to talk about Apple's 4 to 1 split and Tesla 5 to 1 split exactly what does it mean and what does it do for these companies in the future. But enough talking, let's get straight into the video. Welcome back YouTube. So, okay, upcoming Monday, Apple and Tesla is going to display their 4 to 1 and 5 to 1 splits. Apple is going to split their shares 4 to 1. That means every one share that you have with Apple, you will be receiving 4 shares of Apple, but the price of Apple is going to be divided by 4. So if Apple was at $400, on Monday, Apple theoretically would be at $100 since that price get cut in half by 4. Tesla is going to have a 5 to 1 split on this upcoming Monday. Two big major tech companies is going to have a split and that is great news. Theoretically, a split does not change the value of a company just because you have more shares. It's actually valued at a cheaper price. So it doesn't change the value of a company. Now, historically speaking, this is my first split since I've been investing. If you guys been following this channel for a while, this is my first time in the split. So we're going to run this experiment together and learn from our first split. If this is your first split, as well, go ahead and leave a comment down in the comment section. But historically speaking, when they stock split, it outperforms the S&P 500 by 8% the first two years. So a stock split is actually a pretty good thing. It doesn't change the value of a company at all when they split. But many investors, when they're looking at Apple and it's $500, a lot of small investors really can't afford a $500 share of Apple. But when they split that stock by four and the price is around $125, they can buy one or two shares worth of Apple. Tesla's up in the $2,000. Many people, if you didn't get in early on Tesla, I own a share Tesla. If you didn't get in early, Tesla would cost you around $2,000 right now. But when I have this five to one split, you're going to be like, wow, okay, let me go ahead and grab a share to Tesla while the price is low before it goes back up. So that's why companies have a split for a lot of small investors can buy into that company. If there are a lot of people out there like me that don't have $2,000 to throw out to buy share of Tesla, then now would be a great time to pick up at least one share of Tesla and at least one share of Apple. If you can on this upcoming Monday, if we take a look at this chart right here that I'm going to pull up on the screen, you guys can still see that, yes, ever since 1990 when stock splits, they outperform that counterpart, they outperform the S&P 500. So stock splits are a good thing. So I'm going to pull up my Ribal Hood account right quick, but I'm letting you guys know on Monday when Apple splits and when Tesla splits, I'm going to throw all the money that I have left in my Ribal Hood account into these two companies and buy up as many shares that I possibly can. That's what I'm going to do. You don't have to do that. You can sell Apple, you can sell Tesla if you want to, but me personally, I'm going to try to pick up a couple more shares while the price is affordable for me. But let's go ahead and dive into my Ribal Hood account to see what would the price be on this upcoming Monday. All right, guys, here we are on my Ribal Hood account. My account is at $27,000. Wow, I never imagined that it would be that high. Over the past week, I'm up 2.75%. I'm up $723.44. So I had a pretty solid week when it comes to investing into the stock market. Let's open up this free stock. If you guys want a free stock of Ribal Hood, all you have to do is click the link down in the description. Just sign up and then you'll get a free stock of Ribal Hood just for signing up. Let's click D1 in the middle. I got DDD, 3D Systems. That is worth $5.41. Thank you. All right, so let's go ahead and pull up Tesla right quick. All right, so Tesla, I own a little bit over one share of Tesla. I did buy a fractional share of Tesla, but let's just say I own one share of Tesla. Tesla is at $2,217. I got in at $638.07 and I have a profit of over 247%. So I got very, very lucky by getting on Tesla early. I'm up $1,683.93. Now remember, Tesla is having a five to one split. So let's see, what would the price be of Tesla on Monday at its current price right now of $2,217. So $2,217 divided by five. So if everything plays out, how we think is going to play out, Tesla is going to be at $443.40 on Monday. So that's even cheaper than the price I bought Tesla at $600 at. So I would definitely try to pick up a share of Tesla while the price is at $443.40. Let's go ahead and take a look at Apple and see where would that price be on Monday. Okay, here we are on Apple. Apple is at $502. Crazy how both these companies are pretty much at an even dollar number, but Apple is at $502. I own almost half a share of Apple, 0.46% of a full Apple share. So I wasn't able to buy full share of Apple. Like I said, Apple is getting very expensive and I got in at $347. I'm up 44% on Apple, up $41.38. So let's see what would be the price of Apple on Monday with a four to one split of $502. So 502 divided by four. So Apple on Monday should be around $125.50. So I'm definitely going to grab a couple shares of Apple while I can. So yeah, guys, that is my plan for the weekend. I'm going to pick up Apple. I'm going to pick up Tesla and I expect that these two companies are going to gain a couple percent this week alone coming up on Monday when they have that split. Let me know what your guys are going to do down in the comment section. Me personally, since both of these stocks are going to be down below the price that I initially bought into these companies, I see them at a pretty good value. I can see that these companies are going to continue to grow. In fact, this is not Apple's first split. They have split back in the past before and they continue to grow and raise that company value every single year. And I can see Tesla doing the exact same thing. Hopefully Tesla is not in the bubble. But anyways, let me know what you're going to do down in the comment section while you're down there. Make sure that you hit the thumbs up on this video. Hit the thumbs up really helps out this channel a lot more than you can even imagine. And while you're down there hitting buttons, make sure that you hit the subscribe button and the notification button so that you don't miss out on any future videos. But other than that, I'm Zeke, I'll bring you the Dream Green Show and I'm out. Peace.


SCP-13 is the collective designation of 242 cigarettes, which display similar anomalies. The most common external detail between instances is the presence of the words Blue Lady, hand written on each cigarette in blue ink. Subjects who consume the contents of SCP-13 through inhalation will begin to perceive themselves as a specific unidentified woman. Subjects have described the woman to be aged between 25 and 35 years old. Shortly after consuming an instance of SCP-13, subjects will gradually begin to perceive reflections of themselves as having the features of the woman, and will gradually perceive their bodies changing to reflect her appearance over the course of the following weeks.


back to the reflex. All right, here we go, eliciting stimuli. So the stimulus elicits the response of, pew, out it comes, right? In reality, it's not one single stimulus, it's a class of stimuli, right? So there's a lot of ways to puff air into my eye. Just a paper here, I'm going to puff some air into my eye in one way. I blink, right? You could sit there with a turkey-based drink, and I would blink, right? It's all a class of stimuli, puff of air. It doesn't have to be the same kind of air. It doesn't have to be the same temperature air. It doesn't have to be the same color air. It doesn't have to be air. Just stuff blown into your eyes, right? And then you'll react to that. So it's a class of stimuli. So something blowing at you will then cause your eyes to blink, or getting dust and things like that. That is associated with a corresponding response. Now here's the thing. The way the reflex works is that you've got a stimulus and response. The response, in order for it to be a reflex, needs to not really be happening very often without the stimulus present. What a wishy-washy way to say that. Basically, the point is, is that these responses like blinking your eyes, all right? I can do that without the eliciting stimulus present, but it's often not going, more often than not, it's not going to be the case. I'm only going to blink my eyes when a couple of things happen, when I need to moisten my eyeballs, I guess, my brain detects that, or when there's a puff of air to it. So that's one of those important things about the reflex, is that those two things are tied together really, really closely. Of course, we can talk about all the sensory neurons and the motor neuron, afferent, afferent neurons, blah, blah, blah, blah, blah, all that fun stuff. So you get the sensory neuron, picks up the stimulus, and motor neuron, the stimulus goes, bounces around the body. Sometimes it just goes through an inner neuron before the signal gets to the brain. Sometimes it goes all the way up to the brain and back down. All depends on what type of reflex you're talking about beyond the scope of this course. Oh, I guess I have inner neuron on here. I should probably put that up there. So again, sensory neuron picks up the signal.  Well, the first thing that's going to happen with that particular case is that the signal is going to go up my arm, right? So up the neurons up my arm, and it's going to get up into my spinal cord. And then when it gets up into my spinal cord, it's actually going to make a quick jump and jump right over the motor neuron. That jump is done through what's called the inner neuron, right? So that jumps across into the inner neuron and right back down. My brain didn't even receive the signal that it's hot before my hand pulls off. That's a cool thing about a reflex, right? Sometimes, not always, but sometimes the brain doesn't even need to be involved.   But those are not the reflex. The reflex is this, the aching your hand back. And you did that without thinking, right?  But in order to keep your skin intact, you have the reflex happen quicker by using that inner neuron. So it shortens the reflex arc, if you will. So those three things, the sensor neuron, the motor neuron, the inner neuron, all sorts of things involved if we really get detailed, those form the reflex arc. Those are your three basics. So that's the reflex. We're going to look at reflexes in a little kind of a little more detail.