Archive for the ‘Emergent Design’ Category
What is Emergent Design?
Last week I had the opportunity to talk to a data science team about the problems associated with building a modern data capability in a corporate environment. The organisation’s Head of Data was particularly keen to hear about how the Emergent Design approach proposed in my recent book might help with some of the challenges they are facing. To help me frame my talk, he sent me a bunch of questions, which included the following two:
- Can you walk us through the basic steps of emergent design in data science?
- How does emergent design work with other data science methodologies, such as CRISP-DM or Agile?
On reading these questions, I realized I had a challenge on my hands: Emergent Design is about cultivating a mindset or disposition with which to approach problematic situations, rather than implementing a canned strategic framework or design methodology. Comparing it to other methodologies would be a category error – like comparing pizza to philosophy. (Incidentally, I think this is the same error that some (many?) Agile practitioners make when they mistake the rituals of Agile for the mindset required to do it right…but that’s another story.)
The thing is this: the initial task of strategy or design work is about a) understanding what ought to be done, considering the context of the organisation and b) constructing an appropriate approach to doing it. In other words, it is about framing the (strategic or any other) problem and then figuring out what to do about it, all the while keeping in mind the specific context of the organization. Emergent Design is a principled approach to doing this.
–x–
So, what is Emergent Design?
A good place to start is with the following passage from the PhD thesis of David Cavallo, the man who coined the term and developed the ideas behind it:
“The central thrust of this thesis is the presentation of a new strategy for educational intervention. The approach I describe here resembles that of architecture, not only in the diversity of the sources of knowledge it uses but in another aspect as well – the practice of letting the design emerge from an interaction with the client. The outcome is determined by the interplay between understanding the goals of the client; the expertise, experience, and aesthetics of the architect; and the environmental and situational constraints of the design space. Unlike architecture where the outcome is complete with the artifact, the design of [such initiatives] interventions is strengthened when it is applied iteratively. The basis for action and outcome is through the construction of understanding by the participants. I call this process Emergent Design.”
Applied to the context of building a data capability, Emergent Design involves:
- Having conversations across the organization to understand the kinds of problems people are grappling with. The problems may or may not involve data. The ones that do not involve data give you valuable information about the things people worry about. In general the conversations will cover a lot of territory and that is OK – the aim is to get a general feel for the issues that matter.
- Following the above, framing a handful – two or three – concrete problems that you can solve using skills and resources available on hand. These proof-of-concept projects will help you gain allies and supporters for your broader strategic efforts.
While doing the above, you will notice that people across the organization have wildly different perspectives on what needs to be done and how. Moreover, they will have varying perspectives on what technologies should be used. As a technology strategist, your key challenge is around how to reconcile and synthesise these varied viewpoints. This is what makes the problem of strategy a wicked problem. For more on the wicked elements of building data capabilities, check out the first chapter of my book which is available for free here.
Put simply then, Emergent Design is about:
- Determining a direction rather than constructing a roadmap
- Letting the immediate next steps be determined by what adds the greatest value (for your stakeholders)
With that said for the “what,” I will now say a few words about the “how.”
–x–
In the book we set out eight guidelines or principles for practicing Emergent Design. I describe them briefly below:
Be a midwife rather than an expert: In practical terms, this involves having conversations with key people in business units across the organisation, with the aim of understanding their pressing problems and how data might help in solving them (we elaborate on this at length in Chapter 4 of the book). The objective at this early stage is to find out what kind of data science function your organisation needs. Rather than deep expertise in data science, this requires an ability to listen to experts in other fields, and translate what they say into meaningful problems that can potentially be solved by data science. In other words, this requires the strategist to be a midwife rather than an expert.
Use conversations to gain commitment: In their ground- breaking book on computers and cognition, Winograd and Flores observed that “organisations are networks of commitments.” between people who comprise the organisation. It is through conversations that commitments between different groups of stakeholders are established and subsequently acted on. In Chapter 3 of the book, we offer some tips on how to have such conversations. The basic idea in the above is to encourage people to say what they really think, rather than what they think you want them to say. It is crucial to keep in mind that people may be unwilling to engage with you because they do not understand the implications of the proposed changes and are fearful of what it might mean for them.
Understand and address concerns of stakeholders who are wary of the proposed change: In our book, The Heretic’s Guide to Management, Paul Culmsee and I offer advice on how to do this in specific contexts using what we call “management teddy bears”. These involve offering reassurance, advice, or opportunities that reduce anxiety, very much akin to how one might calm anxious children by offering them teddy bears or security blankets. Here are a few examples of such teddy bears:
- A common fear that people have is that the new capability might reduce the importance of their current roles. A good way to handle this is to offer these people a clear and workable path to be a part of the change. For example, one could demonstrate how the new capability (a) enriches their current role or (b) offers opportunities to learn new skills or (c) enhances their effectiveness. We could call this the “co- opt teddy bear”. In Chapter 7 of our data science strategy book, we offer concrete ways to involve the business in data science projects in ways that makes the projects theirs.
- It may also happen that some stakeholder groups are opposed to the change for political reasons. In this case, one can buy time by playing down the significance of the new capability. For example, one could frame the initiative as a “pilot” project run by the current data and reporting function. We could call this the “pilot teddy bear.” See the case study towards the end of Chapter 3 of the data science strategy book for an example of a situation in which I used this teddy bear.
Frame the current situation as an enabling constraint: In strategy development, it is usual to think of the current situation in negative terms, a situation that is undesirable and one that must be changed as soon as practicable. However, one can flip this around and look at the situation from the perspective of finding specific things that you can change with minimal political or financial cost. In other words, you reframe the current situation as an enabling constraint (see this paper by Kauffman and Garre for more on this). The current situation is well defined, but there are an infinite number of possible next steps. Although the actual next step cannot be predicted, one can make a good enough next step by thinking about the current situation creatively in order to explore what Kauffman calls the adjacent possible – the possible future states that are within reach, given the current state of the organisation (see this paper by Kauffman). You may have to test a few of the adjacent possible states before you figure out which one is the best. This is best done via small, safe- to- fail proof of concept projects (discussed at length in Chapter 4 of our data science strategy book).
Consider long- term and hidden consequences: It is a fact of life that when choosing between different approaches, people will tend to focus on short- term gains rather than long- term consequences. Indeed, one does not have to look far to see examples that have global implications (e.g., the financial crisis of 2008 and climate change). Valuing long- term results is difficult because the distant future is less salient than the present or the immediate future. A good way to look beyond immediate concerns (such as cost) is to use the “solution after next principle” proposed by Gerald Nadler and Shozo Hibino in their book entitled Breakthrough Thinking. The basic idea behind the principle is to get people to focus on the goals that lie beyond the immediate goal. The process of thinking about and articulating longer term goals can often provide insights into potential problems with the current goals and/ or how they are being achieved. We discuss this principle and another approach to surfacing hidden issues in Chapters 3 and 4 of the data science strategy book.
Create an environment that encourages learning: Emergent Design is a process of experimentation and learning. However, all learning other than that of the most trivial kind involves the possibility of error. So, for it to work, one needs to create an environment of psychological safety – i.e., an environment in which employees feel safe to take risks by trialling new ideas and processes, with the possibility of failure. A key feature of learning organisations is that when things go wrong, the focus is not on fixing blame but on fixing the underlying issue and, more importantly, learning from it so that one reduces the chances of recurrence. It is interesting to note that this focus on the system rather than the individual is also a feature of high reliability organisations such as emergency response agencies.
Beware of platitudinous goals: Strategies are often littered with buzzwords and platitudes – cliched phrases that sound impressive but are devoid of meaning. For example, two in- vogue platitudes at the time our book was being written are “digital transformation” and “artificial intelligence.” They are platitudes because they tell you little about what exactly they mean in the specific context of the organisation.
The best way to deconstruct a platitude is via an oblique approach that is best illustrated through an example. Say someone tells you that they want to implement “artificial intelligence” (or achieve a “digital transformation” or any other platitude!) in their organisation. How would you go about finding out what exactly they want? Asking them what they mean by “artificial intelligence” is not likely to be helpful because the answer you will get is likely to be couched in generalities such as data- driven decision making or automation, phrases that are world- class platitudes in their own right! Instead, it is better to ask them how artificial intelligence would make a difference to the organisation. This can help you steer the discussion towards a concrete business problem, thereby bringing the conversation down from platitude- land to concrete, measurable outcomes.
Act so as to increase your choices: This is perhaps the most important point in this list because it encapsulates all the other points. We have adapted it from Heinz von Foerster’s ethical imperative which states that one should always act so as to increase the number of choices in the future (see this lecture by von Foerster). Keeping this in mind as you design your data science strategy will help you avoid technology or intellectual lock in. As an example of the former, when you choose a product from a particular vendor, they will want you to use their offerings for the other components of your data stack. Designing each layer of the stack in a way that can work with other technologies ensures interoperability, an important feature of a robust data technology stack (discussed in detail in Chapter 6 of the strategy book). As an example of the latter, when hiring data scientists, hire not just for what they know now but also for evidence of their curiosity and proclivity to learn new things – a point we elaborate on in Chapter 5 of the data strategy book.
You might be wondering why von Foerster called this the “ethical imperative.” An important aspect of this principle is that your actions should not constrain the choices of others. Since the predictions of your analytical models could well affect the choice of others (e.g. whether or not they are approved for a loan or screened out for a job), you should also cast an ethical eye on your work. We discuss ethics and privacy at length in Chapter 8 of the data strategy book.
–x–
These principles do not tell you what to do in specific situations. Rather, they are about cultivating a disposition that looks at technology through the multiple, and often conflicting, perspectives of those whose work is affected by it. A technical capability is never purely technical; within the context of an organisation it becomes a sociotechnical capability.
In closing: Emergent Design encourages practitioners to recognise that building and embedding a data capability (or any other technical capability such as program evaluation) is a process of organisational change that is best achieved in an evolutionary manner. This entails starting from where people are – in terms of capability, culture, technology, and governance – and enabling them to undertake a collective journey in an agreed direction.
…and, yes, all the while keeping in mind that it is the journey that matters, not the destination.
Preface to “Data Science and Analytics Strategy: An Emergent Design Approach”
As we were close to completing the book (sample available here), Harvard Business Review published an article entitled, Is Data Scientist Still the Sexiest Job of the 21st Century? The article revisits a claim made a decade ago, in a similarly titled piece about the attractiveness of the profession.2 In the recent article, the authors note that although data science is now a well- established function in the business world, setting up the function presents a number of traps for the unwary. In particular, they identify the following challenges:
- The diverse skills required to do data science in an organisational setting.
- A rapidly evolving technology landscape.
- Issues around managing data science projects; in particular, productionising data science models – i.e., deploying them for ongoing use in business decision- making.
- Putting in place the organisational structures/ processes and cultivating individual dispositions to ensure that data science is done in an ethical manner.
On reviewing our nearly completed manuscript, we saw that we have spoken about each of these issues, in nearly the same order that they are discussed in the article (see the titles of Chapters 5– 8). It appears that the issues we identified as pivotal are indeed the ones that organisations face when setting up a new data science function. That said, the approach we advocate to tackle these challenges is somewhat unusual and therefore merits a prefatory explanation.
The approach proposed in this book arose from the professional experiences of two very different individuals, whose thoughts on how to “do data” in organisational settings converged via innumerable conversations over the last five years. Prior to working on this book, we collaborated on developing and teaching an introductory postgraduate data science course to diverse audiences ranging from data analysts and IT professionals to sociologists and journalists. At the same time, we led very different professional lives, working on assorted data- related roles in multinational enterprises, government, higher education, not- for- profit organisations and start- ups. The main lesson we learned from our teaching and professional experiences is that, when building data capabilities, it is necessary to first understand where people are – in terms of current knowledge, past experience, and future plans – and grow the capability from there.
To summarise our approach in a line: data capabilities should be grown, not grafted.
This is the central theme of Emergent Design, which we introduce in Chapter 1 and elaborate in Chapter 3. The rest of the book is about building a data science capability using this approach.
Naturally, we were keen to sense- check our thinking with others. To this end, we interviewed a number of well- established data leaders and practitioners from diverse domains, asking them about their approach to setting up and maintaining data science capabilities. You will find their quotes scattered liberally across the second half of this book. When speaking with these individuals, we found that most of them tend to favour an evolutionary approach not unlike the one we advocate in the book. To be sure, organisations need formal structures and processes in place to ensure consistency, but many of the data leaders we spoke with emphasised the need to grow these in a gradual manner, taking into account the specific context of their organisations.
It seems to us that many who are successful in building data science and analytics capabilities tacitly use an emergent design approach, or at least some elements of it. Yet, there is very little discussion about this approach in the professional and academic literature. This book is our attempt at bridging this gap.
Although primarily written for business managers and senior data professionals who are interested in establishing modern data capabilities in their organisations, we are also speaking to a wider audience ranging from data science and business students to data professionals who would like to step into management roles. Last but not least, we hope the book will appeal to curious business professionals who would like to develop a solid understanding of the various components of a modern data capability. That said, regardless of their backgrounds and interests, we hope readers will find this book useful … and dare we say, an enjoyable read.
Note:
You can buy the book from the Routledge website. If you do, please use the code AFL03 for a 20% discount (code valid until end 2023). Note that the discount has already been applied in some countries.
Making sense of entrepreneurship – a conversation with Craig Brown
KA: My guest for this instalment of my “sensemaker” series of interviews is Craig Brown. I have known Craig since about 2009 when he was a project and program manager. He has since transitioned to running his own software development company, Everest Engineering. So, welcome Craig, let me begin by asking you to introduce yourself and talk a little bit about your journey that got you to where you are now.
CB: Thanks Kailash. How far back do you want me to go? Would you like me to start right at the beginning or just the last few years?
KA: Mostly the transition from project and program management to entrepreneurship. What made you do it? What drove it?
CB: OK. Well, early in my career I worked at different companies and corporations, as many of us do. I even did a very small stint in consulting. These experiences were interesting because I learned a lot about how things happen in organisations – what works and what doesn’t. Early last decade, I started working at a SaaS company in a general management role. That was interesting because the culture in those places, the way they operate, is very different from the established corporate world. You’re much closer to “life or death” issues on a month-to-month basis. As a result, you’re much more invested in delivering customer outcomes and value than in compliance, rules and process. That was refreshing and super interesting because I had never been in that situation before.
Anyway, then the day came when it was time to leave that organisation. One of the guys that I worked with, Ranganathan, used to manage part of the team in India while I managed the team in Australia. The two of us decided we would start a software product development agency together, and so began Everest Engineering.
The switch from working for someone to working on your own business is a big one. Many of the differences are well-known, entrepreneurs have talked about them: it’s a lot of work, it can be very stressful, you’ve got to be multifaceted, you’ve got to be wherever the business needs you at any particular time. So, being able to switch modes and roles is really important.
As the company has gotten bigger, we’ve hired other people to help manage the business, grow it, support it. Ironically, this next stage is about breaking our old habits of being everywhere all at once, its about learning to delegate authority, share responsibility and all that sort of stuff. What I think is particularly interesting about what’s happening to us now is that it’s kind of the opposite journey to what large companies are trying to do: i.e. they try to reduce bureaucracy and increase entrepreneurship by giving people autonomy and responsibility. We’re headed the other way, not towards bureaucracy (I hope!), but towards more structure and order from what can be described as chaotic, freewheeling entrepreneurship. Yeah, it’s stressful but a lot of fun.
KA: OK, before we get deeper into the conversation, what does Everest Engineering do and where are you located?
CB: We are a software product development agency. Capability wise, we have software engineers, platform engineers, product people, designers, testers, business analysts etc. Our team members live in about half-half on the east coast of Australia (mostly Melbourne) and India. We also have a few team members in North America and have just started building a development team in Malaysia as well. So, we’re kind of distributed across the globe. At the moment, most of our customers are in Australia but we’re growing the customer base around the world as well.
KA: Hmm, there are a lot of companies in the software product development business. It must have been difficult to get traction. How did you do it?
CB: The traditional story (in software development) is that you either a) find a niche that no one is addressing well and zero in on that or, b) you come in cheap and claw your way to the top. When we started our business, we didn’t want to do either of those things. We also wanted to build a generalist software product company, not focusing on a particular domain or particular skill set as many small outfits do. Our vision is that we become a big global company that can engage with lots of different problems. At the same time, we knew that if we swaggered in to client discussions saying that, no one was going to be interested.
So, what did we do?
We started by focusing on the Melbourne market, primarily because that’s where I live. To get traction we decided that we would be compelling in terms of the match between price and quality. In the world of software, you can rent services from agencies which are poor or average quality on the cheap, or you can pay a lot of money for top shelf quality. What we wanted to do is not be the cheapest in the world, but be reasonably inexpensive while also really focusing on quality. Interestingly, over time the price-quality trade off has become less important, which has enabled us to focus on quality. I’m not sure why this happened but I guess it has to do with a common experience in life: when a piece of work is completed, what’s remembered is the good outcome, not the cost to get there.
There’s a kind of irony about day rates versus outcomes. It’s a weird one. For example, the price of some of our India software development teams might be double or even more than what some of our competitors provide. But the deal is that we’ll get it right the first time, within the timeframe and the budget that you’re asking for. Compare this to having an expensive rework nightmare, which often happens when the upfront focus is on cost. I’m aware that this could be sounding like an ad, but it’s really that focus on delivering a quality, delivering an outcome the first time that is the key. Our customers don’t necessarily understand this upfront because quality is hard to talk about, but it is easy to understand when you see it. So the deal is that after our customers have worked with us, they begin to appreciate the quality aspect we bring.
Another aspect of our strategy is maintaining relationships and sticking together over the long haul. It’s really simple to state: win over customers through doing good work and keep them through being compelling in our value proposition. However, it is not easy to do. Indeed, it is work in progress, we’re not perfect. These are aspirational goals, and we’re working our way towards them.
KA: I understand the price-value proposition. However, because it is such a crowded market, your first few gigs must have been hard to get. How did you go about doing that?
CB: Yeah, I think it’s a trust-based decision making process when buying expensive, large services. The customer will not know upfront what the quality is going to be like. Fortunately, over the last two decades, I’ve built good strong relationships with lots of people across our industry. So, a lot of people know me, and I’ve had interactions with them through my work or contributions to our professional community (Kailash’s note: For example, Craig is the founder of Last Conferences). That’s gotten me access to a lot of people. To add to that, in the early days of Everest, we would straight up give people a money-back guarantee. We could do this with confidence because we knew our team members – we knew they were smart people with a lot of enthusiasm for doing right by everyone around them. That enabled us to say to our customers, “if you don’t like the work, you don’t have to pay for it.” That combined with my personal connections meant that we were able to cut through and get that first round of trust that enabled us to build the company.
KA: It must be doubly challenging to maintain quality and align expectations with a distributed team. Can you talk us through some of the challenges that you have faced?
CB: Yes, and there some nuances around this. One is that the software labour market in Australia is older, on average, than in India. So, there’s an asynchronicity of experience, and with that comes a misalignment of expectations. A really important aspect of this is that we try to be explicit about expectations from different teams, and this is mostly about managing people’s expectations of what’s going to happen and when. Another aspect is for us to develop a shared understanding of what Agile means to us: things like transparency, focus on throughput, customer value, responding to feedback etc. Once we agree on what they mean, we have to do those things on a day-to-day basis.
It gets even more complicated when you bring the customer in. As you know, every organization has got its own version of what Agile looks like, and different understanding of what “good” means. So, we try very hard to moderate our version and meet the customers where they’re at. In other words, we co-develop shared Agile practices. A phrase that I think really resonates with the customers we work with is let’s improve together. When there are cultural differences, we don’t see them as barriers. Instead, we reframe them as strengths. It is like, “right, we see things differently, and that is interesting because I hadn’t thought of it that way.” These differences aren’t necessarily country to country, they can also be industry to industry or organisation to organisation. Of course, there are things that are cultural too. For example, if we’re doing retail websites, the online retail experience in India is different from one in Australia and, therefore, so are expectations of how things should work. You have to step back and go to first principles of user experience design and product management; you have to slow down and talk about what good looks like, and how we’re going to get there.
Lastly, there’s the issue of managing timezone differences. To be honest, we don’t find this a problem. The overlap between Australia and India is sufficient, and can lead to some good patterns where there’s like a half a day of focus time and a half a day of collaboration time. But again, this requires planning and preparation. You can’t just turn up to work and go; you have to be thinking ahead about what you are going to do. As long as you’re able to level up your planning you can take advantage of this. This also has general positive downstream effects: if everyone’s more organised, there’s less waste, better decisions are made better, and so on. However, it does take effort to get there.
KA: You used a phrase, “let’s improve together with our customers.” Can yougive me some sense of how this works in practice?
CB: The examples are quite mundane to be honest. When a bunch of people come together to work on a new project, there is some learning required on how you are going to work together. As I had mentioned before, patterns and practices will differ between organisations. For example, should you focus on Continuous Delivery and DevOps stuff. or should you focus on better product management or sensemaking and design work? The answer is: it depends. We (the customer and us) bring different strengths to the table, so we look at the situation in front of us and decide how to work together.
First of all, we agree on how we communicate, how our day and week runs – all that kind of normal sprint cycle stuff. Then we can get into specifics such as, how do we optimize (our ways of working) around the product that we’re working on? What is a good outcome? What are the constraints? In addition, we will have patterns and practices that we can kind of share with each other and learn together. This is not about telling people about your practices like you have some special access to the truth. Instead, we slow down and go, “Alright, cool. I see this problem here. Do you see it too?” And then you might go, “Yes, I do.” Or you might go, “huh, I see a slightly different problem.” Or you might even go, “I don’t see a problem.” That opens a dialogue and, before you know it, we’re solving the problem together instead of telling each other what to do. How that manifests could be as simple as changing how you run stand-ups, or set up sprint plans, good coding standards, or the emphasis you put on product design versus shipping a product. These are mundane, well-known things but the trick lies in how you customize them to the context of a specific relationship.
KA: Interesting. So, when you actually hire and get people in, you’d be hiring for technical smarts on the one hand, but you’d also be looking for, a kind of propensity to collaborate. Is that right?
CB: I hire certain kind of certain roles but the bulk of the workforce hiring is done by other people so I’m not actually close to the details. However, I do know that the notion of culture fit is taken pretty seriously in the recruiting process. From this perspective it is mainly about managing the tension between being an individual contributor and a team member. On a team, you will be an individual contributor so you do need to master your craft, be good at the job and all that sort of stuff. However, you also have to think about where your ego is. Do you have this deep need to be the hero, telling everyone what to do and being the master programmer. Or do you deploy value through a collective effort? By doing good work, but also looking around, seeing your teammates, recognizing their work and supporting them when needed. We draw these kinds of things out in interviews through storytelling, by asking for examples.
KA: When I look at what you’ve done, it seems like, such a simple idea: to not go on price or quality alone, but somehow marry the two. It’s like you saw a gap in the market, an anomaly that nobody else noticed – or if they did, they did not think it worth pursuing. I find that really interesting.
CB: Yeah, it is kind of like that. There are a bunch of software agencies that I used to work with, here in Melbourne, they are full of great people. They are also what you would call the premium software agencies in Melbourne or in Australia – quality is top shelf but so is price. Then at the other end, you’ve got these big factory warehouses of people who are lowly paid and not well supported. And then there’s this place in the middle that’s almost unseen. What we thought we should do is compete on the one hand, at the quality end, and then also come in cheaper by leveraging the cost differential between the two countries.
You might say we are reinventing the outsourcing experience by maintaining the connections and relationships like small agencies but being able to do things at scale by having the staff, skills and experience commonly found only in much larger outsourcers.
KA: Right, and the interesting thing is that you grew the business in some pretty challenging times. Could you tell us about how you handled the challenges thrown at you by Covid, for example?
CB: Yes, there’s been a few things right, there’s been the COVID pandemic and now we’re on the cusp of another economic crisis. Indeed, the pandemic hit right after we got started. One of the things that I think enabled us to be resilient has been spreading our bets. So rather than chasing after a handful of big customers, what we’ve done is pursue a relatively even spread of customers in different segments, sizes and organisations types. So, as these crises ripple through different parts of the world economy, it hits us at different times rather than all at once. Don’t get me wrong, the middle of 2020 was really tough, but the fact that we had our spread was what got us what got us through that. I’m not sure if I’m using the term antifragile, properly, but it kind of leans into that. By spreading your bets, you discover all these new people, markets and domains that can grow into opportunities.
KA: That makes good sense. So, what next for Everest?
CB: We’ve been fortunate to have attracted these really interesting and diverse bunch of people to work for us. Equally, we’ve attracted an interesting and diverse bunch of companies that work with us as customers. We’re only a few years old – four years this November – so we’re still focusing on our core business which is software development. I think in a year or two ahead, I think we will start to see that antifragility or diversity blossom into new opportunities. For example, we definitely want to work in the data space. We’ve got data engineers and some people who have done projects, with machine learning and so forth, but we don’t actually have it as a practice. It’s kind of ad hoc at the moment. So, maturing these things into proper business units that have got sustained impact on the world will be something for us to do. And then there are other things we’re looking at – for example how product management works in the industry. Specifically, the patterns and the strengths and weaknesses in the product management industry and whether there are ways in which we can contribute to that community.
At heart we are a bunch of explorers and experimenters still…and hope we will remain so. We are on a journey through adjacent possibles. It is the only way to stay fresh and ensure that we don’t get pigeonholed.
KA: So, you’re continually scanning the periphery and horizon to see what new things you can do by adapting what you have. That’s brilliant!
CB: A lot of it comes through the diverse talents and interests of the people we work with, right? We’ve ended up attracting quite interesting people to work with us. Interesting people have – well – interesting interests! So, for sure, the key thing is to get work done and ship products in time. But another important thing is to make the mental space so that you can actually invest time and energy into the things that you’re curious about. Ultimately that’s what spawns new ideas and new opportunities.
KA: That’s a nice place to close our conversation. But, before we do that I want to ask you one final question: what advice would you give someone who wants to start doing their own software development (or any other) business?
CB: The advice you hear from people that study new businesses is generally something along the lines of: it’s going to be harder than you think; it’s going to take longer than you think; you’re going to get very stressed and have these moments where you wonder why you’re doing it. But at the end of it, you’ll look back and love the fact that you’re doing it. And I think that’s actually true, right. That said, I think that embracing the chaos and uncertainty isn’t for everyone. Like, here I am, I grew up poor, in a single parent family in regional New South Wales. In my late 20s, early 30s, I started working in corporate Australia in tech. All along I have been burdened by the usual mortgages and lifestyle costs and all that sort of stuff. And I haven’t climbed out of that yet: I’ve still got a mortgage I can’t afford. But yeah, it took me a while to get started on the entrepreneurship thing. I was 48 when we started Everest, and it was driven partly by events outside my control. As I said at the start, the company I was working for got acquired and that gave me the push I needed to do my own thing. So, there you go. It’s not for everyone and, yes, the right circumstances have to be in place for you. But once you start, I think you’ll embrace it.
KA: That’s an inspiring story and some great advice Craig, particularly for older people who want to start doing their own thing. You were driven to entrepreneurship in a way but you stuck to it and made it your own. Brilliant stuff, thanks so much for making the time to have a chat.
CB: Thanks Kailash, always a pleasure.
Eight to Late 