Tech Talk: How to Enable Organizations to Go Faster with Fred George

Table of Contents

This week, we’re featuring presentations from Microservices Day London. Kudos to nearForm for assembling an all-star lineup of speakers! All of the videos are posted and in case you prefer to read through the talks, we’ve selected some standouts to offer in transcript form! We continue with Fred George, Principal Consultant at Fred George Consulting, who has without doubt made an indelible mark on the industry.

We hope you enjoy the presentation as much as we did!

How to Enable Organizations to Go Faster

Presented at Microservices Day London

Video

Transcript

Introduction

I have an interesting way to talk about microservices. I’m going to talk about everything but microservices to some degree, to introduce this. To some degree, microservices done by itself will probably fail. There’s a lot of ancillary things you want to do to make sure it works. That’s the subject I’d like to talk today.

This is just, basically, the deck in case you get a copy. The key thing here is this and I’ve basically spent my career being on the edge of technology. A lot of the things I talk about are bleeding edge things. They may be things that are not appropriate for you and your organization yet, but my guess is within the next 3 to 5 years, you’ll be doing a lot of things that you’re hearing about today. Don’t feel bad if you’re not doing a lot of these things yet. It will happen.

I go to a lot of conferences. I usually speak at around a conference a month for the last 4 or 5 years, and I see a lot of conference topics come up. Microservices now has a dedicated track. There are a few dedicated conferences associated with microservices, but you’re also seeing these other topics becoming vogue in these classes. Cloud’s been there for a while. We have dedicated conferences associated with Docker at this point. A lot of other technologies there. You’re also seeing a lot of focus on process stuff. We’ve been doing Agile now for over 15 years, but now that becoming some more advanced Agile, more aggressive Agiles, things coming out.

I talk about one called “Programmer Anarchy”, which is my experience here at London, working for a company called Forward. It is also Erik Meijer talking about this stuff. He calls it “One Hacker Way”, a more aggressive style of Agile. You’re also seeing things that the business side is also trying to adopt very similar sort of Agile concepts. Things like Lean Startup movement, and the whole concept of Minimum Viable Product. You’re also just seeing now a focus on particular roles. There’s entire conferences associated with DevOps, and there’s a new focus on full stack developers being something you may wouldn’t want not to do, versus the specialists we tend to have. There’s a common theme I’ve seen through all these things. All these things are designed to allow your organization to go faster. From the time I have an idea to have that idea deployed, we’re trying to make sure we do that faster. These all are topics associated with that speed. I want to talk about what it takes to go faster.

[2:33] To some degree, we’re solving a different class of problems now than we solved 20 years ago, when I was writing code then. It’s best explained using the Cynefin model from a guy named Dave Snowden. He’s Welsh. We won’t hold that against him, I’m sure. He talks about breaking problems up into various classifications. He says simple problems that cause and effect relationships very straightforward. This might be an organization where you have a call center and it’s very easy to talk about what call center should do. He also says it’s a complicated problem. There is a cause and effect relationship, but it’s somewhat convoluted. It’s the domain of the expert to help you to figure that out. He doesn’t stop there. He also says there are other problems he calls complex and chaotic. A complex problem is one where the cause and effect relationship does not exist. Yes, if something happens, you can figure out why it happened, but it doesn’t help you predict the future.

This is the domain of problems like Google advertising, day trading, things like recommendation engines. Should I loan you money? What’s the next book you should read? These are kind of fuzzy problems, and it turns out this sort of organization does not work well solving complex problems. Yet it turns out complex problems are the ones that make a lot of money these days. We’ve pretty much done our payroll systems. The complicated stuff’s been done, and done again, and again. When you move over to complex problems, that type of organization does not work very well. That’s where we’re having some strange things happening.

One of the things Dave Snowden would also say is most of the times, you don’t know what type of problem you’re solving. You have to sort of watch how it behaves to see if it behaves in the sort of ways associated with these classifications. He says about 85% of problems are this nature. He also said you tend to have a prejudice about where you like to solve problems. If you’re Donald Trump, everything is simple. You elect me and I’ll fix it. Yeah, I’ll raise taxes, we’ll fix it. I’ll lower taxes, we’ll fix it. We’ll do something else like that. Of course, it’s not a simple problem he’s trying to solve. These are really complex problems.

I tend to have a prejudice myself. I tend to like complex problems because I kind of like the disorder associated with that, they very cowboy sort of nature of that, being an American, of course. I tend to like to work in that segment. It turns out, that segment makes a lot of money these days. We’re solving different type of problems, and so a lot of the traditional way of thinking about things don’t necessarily work.

Delivery cycles - How fast can you go?

[5:00] How fast can you go in this world? how fast can you go? I’m looking at a couple things. Again, being old, you tend to reminisce about things, so I drew some charts reminiscing about stuff. That’s a log scale on the side here. It talks about how long an iteration lasts. The original Agile processes, there were quite a few processes back in the original times, extreme programming from Kent Beck, who’s one of the fastest. It was about a 2, 3 week iteration cycle. Scrum was taking around 2 or 3 months for their cycle, and for that time, that was extremely fast.

As we started playing with this stuff, the 2 or 3 week cycle of extreme programming got shorter and shorter. To some degree, I discovered that if you have a 3 week iteration, the first week the programmers kind of rest, the second week they kind of work, and the third week they panic. It turns out panicking is really productive, and so it kind of cut our iterations down to a week. We didn’t stop there. All of a sudden, when I was working with some companies here in London, all of a sudden it almost got down to a day, a lone iteration. Our scope … Then it got even crazy and faster than that. We’re not sitting where we were. If you’re still doing 2 week iterations, you can go a lot faster than that, and that’s happening as well.

[6:19] Another historic chart, and this is project delivery cycles. How long does it take to get code out the door? I’m going to start with 1980 in this case, another 10 years back, or 20 years back. Again, a log scale at the top. This is me working at IBM. I worked on a project at IBM in this timeframe. It took 3 years. We had 1,000 programmers working on it. We delivered on time, it was exactly the schedule it was supposed to be, and don’t feel too bad for me because we made one billion dollars with that software. It was a very, very productive project.

As I kept working at IBM, we got a little bit faster. I got to the point where I was probably delivering every 8 months or so. Even when the introduction of object-oriented programming to IBM didn’t really speed that up much. Again, this is a log chart, so any straight line here is really a hockey stick. This is pretty good. We’re getting some progress here. Agile, start playing with Agile, again we’re shipping in 3 or 4 month cycles, so again, nice improvement, but nothing spectacular. Then the bottom fell out. We basically got into some aggressive Agile processes, and we got into this. This is a hockey stick on a hockey stick chart. This is brutally fast. How fast did we get? Working a few years ago, we got to the point where we were pushing something new into production every 3.5 minutes. If you think you’re going fast, you can go faster.

Inhibitors - What keeps you from doing 3.5 minute iterations?

There are really a set of inhibitors associated with this, and I want to talk about some technology inhibitors, some process inhibitors, and we’ll wrap it up with some organizational inhibitors, and how we tend to address these and some various clients I’ve worked with.

[8:00] First of all is there’s “Valley Tech”. This is a term certainly used by CEOs in the US, and it refers to the concept of, what is it these Silicon Valley companies doing that we’re not doing? Why can’t we be like them? To some degree, it’s because they’re using technology that a lot of the larger companies are afraid to touch. Whether it’s using the cloud, using new programming languages, using open source projects, but we can’t do that because we’re not sure about it. It sounds kind of scary. If you’re not doing this, your competitors are doing it, and they’re going to kill you, because this makes them go fast.

First of all, from an organization, are you using the right technologies? Are you afraid of these technologies, or are you trying to figure out how to embrace them? The other technology is hardware lead time. How long does it take to get your hardware to do something? Again, I want to go back and draw a nice historic chart. Again, log scale on the side. We’ll start in 1990. Basically, if you need to get some hardware in this timeframe, in 1990, it took probably took you about 3 to 6 months to get the hardware. You had to go figure out what you needed, had to go order it, you had to get it installed, get it all working. That’s a bit of a lie because generally you had to allocate the capital expense for it the year before. It would be somewhere between 12 and 18 months to get the new hardware in. That didn’t allow you a lot of flexibility.

The nice thing is, along came virtual machines, so I could take this hardware now and carve it up differently based upon my needs. It gave you some new flexibility. Then it got really crazy, because then Amazon comes along, and now I can go get computing power when I need it. It’s gone from basically being a capital equipment problems to becoming an operational expense. You think that’s crazy, Docker comes along and now I can get stuff in like 5 seconds.

What does this do? If you don’t take advantage of this, again, you’re missing an opportunity. What this winds up doing is basically kills the whole concept of capacity planning. If you’re doing capacity planning, you’re sitting back in the 1990s thinking. You’re not thinking like today, because it’s not a capacity issue anymore. If you need the processing power and it can make you money, go buy it. Don’t be an idiot. The other thing is, these ops guys, they’re kind of out of a job. In fact, the DevOps guys get together and have DevOps conferences, and mostly it’s Ops guys talking to each other, saying, “Oh, I have a job. Do you still have a job?” “Oh yeah, I still have a job.” “Well you must still be important.” They’re not.

We’ve outsourced all that stuff to very aggressive tools with some very, very smart companies doing this stuff. Yeah, if you’re still doing capacity planning and having these capital expense plans, you’re wasting your time. If it constrains you from doing the right thing when you need to do it because you’re afraid to use the cloud, your competition will kill you. Another technology inhibitor that you need to take advantage of.

[10:43] Based on this, we now have our microservices world. It’s a direct impact of that curve. It used to be, when I was writing code a lot, they called this a Rails and Java Zone. Again, this is a log, log chart, so this is crazy charts. One big application, it’ll be 100,000, 1,000,000 lines of code, or 10,000,000 lines of code. Then, maybe in about 2004, 2005, service-oriented architectures come out. I remember Credit Suisse at this time was very aggressive in this space. They took their million lines, multiple millions of lines of code, and targeted it into 50,000 or 100,000 line pieces. That began the SOA stuff. They had some very large pieces like that.

But with the advent of the cloud in computer, and the advent, especially, of Docker, you wound up with a whole new world of microservices. In this space, there’s lots of these very, very small services running very aggressively. I used to work on a project in India many years ago like that. I will never do that again. It’s just not worth your life to do that sort of stuff. I teach a class. We do a workshop where we build microservices in this space. There are about 50 lines of code. We do about 15 or 20 of them in the workshop. This is Forward, the company up in Camden that I worked with for 4 or 5 years. They split off, uSwitch as part of that. Basically, we had around 300 services. None were much more than 100 lines of code.

Netflix. Your online Netflix, this is where they’re sitting. Mostly about 600 services, they run about 1 or 2,000 lines of code in Java. All of this a result of the previous curve. You can do this because you’re taking advantage of the fact that computing power can be at your access when you need it at very aggressive timeframes. This is where the world is going. This is where microservices sit. By the way, this is why all these companies came up at the same time tried doing microservices. These companies in parallel recognize the previous curse.

Incremental Applications

[12:45] The other thing this allows you to do with microservices is you can now build an incremental application. You don’t have to build a big thing and turn it on. You can sort of build a little at a time, get a little more functionality. This was an example I used in a lot of my presentations talking about putting advertising on a webpage. Basically, we build ourselves a little application that does that. We have something that says, Yeah, I might need some advertising, and got a couple guys down here services that respond and give you some ads. It’s up and running. We’re starting to make money.

I can incrementally add things to this application. I can add information about the membership in my frequent renter program. I can do customer segmentation. Add additional information. Now it’s a smart application, makes even more money. The ROI on this is very aggressive because I get something out so quickly and so early, and I’m trying ideas out aggressively. This gives me competitive advantage.

Database: Holy Grail or Ball-and-Chain?

Turns out, databases are the thing that’s going to hold you back from aggressive microservice deployment. The holy grail has always been, I want an operational database and I want a reporting database. We have two of them because we organize them differently. The operational database is pretty much dead. I went to a client, I was talking to one of our hotel clients, and I go into his chief architect. I say to him, “How many databases do you have?” I’m a troublemaker, so I knew kind of what his answer was going to be. He says, “We have 3 right now. We’re trying to get it down to 2.” I say, “That’s really interesting, because you really need 300.” He thinks I’m crazy, and by the way, that’s the last conversation we ever had, which was perfectly okay because after our meeting, he was going to tell his new vendor about his new waterfall process. I didn’t want to talk to him either.

What’s going on in, again what is happening in a lot of the Silicon Valley companies, they’ve killed the operational SQL database. They’re replacing it with an event bus. The event bus becomes sort of the operational database of sorts. It’s a persistent store itself. Each of these little services has a database of its own if it needs one. Yes, I’ll have all sorts of redundant data. I don’t have perfect consistency, but for solving complex problems according to that model, this is an excellent architecture. It gives you a competitive advantage. We use lots of different databases. Just because this service over here has to have transactions doesn’t mean all the rest of us are stuck with using SQL server or Oracle. We can choose the proper database for our need. Little key value store is all we need. I don’t need this big Oracle instance in this situation. It turns out, that’s the key chain is to rethink how you’re using the database. Chad Fowler, who’s the now sort of the CTO/CEO of 6Wunderkinder, a company who just got bought by Microsoft last year, the first thing he did with his application was tear the database apart and then build a set of services around that information. That’s how he migrated it from one of those ugly Rails things into a system that made it so attractive that they paid a billion dollars for his company.

How does this look? This little service up here I talked about basically is sitting here, is publishing an event on the bus, saying “I need some advertising.” It’s collecting the answers, it puts them in its own little Redis database, and then at some point decides it’s going to respond back to the customer and give him an answer. I’ll be running 4 little pieces of code in 4 different Docker containers, and this little service has its own little database. Very much like all these others did. This is the new architecture.

The event bus is really your persistent store and these little databases cache information for you. A whole new architecture associated with this. The other thing is, the open source community is live and active and writes some extremely great software. Netflix, of course, is open source, almost all their software stack. Over 40 open source projects. Very large companies in the US, including the US Department of Defense, are using this stack to build their next generation applications. It’s that powerful.

Containers

You also have things like Docker. If you aren’t part of the container world, listen to the container world. It’s amazing. Amazing how fast these things work, and it’s taking over by storm. Almost all of the major vendors now have signed up for this container architectures. It’s even become a native architecture now soon on the Mac and the Windows machines, where you can run native Docker containers on these platforms. Again, open source stuff. Don’t be afraid of it. Embrace it.

Languages

Finally, there’s some disruptive languages. Functional programming languages, a new family of languages. Actually, not that new. Lisp is one of the oldest languages ever, but some new languages are being used to do interesting things. If you look at some of the really reliable key pieces of software, Kafka is a event bus used by LinkedIn. It’s not written in Java or C++ for performance reasons. It’s written in Scala. A functional programming language on the JVM. RabbitMQ, one of the most reliable pieces of little software you’ll ever run across, used to be written in a different language. It was buggy as hell. Now it’s written in Erlang, a really old language, but a very strange language. They don’t use Java and C++ for these things. In our experience here in London, I worked with The Mail Online. Clifton Cunningham will come up later and talk about some of our experiences there. We basically had 130,000 lines of Java just to render the pages of The Daily Mail. We replaced that with 4,000 lines of closure. These languages are silver bullets. If you’re not using them, your competitors are. They’re way faster than you are. Don’t be afraid of some of this technology.

Process inhibitors

That’s kind of the easy stuff, actually. That’s just the technology stuff. You can sort of get your head around that, because we’re geeks at heart. Let’s talk about some of the other things. Process problems, because the processes are also inhibitors. First process issue you got to wrestle with is what type of problem are you trying to solve? If you have experts, that’s your world, architects, designers, business guys who understand the business in intimate detail, and they’re driving your organization, and you wind up having to solve a complex problem, it will not work. There are no experts in a complex problem. There are people who think they’re experts. They’re lying.

[19:07] There’s also no role in this for the managers, because part of the manager role is make sure people are doing what they’re supposed to do. They don’t know what they’re supposed to do. It’s a very frustrating job for a manager to send into a complex problem. They don’t understand what’s going on. If you try to take your existing organization and solve these problems, it will be extremely frustrating. You will have massive failures.

Understand what type of problem you’re solving. If there’s one of these, yeah, you’re … One of these? Yes, traditional structures we use, sort of the classical Indian offshore model, works extremely well for complicated problems. If you’re in the complex domain, don’t try it.

New vision of “what” to build

The other thing is you got to revisit how we build things and how we figure out what to build. To some degree, our requirements have always been concepts of stone tablets. To some degree, frankly, this is my fault, or at least my generation. Back in my original programming days, back in the ’70s, when I was writing code, I’d sit down with the customer and rewrite some code. It wasn’t a lot of code, so it was easy to do by 1. Turns out, when we got larger and larger, these problems got larger and larger, we needed a team to work on them. We finally began to tell the customer, “Tell me what you want and go away, please.” But you want to sign it in blood. Sign in blood what you want, we’ll go away, we’ll get it. Trust me.”

We pushed the customer away. Turns out, that’s a really bad idea for complex problems. Again, you don’t know what the answer is. For complex problems, we want to move from the stone tablet version of the world into how fast can we try out a new idea? How fast can we try out ideas? You basically want to get in this process of trying things out very aggressively, because there is no expert. There’s only ideas, “Maybe this’ll work, let’s try it today. Maybe we’ll make some more money. Okay, what’s another idea? Let’s try that one.”

Competitive advantage is how fast can I go from an idea to trying the idea out, and either accepting or rejecting it, and trying the next idea out. This sort of stuff slows you down. We want to have a whole different relationship with our customer in order to do this. One of the mantras that we used at Forward was “Experimentation Drives Innovation”. This was our watchword and how we thought about ourselves. The concept of experimentation is, we’re going to try things and they will fail. Expect it. If you don’t expect the failure, if you’re trying to make sure the failures never occur, you’re not trying to solve a complex problem. You got some easier problem to solve.

For complex problems, you will have to experiment, and they will fail. We were very good about this at Forward. We would try our ideas out. I would say probably 6 or 7 ideas out of every 10 failed, but the 3, we made a lot of money off those 3. We had one point where we had 50 employees at that point in time. Probably about a third of those were programmers. We made 50 million pounds that year. By being aggressive in how fast we could try ideas out. It works extremely well.

Re-think interactions with customers

[22:00] All right, you also got to rethink how you’re interacting with your customer. Colleague of mine, back in ThoughtWorks Day, we drew this triangle many years ago. It basically sort of says, characterizes how you talk about requirements in Agile. Most Agile process have a concept of story. You take a story and break it down into tasks. We said, okay there are other higher level things. Things that you might call a feature, and above a feature is sort of working on a project, and these projects are associated with some sort of a business initiative at the corporate level. The nice thing about Agile, it’s very traceable. Whatever you’re working on, you can tie it back to a business initiative.

Most of your Agile processes say, this is how I interact with my customer. My customer decides what the stories are, we measure the stories, we count the stories, we estimate the stories. This is our level of estimation. Unfortunately, when I go into Agile’s shop and look at how they’re working, you see a lot of this, where in fact they’re managing the programs at the task level, which is not very fun if you’re a programmer. It’s like, “What’d you do yesterday? Why’d it take you so long?” It’s like, “Well, I can’t wait to go home. I don’t want to be here.”

One of the things we’ve done is basically we change our level of interaction with the customer to raising our level of interaction to the feature level. “Customer, tell me what you’re trying to accomplish, tell me some KPIs, and then get out of my way. I’m a programmer. I’m really good at figuring out algorithms. Tell me what win means, and I can figure out ways to win, especially with these complex environments.” We changed our interaction models with how we interact with our customers. The customer role is now to sit with me and generate ideas. We’re going to generate our own ideas as programmers, and we’re going to keep doing this.

This works, again, extremely well. We don’t want to get caught in the story level. That’s actually too low for this sort of problem solve. It slows you down. The other thing we started doing is we started measuring our programmers on different metrics. I’ve been a programmer since 1968, I’ve been measured about everything you could possibly imagine. Function points, lines of code, call links, literally characters I’ve typed into the keyboard. How many characters did you type in today? Basically, it’s just a milestone. Believe me, I can game all these metrics, and we do. We game these metrics to make sure we succeed, because that’s the metric.

We started using a different set of metrics with our programmers. We started giving the business metrics. How much money we’re going to make. How many clicks did we get? How many sales did we make? What’s the login time? Page retention times? These became the metrics we gave to the programmers, and believe me, we started playing these games. We played this game too, only when we play this game, we all make more money. We’re all more successful.

We had a lot of cases where the customer would come in and say, “Wow, what did you do yesterday? We got more logins yesterday.” “We tried such and such trick, and it worked.” “Wow, I never thought of that.” That’s because we tell the programmers what the game is. The game is this. Tell us what the real game is. That’s very important to change what we’re measuring. That’s one of the process changes we need to put in place.

Mitigate organization inhibitors

[24:59] It turns out the way we organize ourselves almost encourages slow processes. It encourages and actually discourages a lot of innovation. For this, I’m going to talk about the key of this is overspecialization. The thing I really wind up seeing … Hi. She’s my timekeeper. It may be for me. We overspecialize, so we tend to actually do … We overspecialize our people. The theory behind overspecialization is a specialist is faster. We want to make sure our specialists are doing the things they’re best at. Of course, we know now we’ve underestimated completely the cost of overhead communication between the specialists, and of course all the work imbalances that created. It turns out, that completely eats up any of the productivity you gain that way. Basically, the Just in Time stuff and all the stuff from Japan, all the Agile movement has told us that’s a really bad idea.

Specialization & Changing titles

Alright, so let’s do sort of a case study. It turns out, the titles are in fact become the concept of specialization. Specialization’s almost encapsulated in your title. This was a case study. I came back to an organization that had about 50 IT professionals. We had about 25 different titles, and we had 0 people who knew what we were doing. This is what I walked in to see. Literally, the scrum master was trying to understand what was going on. At a scrum master level, because nobody else had a picture, because they’re all specialists.

That’s what we wound up with. Basically, the idealists pick the titles. We got to fix this problem. The specialists are not working for us. We fixed the titles. We took an approach that said, “Let’s define what we care about and the level of competency our HR people have and things we care about.” I’m kind of a fan of the three tier model, master, journeyman, apprentice. You can use a fourth tier, you can rename it. It doesn’t really matter. Then we went through and identified the technologies we liked. The things we thought were important to the business. Java was on the list. I tried to get Java thrown off the list. Clifton wouldn’t let me do that. Clifton will explain why he didn’t do that later.

We had a list of key technologies. We basically had the programmers assessed related to their skill level in each one of these key technologies. We kind of had that mapping, and then we went through and defined new titles. We killed the concept of Java Tech Leads, and Scrum Masters, and all these other titles. Killed all those things in favor of these titles. If you wanted to work on one of the new projects, this was the tile you had to assume. Yes, I can’t turn around and change your tile because it’s contract or whatever, but I don’t have to give you the new work. You want to work on the new stuff, those are your new titles. You get to choose.

[27:40] We called you a developer if you’re competent on one of our key technologies? We called you a graduate developer, you’re competent. I put this for Clifton’s purpose because Clifton wanted it, but why would I hire somebody who can’t do anything? I’m not sure. We never hired any of those guys, but it’s easy to put them on the chart. we called him a senior developer, you’re an expert. If you’re one of those masters of technology, whether it’s database technologies or perhaps Java, we called you a senior programmer. This is traditional structure at this point.

Then we did something a little weird. We called you an Assistant Developer if you’re competent in 5 to 7 technologies across the board. Competent, not expert. These are your full stack developers. These are the sort of guys I can give a problem to and they can solve it. I can tell them about a feature, and they know how to carve up between frontend and backend, deployment architectures, and the like. They know their limit. They know when to go grab the experts.

We also threw in the accounts of a master developer, just to make it interesting. We would pay a senior developer the same amount of money. If you’re a program that came to us and says, “Gee, I want to work on iOS, because I don’t know it,” we’d say, “Fine, that would broaden your skills. We will invest in you to learn iOS, because we’re trying to create more of these system developers.” Different mindset. “We’re not trying to use what you’re good at, we’re trying to grow your brand to solve real problems.

He had a parallel track there. Working for the Daily Mail, the Daily Mail was founded in, I think, 1890, so it’s 125 or 26 years old. Run by Lord Rothermere, the fourth Lord Rothermere of his title. I go to HR in this organization, say, “I want to change the titles.” What do you think they’re going to say? They loved it. Surprised me. I wasn’t expecting that. They don’t want to be in the business of classifying programmers. That’s nonsense. There’s forms and … They don’t want to be in that world. If we’re going to be doing it for them, I love this stuff. We got an endorsement from a 125 year old company that do this sort of stuff. It worked really well.

[29:36] The other thing we did was we fixed the furniture. This is why Kent Beck said in his first book, “You’ve got to make sure people who are working together are sitting together,” for very good reasons. We actually ripped out all the desk and put in tables. This is my doing this in India, by the way, but we did this as well at Daily Mail.

Concept of leadership

Finally, we also have the concept that we don’t have any dedicated leaders. There’s no concept of a leader as a title. The teams will pick their own leaders based on what they need to do. Early on, when it’s probably your architect running the team, but we get our time to sort of deploy stuff, somebody with more operational experience should be the guy running the team at that point. And we steal this, basically from the idea of this sort of book on cultural anthropology, because you look at this book and it says villages never had a dedicated 100% time leader, until they got to be 100 people. You’re sitting there with a team of 4 or 5 programmers, you’ve got a full time manager? Really? This is not the rule. You don’t need that full-time manager. He needs to be doing something else as well.

We went to the concept of leadership being circumstantial, and we bring up the right leader, the right leader will emerge as necessary. That has worked really well. The other thing is, we decided you don’t want to keep reforming teams around projects because projects kind of don’t have any meaning anymore. We don’t want to necessarily do a big thing and then ship it. We’re kind of incrementally doing stuff. One of the things you want to be careful of is every time you shuffle a team around, it takes a while for them to get productive. Don’t keep shuffling a team around. Bring a new problem to them. They already know how to work together. Keep the teams together. Don’t play musical chairs with your programmers. They’re not just elements in a spreadsheet to be run around. They aren’t instantly productive. We put a team together, and we keep bringing new problems to the team, because they know how to solve problems.

That’s the difference between dealing for an organization perspective. If you want to go faster, it’s not just microservices. You need to pick a couple of these other things to sort of complement microservices, or otherwise I think you will fail and fail badly. You probably need to make sure you’re going into the cloud, make sure you’re using central container architecture, maybe use some sort of manager-less process, because you’re solving complex problems. You want to go fast, these rules have no sense. These are things you need to do. If you do these correctly, then you’ll wind up with sort of the thing we had observed when we worked in London, and then later on at the Daily Mail, is yeah, we’re staring at a hockey stick. This is a hockey stick on the log chart. You while you’re doing a hockey stick on a hockey stick. You get absolutely insane how fast you can go.

This is the benefit of, in fact, fixing some of these other problems and making it work. That’s the story. I have some acknowledgements, though I don’t have time for those, and I’m completely out of time, I suspect, presenting.

About the speaker

Fred George Profile Photo

Fred George is an industry consultant and has been writing code for over 46 years in over 70 languages. An early adopter of OO and Agile, Fred continues to impact the industry with his leading-­edge ideas.

Like what you read?

Signup for a free FlockerHub account.
Sign Up

Get all the ClusterHQ News

Stay up to date with our newsletter. No spam. Ever.