A look at how organisational structure can be optimised to help your business get the most of its resources, and get prepared for growth.
In May 2020, Mark Logan was commissioned by the Scottish Government to undertake a short-life review into how Scotland’s technology sector can contribute to the country’s economic recovery after the Covid-19 pandemic, providing recommendations on how to develop a world-class tech sector.
Auto-generated transcript - may contain errors. Tap a timestamp to jump the video.
Hey, gang, welcome back to Turing Fest. We're on week five of our online series that is Turing Fest twenty twenty. So we're into the second half astonishingly. It feels like we just kicked off. Just a quick mention that all of the keynotes and interviews that we've had to date, everything's available to rewatch on the platform, which we're using Swapcard, as you'll all know.
So yeah, you can rewatch if you miss out on anything, you can go back and check it out again. It's also going to be available after the conference finishes. So we wrap up on December the tenth, but all of that stuff will transfer it over to the TuringFest website, but you'll still be able to access everything.
Okay, so coming up later this week, on Thursday, we have Val Geiser, who's one of our speakers last week, She's hosting a roundtable discussion on email marketing. That's those discussions they're small, it's a small setup we were looking at sort of seven or eight people typically any more than that it gets a bit unwieldy.
So if you want to, have a chat with Val definitely sign up for that it's gonna that's gonna be popular I think. She's brilliant, she's really really excellent email marketing is the subject. She runs fix my churn this is really her sweet spot so well worth getting into that.
We've also got an interview with someone that I wanted to have a chat with on the TuringFest stage for a long time, which is Erin Platts. She's the head of Silicon Valley Bank in Europe. Erin's a phenomenal woman, phenomenal leader in the tech industry and someone who has every time I talk to her she's got been promoted.
She's had an incredible career at SVB and she's also in a fascinating spot. SVB is basically at the intersection of technology and capital so have a really great vantage point of what's going on in the European tech industry. So really, really lots of insights that we'll get out of that chat with Aaron. But back to today.
So we have three keynotes as ever for our Tuesday sessions. On the build track later on today, have John Cutler from Amplitude. Any of you who are in the product world will know John. He's highly renowned there and delighted to have him with us.
He's going be talking about the North Star framework, something that's been mentioned in a couple of talks so far. Itamar Gillad touched on it and Mark Logan's going to touch on it again today. Then we have Chris Savage of Wistia. So Chris is the founder and CEO, co founder with Brendan and CEO of Wistia.
Great company, one of my favorite, tech companies out there, a long time supporter of TuringFest. As some of you may know all of our videos etc hosted by Wistia, great company. And Chris lots lots of interesting stuff to talk about with brand and content.
But first up we have a man who's really been in the news a lot this year in Scotland at least and he he's taken the bull by the horns really with with how do we reshape the Scottish tech industry and how do we build an ecosystem and an industry that can compete internationally.
Scotland's doing okay for sure, but there's more we can do, a lot more and Mark wrote, as some of you will know, he wrote the Logan Report commissioned by the government earlier in the year, Fantastic document and has really laid out a blueprint for what we need to do in Scotland to sort out our tech industry and get us onto a global footing.
But for today, he's talking about things a little bit more directly related to all of us, which is around organizational health and how do we optimize our orgs for scaling. So without further ado, over to Mark. Hi, everyone. How do we unlock the scalability that's inherent in our organizations so that we can execute on our strategy and meet the goals of the business?
Well, in this presentation, I'd like to share with you a technique which I call scale models that enables us to do just that. And it's a technique that I found profoundly valuable to my own career. And we're going to discuss first of all, what scale models are.
We're going to look at some of my favorite examples that have really helped me over time. I'm going to give you some tips and tricks about how you can create your own scale models. And I hope that at the end of this presentation, you'll think about scalability differently than you did before.
But first, let's briefly reflect on the true nature of scalability. We often think about it as a function of the number of people in our business, but that's not strictly true. If it was, then we wouldn't see so many situations where we add people to a team or people to a business and we end up not getting more done.
In fact, quite often things actually slow down. So scalability is not directly a function of the number of people in our companies. It's more properly thought of as a function of time, or rather what we make of time. Consider that in any organisation, you have some kind of structure which essentially forms a network that might be a top down hierarchical model, or it might be a more distributed model like squads and tribes, for example.
But in any of these networks, there are always focal points, concentration points for things like decisions and experience. So therefore it follows that the scalability of our business is actually a function of the personal scalability of a relatively small number of people. And from that, we can, of course, conclude that if we can improve the personal scalability of those people, and I suspect that applies to many of the people who are in this session today, then we can also improve the scalability of the business as a whole.
And that's where scale models come in, because they allow us to use low cognitive effort to make high quality decisions. And therefore we can make decisions more quickly, more frequently, and we can also save much needed cognitive energy for those really hard things that we haven't come across before.
And shortly, I'm going to bring skill models to life a little bit for you by sharing some examples. But for now, I'd like you to visualize that if you're a leader in whichever capacity, that one of your jobs is to essentially over time fill a toolbox with scale models that you can take out and use on a daily basis using less energy to make high quality decisions.
So that's what we're going to look at here. And let's now look at some examples from my own personal toolbox. These are from disparate areas of leadership just for illustration. And I hope that they will not only illustrate what skill models are, but also that you'll able to use these examples in your own experiences as I have done.
So the first example we're going to look at is called logarithmic prioritisation. So what does that mean? Well, consider our earlier diagram where we talked about that small number of people that determine the overall scalability of an organisation because they act as concentration points.
Another way of saying that is that these people are overloaded with priorities and practice. And if you've ever been in that position, I'm sure you probably already are, then you'll know that pretty much every time management course recommends that you get a two by two diagram like this, and you array your priorities onto it and focus on those ones in the top right hand corner first, and so on.
And that works quite well up to a certain threshold of priorities. But beyond that, it breaks down very rapidly. So for example, if we align our priorities into these categories, we often find that we've still got a whole bunch in the top right hand corner, and we're still overwhelmed and nothing's really improved.
So the next thing we often try and do in those circumstances is to rank those priorities in some relativistic manner so that we can work in number one more than number two, etc. All very obvious. But in practice, that usually still doesn't work.
And the reason that that doesn't work is because although in this diagram, these priorities look somewhat separated, it's not like that in our minds. In our minds, it's a bit more like this. So these are slightly separated, but they're all absolutely important. So for example, priority one has a score of nine ninety nine out of one thousand in your head, priority two nine ninety eight.
So the difference is a rounding error on zero, and they're all still absolutely important in psyche. So we tend to still thrash around between them. So, like everybody else, I experienced all these issues myself. And then I realised I could put a scale model in place that would help me deal with this situation much more easily.
And that scale model was based on the simple observation that in practice, priorities tend to organize themselves in a logarithmic fashion. And what does that mean? Well, it means that one of the priorities is always a practice in order of magnitude more important than the second one, which is in turn an order of magnitude more important than the third.
And that's what it means to prioritise logarithmically, to embrace that practical reality, as always seems to have applied in my experience, so that you can much more quickly focus on what really matters. So simply to recap, I always take my priorities and apply them at this.
Priority one is ten times more important than priority two, and so on. And when you do that, you end up with a very different looking priority graph. Now we can see where very clearly where we should be spending our time, where we should spend a little bit of time and then where we shouldn't spend much more time.
And when I take my priorities and organize them like that, and then I look at my calendar, I often find of course that by default, I haven't prioritised my time in that way. So the first job to do is to shift my time allocation to more reflect the priority of these orange bars here.
And you don't have to literally arrange every minute an exact, alignment to that, but you're far more likely to put time into the things that really move the needle if you use logarithmic prioritisation and then simply do that calendar check to align to it.
And yes, it does mean that you're going to have to defend your allocation of time against those people who wish you were working in priority seven, priority eight, but you are far more likely to more consistently move the needle in your business, make impact on a regular basis, and that gets noticed and that gets results.
So very simple model. Whenever I've got priorities in front of me, I always very quickly organize them according to logarithmic prioritization and get started. Saves me a lot of time, saves me a lot of grief. The next example we're going to look at now is from operational management, and it's called Only One Constraints.
Now, in your business, you can really think about it as a set of processes. So building features, fixing bugs, onboarding customers, handling customer tickets, onboarding employees, and so on. These are all very important processes that make your business work. And it's almost always the case that as your business changes, as it grows, for example, processes start to slow down, because we add more people to them, more touch points, more complexity to the processes.
And we try to push more stuff through those processes. And very frequently processes actually don't just slow down, but they slow down catastrophically. Then the question is, well, what do we do about that? Now, again, that question leads to a sense often of feeling overwhelmed, you know, and our minds or processes look a bit like this.
And we're not sure where to start. And because of that, we start to grasp at plausible sounding solutions. For example, we should deploy Salesforce everywhere in the business, or we should work on six or seven bottleneck areas at once and so on. It's all overwhelming. It's all cognitively exhausting.
And once we've chased those rabbits down those holes, we often still find that we still haven't actually made the process go any faster. So we need a better way and one that doesn't overwhelm us in terms of mental energy being required. The model I use here is only one constraint, it's borrowed from the theory of constraints.
I've simplified that a little bit further to make it easy for me to apply without an awful lot of cognitive effort. And this essentially is the model. You should analyse your processes as essentially a water flow system, a set of pipes, with water flowing in the top left corresponding to the raw materials of your process, requirements, for example, and water coming out the other side, the bottom right, being the finished article, the software implemented as an example.
Now, this analogises to your process. The individual pipes you can see in different widths, these analogises to stages in your process. And if I was to ask you, which of these pipes in this water system governs and determines the overall flow rates of the system?
I think most of us very quickly would spot that it's the thinnest pipe roughly in the middle of the diagram there. That's very intuitive. And we obviously wouldn't waste time trying to make pipes before that point or after that point wider, because we know that would make no difference to the flow of water through the system.
But when we bring this back as an analogy into our process world, that's exactly what we do. We try to make several pipes at once wider, we work on pipes before the thinnest pipe and pipes after, and then we're surprised when nothing changes.
It's a lot of wasted effort. So this model is profoundly powerful because it simply says that in any flow, in any process, there is only one constraint. And all you need to do is find that one constraint. And that feels a lot easier to do mentally.
We can always find one thing, can't we? Not ten or twelve, we can always find work on one thing. So it's a very powerful model. And, you know, here's an example from a previous job, in a previous company I was in, where we had seen our billing reconciliation process slow down significantly.
And we mapped it out on the wall. It was an old process, ten years old. And we knew that because there was only one thing governing the overall flow rate through this process, that we could find one thing, it's easy to find one thing.
And we found that and we elevated the bottleneck, so the process went faster. And we repeated that process because of course, once you've done that, there's a new thinnest pipe, repeated that process until we got the flow rate that we needed. So very simple, very powerful process of our scale model that requires a little effort to make high quality process optimization decisions.
The final example from my toolbox I'd like to share right now is from organisational design. And we call this one pushing agency to the frontline. Now, have you ever experienced when you're building an organisation, changing an organisation, that the changes you're making sometimes feel a bit arbitrary, and you're not really sure they're going to make things better.
And we're all aware, aren't we, of the cynicism that people and all businesses have towards organisational and structural change. So there's not without foundation. So what we're lacking is a simple, North Star to tell us, is our organisation right? And how should we direct changes in it?
And that's where the scale model becomes very powerful. So think of your business, in other words, a bit like this. It's a sphere with an outer green surface here, representing the front line of the business where the work is actually done. And when the business was smaller, it was just the black sphere.
So when you started out, that was just a black sphere. And decisions were made over in the center of that sphere, and the work was done in the outer edge of that sphere. But because the company was so small, the people making the decisions were also the people on that frontline.
But then as the business grows, we add layers to this sphere, the frontline pushes away from the centre. And if we don't push agency out at the same rate as the company's frontline moves out, then we start to see the business slow down.
For example, as illustrated here by these blue arrows, decision times take much longer as the business grows, the frontline gets frustrated and of course passive, the centre gets overloaded. So this is essentially the fundamental scale model for organisations that I use. And I always ask myself, is agency to get things done present on the front line of this business?
And if not, what do we do about it? And that's my North Star. And by agency, I simply mean, do the people on the front line feel sufficiently competent to do the job? For example, I used to manage two people successfully, can I manage ten successfully?
Now we're bigger. Are you investing in my ability to do that? Do they have clear ownership so they know what they can make decisions about without asking? Are those good decisions because they're aligned to the strategy of your business? And do they have the resources and all the forms needed to do that job?
If you continuously ask yourself these questions about the people in the front line of your business, then you'll very rarely go wrong when it comes to organisational design. Push agency to the front line is a simple but powerful model there. Now we've looked at three of the models I frequently employ in my jobs.
But how about creating your own models? How do you do that? Well, of course, the place to start is to see if you can borrow other people's models like these ones, for example. But if you can't do that because the circumstances are unique in some fashion, then the recipe is very simple.
The first time you encounter a new situation at work, you simply, that you haven't seen before, you simply figure out what to do from first principles. Use a lot of cognitive effort to do that, don't skimp on that. But then consider if it's worth taking a little bit more time to turn that into a memorable scale model.
So first time, it's first principles, second time, it's a model. And to help us do that, the first skill you really need to develop is this notion of model alertness. Once we start explicitly thinking about scale models, we start to see opportunities for them everywhere.
Let's give you a couple of very quick examples. A colleague of mine, an ex colleague of mine, when she started out on her executive career, was in one of her first executive meetings. The next agenda item came up, and that was company X might be in danger of infringing our IP, what should we do?
So she started to work through internally silently in her head, all the possibilities. So we could ignore this, could be frivolous, but that could result in other competitors piling in doing the same thing. But if we sue this company, they might sue us back.
And that's very distracting when we're extremely busy and so on. But her CEO, very quickly simply said, we'll sue them, now let's move on to the next agenda item. And she was astounded at how quickly he processed these options. So after the meeting, she asked him, how did you decide what to do so quickly?
And he said, it's quite simple. Whenever someone is in danger of fringing our IP, we always sue, because our IP is all we have. Now, that CEO had clearly created a scale model in the past. First time he'd experienced this situation, he'd had to work out all the same things as my colleague.
But now he'd created a scale model. He could use low cognitive effort to make a high quality decision quickly. And his model was portable because my colleague can now start to use that model without bothering the CEO about such issues in the future.
Here's another example from Michelle Obama, and the famous statement when they go low, we go high. Now that is just a scale model. And the first time she experienced people conspiracy theorizing about her family, etc. I'm sure she's sweated over what to do about it.
But now she simply uses this model. She immediately sets the tone of the response. And it's a portable model because her staff can use it too on her behalf. So skilled models are everywhere once you start looking for them. And what these examples illustrate is the idea of model portability, which is to say that other people can use your models because they're transferable.
Also helps you remember them too. But let's look at a case where we sometimes and very often in fact get that wrong. And that's in the area of strategy creation. And, you know, strategy really is a scale model because if you can get a portable version of that strategy, then other people can remember what to do without having to put a lot of effort into figuring out what to do today and what to do next week.
But this is how we normally create strategy. We start on the left with a small group of people who are spending days and days in rooms trying to figure out the strategy, building an intuition for it. We then, when we're ready to communicate it to the company, we craft a huge presentation, present it on a wet, dreary Friday afternoon, and then we wonder why nobody knows what the strategy is.
And the problem is that we have created a model, but it's not portable. So therefore it doesn't really work. Let's see how that could be done better. And I'm going to take as a case study Zoom, because we're all very familiar with Zoom these days, aren't we?
Unless you can get Zoom strategy on one slide with a minimum of text so that it's a portable scale model. Well, this is Zoom's core strategy. We have organizers of meetings who invite people to those meetings. And some of those people become organisers, and sometimes the same process takes place at first company boundaries.
So then what happens is those new people in those companies repeat this process. And so Zoom spreads virally through companies and through the community. And that's the core strategy of Zoom. Then over that, they've added another mechanism where they have some commercial folks that encourage people to upgrade to premium services.
They use a revenue from that to hire more commercial folks and so on around. And then finally, there's a network effect of brand as a business grows. The more people trust the brand, the easier it is for these inner loops to operate. And that's why Zoom, for example, were very responsive to those early lockdown security issues that arose in the product, because they knew that was critical to the strategy.
So this is Zoom strategy on one page. It's very communicable. It's a portable scale model. So it can be done. So in summary, remember that the scalability of your business is a function of the personal scalability of a small number of concentration points of people like you and I.
And your job, if you're one of those people, is to populate a scale model so that over time you can become more personally scalable. And the way you do that is be model alert. First time it's first principles, second time it's a model.
And finally, trying to make your models portable so that you can remember them and so that other people can benefit from them too. Thank you. Okay, we're going bring in Mark now, who has just talked us through some pretty, pretty, eye opening stuff, frankly, about organisational health and structure and how we should think about scale models.
So Mark, if you're if you're there, come on in. Hi, Brian. Hello, everybody. I am indeed here. Yeah, Mark, sorry, missed. My audio was off a little bit there. At. Yeah, but we have you back now. You can hear me now, Brian? Yep. All good. All good.
Yeah. Good. So something that occurred to me when just watching your talk, and it's something I've I think I've come across a lot of times is in even in software organisations, there's all the technical challenges, there's all the challenges around understanding the audience of the customers, understanding how you want to build, what you want to build, how to sell it, etc.
It seems that everything kind of comes back to people problems. Is that Is that a fair assessment or maybe not everything, but they're the most important problems? Well, I'd probably say everything comes back to people. People problems are a subset of people obviously, and sometimes we give each other problems.
But, you know, I've always thought that the technical part of any product nowadays is easy. Let's be honest. I know it doesn't feel like it, but it is. I remember in my day when we had to build everything from event loops upwards, you know, it was always a question of would we ever actually get the software to stand up and work at all?
But that's not the case nowadays with so many libraries and layers and frameworks. The tech part's easy in relative terms, but what's hard is can we conspire together to actually allow us to get stuff done? So really in the end, are a function of how well people work together.
That's always been true, but it's now really the main issue in my mind. If you can solve that, then you can build pretty much anything nowadays that you want to build. Yeah, yeah, it certainly seems how much, yeah, given how much software is sort of, it's not plug and play, but we have so many parts of the stack that other people have built on that we can build, but we still need to figure out our own people to people challenges.
In the presentation, one of the things that you talked about was, logarithmic, prioritization. And you've outlined a really great system for priority management, time management. How ruthless do you need to be in implementing? Once you've decided what your priorities are and then you get, know, people bugging you on Slack or email or whatever, how do you rebuff that?
Or how do you stick to your what you've already set out? Well, there's always going to be limits. Obviously, you're not in control of everything and there are figures and greater authority than you who sometimes tell you where you need to be and what you need to do.
But I found that two things are helpful. One is just having an awareness of the concept of logarithmic prioritisation tends to on average cause us to allocate our time more sensibly. So, you know, that gives you some benefit even if you don't do anything else.
I've always also found it super important as much as possible to try and create contiguous hours in your diary. So, you know, I think a lot of people on call will be familiar with the idea of maker time and manager time. But just to recap that, maker time is contiguous hours to get something done that kind of deep level.
And manager time is those short bursts of context switching between meetings, etcetera. And every job, you know, be you an engineer or product manager or be you a senior executive, actually you need a bit of both. The balance is different in all cases, but it's really important to try and kind of build and maker time because otherwise you never get deeply into anything and you tend not to get very much done.
So to preserve that maker time, I found it super important to be pretty ruthless about what meetings I choose to go to or get myself involved in. Your people notice when you move the needle, when you make impact, and they don't really notice that you turned up at all those meetings.
So in summary of that, I'd say try and build and make your time and just being aware of logarithmic prioritisation and embracing it, even if you do nothing else will tend to shift your behavior without you even realizing. Yeah, the tyranny of meetings is something that we all probably struggle with.
I think it's been interesting though, through this whole lockdown period about, you know, has become harder or easier for people to sort of just schedule meetings in people's calendar? Let's just jump on Zoom versus let's all go to the fifth floor and go into that room that we've had to book and we've held for two weeks, etcetera.
There's definite cultural shifts happening there. So a question that's come in from one our audience Robbie Law asks about logarithmic prioritisation and wondering about you've used ten as the logarithmic base to differentiate between your priorities He's wondering, you know, can you use a smaller number?
Does it matter? Or is it just the idea that there is a logarithmic separation? Yeah, it's good question. You can tell this is a tech conference when you get a question about what base are you using for your logarithmic prioritization, but it's actually a very good question.
I think it doesn't really matter. I mean, for example, when I've discussed this with other people, some people prefer five because it's not so brutal. And that's fair enough. It doesn't really matter the base. It's just more that you embrace that there is an order of magnitude of some base separating these priorities.
You know, I've just found in practise that turns out to be true. We don't often notice it because we're not looking for it. But when we really look for it, there's often things that we push to the back of the queue because they're hard to do, but they're probably the most important.
You know, very often strategy or strategic goals are given second place to things that are tactical and easy to do now, for example. So it doesn't really matter the basis, it's just the concept. And some people I've found are more comfortable with saying it's five times that a ten, ten seems a bit extreme.
But I use ten in the presentation to make the point that, if you don't embrace this idea that priorities arrange themselves logarithmically, You're not going to do it. So I use ten to be extreme, but you pick your base and just remember the underlying magnitude concept.
That's the important part. A few years ago, probably about two years ago now, was at Web Summit actually and having a conversation with Des Trainer from Intercom and a couple of other founders. And one of the things that came up, there were people who were at different stages in their founder journey.
And DES at that stage, I think Intercom was five hundred people or so, maybe six offices around the world. So they were at a pretty big scale. And he was talking about the idea that people complain, or at the beginning as a founder, everything is hard and complicated because you have too few resources to do all the things you need to do.
And that he kind of expected that over time, as they scaled, that more resources would make that easier. And he found that actually everything gets more difficult and more complicated, and often because you have too many people or, just the inherent, complexities of scaling.
From your own career, have you found that to be the case? Have you any examples of the early days and somewhere where you were wishing, oh, if only we had more people versus what it turned into later on and how those headaches changed.
Yeah, I mean, think we've all got those experiences. I like to summarise it by saying that it's always better to have too few people than too many. The question is what's too many? Well, that really comes back to a function of how much agency have you installed in those people.
You know, I remember a calling lesson for me when I was back in Atlantic, which was a company when I was a VP of engineering and we sold that company eventually to Cisco back in two thousand. But I remember just after the internet bubble burst, I'm sure some of us are old enough to remember that.
And we had to lay off fifty of our one hundred and fifty engineers, you know, and other people as well. And it was extremely painful thing. Was a young guy at the time, never had to face such a thing. And it was really difficult to sit down with people and tell them that they had to leave the business, people you'd worked with for, you know, five, seven years.
So that was a bad experience. But what was almost as galling is that after we shrunk down to having essentially a hundred engineers to one hundred and fifty, our productivity almost doubled. And, you know, it made us wonder what we'd been doing so badly wrong all that time.
And basically we hadn't embraced the idea of agency on the frontline. People would join our business. We wouldn't onboard them well, they wouldn't understand exactly what we're trying to do. Our code was, excuse me, badly documented, etcetera. So all they could really do was displacement work, you know, fix the odd low level or low priority bug.
So I learned a lot of painful lessons from that. It's not that you've ever get too many or too few employees, it's how effective can those people be. And I like to think about it as, you know, if my, as a founder or as an early employee, if my agency index is a hundred, then what's the agency index of the employees that come after?
And is it still a hundred? Well, usually by default it isn't. So that's your job in management, but you tend to find that, you know, you could put a scale on this, would find that employee two hundred comes in with an agency index of thirty relative to your hundred, because we didn't onboard her properly, the code's badly documented, we're not really clear in the strategy, she doesn't know what she owns and has to negotiate that, etcetera, etcetera.
So that's the key question, is agency on your frontline rather than any particular number of people? And if you can get that right, then you never have too many people. You mentioned agency in your talk today. You mentioned it a lot in your talk in twenty eighteen.
We'd Roan Lavery from FreeAgent a few weeks ago talking about autonomy, which is, I guess, a related principle. Of all the many components that go into a successful business, particularly when the scaling, agency seems to be one of the most important for you.
Is that fair? Yes, that's fair, Brian. You know, I make the distinction between autonomy and agency in the sense that you can be autonomous and incompetent. And I don't mean that in a facetious sense, you know, it's possible to have power over your decisions but not be competent enough to make those decisions.
And that actually creeps up on people because competence goes off. You know, if your competence is a hundred out of a hundred today, and the company doubles in size, and we haven't invested, and you haven't invested personally in repairing your competence, then you'll find that your competence has gone down and sometimes catastrophically.
So for example, I mentioned in the presentation today that, you know, as an example, I may be able to manage two or three people very competently, but now you've just made me a manager of managers and then managing fifteen people because the company's grown and I'm incompetent as manager because you haven't trained me how to work at that level.
I didn't invest in my self learning. So I think it's very important that we don't just ask about autonomy. Autonomy is a key component of agency, but it's, as I say, necessary but not sufficient. You've got to make sure that people are also competent enough to wield that autonomy and that you've created the conditions where they can do so.
You know, I've noticed actually that in a lot of cases you find if you join a business, for example, when I joined Skyscanner, a few people who were deeply frustrated at the time. And your first instinct is all these people, you know, they're here just to be naysayers.
But actually I discovered repeatedly in both the Skyscanner example and then many others that, you know, the most frustrated people are often your best people, but they're frustrated because you haven't given them the autonomy but also they don't know what they own and what they don't own, etcetera.
Yeah. No, it's something I think we, you in conversations with founders, particularly as they start to scale, it's something that comes up again and again, and something that's hard to get right for certain. A question that's come in from Katie Beaton talking about your 'Just One Constraint' idea.
Her question is 'If engineering resource is available, what's your go to action to relieve the sorry, if the constraint is the engineering resource that's available, how do you what's your go to action to relieve that? Well, really it's as simple as whatever your constraint is, you need to, and terminology you subordinate everything to that constraint.
What does that mean in practise? It means you reduce the amount of work going into that constraint. And that may mean that people go idle elsewhere in the system, if you like. Let me give you a real example of that, which I've seen multiple times.
Let's say we've got a bottleneck in engineering. So we help engineering, you actually slow engineering down by operating as if these are two separate activities. So the general rule is before you do anything else, you need to reduce what's going into that bottleneck to a level the bottleneck can sustain.
So you don't create more dysfunction. And then you've got choices over how you address that. Taking it, maybe going back to some real world examples. These days, from being a professor at Glasgow University, you work with a lot of startups and you're an investor in some of them.
What are the organisational problems and or mistakes that you see being made and are there patterns? Yes, there's definitely patterns, Brian. So I think the most common issue that I see is that companies, businesses tend to not do a great job of thinking through strategy.
So we tend to think about it tactically, throw things at the wall, etcetera, or we deliver, you know, long detailed slide packs that we're not really feeling control of. I think it's important. And I think the remedy for that is understanding the framework in which your company operates.
So for example, what is your business model? Are you in a two sided network? What's the playbook for that? How do your customers come to your product? Do you use growth loops to do that? Do you use some other mechanism? Just getting very clear on what the basic framework for your business model is.
It makes it a lot easier then to make the right decisions around strategy. So I think that's a mistake that's often made and is easily the subject of a longer presentation and discussion. But getting some intellectual framework to what you're doing is super important.
You know, enumerating the network effects, enumerating the growth loops that you can or are exploiting and then putting the data around that. So, you know, if you've been successful, that's something that we often do a, you know, a pretty bad job of. And then I think that the second area is we've talked just a few months ago about constraints.
We often fail to think about what is the current constraint on my business versus what we're trying to achieve. And it's a great question to ask. You know, it's always one thing that's constraining you and asking yourself, what is that? It's a great question because it starts to reveal different answers.
We often otherwise just get consumed with activity. You know, we're doing stuff, we're busy. But always ask yourself, what's the constraint currently that most skates what we're trying to achieve and you'll tend to navigate through problems more easily. So I think that's a couple of areas that I think people often struggle with.
Activity over outcomes and a lack of an intellectual framework, portable intellectual framework for what the business is actually trying to do. Lots of great stuff for everyone to think over there. I think we're running out of time. So I'm afraid we're going to have to wrap it up there.
Just before we go though, I just wanted to say thank you not only for joining us today, but people who are in Scotland will be aware of the work that you did earlier this year, the report that bears your name now and roadmap for Scottish tech over the next, I suppose, the next decade or so.
But I just want to say thank you for that. I think that's a fantastic piece of work. And if Scottish government embrace it, then our ecosystem is going to be in a much better place. So great work on that. Well, thank you, Brian. I appreciate that.
It's a document that, you know, lots of people in this ecosystem could have written, but I was delighted to get a chance to contribute it into our mutual efforts. So thank you for that. And thank you for, and your team for this great conference, which is a key part of that ecosystem.
So much appreciated on behalf of your audience. Thanks. Thanks, Mark. Catch you next time. Okay, thank you. Bye, everyone. Okay, folks. So as always great to chat with Mark, we could probably chat for a lot longer, but time is against us. We're going to take a quick break and we're going to be back with Chris Savage from Wistia in at three pm.
So just in just over ten minutes. So see you then.
We use cookies to measure traffic and improve the site. You can accept or reject analytics & advertising cookies. Privacy Policy