Sure, so I’m chief architect at Zeebox, which is a second screen startup here in London. I’ve been working in the industry for about 20 years. I’m originally from Australia and I came to the UK about 10 years ago. Zeebox it’s about my third startup. So as chief architect often you are sort of viewed as the person that are living in the Ivory Tower and you are telling everybody what they need to do and that sort of stuff, but I definitely don’t take that role at Zeebox. I sort of view my role almost as Head Gardener, making sure teams are shaping their plants nicely and advising where they should prune and where they shouldn’t, or whether something it’s a good idea or not, but we definitely not dictate to our teams how they should build their systems. We try to work very much with our teams, we trust them, they are very smart guys, and I’m very lucky I work with really smart bunch of guys. And really my job is just to make sure that they are thinking about those things that they might forget in their day-to-day job.
I definitely like to think that I would work to myself now. I think I’ve matured quite a lot and learned a lot about myself and how I work. I learned a lot of empathy towards people and I’m trying to understand people a lot more and try and understand how I work and how I’m being perceived by other people. So yes, I think I would work for myself now, I get positive feedback from the people I do work with, so yes, I’d like to think so.
I think that unfortunately it’s still very common from what I see. I do see a trend towards a more relaxed style and a more trusting style of management. I feel that at least my generation if you sort of speak, so the people that are come up through the ranks over the last 10-15 years have suffered quite a lot of bad management and we are starting to step back a little bit more and learn a bit more about what management can be. So I definitely see trends to improving things but I still think command-and-control unfortunately is still quite prevalent.
4. I also saw that you like to build great teams, so in your view what makes a great team?
So a great team it’s a team that works very well together, that is able to understand what they are trying to achieve. So they understand the goal that they are trying to reach and probably more importantly that they put some time into understanding why they want to reach that goal. A great team sort of tends to do that naturally. The challenge’s taking a desperate set of individuals and bringing them together into a really good team, that’s very difficult to do, sometimes takes quite a bit of coaching with individuals and getting them used to working in a team. It’s really about building a sense of trust and honesty, making sure everybody knows that they are free to say what they feel without any sort of repercussions from anybody in the team. If they feel they can do that, then I find that you can reach consensus in a much smoother way, and people tend to give better work. Even if you do come to a decision or that somebody disagrees with, at least they tend to come to it with the attitude that they understand why there is a disagreement and there is no resentment or distrust built up.
So obviously you want the teams to be able to jell. It doesn’t matter if you have 7 geniuses if they can’t deal with each other. It’s never going to work. One of the pieces of advice I was giving very early in my career is: when you are hiring, you really want to hire someone better than yourself, because you want to go on and do more interesting things, so I’ve always kept that in the back of my mind. I’m never looking for tie myself, it’s very difficult to do because you have that natural bias towards somebody that you feel comfortable with, but I tend to keep in the back of my mind that I’m looking for somebody who is going to offer something different to the situation, so somebody who perhaps got different experiences or has a different outlook on things, but still has a personality that is flexible enough to work within a team.
So one of the things is really trying to build that share of understanding of what and why. If you concentrate on what the team is going to build, everybody comes out with a different attitude. If you concentrate more on why we are going to build this, I think you get better interactions within the team and people tend to understand each other a bit better. Encouraging conversations within the team really helps, and that conversations are around the water cooler or coffee machine. Those sort of things are in some ways even more valuable than when people are sitting at their desks talking to each other or even in a meeting room talking to each other, because they get a better understanding of how to communicate with each other and be understood.
I like to work where I feel that there is some sort of deadline or something that needs to be achieved. If there is no pressure to achieve something, then in my mind is very difficult to see why we we’re actually doing it. And there’s obviously not a reason for it if there is no driving pressure to produce it. I like to work in great teams. Great teams generally have quite a strong personality. So in the talk I talked about pressure is really sort of influence and almost persuasion and can be intimidation. But these are all natural things that we encounter in the work force and that is learning how to work with them and how to work with these great charismatic people that startup founders often are, to produce our best work.
So in common obviously a lot of the technology, even if languages and frameworks and operating systems things differ, they are all fundamentally things you’re used to working with. The patterns and approaches that you apply are equally valid in every industry. The differences tend to be on the focus of what you are working on. So when I was working in defense obviously safety critical was the most important thing and very early in my career I worked for three weeks to solve a bug and need to be told that would never get applied to the system because of the risks involved. So it’s really what is the focus of the industry, what do they think that it’s important with the speed of deliveries, important with the safety criticalities, important with the accuracies, important….
I think the commonalities are important, I think it’s good to move between industries, because then you learn to adjust your focus and your priorities. I think that when you are building a team looking for somebody outside your industry can be really, really valuable, because they bring a very different perspective and bring things into what you are working on that you would otherwise miss.
So my role at the BBC was kind of interesting one. BBC R&D was setting up a team, essentially trying to behave as a startup within the BBC and to try to encourage some more startup like practices for teams within the BBC, which was a very interesting challenge. I’d come from a startup and all of the sudden you are in a very large bureaucratic organization and one that has quite a lot of internal politics because of the division of people and budgets. You are dealing with a broadcast where things have to be done in particular ways within particular groups. So that was quite a learning curve for me. Even though I’ve worked in large organizations before that, I think the scale of the BBC was something all together different and I was coming into the seniority where I had to deal with fairly senior people across the BBC. And that was a challenging environment, but I think I learnt a lot from that around project management and interacting with senior people, which I’ve obviously brought with me to Zeebox. We have quite a few ex BBCers at Zeebox as you can imagine. And I thought we really seeded some good ideas inside the BBC at that time as well, so we introduced things like Kanban and different styles of project management.
So we approach Lean in a couple of ways. One is that we almost constantly question ourselves as to whether we actually need something. Do we actually need to build this feature? Is that something simple that we can do, do we actually need this service internally? And it can even come down with office space. Do we actually need a bunch of spare desks if they’re not going to get used? It’s really, really simple stuff. The whole Lean Startup methods of testing your ideas and building prototypes and testing those have worked very well for us. It has certainly changed our approach in what we are building. The working across time zone… so we have an office in Sydney, Australia, we have an office in New York. I think Lean has helped us in shaping the product because they were able to provide us feedback from the market that they understand and we can also test it locally with users and doing user testing. And we’ve learned to build only things when we really need them, we haven’t gone and internationalize the whole product from day one, we built just enough to satisfy our market.
I think obviously the context between a large organization and a startup is very, very different and you have different priorities. But I think the Lean principles, the seven principles that are outlined in Wikipedia, can be applied no matter your situation and trying to understand which of the seven principles are the more important for you at any one time and understand that you can adjust sort of the tension between those principles over time to better improve things. Obviously you are not going to jump in and change everything all at once, because every organization and every person has inertia and you are not going to work around that. But I think just understanding the principles and then stepping that from your day-to-day work and see how you can apply those principles I think, can make a big difference.
I think Scrum has been a huge success almost because it’s something that’s very marketable. It’s a very… set process that you can teach people within a short period of time, so 2-3 days and they get a Scrum Master and then can go and apply this. Scrum as a process I think it’s not too bad. The problem I have with it is blind application. Quite often it’s applied blind without any thought to doing it to improve our engineering process. Does it actually make sense to what we are trying to do and quite often it really just comes down to… we are going to take a current problem that already has a list of things that we need to do it and just chunking up into time, there is no learning involved. It just becomes a spring 1, spring 2, spring 3 situation.
14. What does, what approaches can help to bring innovation into an organization?
João's full question: I read a post on your blog on the dangers of skunkworks projects. I’m assuming that these kinds of projects appearing in the corporate world to help, to bring about innovation away from the system. But I got impression that you don’t really think skunkworks cut it. So what does, what approaches can help to bring innovation into an organization?
So I’ve seen skunkwork type projects done several times, usually within larger organizations. And I think the problem there is that the project that they do is often fairly successful, it often does very well. But then there is an expectation that the skunkworks team or the skunkworks idea can magically transform the rest of the organization which just doesn’t happen because the skunkworks team usually succeeds because they’ve been nurtured as a team, they’ve been given the space and the freedom to succeed as a team. And I think all that does really within a large corporation, it builds resentment from the rest of the company to that select group. They’ve been given the privilege if you like of working on something cool and fun, while they’ll had to do with everyday stuff. So I think if you are going to embark on that sort of project, it needs to be open and it needs to be… everybody needs to have visibility on what they are trying to achieve and why, so that they can learn from as the project progresses and not just the dissolution of the team at the end. It’s quite often that this skunkworks team gets spread across the company and then they get disillusioned because they don’t work with this great team anymore and they want to work with great teams, so they end up leaving.
So yes, I’d say it’s quite a strong DevOps space if you like. We have this attitude of “you build it and you run it”. So each of our teams are responsible for this or this is from inception and definition right through to running in production and maintenance and monitoring. They are the ones that are going to wake up if everything’s fall over in the middle of the night. We’ve not really spent too much time on process, or even tooling for that matter. It’s really being trying to cultivate an attitude of ok, this group owns everything that they produce and the responsibilities and owning something is you have to see it all the way through. So there is no handing off to an operations group, we don’t have an operations team, they are responsible for working how it needs coming to production, how it needs to be monitored and so forth. We have a platform team, which has quite a strong operational focus, and they have responsibility of some of the more core infrastructural type pieces like LDAP and certain databases and tooling for Amazon and so forth. But they don’t babysit anybody else as work, if something really goes wrong and our team needs help, we get called into helping them but we don’t run anything for any other teams.
16. How does Lean relate with DevOps in your view?
I think DevOps and Lean mesh very well, because DevOps is really about trying to remove barriers as you go down the chain and Lean is about removing waste and any sort of barrier or queue or handoff is essentially waste. Conversely also, provides really good opportunities for learning, so in Lean you talk about amplifying your learning which many people take as learning from your customers but it’s also about learning about how you work and the things you work with and the tools and frameworks and so forth, it provides means for your team to learn how their system actually works and is actually used in production.
Definitely I think they exert influence on each other, if you have a very strong monolithic architecture it’s often overwhelming to try to introduce a DevOps type environment because you have so many people working on this one big chunk of code that needs to get into production. So if you are taking the view that you want people to own their space, then it’s a… There’s the Conway’s Lay which says that your architecture reflects your organization, so if you want people to own their pieces you have to essentially have the architecture reflect that and let them own that piece through to production. It sort of encourages easy adoption if you have the right architecture, and I think if you want to go to a nice DevOps and we often think about that as the deployment pipeline approach, then having those smaller pieces really makes a difference.
18. Before closing, do you have any final thoughts to our audience?
I definitely encourage people to go read and learn about Lean and DevOps and Continuous Delivery. There are a lot of really nice books out now and a lot of resources on the web, it doesn’t cost very much to sit down and watch a few videos on InfoQ about how people have made this happen and just enjoy what you do.
João: Ok, thank you so much Glen!
Thank you!