How To Become An Outstanding Chief Technical Officer

1. Course introduction: congratulations with your role as new CTO for your organization. Or maybe you were not CTO. Yes, your inspiring CEO Ahn's You are preparing for a job interview or you're expecting an upcoming promotion. But let me ask you something. Are you ready for your job? Are you ready to be a great CTO? Because being a CTO is really, really hard. It's a very difficult role on. The reason is that as a CTO, you are responsible for all technology in your organization. You are the public facing executive responsible for all tech in the organization, but you're also responsible for your team. You are responsible for the development process. You were responsible for the overall technical architecture in the entire organization. You are responsible for every single technical product on projects in your organization. You're responsible for customer satisfaction of all the customers using your products on projects. The list goes on, so it's a difficult role. A recent survey has found that off all CEOs for executives of people being promoted into an executive role, 33% doesn't make it into the second year. So please don't be part of that 33%. But don't worry. I'll help you. In this course, I have compiled 15 CTO leadership PACs that will help you become a great CTO on. Make sure that you do survive into your second year. So what we're gonna do, we gonna start with something I like to call a started prep. So this is a set of exercises that will help you get into the right mindset to gets off to a great start in your role as a CTO. Then we'll move on to situational awareness. So I will make you become aware off the political and vitamins in your organization. We will identify all stakeholders that hold power over you on. We will investigate what the stakeholders expect from you. Finally, we move on to your team and your development process. We will take a long, hard look at both your team and your process on. We will turn them into a well oiled machine that can assure in out products after products after products. So this course contains 15 lectures, one natural for every city. A leadership pac, aren't There are quizzes at the end of every section to test your knowledge. So are you ready to become an outstanding CTO, and this is the course for you. I created this course specifically for people like you who are CEOs who are new sitios on. I want to bring their skills to a higher level or they are aspiring. City else were preparing for a job interview or for an upcoming promotion on Want to make a great impression on their organization. So thank you for listening. I look forward to welcome you in the course. 2. Hack #1: don't underestimate the job: so today your homework is very simple. I want you to, um, practice, Um, a bit off humbleness in your new role. Um, you're starting out as a new roll CTO on. You might feel maybe feel a bit intimidated because this is your first. See if your role Or maybe you have bean cto for, like, 10 years thistles. Just routine. You're not really worried about it at all, But I want you to, um at least be aware off the statistics. These statistics are not in your favor. If we look at new hires, new executive see section hires on We look at executives that are promoted internally. So these could be architects promoted to CEO or, say, a seat Oh, promoted to C. E. O. So people promote it into the C section. Then the failure rights is 25 percent, 25%. So after 18 months in the new job, 25% off, these people have failed. They are no longer able to perform their job. Let's be high. That's one in four. So these all this are working against you. It gets even worse for external hires. So, for example, these are people CEOs, the CEOs who have being pulled in from the outside, so they have no experience with the company culture company environment. The literally literally dropped into a new company on these external hires again. After 18 months, there is a failure right off 33%. So obviously this rate is higher than the 25% because these people come in from the outside so they don't they They don't understand the company culture they need. Teoh familiarize themselves with the company process the industry. Three employees. The political dynamics off the off The job on this is much more complicated if you've worked at this company for 10 years and you get promoted up to CTO, so for external hires the bar is higher. It's harder to do the job right on. 33% fails after 18 months, so I have no idea if you're an internal hire or an external higher. But be aware of these percentages. 25% and 33% obviously is 1/3 so only 2/3 awful executives are still on the job after 18 months. So what I'm trying to say is this job is hard. It's really difficult to be a successful CTO in a large corporation. A large organization on day to excel at the job, do the job, right. That doesn't mean that you're going to fail, obviously. I mean, in this course, I'm gonna help you through, Not fail. Um, but I would like it to be humble to realize that the job is difficult on that it is going to take hard work and dedication to not be in this 25% or 33%. I'll give you one statistic. If we look at executives, see section executives that survive into their second year. So they have successfully completed the 1st 12 months off their job on bond. They still have a job in their second year. That is 67%. 67% of all executives survive into their second year. So obviously we're gonna make sure that you are part off that 67% 3. Hack #2: onboard yourself: today. What I'd like you to do is on board yourself. So what I mean by that is, um a lot of corporations they actually do not have on boarding procedure. Um, if I look at my career, I've been in I t. For more than 20 years. More than two decades on the last time I was professionally on board it in a large organization was 1995. So you can imagine. I've seen a lot of companies after that, and they have no on boarding whatsoever. The on boarding is that you start out with a new organization on their roll out the red carpet for you. You get invited into tons of meetings, material documentation, papers, presentations. People love this. This there is you this process, this intense presentation process to get you up to speed to get you completely embedded in the organization as quickly as possible. So the last time I experienced that was with CMG, a corporate consulting firm in the Netherlands where I just started out in 1995. Junior consultants on today gave me a three day training program intensive training program , lots of meetings, lots of presentations, lots of homework documents to study on. It really got me up to speed very quickly with the company culture. Now, I'm betting you're a CTO in a new organization on your organization. Probably doesn't have a on on boarding procedure or it has one, and it's really simple. It's just four or five meetings, and that's it. So you're gonna need a lot of information to the job, right? So you have to onboard yourself. This is fairly easy because you're the new guy. When your girl people will want to talk to you, they will want to tell their problems to you. They want to explain to you how the organization works. There's gonna be a lot of good real in your first week, and you can exploit that court well by meeting with as many people as possible and really pick their brains. So I've created a list off people that you can focus on during your on boarding process. First of all, the first thing that you want to do is create plum so right down the information that you want to uncover in the organization. What are you interested in? Whether your gaps in your knowledge that you want to talk to people about? Make a list of people that you want to talk to to make sure that your list contains at least your boss, which would be the CEO so talked with CEO on. Find out what are his priorities. His or her priorities, challenges and expectations because they will determine how you will be judged in your roll . CTO. Then talk to your direct reports, people that report directly to you. So this will probably be the architects, the VP of engineering, the project manager. Maybe there's a functional designer in the company. All these people will be reporting to you so talkto them on. Let them know how you would like to be briefed in future conversation. So give him a glimpse off what your expectations will be when you talk to them in the future. On also check. If anything is on fire like, Is there a calamity? It has something broken. Our customers unable to use the system is the live connection with the bank offline. Nobody come use the system anymore. Salesforce stopped working. See if there's anything with fire so that you can hit the ground running and you can start your you can start your roll is a firefighter. Basically, make sure you meet with security I t h. R and facilities for the usual stuff. Your log In accounts for the company system, you will want to badge to be able to enter the building. You're the alarm codes. You want to know the building procedures, simple stuff, like lunch arrangements. Get up to speed quickly with with that kind of information, then also, don't forget to meet with C f O. Because you want Teoh get a quick rascal finances. You want to know What's your budgets? How do you love your expenses? How can you view financial reports from the company system like, How can you get a monthly expense reports for your department? You want to be able to do all these things yourself. So you want someone to show you the financial systems and get you up to speed. And of course, you want to know the numbers like, What's your budget? What your expense budgets. What's the like, your predecessor? What was the income per month off your departments? If if your if your role involves direct revenue director reviewing home eso get those financial numbers from the CFO, then try to talk to important customers, major customers that use your product or your application. Are they happy? Which version of the upper using, however, using the app. What's What's the vibe? Other customers about to go to a competitor or are there still happy and loyal to you? So at least get a feeling off off how content these people are on finally talking appears. So you're in the C section. So I talked to the CFO seat. Oh, uh, old, all the people in the C section on find out what are there really that worries will ever play up Priorities. One of their challenges. What's going on in the organization? Because our CTO you will be responsible for I t systems. And a lot of these systems are built specifically for use by the other by your peers in the C section. Eso maybe your team, maybe your predecessor has used the deaf team to create a financial system. Now the CFO is using that system. So what are the challenges off the CFO? Is everything working fine? Are there certain reports that cannot be created because the system would allow it. Is the organization using a budgeting model or the finance model? And there's no way to lock that into the system like they're using. Salesforce on expenses cannot be ends with in Salesforce because it's been configured incorrectly to try to see if you can find his pain points in the organization very early on that you could fix by rolling out I t. Solutions in the future. So that's in a nutshell. How you can onboard yourself in the organization credit plan decides what information you are interested in. What are you trying to uncover in the organization? Who are you going to talk to on? Then? Just book yourself into these talks one after another talked to as many people as possible . 4. Hack #3: get to know your team: today. So today what I'd like you to do is get to know your team on when I say team, I mean all your direct reports on maybe one layer below. So get to know all the people that you will be interacting with in the future as you perform your role. A CTO in the organization. So your team, I mean, depending on how the organization was structured, your team, there could be several types of people. Like, if you're running a small start up your CTO, then you probably have a lead developer in a couple off developers. That's the entire team. If you work for a huge multinational, then you're gonna have lots. And lots of people have architects, project managers. You're gonna have developers, you have an extra piece of engineering answer one and so on. So affairs a list off roles that you will probably interact with. Its a good exercise to start by seeing if these people actually exist in the organization. So let's go through the list. Eight people that eight different roles that you can expect in small and large organizations on if these roles are missing, then that's also an important clue, so to start out the lead developer. So the lead developer is the person responsible for managing and caution developments. Team. So the lead developer is usually the most senior person in the development team. The most able developer thats present will have management skills will be responsible for managing the deaf team. So basically taking tasks and distributing them over the team, assigning them to individual developers based on their level off knowledge. So the lead developer will need to know from anyone in the team what their specific skills are. If there isn't any developer, that's a bad sign because development team needs to be managed. It works best if the senior developer does that. Eso without a lead developer, you're looking at a deaf team without a leader, so that's a red flag. Second, the architect theme architect is responsible for creating the high level technical design off everything that is built in the organization. So the architect is not programming. Thea architect. It's not a developer. He or she is not producing lines of code, but the architects produces high level diagrams off how large microscopic software components will fit together. Eso these will be architecture diagrams basically describing the software, the applications in the entire enterprise. Um, architects. They were a distinct role because they only look at high level functionality. They don't know any coding, which is low level. They only create these high level abstract diagrams on. It's very hard for a single person to do both a low level on a high level job at the same time, because it requires a kind of a mental context switch on. It's hard for people to achieve that. So if there's no architect again, that's a red flag, because that means that if someone else is doing the architect ing, probably that's the lead developer. So then you have one person doing the low level stuff on the high level stuff at the same time, and that never works. So make sure the organization has an architect. Then Number three, the Scrum Master three organization. I hope the organization uses agile for their projects, managing methodology aunt. If they scrum, there will be a scrum master, and this is basically a facilitator who make sure that the scrum process runs unimpeded in the organization. So if there's anything happening, political or technical or whatever in the organization that impedes the scrum process. The scrum master will make sure that these impediment is removed so that the process can continue unhindered. If there's no scrum master than the organization is probably not implementing agile eso again, that will be a red flag if you work for an organization that says they're doing our job. But there's no scrum. Master Number four is the product owner again. This is a role that belongs to scrum. The product owner is the person who determines the functionality off what is being built on bond. What order Different functionality is being built. If you have a large project, a large puddle doctor large publication being built than the product owner will be responsible for deciding what is built like what the functionality of the application is in detail on in what order is functionality is being built by the deaf team, so it's an important role, and again it belongs to agile so again, an organization that says they're doing agile. There's no product owner, a red flag. You will want to see a quality assurance department, or Q. A quality assurance is responsible for testing. There's very important because software is quite body in general on it needs to be tested extensively to make sure it's fitful production on developers cannot test their own codes because they have a blind spot for thief functionality. If you ask a developer to develop a test for their own coats, they will not create a complete test because they will. I'm. It's hard to explain, but they have a blind spot for the functionality off their own coat, so they will not create a test that has 100% test coverage because they will conveniently forget to test specific bits of functionality is much better if a test is created by a group of people like a team completely independence from the development team. Andi, if we're talking about acceptance, testing, testing. If the application, as a total works correctly on conforms to the expectations off the customer, then of course, the tester will need to be either the customer or somebody really close to the customer. And again, it can't be a developer, so usually these people are combined in a Q A department. If there is no cure A departments, it's a red flag because it means the organization might not spend a lot of time testing their products, so that could be a problem and issue with quality. With products quality, there's a develops manager. Devils manager is responsible for rolling out new versions of the products of production. Eso. If everything has been set up correctly, there will be like a development environment, integration, environment, staging environments and production environment on develops is responsible for creating all these environments on moving products from one stage to the next. So moving codes from staging to production on if something doesn't work, moving a faulty version off a product from product back to staging so that an older version can be restored so that helps is really important. If there is no develops than rollouts to production is probably a manual process and owned by the deaf team on again. You don't want this. You want people specifically responsible for infrastructure and responsible for rollouts of new code versions and rollbacks. In terms of a calamity, there's gonna be a project manager responsible for project planning on setting milestones on monitoring progress on escalating when something unexpected happens, So that's really gonna be a project manager. I've never seen an organization without a product manager, So this probably roll you will and council. And finally, the SPP off engineering s VP of engineering is your right hand man or woman. It's basically the person who is responsible for executing your vision inside the organization. What I'd like to say is that the CTO role is kind of split down the middle. The CTO you are responsible for evangelizing the technology of the company outwards to the press, to the media, to customers. So you're the public facing, um, head off the company responsible for technology are the SNP off engineering is your right hand man of woman who is responsible for expressing for broadcasting the same vision into the organization. So this is really important that you have a good relationship with the S a p of engineering . It is possible that the role is missing on the organization. That's not a bad thing. Usually means that the organization is very small on that they will expect you to be both Evangel eight evangelizing outwards on inwards. So basically, you've lost your right hands amount of on you also have to minus your vision within the company you have to do that same role, so your role will be a little bigger. If you don't have an s VP of engineering, it's gonna tell. So you see this role in some organizations, you don't see it in others. It all depends on how the company is structured. So these are eight rolls that you will encounter in your organization. Your homework for today is to get to know these people, sit down with them, have one on one meetings with them. Find out what the challenges are, what their priorities are, what they worries. Whatever proud off. Just book 30 minutes with each person on bond. Find out what's what's going on in their life. 5. Hack #4: pick your Agile method: today. What I'd like you to do is finance what kind of agile methodology the organization is using . I'm going to assume that the organization uses agile because agile is a lot more efficient on a lot cheaper than using traditional project management methodologies. Traditional methodologies like STN, which are based on planning up front and then doing the work, then testing at the end. Agile is much more in line in tune with the with the idea with the philosophy that software is inherently unpredictable. That's softer developments. ITT's almost impossible. Actually, it is impossible to develop complex software. Aunt plan Everything meticulously off front, there simply are going to be calamities. They're going to be failures on unexpected setbacks happening in the middle of the project , and it's pretty much impossible to see these coming in advance. So for software development as a CTO, I urge you to embrace agile, to embrace and agile project methodology. That's, um, um, my Scientology that's realizes that unexpected stuff will happen. So our joy he's an umbrella term for a lot of different methodologies. On there are three big ones that you will encounter in I T organizations, and they are XP, which stands for extreme programming. It's the oldest. Are your methods better? Scrum Tom that is Come So XP scrum and come back on these methodologies. They all have pros and cons, so I've created a matrix, which compares the three methodologies. So if you look at The Matrix, you could see that six P has bean designs, mainly for software projects. Well, actually, it has to be designed explicitly for software projects. You can only use XP on software development projects. We look a scrum. It is mainly software projects you can you can shoehorned scrum into different fields into different sectors, and it will still work. And then there's Cambon, which has been explicitly designed for any type of projects. So come on, there's no link between come bone and saw for development. So if you're in a software company, you can basically pick any one of these three. But if your team is not primarily doing software development but they do something else, then your best choices come on. If you got the team size again, come on stands out because it can handle any team size. There's no limits built into how large team can be Expedia and Scrum. Both the kind of matched out of 10 members experience 10 members and scream at nine members . So if you have like a department of 20 people and using scrum, then you're basically forced to split them into two teams to keep everything manageable on with combine. You don't have to do that. The alteration life, how long it takes until a new version off a product is available also varies a bit with experience to the three weeks with scrum, it can be anything less in a month with combine. It's one week. The next one is important. Both Expedia on scrum half very specific roles that go with a methodology. I mentioned some of them before, like the scrum monster, the scrum master Israel specific to scrum product. Older is also a role specific scrum. So if you want to introduce scrum in the organization, then you will have to designate thes rules to people. You have some points someone and say, you know this crumb monster would come down. You don't do that. Condom use is the existing roles in an organization to implement the methodology, so there's no need to give people different hats. So if you need an organization that's kind of resisting, agile when it's it's hard to get them toe adults a job. Come bone is your best pick because you can simply layer combat on top off the existing rolls off the team. Then I'll quickly go to the remainder. If you look at virtual teams, can you run this online? It's speak. Cannot run online. XP will only work in an office with everybody in that same office. So this is quite a quite a impediments because now days we see more and more distributed teams with people all over the world. So if you have that kind of organization, you're gonna have to use crumb or come back. The risk mitigation level is also very spare. Mythology scrum Massey highest risk mitigation, so scram is explicitly designs to completely minimize risk during implementation. On both XP, Cambone are less so they're less rigid. The methodologies are less regents Onda. As a consequence, they are slightly more risky. Aspinall customer interaction. If you look at customer interaction, so how deeply embedded is the customer with develop development process, then XP has extremely high customer interaction, the customer is basically a member of the deaf team. Andi. With scrum. The interaction is lower. There are, um, meeting points are moments when the customer has to interact with the team. But it's not like every day, like with XP on this come down. Customer interaction is very low. So again, if your customers are not really willing to help you develop the next version off the products that they were willing to come for acceptance tested only once, and then you know it has to come again. It's just too much trouble then Combo is your best pick because commonplaces to least demands on your customer. If you have customers were willing to participate in R and D, then you can use chrome on if your customers internal. Then you could consider implementing XP. So in a nutshell, this is how the three different, agile methodologies compared with each other on gun, you need to use this information to pick the best methodology for your new role. If the organization is really using the one of thes three methodologies, then keep your eyes open. See if allow these criteria if all the criteria correct, So if you're in an organization That it up Scrum. Keep your eyes open and see if scrum was actually a good choice on if maybe come back would be better. You never know. 6. Hack #5: is anything on fire?: okay today, I want you Teoh, Look at the organization on, See if anything is on fire. So what's a fire? Fire? Could be a product that has stopped working. For example, in online system used by thousands of customers on people can no longer Logan Logan function stopped working. So this is a big calamity. Of course, nobody could use the system. Eso phone calls of your customers coming in customer support Customer support is getting overloaded with angry calls. You're losing thousands off those of revenue per minutes on. Something needs to happen right away. So this is obviously a fire situation. You need to get in there, grab a hose and start squirting water on the fire to resolve the problem. The fire could also be a leadership issue. It could be a leadership anti pattern where, for example, a team is dysfunctional or two very powerful stakeholders have started feuding on our sucking the entire organization into their conflicts. On all progress has come to a complete standstill. It could be organizational. It could be that the organization has adopted scrum on and the management is blocking scrum . They don't believe in agile and they are obstructing the process. So the sprints are being run. But the deliverables at the end of the sprint are not really changing a lot. There's no forward progress anymore. So something needs to be done way. Maybe the scrub monster wildfires on nobody has replaced him or her, so part of the organization could be on fire. However, now, what is a fire where you are expected to immediately jump in, start, start helping to put out the fire on what kind of fires Could you just leave for a while and not focus on right away? Because you can't really afford to get sucked into these thes calamities this fire situations on then get stop there permanently. So there's a simple system that you can use a very simple matrix that you can use to decide which fires you're gonna put out immediately. Which fires you will leave burning for a little while while you get up to speed in the organization. The only thing you need to do is creating matrix three by three matrix like I don't right here on, um on the vertical axis puts the likelihood that a certain risk is going to happen. So we're going to look as potential calamities on. Look at the likelihoods. It is very unlikely that something's gonna happen. Is it likely, or is it very likely that something is going to happen then, on the horizontal axis? Put the impacts off the calamity. If this this calamity were to happen, what's the impact? Is it a minor impact? Minor impact Meat's annoying as hell, but you can live with it. Is it a moderate impact? Moderate would be essential. Functionality has stopped working, but there is a workarounds so super annoying workarounds super slow work around on expensive work around. But there's a work around. People can still use dysfunctionality. Or is it a major imparts? A major impact would be a specific bit of functionality I stopped working on. There is no workarounds. There's absolutely no way Teoh get this functionality through any over means, So it has basically disappeared. Now, if you look at those two dimensions, then off course, a very likely risk that has a major impact needs to be dealt with right away. So that's your first priority. Identify the very likely risk in the organization with a major impact if you can identify that. Then get right in there to mitigate that risk right away. First thing you if there is a likely risk with also with the major impact, then you got a deal without next. Your first gonna put out this fire on. Then you want to look at this risk. If you are dealing with a very likely risk, very likely calamity, that has only a moderate impact. Then you are going to contain that risk with contain the risk. I mean, you're not gonna solve it. But you were going Teoh. Look, in this work around, there is a work around to get around the problem. You're basically going to make sure that this workarounds will keep functioning will keep working for the next couple of days for the next couple of weeks. Once you have that garden, see, you can basically relax on, Say, you know for sure that this moderate risk, it's not going to suddenly turn into a major impact risk. Everything else you gonna ignore. So unlikely calamity with major impact you don't ignore. You will be aware of it. But you're not going to deal with it right now, Andi. Anything which is unlikely, but minor or moderate impacts. You can safely ignore anything that is likely with a minor impact. You can safely ignore anything that is very likely with a minor impacts, likely with the mothers impact. What unlikely? With a major impacts, you're also going to ignore it for now. Gonna put it on your list, write it down so you're aware of it. But you're not going to wait in rise in the first week off for a second the 1st 2 weeks off your job to put that out. Because obviously, if you will focus on this whole matrix, you will be permanently locked into firefighting mode. You don't want that. So to summarize, put this plan. I was right away. Put this fire out next and contain this calamity so that the workarounds will keep working for the next couple of weeks. These three risks be aware of thumb. Don't do anything about them as these risks you can safely ignore 7. Hack #6: who are your stakeholders?: today we're going to focus on stakeholders. We want to look at all the stakeholders that directly or indirectly influence your role in the organization on what I want to do is split the stakeholders into groups, so we're gonna look at ordinary site colors. We'll also look at power holders, power holders, stakeholders which they wield a certain amount of power. A large amount of power over you over your team over you over your ability to function. So power holders are the subset of stakeholders who can make a real difference in your ability to deliver and reap rewards on beware. This difference can be positive or negative, so power holder can really help you achieve your goals. But in obstructive power, Holder can also completely block your progress and set you up for failure. So it's really important that you become aware off this this political landscape within the organization who are the power players on and what's do they want? What are their goals? Were their ambitions and the align with your own goals and ambitions. So the Ford power holders that you can focus on our first of all the people directly above you that will be your boss, the boss off your boss. The board of directors. So these people are directly above you. They wield an enormous amount of power, Onda. And they can make your job easy or really, really difficult. So much these people write them down. Who are these people? The second group of power holders are the people above you in the organization who will panic if you fail to deliver. So if you commit to a delivery and for some reason you cannot make that commitment, something goes wrong. Who was freakouts? Who would start calling you leaving? You angry Voicemail. Missing messages. Who would freak out above you in the organization? When this happens, this again is a power holder because that person is above you. Write their names down. Who are these people through its once Which people in the organization. If imagine that the imagine that these people would quit for a month. They would suddenly announce that they're going to take a one month sabbatical and they leave for the next 30 days. They're gone onto their absence. Destroys your ability to live, to deliver. You are no longer able to deliver anything because these people are gone. So there's a very strong dependency with these people, so they don't have to be above you. Think this could be a developer? This could be a senior developer with crucial knowledge within your team. When that person leaves, that knowledge is gone for 30 days on, you can no longer do anything. It could be your develops manager, the person who can roll back faulty releases, only production environments without your develops manager. If nobody knows how to perform a rollback on, something bad happens. Then your whole system goes off line and there's nothing you can do about it. So these are people that you are singularly dependent on. Who are they? Write it down. Write down as many names as you can think off. So these air power holders and they can be below you and the fourth group who needs to cooperates with you or your team in order for you to meet your goals to meet your commitments. So whose cooperation is necessary for you to be able to do your job? Um, think of as many people as meaning names you can think off on right down to these four groups together, the power holders these people reels power over your ability to deliver. Eso were not yet mitigating this power were not yet doing a risk analysis and making sure that nothing can go wrong. For now, the only thing you need to do is be aware off these people be aware off their names on what kind of power their wheels over you, the remaining stakeholders, normal power holders and also very interesting. For example, who was passed over for your job? You're the new CDO who almost got the CTO job. But at the last moment, the company decided to hire you. Notice all the person This is a stakeholder on it. It is a stakeholder who could make your life difficult in the future. Or maybe knows maybe you can have an excellent relationship with this person, but you need to know who this is. Who are the junior players in the organization who want to hitch a ride along with you? Like for example, this could be the s u p of engineering was going to closely work with you. Hitch a ride along with you. Use your success. Put that on their resume Maybe use this to become CTO in the future for a different organization. So who is along for the rights wants to bask in your glory. Basically beautiful. Look at internal customers or consultants that used to work with the team. So people who still have a relationship with the team out of past history, who are they finally identify anyone else who is relevant to you. You're old or the team. All these people together are the stakeholders that's can influence your ability to deliver your commitments. So you need to be aware off these people. So write them all down, creates a stakeholder plum or a stakeholder least on basically Brighton on the names. Just distribute them in groups. So have your power holders in the separate set of groups. Half your normal stakeholders in groups. Be aware of all of these people, so that's when people start to work against you in the future. At least you have month amounts in advance on You are not surprised. You know that is the person who was passed over for my job Off course, he or she is going to sabotage my progress a couple of weeks down the line. I'm not surprised. Actually, I prepared for this calamity, so be prepared 8. Hack #7: find out what matters to your stakeholders: So today we're consul refined the list off stakeholders we created yesterday. So by now you have a list of stakeholders in the organisation and you've groups in power holders, noble stakeholders. So these are all the people in the organization who can influence your ability toe to deliver your commitments on today, we're going to look at what is important to the stakeholders what matters to the stakeholders. Because by knowing what matters to them, we can accurately predict if they are going to be working for or against us in the future. On we can predict what we need to do for the stakeholders to keep them as a friend. So we're basically going to look at the power dynamic in the organization, so to speak. So I want you to create a new document. Andi, this is going to be kind of like a stakeholder force field. So we're gonna look at all the stakeholders. Are we going to look at what matters to them? So let's get started. So I want you to I want you to right down five things for every stakeholder. So you can do this in the spreadsheets. You can make a stretch it with all the stakeholders in the first column on. Then you make five additional columns and you go to write down these five suspects for every stakeholder. So, first of all, how are they rewarded? On what basis is the stakeholder rewarded? So what are they? What do they need to do to be rewarded? Do they need to stay in budgets? Do they need to maximize customer satisfaction? Do they need Teoh? Dominate the industry? Stay out the number one position in the industry so they need to maximize profits? Do they need to maximize revenue? How are they rewarded? Write that down. If you know it, then look at importance, which rewards are importance. Toe these stakeholders. So what kind of rewards would be important to the no mystery expectations? Write down. What's the stakeholders expect from you? If you don't know for sure, Take uneducated guess or maybe you could even ask him. So find out what all of the stakeholders expect from you. Then write down what you need from the stakeholders. The's stakeholders that could be power holders. They could be normal stakeholders, but they have a certain level of power over you There was a level of influence over your ability, Teoh. Make your commitments. So what do you need from them? What is it that you need from them? In order? Teoh Function finally. So this is purely hypothetical. But finally, look at threats. How could these stakeholders make your job really difficult? How could they turn up the pressure? Could a stakeholder set a deadline? Like you said, the milestone dates for your projects. And then a state hook stakeholder moves that deadline forwards by two months, putting a huge time pressure on your team. Like Jesus Takeover able to do that, could a steak all the country budgets like your budget is $50,000 per month in the stakeholder comes in and says, No, no, no, no, no. 20,000 for the next two months and suddenly you're out of money. Can a stakeholder do that? So we're doing a what if analysis by pretending that the stakeholders gone rogue is working actively against you on is turning on the thumbscrews, so to speak. Teoh really put the pressure on you. What's could they do hypothetically, to make your life difficult? So these five suspects these five things write them down for all your stakeholders. Andi. Actually, most importantly, the power holders focus on the power holders. Do as many stakeholders as you come filling as much as you know. If you can't answer any of these questions, maybe sit down with the steak. All those and suddenly suddenly ask them directly. Like, what do you expect for me? I mean, it's a legitimate question. You can sit down with the CEO, so Hey, what you expect from me? Right, So right this whole down. This is your stakeholder power diagram your power map off the organization. So this is gonna help you to identify which people will rally behind your course on which people could become obstructionists in the future. So crazy. 9. Hack #8: how does your team create value?: today. What we're gonna do is we're going to look as how your team creates value. No, this might seem like a totally obvious question because you're in an organization. I'm assuming into 90 organization. You were delivering products. You're rolling US products. Customers are using your products. So obviously your team is creating products on those products. Create value for the organization, right? Well, actually is more complicated than that. Yes. You're producing products. Yes. Those products create value for the organization. But your team might be creating value in all kinds off different ways. It doesn't simply have to be the output, the software output that they are producing week after week. It could be entirely different things. You don't wanna be surprised about this. You don't want to want to discover that the main value your team was created, it was knowledge or training that your team was actually being used to train developers to get them to a senior level and that the products that you're producing is actually of lesser importance importance to the organization. So what we're gonna do today is Williams observer team discover which outsports off the team is values the most in the organization, actually, which how sports are valued in general. So we're not just gonna look at the deliverables at the products. Will also stuff like coaching mentally training, knowledge, transfer, etcetera, etcetera. So to start to start you out in your fact finding mission, the first thing you need to do is observe your team on Look at the deliverables that they are creating, and then ask him, How would they describe their deliverables? How do they describe the output of what they are producing? Look at how they are spending their time. Are they working full time on creating these deliverables or are they doing other stuff on the site? Are they running size projects? Are they coaching and mentoring difference teams? Different departments? Are they conducting presentations and transferring their knowledge over the organization? Look at additional activities outside off the main production work. Look at what customers receive. Are the deliverables going to the customer? Are they going internally to internal departments? Are the customers receiving the full products are only apart off what your team produces. Look at what is actually flowing from your team to the customers. Then look at the customers. Look at how the deliverables are being used. It's not uncommon for parts of the deliverables to be discarded, so you delivered a product to a customer customer only uses 10% of your deliverable under remain united percent is simply not used. So this is really interesting because it means that you are creating value in 10% off your total ah production, our sports on the remaining 90%. You could might as well just stop working on that section because nobody's using it. So look at your customers and find out how they are using your products, which part of discarded which parts are under used. Which parts are modifies like you deliver products on sections are immediately modified by the customer to be used differently? Look at that. Then look at other groups. Look at other groups that have a relationship with your team. What's to other groups? Game from your team? Is there knowledge transfer? Is there an exchange off? Individuals between these two teams are people in other groups being mentors or coached Eso is your team actually creating knowledge as well as creating a product on Finally look at discrepancies in the organization. Um your team is deliberately sorry Your team is delivering something to the organization, probably multiple things, knowledge products know how, theon pertuan iti to grow in a career and so on and so on. So look as people who are impressed or thankful who is receiving output from your team and is thankful on impressed by what they have received. But also look at people who seem unhappy people who are silence. Look at people who receive something from your team. Andi are very quiet about this because there might be a discrepancy there so much. These four things about these four things to discover how your team is creating value on you will probably discover that your team is house putting a lot of deliverables, producing a lot of liberals, but that 30 or 40% off those deliverables are actually creating value for the organization on. The remainder is not on the remainder is either ignores or it might actually be harmful for the organization. I mean, there's a famous 80 20 which basically sets of 20% of your output is beneficial on the remaining 80% is harmful, so you could actually reduce your outputs by 80% and still have happy customers. So it's really important that you get to the bottom office. How are you creating value for the organization? And I bet you it's in a different way when you was originally think. 10. Hack #9: what does your team have to prove?: today. Today we're going to look at what your team has to prove. So in your new role, a cto you were being watched. All the stakeholders above you in the organization are closely monitoring your progress. Andi have certain expectations. So you and your team needs to prove certain things to your superiors. My question is, what? What other people above you. Um expecting What do they want to see? So what does your team have to prove that this is a very important question because you might be completely wrong about what you think. You have to prove. You might think that you need to deliver products on time because your predecessor kept missing his or her milestones. But in reality, the people above you want you to maximize customer satisfaction, which is a completely different thing. Or you you spend your first few weeks focusing on getting costs under control, reducing expenses and making sure that your department to start making a profit on. Then you discover that you were actually a cross center. People don't care above you. They're happy to make a loss. That's not much. You maximize customer satisfaction, so it's really important to find out what you on what your team has to prove, so we'll start with team. Um, you need to start monitoring who is watching your team. Who is looking at your team's performance on what's do they expect to see by. Well, what do they want to see on which dates to the half in their minds? On what age do you needs toe deliver specific things? Um, trying to discover what kind of metrics these people these power holders are using. Which KP eyes are they using to monitoring the success off your team? Of course, If you know a better KP, I then educate them on on the more useful KP ice that you bring forwards over the ones that they are using Now. Now there are three time frames that we're looking at. The first time frame is immediate. It's the 1st 30 to 60 days, so immediate time frame. Their term future timeframe is 2 to 5 months on. The what we call the first year timeframe is 6 to 12 months, so these are three time frames onto the expectations will differ for these three time friends. So you've just started a CTO and people will expect something in the immediate future from you. They will expect something different and in the future, and they will expect again something different for your first year. So when you're pumping out these expectations, make sure to group them in three separate calls. So to find out what's these? Expectations are from your power holders? The best thing you can do is look at Um, look at the questions the power holders are asking themselves about your team. I've written down four different questions that you could encounter the first. The first question is result oriented. The power holder is asking themselves. Is the team delivering the goods has promised? So you committed to delivering a certain type of products? The power holder is interested in seeing if that social tee off the specific nationality he's delivers Seconds is competence. The power holder is asking himself, Is the team capable? So this power holder will look out to the capabilities off the team? Are the teams capable in executing their roles, executing their jobs? How many? Jr said on the team. How many seniors How is the team leadership organized? Is the team a well oiled machine Or is it a bit chaotic, so power holders might look at your team on judge you by competence. The third is workloads. Power holders look at your team on. They expect to see sweat. They want to see everybody working at 100% capacity. So if team members are slacking off thes power hold that will not be happy. So this is an interesting one because you might be delivering the exact functionality that the customer wants the 10 90% story again. So you're living a product and only 10% is off interest to the customer. So you decide to only deliver that 10%. So suddenly your team has 90% free time. And then there's his power holder looking at your team, seeing people not working 90% of the time. I'm thinking, huh? Terrible. The CTO is doing a terrible job. You just maximize customer satisfaction and you still get judged negatively because your team isn't working at maximum performance. So beware of power holders who judge your team by workloads. Finally, compliance. A power holder might look at your team to see if they are following procedures if they are working in compliance with company regulations. So if you're the kind of person who likes to cut corners on, play fast and loose with the rules, embrace new technologies. Teoh achieve goals. I'm not kind of person. Then you would get jobs negatively by a power holder who was looking for compliance on for adherence to rules. So be aware of thes kinds off power holders you might be playing fast and loose, and a sing one projects in one product after another on Still, you get judged negatively by a power holder because you're not staying within the lines so much. Your power holders along these four possible dimensions results, competence, workloads and compliance to find out what your team has to prove. 11. Hack #10: what do you have to prove?: today we're going to do something similar to yesterday. So yesterday we looks at what your team has to prove. We look at all the power holders who are closely monitoring your team on. We looked at what they expect, how they are judging the performance off your team on. We looked at several different dimensions, several different judgments that you could receive from your power holders, which might not be the ones that you have in mind when you are motivating your team for top performance. But that only covers the team today. We're going to look at what the's power holders expects from you because the same power holders are also closely monitoring your performance as CTO. It is very important that you find out who is watching you. Which power holders are looking as you on. What do they expect to see a chance by when Now again, we have thes three times pounds. We have the immediate future, which is the next 60 days. We have the near term future, which is the 2 to 5 months out on. We have the first year, which is basically everything from six months out to 12 months out on, you're gonna have to prove yourself to your power holders in these three different times. Pounds so again makes Pesci's write down your power holders in the first column. Makes three columns for the different times. Pounds on. Write down what the's power holders expects from you. Um, it will probably be one of these three things. It will probably be these three things. It's will be clarity. Power holders will expect you to have a clear picture off what you want to achieve on by when they want you to understand their industry. They want you to be fully up to speed on how the organizations run, how the organization excels within the industry, what strategies the organization is going to follow in the next 1 to 5 years. To improve even further. They want you to be completely up to speed. So Teoh make those power holders happy. In the immediate future. The best thing you could do is demonstrates that you have a very clear vision, so learn as much as you can from as many people as you come in the organization on. Then formulate your goals. Formulate your strategy on to communicate your strategy to your power holders on. Even if you're on the wrong track, your power holders will appreciate that you have a clear vision and that you're pursuing a clear vision. And if you understand the industry for the mayor term future, the power holdups will probably judge you by your competence. So a CTO you're responsible for running your team. You're responsible for turning your team into a well oiled machine that can efficiently produce deliverables week after week. So in the near term future to £5 outs, your power holders are going to be looking at your performance. They're gonna be looking at how you run your team on how your deliverables live up to the planning. So are you able to run an agile team? Are you able to produce deliverables at the end of every two weeks? Prints on are those deliverables covering Maura Maura more functionality that is making the customer happy. The power holders will be looking for basic CTO job performance job competence in a nutshell. So by doing your job perfectly well, doing an outstanding job, you will impress those power holders. So that's your responsibility for the near term future. 2 to 5 months out, accounting from the start. Finally, the first year power holders are going to judge you on the first year off your performance on what the problems are. Look at us. Is your capability for self improvement because during your job interview on the people who interviewed, you have become aware of your weaknesses. You have weaknesses. Everybody has weaknesses. Andi, you can't really hide them When you are interviewing for a high level job like CTO, people clearly see your weaknesses. You got hired. So that means that people decided that those weaknesses were not an impediment to hire you . But they could be an impediment to do the job well in the long term. So what these power holders want to see is that you are aware off your own weaknesses on that you have a comprehensive plan to tackle them. So basically you are committing to continues self improvement, and you want this self improvement to become a parent, a t. The end off your first year on. By doing that, you will send a very clear signal to your power holders that you were tackling your witnesses. You are committed to becoming the best version of yourself, Onda, and this will set some of these. This will actually impress them a lot. So I focusing on these three things on clarity of vision, on competence of roll on on self improvement. You will impress your power holders in the immediate future than near term future aunt in your first year. 12. Hack #11: check out the backlog: today. What I want you to do is take a look at the backlog. So in the agile project management methodology, the backlog is basically the Q or functionality that needs to be developed by the development team. So every time when the team started a sprint, they take functionality from the backlog on that planet in into the current sprint. So the backlog is basically a planning for what is going to happen in the next 1 to 6 sprints. So it's a like a short term project plan. So what I want you to do is first of all, check. Is there even a backlog? Is your organization using agile uses from Andi? If so, is the backlog present? I certainly hope so. On if there is a backlog, is there also a product owner? So that's a dedicated role Dedicate. His role focused on maintaining the backlog on adding new user stories to the backlog, refining these stories, breaking them down into tasks and then prioritising the tasks, putting them in sequence so that the deaf team knows exactly what to work on during each sprint. So check if there is a dedicated products owner role in the organization. If the product owner is missing, that's about sign. Okay, assuming that is a product owner, check out of the back. Look, now I've drawn a diagram off what the backlog is supposed to look like. Check this out. So here this pyramid represents the entire products. Battle on the back look should be structured as follows. What I would expect to see is on the 1/9 off the backlog up here, I expect to see the original use of stories. So these are user stories and Epix, which have not been refined yet. They are microscopic stories written down in the vocabulary, off the end user, like we need a locate screen. Then, as you proceed through the back look, I expect in the next step, I expect to see refined stories or stories that are being refined, broken down into tasks. And then if I move further, I expected to see tasks so sprint level task that could be implemented by the deaf team. But they have not been prioritised yet, so they're just random sequence on Finally at the other end back. Look, I expect to see spring level prioritized tasks, So these are tasks that are ready to be executed by the Dft on they are prioritized so that in the right order, so the team knows exactly in what order to implement these tasks. So if you find a backlog in your organization with those four steps, so a backlog that starts with high level user stories and then breaks them down refines them into mortem or specific tasks on ends with prioritized tasks for the deaf team, that's fantastic. That's what you want to see. But now let's do a final check. Let's look at the size off the backlog. So, first of all, what I expect to see is that the entire backlog is no longer than six sprints. So right here, the entire backlog is six sprints long. So if we're using scrum, that means that every spends two weeks. So the entire backlog is 12 weeks off work. Now you might be asking, why not longer? Well, if the backlog is longer, if it's like, much longer, like a whole year, then it's not really a back look anymore. It's more like a wish list or a, um uh, a bucket where people have just thrown in all the functionality they can think off. It doesn't really have to do anything anymore with a single project with focused list of functionality for a single project. So you're looking at a limited backlog limited in time? No, the the end of the backlog, the parts where the developers take out the sprint level tasks. I expect that to be 2 to 3. Sprint's right here. The UN prioritized prioritized sprint size tasks that should be no more than 2 to 3 sprints , Um, and again. Well, why knows longer if it's longer, it's not really worthwhile. It's kind of strange. The deaf team is refining tasks, prioritizing tasks together with products owner to get them ready for a sprint. If you have weeks and weeks and weeks off refined tasks ready for development, then Thebe Products owner on the death team, are planning way ahead off the actual implementation. On In Agile, you're not supposed to do that also, why not? Shorter? Well, you can't really go lower than a single springs. You need to have refined tasks for at least for one's friends. On the nice thing. About 2 to 3 to three sprints is that you have a little buffer. So if for some reason the refinement process breaks down, it stops because your product owner gets ill, for example, then you probably wanna calls in sick. Then you know that you have a runway. You have a 2 to 3 springs runway where the deaf team can basically continue working on the refined suspend level tasks. So that's builds in little bit of buffer. It's a form of risk mitigation. So in summary, I expect to see a back look. I expect to see four stages, Um, original, undefined stories, the stories that are being refined, sprint sized tasks which are un prioritized on prioritized sprint size tasks. Andi, I expect the final sprint sized task section off the backlog to be 2 to 3. Smith's long Andi. I expect to see that the entire backlog is six sprints long, coming shorter but shouldn't be any more than six sprints On That, in summary, is what I expect a good, healthy back look to look like. So your homework is. Check out your own backlog on, make sure that it is healthy 13. Hack #12: sprint with the team: you know today what I want you to do is look at the sprint process in your organization. So we've seen working on the assumption that your organization is using agile. If you're not using agile, please, please believe adults are Joe, because agile, agile organizations are running circles around more traditional aboard full based organizations. So if you want to stay ahead in the future, you got an adult agile. So please adult arjo um, in agile development split into spreads. So the deaf team works on functionality for a clearly defined time period of two weeks. We call this a sprint on at the end. They show their deliverables to the stakeholders on. Then the process repeats. The next tasks are selected to be implemented under the team started working on them. We call that another sprint. So the left team is constantly cycling through Sprint's on delivering new functionality every two weeks at the end of a sprint. So this is a very nice process. It's ah, well oiled machine off implementation on def. You implement this process right in your organization, then basically you're deaf. T miss this. This what was well oiled machine that is churning out product functionality week after week after week. It's a self managing, self governing process, so you don't have to micromanage you, that's all. It just runs on its super efficient, but you have to implement agile correctly. So in your organization, I expect to see sprints. I expect to see that you're adopting on agile methodology, be it's Crumb or Cambone. But I want to see a sprint process that looks as follows. So, first of all, I expect each print to start with a sprint planning meeting, explain planning, meeting in the sprints, planning, meeting the deaf team, the scrum master on the products owner or get together. And they plumb what will be implemented in the upcoming sprint. So this is basically a meeting where there's a little bit off task refinement. There's a little bit off task prioritization. The deaf team gets to give their feedback on complexities, unexpected complexities or dependencies between tasks that information come used to put the task in a different sequence, or maybe not implement certain tasks and introduce new tasks. But there's a bit of flexibility. Teoh fiddle around with the backlog, but at the end of the planning meeting. The functionality for the upcoming sprint is set on. Then the team gets to work. The deaf team implements everything that was discussed in the sprint planning meeting. So the sprint is two weeks, so it's two weeks of development. During these two weeks, every morning there is a special meeting called the Daily Scrum. On in the daily scrum, there should be a very short meeting like 10 minutes in the daily scrum. The team, Every member off the team announces what he or she is working one on. If there are any impediments on the scrum, Master is present to remove those impediments. So after every daily scrum, Um after every daily scrum meeting, these grandmaster will have a clear picture off any factors the technological or political or monetary that are blocking the team that is blocking the team from moving forward on the responsibility of the scrum master is to remove those impediments. So we go through these periods off two weeks, the single sprint at the end of the sprint. There is a Sprint review now in the Sprints review. The deaf team shows the deliverables to the stakeholders. So this is basically a demo meeting where the incomplete products is demonstrated. The stakeholders get feedback. They can see their functionality come to life on. They can steer the development. They can say, OK, so we plant the functionality like this. But now that I see it in action, I realized this isn't going to work for our organization. We need to do it differently in a waterfall planning That would be a disaster, because you would have to do your project plan all over again, both in agile. This is just normal. If unexpected stuff happens, you just steer the project in a new direction. So the stakeholders get to provide feedback on the developments on they can actually finality that can introduce new functionality. They can read, prioritize functionality. It's all good. The product owner is present at this meeting to steer the discussion on, make sure that everything stays structured so the product owner basically reconfigures the backlog based on the feedback off the stakeholders. And then there's one final meeting the return perspective. So at the end, off the sprints there's a sprint retrospective where the deaf team, the scrum master on the product I wanna get together on they discuss how this print went. So they talk about how the process went on. They seek alignments on how the process could be improved. So if there were any impediments that could not be resolved by the scrum master and this would be something that comes up in the reeds respective. If the sprint went fantastic and everything was perfect, everything with us plans, you can have a really short retrospective. You simply discuss what was developed. Everything's fine. You move on. So the retrospectives really like this steering committee where you have the opportunity. Teoh, discuss the process on the products every two weeks and then the process repeats. Then the whole cycle repeats and you start the next sprint. So your homework today is to, um, join the team sprint with the team. So sit in on all the meetings, attend a day this crew meeting, attended planning, meeting, attend the review and the retrospective on Did you sit in and see if everything is progressing normally? So if the team is going through this cycle, the sprint cycle, if all the meetings are effective, for example, you could look at the daily scrum on Look, if the meeting is short. The Danish from should be really short, like five minutes or 10 minutes. People should only talk about what they're doing and if anything, is blocking them. So if the daily scrum evolves into this huge to our meeting, that's a very bad sign. So sit in on the team, sit sprint with the team. Look at all these meetings on Make sure that the TV is implementing Scrum or Camba correctly and if not, well, maybe get an external scrum consultant on external agile consultant Teoh. Coach the team on the correct implementation off Joe, because if you implement our job correctly, your team is going to produce an enormous amount of functionality in a very short time and we'll keep producing. Over time they the pace will be sustainable. So, actually is an extremely powerful project management methodology, but you have to implement its correctly. So your homework check if the team is implementing a Joe correctly 14. Hack #13: review the build process: life. Well, today your homework He used to examine the build process off your organization. I'm gonna assume that you produced software. So you have a team of developers and they're coding every day on they they develop their code, they test their colds, they deploy their codes on. Eventually, all this cold ends up on a production system on you have customers, and they used the product on this production system. Now, this entire process from development all the way to production is called build process on. There is a good way to organize it on a bad way to organize it. We left on. I've created a schematic off ideal builds process on your homework is to look in your organization at the way that bills are organized. Compare it to this ideal optimized process on, then find any weaknesses in your organization or any part of the process that is not functioning at optimal performance. Let's take a look. So here is the built process. During the entire process, I'll go through the stages one by one. So we start out with the development stage in the development stage. Your developers are developing coat using company workstations or their own laptops. They write cold. They run unit tests. They check their coats in into source control. Then there should be another stage called the integration stage. So the integration stage is a server. Eso. It's a virtual machine in the clouds or its on premises server that takes away the code off your developers on it combines it into a complete product, and it compiles all the colds, and then it tries to deploy this cold. So it's basically integrating the code of all the developers into a single product. So this is a really important test because your testing, if the codes off one developer works together with the code off another developer. So if anything breaks, then either the compile will fail, you won't be able to compile the complete products, or you won't be able to start the complete its products. It won't run. So actually, doing an integration is a really useful test. You can also augment this with integration tests. So these are specific tests like unit tests, but they're focused on integration. They're focused on the entire product. Then the next step. The next step is what we call in lightly builds. So what you want to see is that every 24 hours, the latest version of all the code is combines into a full build off. The products on the product should be installed into a completely functional staging environment. So this is really cool because you get to test the products every single day. We call it the nightly build, because this process usually runs at night, which means that every morning when the deaf team comes into the office to start working, there will be a completely new, completely up to date version off your products running on a staging environment. So this is absolutely fantastic for testing on. It allows the entire organization to keep track off implementation to keep track of progress. The nightly build. It's super important. Andi is really nice to see it in an organization. If it's done correctly. The next set of staging staging three Idea is that at the end of every sprint, after two weeks, you take the nightly build and you copy it into a staging environment. On there can be tested by Q A by quality assurance so you can have a team off testers that's start hammering the products in the staging environment to make sure that it's running correctly, that everything is working fine on then, when a product on staging passes all tests, you can roll it out to production at the end. Here is the production stage, so this will be your production environments running the finalized product. That is one more stage. If you roll out a hot fixed production to fix a bug on, there's a mistake in the hot fix and you take down the completes products, then you want to be able to do a roll back. So I've drawn this final stage here, which I call the Rolex stage. So this is a process where you would take the code on production and you would roll it back on. Ideally, you can roll it back in multiple versions. You can very quickly go back to a last known working version off your products. This is really useful, of course, when hot fix brakes the products where no one can log in any more. When all the online customers are unable to use the product, your phone lines are going crazy and the CEO is on your voicemail, shouting at you are basically saying we're losing thousands of dollars per minutes. The system is down. Get it working. So in that kind of scenario, it's really nice if you can simply press a button to roll back production to an earlier version. So in summary, this is an ideal build process. These are all the stages I'd like to see on. What I'd also like to see is virtualized development environments for the developers, so that you can very quickly provision in new laptop or a new workstation for a new developer. I like to see integration tests so specific unit tests that run on the integrators code. I'd like to see a fully automated nightly built, so this cannot be a manual process. I would like to see full automation in moving bills, from the 19 bills to staging on from staging to production on. I want to see full automation in rolling back coat from production toe earlier working version with automation. I mean that it is a completely automatic scripted process. I could give an example. A year ago, I worked for a company in Silicon Valley on we had scripted deploys to production. So are Devils manager could simply start a script on. Then 15 minutes later, we would have a new version of production. Fantastic. But every time when we rolled out, a hot fixes actually broke the system and we have to do a rollback. That wasn't the script that was the devil's manager manually executing the script in reverse toe roll everything back on. Of course, that's a terrible process. It's very error prone because it's manual. Andi. It takes a long time. It took about one hour, two hours to do a rollback, so we had scripts for the for the deployed to production. What we didn't have scripts for the rollback. Looking back, that wasn't good. So in a well functioning organization, I would expect to see scripts for everything for the whole process. Final comment. What I'd also like to see is script it provisioning off these five stages, so to give an example, if the production server gets infected with malware on, you have to basically scrap it and rebuild it from scratch. Please don't let that be a manual process. You would want your Devils manager Toby, using tools like Jenkins or answerable to automatically build the production server from scratch, only using scripts. So ideally, this is a single Jenkin script or the single answerable scripts that builds the entire production server in one go eso. If you have a situation where you have to basically rebuild any off, the stage is from scratch. It's an automated process. It takes like 30 minutes, 20 minutes or 10 minutes. But it's not manual, so you can very quickly executed. So in summary, your homework look at your own bills process compares to all these comments I've been making about the ideal build process on, I'd see if you can identify any holes and gaps in your process that you could fiction fix in the short term. 15. Hack #14: hold a fire drill: Well, today, what I'd like you to do, there's gonna be fun. I would like you to hold fire drill. So you were going to pretend that there is a huge calamity in the organization on you're gonna ask your team to fix certain hypothetical problems on seeing how your team deals with a crisis like that, Will, you will learn a lot about the efficiency of your team and if there are any weaknesses in your team or your process. So I've designed four scenarios that you can use in the fire drill on their pretty subtle you're gonna learn about. So, um, first of all, when you organize a fire drill, you're gonna have to announce it in advance because you're gonna The team is gonna take a whole day to basically work with drill. They're not gonna be as fast as you Hope Tasker takes 10 minutes. Could easily take four hours, so blocking entire day on, announce it in advance. So that team knows that they have to take the day out of the sprint so that you're not disrupting their planning. So announce in advance that you're going to a fire drill with the team but don't tell your team what they will do in the fire drill. So give them the scenario at the last possible moment so they can't prepare. So now you're number one. The first thing you're gonna do is tell the team that the production is broken. The production build is broken. So the software that your customers are using online is no longer working. For some reason, let's say the Logan function is not working, so none of the customers can log in. This is a big problem because all your customers are online on your revenue stream has completely dried up. No one is using the software it so no one is paying. So let's say that you have this hugely expensive enterprise software running in the cloud. Andi, it's You're losing like $1000 a minute. So this pretty bad this hugely stressful situation pressure cooker environment. So you're asking your team to roll back the production bills Now you can do, you can ask him to roll back one version. So just go one version back through the previous version. Restore that. But you can also make it more difficult for your team by saying you want to roll back two versions. So, for example, you've discovered that the the problem that broke the Logan scream is not in the last hole fix, but in one hot fix already. So the team has to roll back two versions. But this is interesting because usually a good devil's manager will have a back up off the last known goods production built lying around somewhere. But not many have to backups. So if you insist that they roll back two versions, you're really stressing the Devil's manager. Teoh, test the rollback procedure. So when you do this fire drill, I expected to take no more than five minutes, because what I want to see is a scripted rollback using a repository off earlier known working good versions off the production bills. So, ideally, in sex five minutes. If your team spends four hours to manually rebuild a working version of the software from scratch from source control, then there's room for improvement. Okay, the next fire drill, you're gonna assume that the entire production server is corrupted, so there's malware on the server or a virus or you've been hacked. It could be anything, but you can no longer trust the entire system, so the operating system itself could be corrupted. So you're running in the clouds. It's a provision virtual machine. So you ask the team scratch, scrap the entire production server on rebuild it from scratch. Now we're assuming that the production services corrupted with malware. So the team cannot read any file from the production server. So they have to rebuild from scratch. And they're not allowed to even look at the data because if they look at the copy files out , that could be copying out the malware on infecting the new system. So we're assuming that the entire production server is basically destroyed, inaccessible. So again, interesting test because you want the team to have a scripted provisioning system toe build thes service from scratch. So you want to see something like Jenkins are answerable. You want to see scripts that can build up this entire configuration. Now, good develops. Managers often have these scripts, but which often sees organizations is that the latest configuration settings are not in the scripts there only in the production server. So what the Devil's manager would do is run the scripts to build up a clone of production on, then look at the production Super in the actual one and copy the latest conflict files out and copy them into the new server. But this is allowed. We're assuming that the production server is completely toast. So again, this is an interesting test. Can your team pra vision a production server from scratch without looking at the current production server for the next test, we're going to assume that the company database has been corrupted. So you have a production database. Could be an article, database or post rest or sequel server on it has all your corporate data in its on and the data is corrupted. But before you have backups, so we simply gonna do a backup. But here's the subtle detail. You asked the team to roll back the company database by 12 hours because most Devils managers have backup systems in place or back a processing place where they make a backup every 24 hours. So if you asked the team to roll back 12 hours, don't be surprised if they say we can't do that. We can go back 24 hours, but not 12 hours, and then you simply insist you say No. Sorry. We know that's 12 hours off. Data is corrupted, but the earlier 12 hours are super important and we can't afford to lose that and then see what your team does. Now, if your team has a really advanced backup procedure than they will be able to do point in time backups if they back up their transaction logs, then they can do a full restore off the database and then to a partial restore of a transaction. Look to basically you rewind the database to any point in time. So a good database administrator could basically ask you what time off the day do you want to roll back to on If you say okay, Rollback Teoh 7 45 in the morning that person could actually do is so that's what you're looking for. A transaction Look back up that allows point in time recovery. If your team can only do back can only do restores every 24 hours, then you've uncovered another weakness. Finally, we're going to assume that a development workstation is corrupted, so this could be like a hardest failure hardware failure or and malware or virus that has completely corrupted the operating system. So your star developer, you're senior developer. The hearts and soul of the team can no longer work because he's were. Laptop is completely toast, so the team has to recover. Will not recover. The team has to provision in a new laptop from scratch for four, you start development. How long will this take? Ideally, what I expect is that your use virtual machines. So even if you develop from laptops, you're running a virtual machine on a laptop. With the development environments on, you are developing inside that virtual machine. Then, if anything bad happens, you just take a fresh laptop. You copy the virtual machine on the laptop and you're done. That's all you need to do. That takes at most. One hour no longer depends on the size of the virtual machine. If you have a tiny virtual machine, you could probably do with in 20 minutes, maybe even 10 minutes, so this could be a really fast triple your process. If you see your devils manager manually installing the laptop, installing drivers, installing patches and running software installs by hands, then it's obviously don't have a virtual machine and Even worse, the install isn't even scripted. It's all manual, so that takes way too long. You want to see a superfast laptop provisioning workstation provisioning within one hour. If your team can do it again, that's wrong for improvement. So in summary, this was the fire drill. You've done four tests to see if your team can handle these potential calamities. Observe how your team responds, observed how long it takes your team. Teoh. Implement these recoveries. Andi, identify any weaknesses in the process on in your team on, then address them. 16. Hack #15: test the QA department: today. What I would like you to do is check out your own Q A department. So check out your quality assurance department. If you don't have a Q A department red flag, big red flag. That's a problem right there on their. But if you do, have you a, um, check memos, see if they have their act together. So what would you expect to see in a professional on, well, run away departments? First of all, what you need to look at is how Q A is organized, well organized, curate apartment is in sync with the sprints off the development team at the end of every sprint. So every two weeks there's a new version. I mean, there's a nightly built every day, but after every two weeks, there is a new version on staging, and you expect Q A to test that new version right after it is released. So at the end of every sprint, there should be a little test cycle off your cue. A department. So is your cue a department string Quran ized with your sprint cycle? On second is Q and bed it in the development team. So are we talking about two separate departments? Or is it basically one big group on? Is the Q A manager like adopted member off the developments team, so to speak. Ideally, you want to see some mixing between Q A on the development team on that they see themselves as one big group, so look at organization. Look, if Q A is a separate departments or if they're really close to the deaf team, you want them to be close and check if there's Tesla. A well organized Q. A department has a Tesla for every product. Pounds project seconds. Look at tests. So look at the kinds off tests that Q. A is running. Um, look at the test coverage. How much? How, how much of the product is being tested by the way we call the test coverage, it's a percentage, if you say 100%. That means the entire functionality of the product is being tested and you say 10%. That means there's 90% of the product functionality that is not tested at all back. You a now 100% test coverage is really hard, but you want to be as high as possible. Like 70 or 80%. So find out the test coverage. Find out what server Q is using to test on because if you weigh is testing on the staging server, then there's a chance that's the product of bomb to work when it's rolled out to production . Because there are subtle differences in environments, the biggest difference would be the database. If you're working on a staging server, then you are working against the staging database that it will only have partial customer information in there. Often the information is also sensors so important fields are blankets or they're set to random numbers. So it's quite possible that a test succeeds on staging but completely fails in production. Ideally, you want to be testing on a clone, copy off the production environment on a copy of the production data. If this isn't possible, then a is impossible. But at least try to get as close to the production environment as possible. Then, um, what you want to see is automated testing is Q A. Using automated testing now in the past, away with also manual tests. Curie departments had a team of testers, and they would manually click through an application every few weeks. Now this is pretty hard work. A tester having to retest the same stuff over and over and over again is mind numbing work . So at the beginning of your project, the testers are gonna be really precise and accurate on at the end. When you're ready to deliver, tests will be a bit sloppy because basically everybody is fed up doing the same tests over and over. So nowadays, in the 21st century, what I would like to see is automated testing. So stakeholder goes through a product of once, goes through a test scripts on. Then basically, you record every keyboard and mouse action that the stakeholders doing in the products, and then you just play back the recording over and over. So ideally, you would only ask your stakeholders to do a test once on. Then you can repeat that test every time when you have a new version off the software. So you want to see as much test automation as possible in your Qiwei departments. But you also want to see is that tickets are scripted when a customer reports a book in the products you want to test your product to verify that the bogus there. So you click through the products and verify that you see the bug and then your record that you can play back the recording to repeat that test. So from then on moving forwards, you can always test if every new version off the product no longer has the bug. If the same bug you piers two or three months down the line, you are automated. Test will catch it. So test automation is super. You want as much of that as possible. Finally looked at sentiment. How is the development team perceiving Q and A. How is the feedback of Cuban? A. Communicated to the development team is Q A being condescending towards the team at the hostel? Does the team C Q way as on annoying bureaucratic entity that is impeding the progress. Um, are basically our q A and you're deaf team, collaborative or antagonistic. And, of course what you want to see his collaboration. You want Q and the deaf team to be one big, happy family that is basically working on the same products from different angles. So if you see an antagonistic relationship between Cuba and the deaf team, then get to work because you don't want that 17. Course recap: congratulations on completing the course, So here's a quick recap off everything with you have learned. So we started by looking at, um set off hacks to get you off to a great start and we began with statistics. So you learned that 33% off people being promoted to an executive position did not make it into your second year. So this was intended to kind of humble you and make you realize that video is a difficult job on. You should not underestimate it. Then we looked at the on boarding process and you learned that a lot of organizations do not do on boarding well, So it's very important as new cto that you onboard yourself by talking to as many people as possible you learned about your development team. You've learned about all the roles that you would expect to see the development team like lead developer, architects, project manager, product owner, scrum master. So you talked with your entire team and you were aware off which rolls were present and which roles were missing. For example, if the scrum master is missing which organization adopts scrum, then they have not implemented scrum correctly. There's room for improvement. You looked at the agile process in your organization. So we compare extreme programming. We scrum Cambon. We looked at the pros and cons of every methodology. Andi eso your homework was to find out if the if your organization was implementing agile correctly. If you were using the agile methodology that best much is the expectations on capacity off your organization. And finally you did a quick risk assessment off your organization on checks. If anything was on fire on, if there was a very likely risk with a major impact, then you basically switched out off on boarding modes. You went into firefighting mold, you put out the fire and then you went back to one boarding yourself. So this was a very quick check to make sure that there isn't something crashing softer, completely broken, something that needed your immediate attention. In the second section, we looked at situational awareness. So you became aware of your stakeholders and your power holders on the expectations that these people have off you. You also looked at the team. You looked at your development seem on how they create value for the organization. So you meant out all the deliverables that the team is producing, but also how these liberals are being used by the customers on. Perhaps you found some interesting surprises that the team spends a lot of time developing . A feature for the product on your customers are not even using this feature that ignoring the feature or their disabling it the first thing they do, or maybe even customizing the future because they want something completely different. So here again that are interesting discrepancies that you can use for future improvements in your role on Finally, we looked at what you and your team have to prove. So you learned how these stakeholders and power holders look as your team on. We covered a number off metrics that they might apply when they are judging your team, for example, the team's ability to follow the rules to be compliance with the rules, or how hard teams working if they are 101 100% loaded up with work or not. Onda. We looked at what people expect from you. We split that into three time periods. The shorter, immediate term long term on you learn that in the short term, people will look at your vision. If you have a clear vision for the organization in the medium term, they will be looking if you are able to run your process on your team efficiently in the long term. They are looking at you being aware of your weaknesses on if you are able to delegate around your weaknesses in the short term and deal effectively with your weaknesses in the long term. Then, in the final period, we looked at the our child Process, how the process is implemented in your organization. How your team is implementing the actual process on how your team is executing builds how they are developing software on building software to production. We looked at the Q A department. We did a fire drill, so we were basically stress testing the process. So these 15 hacks that you've learned will help you to become a great city. Oh, on the great video has a number of characteristics. Great city. Oh, is analytical. A great video is empathic a great city. Oh, is visionary under great sitio is driven aunt. By implementing these 15 axe, you will cultivate these attributes within yourself. This will be great for your career. Speaking of career, the career path to CTO is fairly simple. Usually you start out as either an architect or less VP of engineering on. Then you get promoted upwards into the city overall on its not that hard to become CTO. I've been city all three times in my career, but it is important to be on outstanding CDO. A lot of sitios only focus on technology on the technological part off their job. And I hope with this course with these 15 axe, I've helped you also to become aware off the politics on off the interpersonal aspects off the roll. So I have a final tip for you. I already briefly mentioned it's when we talked about the situation. Awareness three Organization on your stakeholders are going to be closely watching you as you progress on grow in your role as new CTO on. They have expectations from you, so let's repeat these expectations. So in the short term, your stakeholders are going to be watching. If you have a clear vision off the organization, you need to have a vision off where you want to take your organization where you will be in one year in five years in 10 years, what are your goals? To achieve that vision, you could be warmed by the way. But the stakeholders are only interested in If you have a vision, having the wrong vision is much less bud than having no vision whatsoever. So in the short term, make sure that you have a clear vision in the medium term, make sure that you are running your team and your process efficiently. So we covered these in the 15 hacks. You want to be implementing an agile process in your organization on Do you want your team to efficiently run through successive sprints? So in the medium term, your stakeholders are going to be looking at your efficiency on the efficiency of your team at your ability to manage your team and your process. In the long term, your stakeholders going to be looking at your weaknesses. Now don't freak out. Everybody has weaknesses on Three important thing is to be aware off your weaknesses and to have a plan to outgrow them. In the short term, you're not gonna have time to deal with your weaknesses. So you are going to have Teoh delegates around him. But in the long term, six months to 12 months down the line, your stakeholders, they're going to be looking at you and they will expect you to grow. So you're gonna have to have a plan, Teoh. Deal with your weaknesses to outgrow with your outgrow your weaknesses. So this is parting advice that I want to give you as you move further on in your career. So again, congratulations on completing the course. Good luck with the rest off your career on bond. I hope we meet again in another course.