The Empowered Technologist

Rachel Laycock ParadigmShiftOur last speaker before the break-- [CLEARS THROAT] excuse me-- is going to build a bit on some of what Adrian was speaking about when he talked about talent density, getting the best people and simply getting out of their way. I think I'm an executive myself. And even for my team, I think I do this. But you know what? I probably don't. I think most of us think that we empower our people and that's our perspective without really understanding what an empowered technologist feels like and thinks like and what they're actually looking for. This ripple effect exists. This ecosystem of value that we're building at gets right to the heart of our people. We're going to hear more about this this afternoon. But before our break, I'd just like to welcome up to the stage my colleague and friend, our Head of Technology, Rachel Laycock. [MUSIC PLAYING] Can you all hear me OK? So if you hadn't already noticed, it's British day. Every speaker is British today. Well, maybe not-- maybe some Americans little bit later. I'm going to try to talk about empowering technologists. And this is something that people have touched upon around the people aspect of this. Ryan touched upon it yesterday. But for your business to be successful in this technology world that we now live in, you need high class talent. And unfortunately for every single person in this room, more or less, including myself, there is a war out there for talent. And every single person in this room is in that war. There was a Forrester Report in July 2015 called Recruit Top Developers by Appealing to Their Social Side. And it's stated, "Computer and programming job openings are growing at twice the national average. But with approximately 43,000 students a year graduating with computer science degrees, there just isn't enough talent to go around." So for the talent you have, you need to motivate them and create the right engineering culture. And this isn't just about making developers happy and technologists happy. This is actually what your business needs because technology is now your business. That's what we've been talking about the last day and a half. And to succeed at creating the capability to deliver faster, you need to attract, retain, and motivate the best technologists. So what do you need to do to create that culture? First of all, you need to create this new world, which some of which Adrian actually touched on. So the Old World of broken down silos, and passing things over the wall, and slow infrastructure that takes forever and ever to set up, maybe a year or two down the line you eventually get some value to your customers, is not going to work anymore, not only because they're are disruptors out there that are going to compete against you and get out there faster, but also because it makes your people miserable and unhappy. So now we have cross-functional teams working together, cross-functional business and IT using infrastructure and platforms to the service, to quickly get value out to your customers. And the commonality of these teams is that they're working together in unison. And every team and every person supports the value driven mission of your organization. This is where the best talent wants to work. And if you don't provide this environment for them, somebody else will. Has anyone read the book, Drive, by Dan Pink? A few of you. So you don't have to read the book, actually. He thankfully put on a 50-minute YouTube video where you can watch. And he talks about how do you motivate knowledge workers, which is what your technologists are. And he asserts there are three factors to motivate knowledge workers. The first is autonomy, the second is mastery, and the third is purpose. But before we dive into this, I just want to explore what's in the way of you unlocking these valuable assets, these autonomous masterful and purposeful people because a lot of them are millennials like myself, actually. I'm one of the oldest millennials according to Don yesterday. So yes. I'm admitting my age now. Because we're not lazy, as he has said yesterday. We actually do want to do stuff. But we want to work in this world. So let's explore that. Ryan talked yesterday about platforms of execution, and those platforms of execution including technology, process, and people. Those are actually what's in your way. Legacy technology, legacy processes, and organizational structures, and legacy management structures, the things that start-ups don't have. So let's start with the easy one. I bet you didn't think I was going to say that. Technology, easy. It's not easy. But it's a solved problem. Much of what Adrian already talked about, there are a lot of patterns in place that you can solve these legacy technology problems. But I'm going to dive into one of the most difficult ones specifically, which is legacy architecture. So who knows what this is? Feel free to shout out. Anyone? Hairball. A hairball. Close. Close. It's actually the most common software architecture pattern that exists in the world. It's called a ball of mud. And I didn't make that up. There's actually a white paper. You can go and read it. And it explains what this is. And everyone has these. So if you have them, don't feel bad. And the only difference between a large organization and a small organization is how many. So a large organizations usually has hundreds. A small one might have less than 10, maybe 20. But more importantly, what this is is the business systems of one of the largest financials in the US. Now, imagine if the value that you wanted delivered to your customers, the value that's really going to be a game changer for your organization, is right here. What do you think happens in these balls of mud, why they're so painful and inflexible? It's that one small change has a huge impact. And that huge impact means lots of regression-- lots of testing. What that really means in bottom dollars is it's expensive and it's really slow. And on top of that it's extremely painful and demotivating for your people to work in this environment. And if you want to get the benefits of the Cloud, you're going to have to start ripping all this up and creating those wonderful things we call micro-services, which sounds amazing but little bit more challenging in practice. But as I said, there are patters for untangling this, which if you want to come talk to me afterwards, I'm happy to dive into detail. And I give many talks on how do you untangle calls of mud because I've unfortunately or fortunately had the pleasure or displeasure of doing this many times over for many of our clients. So that was the easy bit. Let's move on to something a little harder, creating an environment where your talent can be productive and Excel. Your organizational structure and the processes within it, still not your hardest problem by the way. Anyone heard of this? Conway's law? So Melvin Conway, in 1968 no less, so long, long before I was born, he said the "Organizations which design systems are constrained to produce designs, which are copies of the communication structures of these organizations." So given that assertion and given that it's true, why do you think there are balls of mud in your architecture? Because there are balls of mud in the communication structures of your organization. And your architecture is a representation of that. These are some of the things that you're going to need to tackle if you want to move as fast as those that are disrupting you. Silos and bureaucracy will slow you down. Maybe there was a good reason for them once upon a time. There may be some compliance things that you need to still tackle. But they're automated and quicker ways of doing it now. And your disruptors are going to do that because they're not going to go down your route. The frozen middle, we sometimes refer to in our organization-- so often you'll try and make a change at the team level. And the developers and technologists will get on board. And they'll get excited. And you as an executive also might be like, this is what we want to do. But all of those silos and all of those people in the middle, all of the things that got them where they are today is not going to get them where you want your organization to go in the future. So you need to change the way that you incentivize them. Because if you don't, they are the immune system that will attack the new virus that you're trying to create within your organization. You also need to remove the issues that are on your infrastructure so that you can prepare for the unknown. And very much focus on clear, not just one-way communication, but clear, two-way collaborative communication with people within your organization. Because as I said, your disruptors don't have this problem-- not yet anyway. They're not big enough. They will potentially. OK. Let's get on to the hard part. Let's talk about the people, the actual technologists themselves. "...it isn't the methodologies that succeed or fail. It's the teams that succeed or fail. Taking on a process can help a team raise its game, but in the end it's the team that matters and carries the responsibility to do what works for them." Martin Fowler, if you don't know, is our Chief Scientist at ThoughtWorks. He's written many books on software architecture. He's a big deal for developers, if you're not a developer. Basically, people don't follow rules, and especially not millennials. They're not interested in any of that command and control stuff. Teams of technologists, teams of people, are a complex organism. And they're a complex organism that's actually your asset. This is a report that first started in 2014. And it was the first of its kind, the first scientific study to uncover the relationship between organizational Performance, IT performance, and DevOps. So we can now assert with confidence that culture actually matters. The collaboration culture that you create in your organization matters because if you have a high performance IT organization, your chance of exceeding profitably, market share, and productivity goals doubles. These are things that everyone wants. And it turns out that DevOps practice actually strongly correlates with IT performance. And that's DevOps practice, by the way, not tools, not profit, not [INAUDIBLE], not infrastructure as code. The collaboration between developers and operations, which were two opposing-- had two opposing goals at one point. Right? Developers are incentivized to just get stuff done. So quality is not their biggest concern. And operations, they're incentivized to keep the systems up. So they care about quality. And so there would be a battle between them, which I played out many times in my career. So someone had the bright idea of bringing these two groups together to work towards what everyone's trying to do, which is deliver value for the organization. But to create that collaboration and experimentation, which is what came from that, you have to have the right culture. And in order to create the right culture your people being happy and satisfied and motivated to come to work is the number one predictor of that culture, and therefore the performance of your organization. So I'm making this stuff up. I'm not just standing here like, freedom for the developers. Please, let us work how we want. This stuff matters and we've proved it. So let's come back to Dan Pink's model, from the perspective of a technologist. We'll start with autonomy, the urge to direct our own lives. I've spent-- well, these days I'm the Head of Technology. So I'd be lying if I said I coded that often. But I used to code a lot-- so for seven years before joining ThoughtWorks and a good few years into ThoughtWorks. And contrary to popular belief, developers don't like playing solitaire and sitting around doing nothing. And we like to build stuff. And we love it when our stuff is in production. That's why these days not only do people in developer environments have build monitors that tell them whether their code was good quality or not, they also see the analytics of how the users are using the system because that motivates them. That's what we like to see. So one of my first jobs out of university I was on a development team where we had no control over the tools that we used or even the machines that we were given. And we were treated as a cost because that's how it was. And so we were given the same hardware, the same development machines, as every other person in the organization whether they were administrator, or an office manager, or they were in marketing. We had the same hardware, the same CPU processing power. And ever since the world of small talk, the fluid developer environments, mean we compile all the time. And a compile in those environments took 10 minutes. And developers compile more than once an hour. So you can just imagine how much time we sat around doing nothing, waiting for our code to compile. We got and we got frustrated. We were trying to do stuff and we couldn't get anything done. So our Dev manager decided to calculate how much it was actually costing because even though back then developers weren't getting paid as much as they get paid now, we still weren't a cheap resource. We were highly educated. Unsurprisingly, it was cheaper to buy us better hardware. So eventually, that's what they did. To bring that story into today's world. It's the same as developers waiting around for new hardware and new machines so that they can deploy into test environments and staging environments and production environments. Raising two kids, hurry up and wait. Dependencies, we hear it over and over again. It's demoralizing and its demotivating. We want to be an environment where we can be productive and we can make decisions that allow us to be so. So you have to create an autonomous but responsible environment for your developers, for your technologists. Allow them to make as many decisions as it makes sense. I'm sure there are some compliance and security decisions that still need some level of governance. But allow them to choose the right tools that allow them to get stuff into production and deliver value for you. Because if you don't provide that kind of environment, somebody else will. Developers want to be productive. They want to contribute. They want to deploy easily. The second thing is mastery. So why do you think people play musical instruments when they're never going to be a rock star? And yet they continue to practice, sometimes every night, because people like to get better and better at something that matters to them. This is why in my early days of software development when I started hearing about new practices like test-driven development and new tools, even after working 8 and 10 hour days in London, I would still go in the evenings and hang out with my friends and do coding [INAUDIBLE] to learn TDD. And I'm not an exception. That's actually pretty normal. In fact, in that Forrester Report I talked about earlier, they decided to survey developers and ask them, why do you do this? Why do you continue to work into the night for yourself? Why do they write Linux? Why do they contribute to Wikipedia? Why do people contribute to this stuff and they're not getting paid for it? 64% said they code outside of the office to keep their skills sharp and learn new technology. What does that mean to you? It means you have to create the environment where they can do this in your environment. Believe me, the tools and techniques and platforms in this industry change at an incredibly rapid rate, way faster than when I was coding every day. I can't keep up anymore. I'm like, OK. I actually have to rely on people who know what they're talking about because there's just too much out there. It isn't just learn .net and learn Java. There's just masses now. I'm one of the people that helps put together the ThoughtWorks technology radar. And you'll see there's like 100 things on there every six months. And that's a whittled down list-- 100 new things every six months. It's probably not even [INAUDIBLE]. That's just the stuff that we use at ThoughtWorks. That probably doesn't even cover half of it that's out there. So you have to create an environment where your developers can keep learning and keep doing this stuff because this is what they care about. This is what they're passionate about. You can't pay lip service to it. You can't create a school or a facility that's never used. Think about what Ryan said yesterday about platforms of execution-- tech process people. Think of your technologist as value to your business. And therefore, they need to be invested in. They're the ones that are going to allow you to be able to really use this technology to do the things that your disruptors are doing. And I don't want to hear that it can't be done here because we created things like affinity groups and clubs and lunch and learns like they have at Spotify, like you'll read about in one of the largest financials in New York City. So it can be done. You can do this. Lastly, purpose, the yearning to do what we do in the service of something that is larger than ourselves. Technologists are looking for so much more than just to make money. They're looking for so much more from your organization than just to say profit for the shareholders. But thankfully, and I'm sure you'll agree, that every organization has a mission. And I'm going to quote two missions, one from the Amalgamated Bank, a snippet of, which is, "To be the preeminent bank of progressive people, organizations, businesses, and labor." And the second is from a retail organization, which is Aldo. "To ensure an enjoyable and memorable shopping experience for every customer." These are things that people can get behind if that's something that excites them. Make sure that everyone in your organization really understands and is aligned with the mission of what your organization is about. Heavily communicate it. Makes sure they understand the strategy. Make sure they understand the principles. And then allow them to make aligned decisions. Because if you do that and you've got all these autonomous, masterful, and purposeful individuals in your organization, instead of just having a few executives or a few key product people try to envision the future and come up with ideas, you're unlocking, if you have 1,000 people in your organization, 1,000 ideas-- 10,000, 10,000 ideas. In fact, the next problem you'll have is what do you do with all these ideas? That's not a bad problem to have. But in order to have that decentralization of innovation within your organization, you have to make sure they're aligned to your mission. All need to be aware of the mission. All need to be bought into it. You cannot communicate it enough. So I'm going to leave you with three things. Your sponsorship shape as an executive to this is critical. This isn't lips services. Sorry-- lip service. This is really important. But be very, very cautious towards that frozen middle. They need to be re-incentivized in a different way to support the people that are going to deliver value to you, including themselves. Change impacts everybody. It isn't an IT change. I think we've all kind of covered that and talked about it the last couple of days or last day and a half even. It's not just about IT. Its about IT and business people working together. People from different fields, designers, product, executives, IT, technologist, Infra, you bring all those people together, then you can have some really good ideas, things that might actually work, lots of different perspectives. Diversity matters. And lastly, I'll leave you with this because this war for talent is out there. And you're in it. And so yesterday, I liked what Doug Gardner said from River Island. He said, people used to come to us. Because the talent that you have now, even if you motivate them and train them and do all of these great things, still might not be what you need in the future. So you're going to have to go out and get new talent. But they're not going to come to you anymore. They can go anywhere. So you're going to have to go to them. They moved to Shoreditch. In fact, Shoreditch is where ThoughtWorks got me from, from a start-up in Shoreditch. So you're going to have to go to them. You're going to have to be part of their community. You're going to have to make sure that you're not paying lip service and this is really happening within your organization because your technologist will tell other technologists. And then they'll want to come and work for you. But you will need to go to them to be a part of this war and to be at the front line. Thank you. [APPLAUSE] [MUSIC PLAYING]

Rachel is the Head of Technology for North America at ThoughtWorks and is based in New York. She has over 12 years of experience in software delivery, having worked on a wide range of technologies and the integration of many disparate systems. At ThoughtWorks, she has coached teams on Agile and Continuous Delivery technical practices. She contributes to and drives the regional technology strategy, and is a conduit between the technical teams on the ground and global technical leadership. She is also a member of the Technical Advisory Board to the CTO, which regularly produces the ThoughtWorks Technology Radar. She is fascinated by problem solving and has discovered that people problems are often more difficult to solve than software ones.