Transcript
O'Connor: It's nearly 12 years since Equal Experts was founded and I've been there for about five or six. We're a software consultancy and we have learned, in those 12 years, a shocking truth. We're all software people, we understand computers. Turns out people are more complex than computers and a lot of our journey of scaling Equal Experts has been learning how to handle that complexity and how to grow without losing what makes us special.
Equal Experts
We've all worked in other places before, so Equal Experts is made up of experienced software professionals. We've all worked at a number of different places and most of those places have shared some characteristics, most places are a bit hierarchical. There are communication problems that comes with that, things like appraisals that nobody likes. There's a number of things we thought, "Well, let's try something different." We're agile software people, we like to think about continuous improvement and how to iterate a problem and improve it, so we should think about that for how we work as well, because we don't build computer systems like this anymore. Why should we run our businesses the way that we did in the '60s? Can we take some of the lessons that we've learned in how to make better computer systems and apply that to how we run the business?
Command and control hierarchy doesn't work for us. A really important thing to bear in mind for how Equal Experts works is that a large proportion of our consultants are associates, that is, they're contractors. Not only do we not like telling people what to do, we can't, I wouldn't like to try, I'd get laughed at. I don't have that kind of power over the people that I work with, they're my equals, so that's where the name comes from. Equal Experts, we are equal professionals to each other, so we have to work together, which is good because collaboration is how we solve difficult important problems. We whole-heartedly believe that decisions are best made by the people that are closest to the problem, they've got the best context. They are the best able to make a decision. In a traditional, hierarchical place, if you needed to make a decision, you'd quite probably have to go and ask your boss, who might have to go and ask their boss. They might have to take a proposal to a board, it might take ages. You've probably heard that kind of cliché of you can order a meeting for 20 people and nobody bats an eyelid, but try to spend 500 pounds in most typical organizations and they're like, "Oh my God." You just don't bother. There's a lot of good stuff that you lose by decisions being too slow and too difficult and just too annoying to make. We think, "Can we do better?"
Just to give you an idea of the scale, we've grown really rapidly in, over a decade. Dan said 2000, I've got 1,500, it's actually hard to put a number on the number of people in the network because right now we include not just the 800 active consultants that are working right now with clients and the 290 employees around the world, it's also the network of people that have worked with us in the past that have gone somewhere else, they're working somewhere else for a while, but they're still part of Equal Experts. They're still part of our network, we look forward to working with them again, and when they come back, they'll bring something new that they've learned from working with other people and they'll introduce new people that they've met, it's great.
The joke I like to tell, brace yourself, I'm going to try and tell a joke. It's like Hotel California at Equal Experts, you can check out any time you like, but you can never leave. We have 80 clients at the moment and many more that we've worked with in the past. We think of our clients as being part of our network, and the clients that we're not working with now, we very much hope to be working with them again, it's all about the long-term.
The network is what makes Equal Experts special. If you think about, what's a characteristic of the network, a bigger network is a better network and that's what we think around when we're bringing people into the network. Everyone contributes something different and we can be better together. We can support each other, we need to help each other. I find that one of the things that makes it powerful working with part of an Equal Experts team is that there's a critical mass of people that share values, not just technical values, but cultural values, and we believe in the same things around how to make better software and how to influence change. I find that, as an individual, it's really hard to influence change when working with clients or, indeed, working anywhere. With a critical mass that's pulling in the same direction, it's remarkable what you can do, we are stronger together.
We're all over the world now, we started in London and that's still where a lot of our business is, but we've now spread all over the place and we've done this by spinning off into different business units. That decentralized network is key to how we've spread around the world because we let each business unit make their decisions about how they should operate based on their environments and there's not this centralized direction because people closest to the problem or to the opportunity have the best context to make the decision about that, which is cool.
Bigger Is Different
We've discovered that bigger is different. It's not bigger is better, it's just different and different sizes of bigger are different from each other. We are learning that, as we continue to grow, we have to keep thinking about, how can we change how we operate so that we can keep what's special and get better.
When we started, it was a relatively undefined group of people. I mean, it was, to a large extent, a bunch of guys in London that did Java in the early days. There was a bit of structure, but it was really malleable, a lot of this is when you are developing products. In the early days, the important thing is not, how am I going to scale this? It's about, does the world care about this? Finding product market fit is the most important thing in the early stage of a product and it's the same in the early stage of a company. We could never have predicted 12 years ago, 10 years ago what we'd become now. If we had tried to put in place structures that would support what we are now, we'd have got it wrong. The future is full of surprises, we grew where the opportunity was and I view this as a good thing, you could think that it's a bit reactive, but it's product market fit. You pivot to where the interesting stuff is and keep your options open to where that would be.
The trouble with that is that the number of connections between people grow really fast. In the early days, when you've got a small, self-organizing team, everybody knows each other and things just happen by magic because everybody knows each other. I'm sure as many of you know, what's the math equation N squared minus N over 2. If you've got five people, that's 10 connections, but I mentioned that we've got maybe 1,500 people at Equal Experts. That's well over a million connections, so you can't have it, that everybody just knows everybody, it's completely unmanageable.
There's a lot of problems in just letting it just figure itself out and just thinking that you can operate the way that you did when you were small when you got to this bigger stage, because it doesn't happen by magic anymore. You've got to actively influence the culture that you want, because it's left unattended, structure will emerge. There is no such thing as a company with no structure, what you might have instead is invisible structure or implicit structure, and that's incredibly dangerous. If you end up with cliques that are not welcoming to outsiders or you've got this hidden, tacit knowledge about the way the things are that you can't really articulate, it's incredibly difficult for new people to feel part of that community and to feel part of that network. In order for Equal Experts to get bigger and keep that specialness, we couldn't just see what happened and it was faster than we expected that we realized that new people coming in didn't have the same experience as people when we've been 10, 50, 150 people. We have to do something a bit different.
Growing
That's the question. How do you grow without losing what makes you special? We're software people, so what do we do if we've got a software problem that's too big for us? Well, we try to break it into smaller pieces. Then, we try to put together a team that can self-organize to find the best way to tackle that. Another thing that we really feel about our software is that you need to think not just about, how am I going to build it, you've got to think around, how am I going to operate it? What's this going to be like 6 months, 12 months, 3 years into the future? The operability of the organization is super important and it really resonated here when Katherine talked earlier about getting a change to build, to bed in and to change a habit takes a long, long time, and this is exactly what I mean around thinking that it's not just, how do we build a change into the organization, we have to find a way that we can live with it for the longer run.
Then that whole thing about inspect, learn, adapt, iterate, that easy stuff. That's how we do it, easy as that. Well, so how do we do it? One of the things is that we think about how to do distributed decision-making and we use something that's called the advice process. I'll come to what it is in a minute, but a few years ago, something very frightening happened. Our founder, Tom Granier, came back from holiday and said, "I read a book." I go, "Oh, no" and he does this every year and we keep trying to confiscate them, but actually, this one was pretty good. He'd been reading Frederic Laloux's "Reinventing Organizations" who talked a lot around, how do you make decisions in decentralized, non-hierarchical organizations, which sounded like exactly the sort of problem that we wanted to tackle.
To a very large extent, every business problem is a communications problem and we need to make decisions in the business and we need to make good decisions, and we need to make them quickly. We need to involve the right people, but we need to do it efficiently as well. I mean, fundamentally, running a business is making a series of decisions.
As I mentioned earlier, we fundamentally believe that the people most affected by a decision usually are the ones with the best context. We also believe that you can't necessarily predict who is the person that has the information or who is the person that's going to be affected by something. With these principles in mind, when Thomas went off and read his book, he thought, "Aha, this is what we're going to try. We're going to try using the advice process to decentralize decisions so that it's not people coming in asking Thomas what does he think, it's allowing people in the business to make decisions quickly and efficiently with the right people at the right time, and it's pretty simple, the advice process. You state your intention, what are you trying to achieve? What do you want to do? You make an active effort to collect feedback from the people that you think are relevant and broaden that as much as you can and then you make your decision. The key point is that it's your decision, it’s not that you're making a business case and taking it for approval. You seek the right feedback so that you are making an informed decision and then you're accountable for that decision going forward.
What does it actually do in reality? Well, I will try to talk about one that I've done. We're a consultancy company and we deliberately run really lean, so pretty much everybody that is in our network is working with clients right now. We haven't got a bunch of people sitting around waiting around for the next thing to spring up. Actually, that causes us a lot of difficulty, there's really interesting work that sometimes we just can't do because we haven't got people around. What I thought was that we can be a better business and we can do more interesting work if we just have a little bit more time for people to focus on, "Let's set up the next exciting piece of work as well as it can be." In order to do this, I think, "Well, I just put myself together a self-organizing team."
In a more traditional organization, I would put a business case together, I would ask for funding, I'd probably have to go and get a cost code setup or something like that, but that's not what we did. To a large extent, the advice process is just a Google doc. We have a template that we fill out, and the kinds of things that I needed to talk about were what I'm expecting to do, what kind of risks and concerns there might be, who do I think I need feedback from, things like cost and impact, all of that kind of normal stuff. So far, so normal, it's, to some extent, a business case. The thing that's different is what comes next, which is when I went around and got feedback from people.
There were some people that I absolutely knew, "Yes, I know, need to talk to that person, great, I'll do that. I'll make sure I've got that." Critically, this document that I'd written got shared really widely around the organization so that other people that I didn't necessarily know could have their input too. I got some really interesting insight that I would never have expected and I would not have used normally. I also got a bunch of people going, "I don't think this is a good idea, I don't think you should do this. This is not what I think the right thing to do is," which was really useful for me, but it doesn't mean that it's a no.
This isn't about looking for consensus, it's not about getting everyone to agree about everything. It's about seeking critical feedback and making a decision in light of it. I decided to go ahead with it and it was my decision to go ahead with it and it's now on me to be accountable for that. Really, just started, but I will be expected to come back and tell people on what we've got on. It was as simple as that really, decided on something that I wanted to do, get feedback, do it. It was probably about a month from me starting this to us putting the team together and I went on holiday for two weeks in the middle.
It's not perfect though, It's quite possible for things to fall between the cracks. If everyone assumed somebody else is going to do something and whilst we are fairly relaxed with our structure in our org chart, and what our responsibilities are, there is still that natural feeling of the, "Well, that's not my job. That's not my space to question," or, "That thing could do with being better, but I'm sure somebody else is looking at it," no, there's isn't, there's just the person that's seen it. We're really having to learn as a group how to break out of that way of thinking about ourselves as, you know, in our own boxes and feel that, if there's something that we think that the company could do better, we should speak up about it.
There are some things that we do still need to get exec leadership for. We do need to have somewhere where the buck stops, sometimes, that's for legal reasons and also just stop us doing anything completely nuts. This has not really come about yet, but what you could imagine is, you'd say, "Well, I think that we should really move our offices to the top of the Shard because it'd be a great view. It would be really cool. I'd be really impressed with it," and I can go and ask some people that I know are going to say, "Yes, that sounds awesome," and I'll go, "Yep, we've made a decision. We're doing it." Well, that would be a crazy thing to do, so there are checks and balances in place where, if something's going to cost a lot of money or have a lot of impact, then we do need someone to be the final word on it. In reality, that's never been an issue because this decision-making is really transparent and open. It's expected that you will share with the company what's going on, and so if you are doing something completely crazy, somebody somewhere will challenge you on that.
The thing that's probably the hardest is making sure that people are aware of these decisions being made though. Something I found most powerful about using the advice process to talk about putting together my pretty engagement team was that that information spread really widely as people shared the document and gave their feedback, which was ace, but that was probably 20 people saw that document and there's a whole host of other people that don't know about it. In a hierarchical organization, you might have it so that the boss is responsible for telling the people that work for them and spreading the information that way. We need to find a way in our networked organization of spreading information to people as and when they need it and we really haven't tackled this yet.
We use Slack a lot, most of our people are out on the client side. There's not many people in our office, which is another reason why we shouldn't move to the Shard, it's not a good thing to do. It's really difficult to keep track of everything that's coming through Slack, especially if you're out doing a client delivery project. There's an awful lot of chat that goes, just streams by and you're not going to catch it and you can get taken by surprise with things, so we need to get better at sharing information.
One of the things that we've started doing is that every month get together and talk about the advice processes that are on-the-go, so new ones that people are starting or things that are in progress that are getting updates. We get together, we do a really quick update of what's going on, which allows people to then have conversations afterwards around the ones that interest them, and it's had a really nice side effect of bringing us together as a community. We do it as a distributed meeting, this is one where someone was live form Leeds and the rest of us were in London that day, and it is proving to be reasonably effective in getting the word out, but we need to keep trying thinking of finding more ways to do that.
That kind of open communication we try to think, "So how much more can we do there and how open can we be? What can we share?" There's some information that we obviously can't, we mustn't share, certain types of HR information or financial information. That's got to be secret, that's cool. There are certain types of information that must be public. We must publish our financial records on the company sales every year and there's things like our intercept policy. We thought, "Well, why wouldn't we be open with that? Why wouldn't we publish that, that anybody else can use it?" We're trying to think, "Let's be as open as we can be." Not everything's quite so clear cut and we're learning that there are certain things that, it's not that it's a secret, but it's that it's sensitive. An example of that is that we did experiment with completely public Slack channels around who's going to go on what project. We quickly realized that that was just causing so much stress because people would get a little bit of information without context and would get really worked up about what was going on. We thought that actually open this for its own sake, that's not what we care about and it's more about thinking about, we'll be open where it helps us, but we have to be thoughtful about where it might hurt us.
Business as a Dev Team
We're software people, we think about running a company like we run a dev team and it works as a model. This associate model where a lot of our consultants are contractors, it works really well for us. A lot of companies view contractors as an expensive short-term fix for a problem and you'll get outsiders in and then as soon as you've got your capability yourself, you let them go again. This is not the way we think of our associates, we just think that some of the best people out there, some of the best software professionals don't want to be our employees, but it's great to work with them. If we can find a model that's the best of both worlds, so somewhere between being an employee in a consultancy company or being a lone wolf contractor, if we find a place in the middle where we're both happy, then happy days.
It allows us to change shape and size as and when required. To slightly torture a metaphor, it's like using the cloud because we can scale up where and when we need people, using people that are really good at what they do. This spreading around the world is a deliberate thing that we can be more resilient. We can use talent from all over the world and we can do the "follow the sun" deliveries. We've had a client recently where we had teams in Sydney, Pune, Bangalore, and Lisbon all working together around the clock, which was awesome. It allows us to go where the interesting work is and, frankly, spread the risk of Brexit and such like. Half of our revenue now is from outside of London.
Something that's trickier is, how do we break up monoliths? We spend a lot of our time as software professionals looking at big monolithic systems and thinking, "Well, this is too big to handle, it's too complicated, the communication overhead's too high. What are we going to do? We're going to break it up into microservices." Can we think about your business like this? Yes, kind of. I mentioned that all of our places around the world operate as largely independent business units and there are certain things where they'll call home as it were, but for the most part, they run their own businesses separately, which is great.
That's not quite so easy in London and South, because as I mentioned, that's half of our revenue. London and the South of England is already too big to really handle. As I'm sure many of you will be very aware of in the world of microservices, choosing your bounded context is hard. We're trying to think, "How do we split that problem into something that's small enough to manage?" This is our co-CEO, John Dickinson, in a design sprint, because that's the cool thing these days, working up ideas of how could we split London and the South into different business units that can operate independently. We are just on the early stages of that journey, but it is hopefully going to allow us to have that power and the magic of having small people working on the right-sized problem, but still fit in with that complexity of London.
Things go wrong. When we think about our systems, when we're building software systems or when trying to put processes for delivery, rather than trying to control everything, we accept that things are going to happen that we don't expect are going to happen, so the more important thing is that you've got measures in place that can adapt to things as they arrive. Don't build for control, build for adaptability, works for software, works for people as well. If we can have it so that the impact of something going wrong isn't too large, then we're in a good place. This is why we want to split out into smaller units of people where we can experiment in a safer place.
Cross-functional teams are better at solving problems, so we see that with software, so let's think about that when we're running our whole business. This talk is an example of that, this is a collaboration between me and someone in our marketing team to do these lovely graphics, I did not do these. Also, when I was working through what I was going to talk about today, I got a bunch of people together from all across the business, some people from HR, some people that are software developers, some delivery people, people from financing, all sorts of people, because I knew that they'd all have a different perspective on this and that I would get a better talk out of it as a result, I hope.
Just that world of operations as a second-class citizen. I would hope that most of you are living in the bright, new world of DevOps or whatever we're calling it now where it's no longer the case that the developers build something, chuck it over the fence, and then somebody else does the operation side of things. We don't think that is a good way to make and operate software, so why would we do that for our business? We don't want it so that we don't have people in finance or HR or marketing where, "That's their thing. I don't care what they're doing. It's got nothing to do with me," and vice versa. Can we use cross-functional teams to solve business problems? Yes. We have for HR, for example, we are still struggling with what HR means in a decentralized organization. There's lots of interesting challenges there, and in order to solve them, it's not just HR people working on there, it's people that are working with clients. There are people that are in all of the different operational teams and people around the world as well, because we know that the more different types of people, the better decisions we'll likely get.
People Are More Complex than Computers
People are more complex than computers, culture debt is hard to pay back. The concept of technical debt will be familiar, you'll make a decision that you know is going to have a consequence in order to meet some short-term goal. You see this with people, it's harder to fix. One angle is that Equal Experts is not as diverse as I would like it to be. I mentioned it was founded by a bunch of guys in London doing Java, I exaggerate, but not a lot. It's grown a lot through referrals and people tend to know people who were a bit like them, so there's not the diversity in the network that I'd like and it's not going to just happen by magic.
In the same way that your tech deck doesn't just get better because time goes on and you'll work around it. It's only going to get better if you put an active, thoughtful effort into paying down that debt. The same applies when looking at Equal Experts and thinking, "Well, how do we get more different people to join the network?" We have to be really active in going out and talking to people and being seen as being a place that wants lots of different people to be there and to truly live with integrity to show people that they'll be included too.
There's often a short-term pressure to grow really quickly. This is something where we try to be really strict about not growing just because there's a client pressure. It's quite common that you'll have a client say, "I just want 20 people tomorrow," and we have to be really strict and say, "No, we can't do that." We say no to our clients quite a lot, more than makes me comfortable sometimes. We know that if we were to take on a lot of people that aren't right for Equal Experts in order to meet a short-term goal, we know that in the long run that wouldn't be the right thing for Equal Experts or for any of other people that we'd brought on either.
We're quite selective about the people that join Equal Experts, not just on technical skills but values too. It is not worth us compromising on the people we bring in just to meet a short-term goal, that's a debt that's too expensive to pay back. We don't always get it right, interviewing people is difficult, so we have to continually try to get better at that. Just generally, it's just really slow and difficult to change behaviors. When we have had things that have been a consequence of what the early company was like, it's really frustrating to like, "Can we not just do this different?" It takes time and we have to be patient, and we're not naturally that patient.
The software metaphors only take you so far, there is consequence to change. You can't experiment on people, it's really frowned upon, people have feelings, computers don't have feelings, people do. You're always testing in production, you can't try out on somebody and then have another go later. You are always doing something for real and the consequences can be unpredictable. You're always making mistakes, in the world of software, if you find a bug, we want to fix the bug, but we also want to write a test so that the next time we see that problem we catch it. How do you do that with people? Is there ever really the same problem happening exactly the same way twice with people?
What are we doing about it? Is hierarchy a dirty word? Not entirely, I said this at the start around having, it's not that we've got no structure, we want to have a structure. It's not that we have no hierarchy, we want to have just enough that we can get by, just enough that we can break deadlocks and we can make decisions, and if the police come knocking, somebody can talk to them. That's never happened, I really hope it doesn't, but you see what I mean.
We have a lot of trust in people and this whole model only works because we trust the people that we work with. We don't have line managers, we don't do performance appraisals, we don't set targets for people. We've all worked in organizations that do these things and we don't think that they work. We're trying to find out ways that are better ways to incentivize people and to get the best out of people. We haven't solved that problem, but we're not going to just keep trying stuff that we genuinely think doesn't work. We just trust that people are going to do the right thing, but it's really hard.
It is really hard because a lot of the time we're doing these things for the first time, there isn't a lot of precedent for doing what we're doing. There are lots of software companies that have an associate model that are small, that are maybe in the 5, 15, 50 people, but there isn't a company that is trying to be like Equal Experts, that's at the scale where Equal Experts is at. It's just not predictable where we're going to grow, we can't prepare for it all. Diversity and inclusion is hard, all of this stuff is hard. We have a tendency to be quite introspective, that's why it's quite powerful to be here today at QCon on the culture track to hear about how other companies are asking these same sort of questions because it's important that we learn from each other and not just try and do everything from first principles all the time.
Summary
What have we learned so far? A few things. Bigger is different, we are making this up as we go along, that's not a bad thing, that's about us iterating and adapting. There isn't an answer, if we found an answer, it wouldn't be the answer for long, it would change into something else. We definitely believe that bringing new people into the network, different people into the network will make it stronger and that continuous improvement is the driving principle towards us being able to keep growing and to get to the next scale. We're quite big, but we're really small in the global sense when you compare it to some of the really big companies out there. If Equal Experts was 15,000 people, what would it look like? I don't know, but we would have to iterate, adapt, and learn to figure that out.
We are getting better at using the advice process, and it's as good as we've got, the idea of having an automated test in place, that we can get better at things, because the idea is that, over time, you'll see more examples of the types of decisions that have been made in the past and what was learned and you don't have to keep reinventing the wheel.
Some examples. We are often talking about new offices because as we go into new areas and new spaces and we grow, we need more space to grow. We're not going to the Shard, but we are going somewhere, as an advice process got raised to say, "Well, where should we be and how big should it be, and how much money should we spend?" all of this sort of thing that is needed. This is a conversation that's open across the people that are affected, so it's not just, you know, the COO is not making the decision in isolation. He's making it in consultation with the people that are going to be in this office because they're the best placed to know about it.
Another example of something that's a reasonably small-scale one, a question that my colleague Paul Keelan over there raised was, "Should I go to QCon? Should I buy a ticket to QCon?" It costs a certain amount of money and Paul lives in Manchester, so he had to get a train and a hotel, so he asked what he thought was his boss, don't call him a boss, he's not your boss. He asked somebody else in Equal Experts, "Can I go to QCon?" The response he got was, "Well, I'm not going to answer that question, you're going to answer that question. Do an advice process and get some feedback from other people." Paul got in touch with people who had been to QCon before who were able to say, "Yes, it's awesome," and it is, it's great. Gave him advice around how to get the best thing out of the day, it talked about how he was going to network and how he'd, you know, really make the most of it, which is great. Then, Paul still went to Steve and said, "So, can I go?" Steve went, "It's your decision. Do you think, based on the feedback that you've got, that you should go?" Paul said, "Well, yes." "All right, then, so buy the ticket." It came as a bit of a shock to him, I think, that this freedom to make the decision was there and it was so much simpler than how he'd experienced it in places that he'd worked before.
Something that was surprisingly controversial was that we renamed our Slack channels to fit a certain naming convention so they'd be more easy findable. This is an example of where we found some of the limitations of the advice process because what we had is somebody wrote a document, "I'm going to change this to that " and published it and then said, "I'm going to do this," and then told people again, "I'm going to do this," then, he went and did it, and they're like, "Oh my God. You didn't tell me about this.", "But I did. I told you loads of times. It was published here, it was published there" but people, there were, some of the people that were affected, they didn't see the Slack message, they didn't look at the document. They weren't aware of this thing that were affecting it.
Just making something available isn't enough, it's like in "Hitchhiker's Guide," those plans to demolish the earth, you know, "You didn't tell me about this." "Oh, well, they were. They were in a filing cabinet somewhere." Fill in the gaps. That's something where we've learned where we need to do more to spread the news to people that are affected, but equally, it's a learning opportunity for all or someone at work of how to get better at keeping our ears open and listening to the things that are affecting us. That trust to make good decisions and to do your own thing comes with a responsibility to keep yourself connected and keep aware of what's going on and that's pretty hard.
Shall we send a plane into space? I'm not actually kidding, this was actually a thing that one of our associates is a scout master and they were aware that there was a Guinness Record for sending an unmanned vehicle into orbit that they felt was eminently breakable, this scout crew, and they needed a small amount of money to do it. Through this conversation that he'd had with somebody else at EE, was like, "Well, we could ask just, does EE want to sponsor a spaceship?" To his answer was, "Yes," and we did, so there is now the Equal Experts Space Agency. It's a real thing and I think they've done it actually. If you look on YouTube, there's some awesome videos that they go sending their little spaceship into orbit and it also means that people can give themselves titles like Director of Rocket Science and Space Operations and what's not to like?
What Could You Try?
What could you try? What does this mean for you? Could you do something like this in your organization? Give it a go. The advice process is hard, but it's powerful, if you are in a position where you are making decisions, so if maybe you're the manager of a team or you've got some sort of leadership position, maybe there's a decision that you'll habitually make, maybe it's a fairly small one. Think around "Does it have to be me that makes this decision? Can I get my team to take this decision on themselves?" Choose something that's small so it's small and safe and experiment with it. If you can't trust them to make good decisions, you shouldn't be working with them. If you do trust them, why are you holding them back? Try trusting people.
Questions and Answers
Participant 1: Thank you, good talk, really interesting. I'm interested in, especially with what might be ambitious or challenging technology decisions, how it plays out. For instance, how it would work when we've got something to decide as a community and I've maybe got 10 or 15 tech leads that I want to involve in the decision-making process. What if it comes back 51/49?
Host: 52/48.
Participant 1: Whichever. I don't want to draw that parallel, I'm more interested in this one, in terms of you will often get a split and it's almost like we're not, now created another problem. I love the idea, I love the fact that it allows the team to get involved, but surely you must expose yourself to those kind of scenarios where it's not absolutely clear, but we've now found out a significant part of the team would be against what you're trying to do.
O'Connor: Yes, exactly, it's really difficult. I think a key point is that it's not about finding consensus, it's about understanding that there's different views. Somebody is making a decision, we haven't lived through that example of it being contentious and split and it's going to be interesting when we do. We have gone through a process of learning that it isn't about convention. A particularly hilarious example was that a team in Lisbon downed tools for an afternoon to talk about which lockers they should get for the office. On reflection, it was decided that that's not an effective decision-making process, so we've learned that some stuff, you just do it, you don't have to talk through everything. Yes, that split decision, somebody's got to be the one that says, "I know that we don't agree, but we're doing this, we're trying this and we're trying this for this reason, we're expecting this outcome, we're going to measure this outcome at a particular time and then we'll revisit it." Then, yes, hopefully, we all believe in a scientific method.
Participant 2: Great talk. I just want to ask the question around, whip limits on advices because, I can just imagine, if you've got 50 of these flying around and you're asking people for advice, that you're asking potential senior leaders to context switch while they should be doing stuff.
O'Connor: I wish I knew the answer to that. That probably is the problem that we've got right now, is that there's lots of things happening in parallel and you can't keep up with how they're all going, and I think we're at that tipping point with this alone now around, how do we put in enough structure? Again, it's that same thing of early on, it just kind of happened by magic and we're at that tipping point where that isn't working anymore. We've got to find something else and we haven't found it yet.
Participant 3: Can you explain why or how the contractors at Equal Experts are invested and what happens with the company? Because most contractors just get paid regardless. Many situations I've been in, if you just waffle around and waste time, the contractors are extremely happy because they just get paid for doing nothing, so I don't understand how you align their goals with the organizational goals.
O'Connor: Interview is not perfect, but we do try to use our interview to explore people's motivations. When I'm interviewing people, we look at tech skills, but we have another one which is looking at consulting skills and cultural values and all the rest. The kind of questions that I always want to explore in those interviews are about motivations, so tell me about how you get satisfaction from your work. If they can't tell me a compelling story about how they care about delivering value to a client and give me examples of times where they have built something, they impacted change, then it's not going to work out. It's not perfect, but it's a thing to try.
Participant 4: What does Equal Experts do for the contractors/consultants on the other side? You want them to do good work for you, directing the brand and that kind of stuff. I understand that. What do you do for them that's compelling beyond they can just go and get themselves a contract job somewhere?
Host: Nothing that would convene IR 35 certainly.
O'Connor: Good people like working with good people. People that work for Equal Experts, especially ones that have gone away and come back again, when they come back again, they say, "I love working on Equal Experts projects because I know that the other Equal Experts people are going to be great to work with."
Participant 4: So there's not a profit sharing or anything then?
O'Connor: Not for the contracts. For the employees, yes. It's a global profit share, it gets split across everybody, we all share in the benefit, but yes, the contractors do all right.
Participant 5: Thank you, thank you for that. You've touched on earlier, the kind of, "It's not my job" kind of attitude, and I'm guessing that you find some people ask or propose decisions, I suppose, more than others. How do you kind of get around that and try to encourage other people to do that as well?
O'Connor: So, if I understand correctly, it's how to get people to not be in their box about their job and their identity but to think more broadly. If I'm talking about the employees now that are involved in actually running Equal Experts, most people are involved in at least one working group where it's a cross-functional group of people looking at a problem, so we're trying to have it so that people are habitually working with people that have got other specialisms. That's building the habit, to use a word from earlier, of thinking outside the particular space.
I also think though, there's something that comes form working in consultancy, that we are quite used to having to be empathetic about what somebody else needs and put ourselves in the position of people that are doing other jobs, because that's what we're doing with our clients all the time. We're arriving somewhere and having to figure out who's doing what and what do they care about. Whilst it's not always easy to practice what you preach, we do try to use that approach when we're thinking about ourselves, and it mostly works.
See more presentations with transcripts
