Why is Command and Control the de facto leadership style in businesses?
This is an article about software businesses and why command and control is still the most pervasive leadership style in software businesses from small to large (let’s say, at least larger than 20ish people).
It’s a curious thing that it should turn out that way. How does it come to be that way for so many companies? And what you should do about it if you desire to cultivate a modern effective empowered culture as a leader or founder of a tech company?
Well, let’s start here.
By now, you should know the old adage:
Culture eats strategy for breakfast — Peter Drucker.
We are not saying that you are an overbearing leader like the drill instructor in the photo above. But if you think that your business strategy alone will build you a successful tech company long term, then he might be what you start looking like to your people as your tech company grows.
Won’t happen to you?
Let me tell you a story about one company
OK. This is not a true story, this is a story about you the reader becoming the founder of a small tech startup. We are going to take you on that journey that shows you how things might evolve as your business is established and how it grows. And, we are going to illustrate how command and control slowly takes hold of your company and then stratifies your business, as it grows.
The story that follows is looooooong, so if you want to skip this story part and jump straight to the ‘Enlightened Founders and Tech Leaders’ section down the bottom, then go right ahead — but you should know that the story is here to demonstrate to you that even the most intelligent, most diligent leaders fall into the same traps without even thinking about it. We are going to show you that it is all about managing uncertainty at scale, and many founders and tech leaders are not great at doing that very effectively when it comes to working with other people and growing ideas together.
Let’s say that you have been working at a bank for the last 4 years. Perhaps your last two jobs were in a bank too. (It actually does not matter in this story if you never worked in a bank. Any business sector will do, I’m just going to use banking here for fun — those poor banks).
By now, after several years at the bank, you probably know the basics of banking, you’re familiar with all its ins and outs. Also, in your time, you’ve probably seen the odd opportunity in the marketplace for something that’s being under-served by your bank to its customers. Perhaps it is some service that your bank could supply to its customers, but does not yet or will not yet, or perhaps it is doing some other service quite badly and you see untapped potential value to your customers left on the table.
You wouldn’t believe how many businesses have started exactly this way.
You have been talking about that “opportunity “, and you’ve come up with a solution [an idea] that you’ve had for a little while now, that would serve those customers way better. You have socialized that idea in a few casual conversations with a bunch of your co-workers at the bank, and found that it resonates with most of them. By now, you’ve managed to capture the imagination and support of a few of your long-time colleagues at the bank who agree that your idea has some legs, and some have told you that this could be big! “Yeah? so when are you going to go and do it?” they rib you occasionally.
Your bank certainly isn’t doing anything about it, that’s clear, and that bothers you as a bank employee that your customers are left underserved, but life goes on, and you stick at the bank with this idea brooding at the back of your mind.
Over the years in the banks, you’ve been entertaining the idea of leaving and starting your own business with some like-minded people, and then one day, let’s just say that “some event” at the office comes to cataclysmic climax and your group of friends have to leave the bank — voluntarily or you are forced to (not important to this story).
Here you are now, no longer at the bank, without a job, and with nowhere to go, and no idea what to do now.
Inception
You and your colleagues at the bar one night talking about what to do next, and someone suggests that you should start your own business together and go after that great idea that you’ve had for years. “C’mon, let’s show those banks what they are missing out on!”.
After all, you and your ex-colleagues all know banking top to bottom, and together you have decades of experience between you. You all share the vision of this great idea, and wouldn’t it be great to continue your career in finance by building your own fintech company? Kind of feels like a natural career step now doesn’t it? Perhaps too much wine? No matter, it has awakened you and your colleagues to a new possibility.
You look around the table, and Barney has all the legal skills and experience from his 8 years in the risk department, Angela has all the marketing skills to reach and excite your customers, you have the technical skills to build the thing, and then there is Martha who has all the admin skills and level head to herd all you cats together. It’s a perfect team to start a new company!
It will do for starters. It’s certainly a lot more than most start with.
The Vision
“We are all going to build a new software product that lets ordinary people who have numerous bank accounts at various banks, and bring them all together in one handy app”. “With all the standardization in the industry and all the open source assets and APIs nowadays, we can build that app far quicker than the bank can, and we can finally give everyone what they are really looking for!” c’mon it will be great!
You know, the usual pitch
Your new founders are all in, and so you pool together some money and found the company. Initially, it’s the four of you doing it all. You register the business, you create the company constitution and shareholder agreement, and your Terms of Service etc., you get started on building the new app. Everyone puts out their feelers in the marketplace and their networks for potential new customers. You figure out your initial pricing and business model. Scary times, indeed!
We’re In Business!
You’ve figured out from the various people you’ve met so far that you need some kind of marketable title to go by, because people want to know what you do.
So, you decide Martha will be the Chief Executive for now, Barney is going to be the Chief Risk Officer, Angela the Chief Marketing Officer and you the Chief Technology Officer. These titles makes a lot of sense when you are talking to customers and potential investors. Behind the scenes it’s way more chaotic of course. You are just four business partners doing whatever needs to get done to get into and stay in business.
Pretty soon, after much ado on the tech side, you have a prototype in the app store and you have some early adopters using it and telling you how much they love it — friendlies! You decide to crowd fund, or maybe attract the attention of an investor or two to raise some capital to do more. Importantly, you start attracting new customers, and they are genuinely getting some value out of your product, so much so that they are happy paying the small fee for it. You are officially in business!
OK, in reality, that last part I skimmed over may take years to achieve and requires supreme gifts from God to get over the line. Some never make it that far. No fear, in this story, you all have super powers, and those generous gifts from God.
Together as a team of four, you’re handling not just feature requests from your paying customers, but also dealing with compliance and legal issues that now start to crop up. “Is the app GDPR compliant?” “How are you using my personal identifiable information, and what for?” “How do I reset my password?” “Can my kids have access to my accounts?” A million things to sort out, and you four alone are having to deal with it all. Not easy work, but far easier to get it done in a small tight-knit team supporting each other.
Sharing the load
You decide there is too much to do, so you spend some of your capital/revenue on hiring some more people. It’s tough enough recruiting, but you have some old ex-banking friends who decide to take the plunge with you now and join as employees. At least they know the domain, and are familiar with your customers.
Back when you started earlier this year it was just the four of you, all boss-level titles. Now you have five employees — gosh! Staff!. You decide that since you are paying them full time, and not paying yourselves market rates yet, that they remain employees, and perhaps you will offer them share options to earn their stake in the success of the business. They weren’t there with you at the start and they are getting fully paid for their contribution now. After all, no risk, no reward, right?
How the separation begins
When it comes to the strategic decisions, you founders get around the conference meeting table: “Which customer segments should we go after next?” “How do we reach them?”, “What features should we building for future customers?” “How do our terms of service support businesses using our software, what do we change?” “How should we change the pricing and feature sets for an enterprise level subscription?” All those big decisions are being made by the original four together. All the other staff just leaves it all to you guys.
Why not, right? You are the founders, you were here at the beginning. It was your idea to create the company, you all quit your jobs and put in the cash, it was you guys who took all the risk, and no one else in the company has been around here long enough to know the business better than you guys.
You had decades of banking domain expertise between you, and it’s that precise expertise that got you to where you are now. Besides, your employees are far too busy to worry about the business strategy, they have too much other work to do. So you’ve established an informal decision making process. And the secrecy begins.
You have an upturn in business: things are really taking off finally! You decide to start paying yourself a full salary, and hire five more people across the board. That brings the size of the company close to 20. As more people come in, the number of decisions that need making increases, and since you are the boss of all the tech people, your voice and your opinions often go unchallenged.
You don’t notice this at first, but you do notice that the staff are making a lot of mistakes that you think should not be made if they just used their common sense. Or maybe you just get frustrated — “why don’t they just ask for help if they don’t know how to do something?” you think to yourself. After all, you have most of the answers — you are the boss with undoubtedly the most experience in building this business, and you also love problem solving. But it would be good, you think to yourself, to have more people to bounce your ideas off. It’s kinda difficult makin all the right decisions all of the time.
As you’ve brought in new people, you’ve been spending less and less time on the tools and practice and more time organizing the people and the work to do. You seem to be the go-to person for everyone’s problems. All this managing people doing things the right way and formalizing that stuff is getting in the way of the real job you want to do. Designing and innovating the new product for your customers.
The slippery slope
So you think to yourself, how are we going to scale me? There is too much coordination to do, too many things to keep track of, and lots to think about the product too that also needs your attention. You become frustrated that you are dropping too many things, and they are not resolving themselves without more and more effort and sheer willpower from you. You think back to your last few company jobs and how they dealt with this kind of issue.
“Hmm, let’s see, we broke the work to do into well-defined roles and we divided the work into responsibilities, everyone had a title that reflected their role”. Makes sense to you. “Then we had a manager to coordinate everything and everyone. Why not use that model here?” “Yes! Roles and Responsibilities — of course!” “That way we cover everything by defining it, dividing it and distributing it between the people we have, then individuals can focus on their responsibilities and nothing falls through the cracks anymore! genius!”
Seems to work when building roads or houses!
You bring in a Project Manager, no! Product Manager to help you prioritize and manage the delivery of product features — because you are a product company now.
You hire an agile coach to help you standardize the process of design and build for the product teams. You get in a People Manager to help manage the performance and career development of everyone in your organisation. Your peers in the original four do the same thing to scale their respective capabilities and silos with their people. It makes clear sense to you, and that’s how all the other companies you worked for did it, that’s how it was done at the bank. Nice clear and neat divides in the work and smooth sequences of work everywhere. Very orderly you think. Super productivity, just like a well oiled machine!
A “moment of truth” occurs
One day, a big customer contacts your business and is interested in buying 1000x licenses of your app for their company. You pop the champagne at the next top table meeting. This is the big-time and the break you have been all been waiting for. But there is a catch. They need a bunch of new features that you don’t have yet, that they insist that they are deal breakers for them. They will buy your product only if you promise to deliver those features, and deliver them in the next quarter — of course!
As the founders, you get together around the top table and agree that most of the features seem reasonable, some are really out there, and some seem really hard to deliver. You decide the risk is worth taking, this is what it’s all about, and so you decide to make the deal.
You inform your delivery teams that they need to deliver these new features, and that you have established a new road map to track their delivery schedules so that you can keep the customer up to date with progress. The customer makes several phone calls over the next few weeks, and you insist on taking them all personally. You don’t want your teams bothering with the finer points of the deal. You want to be involved in making those decisions, and you also want to remain able to move fast if the customer needs to change some of the details. You are happy to just do that on your own.
The product teams and the Product Manager are currently busy dealing with the latest feedback on their new releases, and of hand tell you that it will be some time before they get to these new features.
Huh? This has never happened before. Can’t they see this deal is really important to the business? You challenge them: “We can’t wait very long before this deal will fall through!”. You say. “We must deliver this stuff to win this deal!”. “If we do win this deal then we generate huge revenue for the company, and Christmas is just around the corner”.
“I’m just not seeing how we can fit it in, we have so much on the go” says the Product Manager. “A lot of these features are not even part of the product!” Eventually, after hearing the details, and arguing against them, you get short and instruct them to get started on the features right away. Tou then demand to know when they’ll be done, so you can update the customer regularly with progress.
Stakeholder-driven product development
Five weeks later the customer calls and cancels the deal: They tell you that “sadly they couldn’t secure the funding to make the deal, so they’ve had to pull out”. You are stunned by that! But everything is fine, you have plenty of other customers, and the new features that were asked for (now partly implemented in the product) won’t get in the way of other customers using the app. The road-map seems like a good tool to help you stay in touch with progress in the product teams, so you keep it. Everyone has a road-map don’t they? You think to yourself. “We did at the bank too!” It’s actually great for helping you answer the questions that board, C-level team and shareholders keep asking you: “When are we going to be able to sell those new features we’ve been asking for?” and “how much will it cost us?”
A few months pass, and you are coming back from a recent holiday you had with your family to Fiji, and it’s been a good time to reflect on the future strategy of the company. You’ve come up with another idea to grow the business that you are keen to share with the other founders. At the next strategy meeting, you present the idea, and the four of you decide that this new idea seems like a good one to go after. It is feasible to build into the product, it’s viable from a legal standpoint and you of course assume that it will obviously be valuable to your customers. So, full of enthusiasm you just write it straight into your road-map to discuss with your Product Manager later. The Product Manager dutifully agrees to it and raises its priority for the delivery teams. You notice that they’ve been a little off since you’ve been back from holiday. That’s weird!
The beginning of the decline
Eventually, the delivery teams get around to implementing your new idea in the product. This validates your initial assumption that this was a good idea. You pat yourself on the back. You even hear from some customers that they saw your new feature and tried to use it, and that is encouraging for you and the original four.
You ought to go on holiday more often, you think!
One day, you get the bad news that the Product Manager has resigned from the company: she’s found a better job elsewhere at a larger company — “well we can’t compete with those large companies can we?” you say to the other founders. Others in the office tell you that she had been pretty upset the last few weeks, and had been shouting at some of the engineers to just get those damn features out the door.
So, you go out hunting for another Product Manager. You’ve interviewed eight different Product Managers in the last few weeks. It's been exhausting. Some have even worked in finance before, but none have wanted to take your offer any further.
You’ve always been pretty good at interviewing people, and you are not detecting any obvious issues in the interviews. But on reflection, you do remember hearing a couple of questions that seem to kill the conversation every time. “Do you use a road-map?”, or another asked you “Who owns the road-map”, you even heard “Where do the ideas and work come from in the business?”. You are puzzled that these questions keep popping up, because the answer is pretty obvious to you.
You’ve told them that you own the product road-map of features, and that you and the other business leaders meet really regularly to prioritize it and come up with new things to go on it.
“So, what about your customers then?” asked one candidate. You are frustrated by this line of inquiry. “We listen to our customers, we are customer driven!” All the senior leaders meet regularly with prospective customers and partners — all the time. All four of you are constantly seeking feedback from whomever you can get it from — every opportunity you have. Even on the train ride to work you often spark up chats with strangers who turn out to be prospective customers too, who like the ideas you are selling. Sometimes, you even get insights from them too, and those go on the road-map as well.
Don’t these interviewee Product Managers know how to use road-maps, you wonder?
Stepping in
Without a Product Manager in the company, you start talking directly to the engineers and designers to try and get a picture of progress. You don’t get much time with them these days, and they seem pretty disengaged with your excitement about customers and where the business is headed, presumably since they lost their Product Manager. The tech leads seem really reticent about making any decisions about any new features, always asking you: “what are you saying we should do then?”.
Frustrated that things seem to have slowed down without your assertiveness and fearing that you may lose some more people, you tell them exactly what to do to, just to keep things moving along. Since they are not making the decisions, you decide to expedite that decision making for them.
Days go by, and you don’t hear anything from the technical teams about real progress. They’ve had a number of production issues to deal with recently. The last one was pretty foundational to the product, something about the authentication system malfunctioning recently after a new feature was released.
On that one, you even had a phone call from a good friend of yours telling you “the app was down for a few hours last week!”, and they could not even login to it! — that’s not good!
So after a deep sigh, you take the initiative to get the technical team together the next day. You facilitate the investigation yourself to find the root cause of these issues, and you assign various people things to do to get it sorted straight away.
It takes a couple days of intense status updates, and some stern statements from you to lift the urgency of all this, and finally the problem is resolved. You feel drained:
“What just happened there?” You reflect. Everyone just felt like drones, and you had to make all the decisions for them, and tell them exactly what they need to do, and what they need to make sure gets done. No initiative from anyone! Didn’t we hire intelligent people?
One morning you get an email resignation from the lead designer, who tells you that she’s “going travelling overseas with her buddies”. Then two days later, one of the developers quits after a very public row in the kitchen with another colleague. Something about “being up the last three nights trying to get some feature done, and now the codebase is in pieces, and the team can’t release because of it!”. Tensions are pretty high in the technical team, and an intervention from you seems necessary.
Sensing some kind of looming crisis, you arrange an emergency meeting in the break room to try and get a handle on what’s going on in the tech part of the company. The other three CxO’s are looking at you seriously worried.
The big ball of mud
After a heart to heart with the team, you discover to your horror that the codebase of the product is in a real mess. No one has upgraded any dependencies in over 8 months. Your domain and SSL certificates are about to expire, and no one can find the password credentials to renew them. There are 12 branches of work in progress, and they cant get a release shipped.
You discover that they’ve built a number of APIs that all do the same thing slightly differently and that has caused major confusion and outages for some customers, they no longer run the automated regression tests, and the devs stopped writing unit tests months ago.
It turns out that they haven’t actually shipped a complete new feature in about 4 months! Those new features that they said were done are actually still hiding behind feature flags that are not enabled in production, because they are afraid that they will break something else.
“What the hell have you all been doing all this time, you ask?” and immediately regret the words spilling from your mouth.
Pro Tip: best not to make a bunch of hard working conscientious people feel like they are useless when they are already dropping like dead flies from your organisation!
“Are you f’ing kidding me?” A designer blurts. “For the last forever, we’ve been working our asses off designing these new features, and then having to wait weeks for the devs to implement them”. “Wait a minute!”, a engineer interjects, “it’s taking us ages because we have to write all this extra framework code to support these new features, since the libraries we are using are all out of date, and we don’t have time to upgrade them just yet.” yada yada yada. “Plus, we don’t want to touch our existing API’s because we’ve had to stop writing tests to keep up with these new features, and we don’t want to break them — remember what happened six weeks ago when the /authinfo endpoint started spitting the dummy at our customers?” he retorts.
Not only are you horrified with the state of the product you are hearing, and the implied delays and broken promises to your customers with it all, but it’s ghastly to hear these guys go at each other’s necks. Given that you’ve all been very tight for such a long time, really good friends. “What on earth has happened here?” You recognize some of the things they are talking about, but can’t see how it all went wrong. Even the lead engineer gives no insight to how it all started or when. You are no longer up to speed on the current architecture and tech stack they are using, so you can’t see through that either.
Is this a technical problem? A teamwork problem? A scale problem? You can’t tell right now.
The myths of the tar pit since 1975
At the next day’s top table strategy meeting, your founder friends are looking at you very sternly. “What’s going on in the company?” they ask you. “Marketing is getting a lot of push back from the techies, and we can’t get the new campaign out to customers yet”. “Sales can’t even get a meeting with them, they refuse to talk to anyone, and the phone is ringing off the hook from our big clients”.
“Your road-map promised us those features 2 months ago, so where are they?”
Martha had to handle a pretty irate customer on social media yesterday giving your support team a hard time for mixing up her bank account information. “…and we had to discount three customers this week because they’ve complained they can’t use the app on their phones!”
Get ready! Here it comes….
“Do we need more tech people to lighten the load on the ones we already have?, or do we need to get some better ones?” “Surely, if we are going too slow, we should hire some more help and accelerate delivery?” your fellow founders challenge you.
“What about outsourcing some of it? My best friend Laura runs a services business and they make apps for businesses, we can use them, can’t we? We have to do something here?” Martha implores.
Whoa! OK what on earth is going on here?
OK, let’s stop for a minute. Feel your blood pressure rising?
Let’s take a step back from the theatre and drama of this story line and let’s take a closer look at how this kind of thing is prone to happen to companies operating like this at this kind of stage of growth.
The founders in the story have been steadily making a number of key incorrect assumptions about how their company should be run as it has scaled in size. They’re not doing this consciously; running the business the way that they are feels absolutely natural to them, and they haven’t stopped to wonder whether it’s the right thing to continue to do as the business scales — until we have a crisis like the one described above.
Up until now, they’ve just been focusing on the day to day journey, thinking that process details and their company culture will naturally work itself out as the company succeeds. “We got great people, doing great things, everything is fine”. They think they have a good enough culture and plan to sustain the growth in the company, and don’t realize that in scaling the business things inside the company roles have changed dramatically.
They are now inadvertently running a command-and-control top-down management process that’s now baked in across the whole organisation — with predictably bad outcomes.
So, let’s look at some of the key assumptions these founders have been making.
Expertise moves up as the company scales up
Also known as the Peter Principle.
As this company has scaled, the founder’s roles in the company have remained at the top of the company in the most senior leadership positions. With more layers of management added below them. Management layers are a common management tactic designed to insulate the senior people from the details of people/process issues below them. We just get a “manager” to deal with the details and have them report up the important information. Now, they think they have time and space to focus on the ‘business strategy’, instead of on the day to day issues in the organisation, or with their customers.
That belief tends also to drag along the the belief that they should also own the ‘product strategy’ too. And that their view of it should be supported and ratified by those in the middle, to those at the bottom. This seems logical to any founder: because the did start the business in the first place, they are the most senior, most knowledgeable about the business, and as such have the influential C-level titles to reflect that seniority. With that self-empowerment, and as leaders, they feel that they should also have the primary say in what gets done and when. They run the show of course!
What they haven’t learned yet is the necessary separation between business strategy and product strategy, and where those two things are best to be driven from.
The way they are doing things now was not how things worked well when the company first started. Back then, everyone was a peer working alongside each other solving complex problems together. It was necessary for those people to take full responsibility together, and share in the successes and failures of doing that — a true venture. And at this time they were conflating both the business strategy and the product strategy within the same group of people. That is not what is happening now, and there are unintended consequences directly related to this difference now.
One of those unintended consequences is that decisions about product strategy are now inadvertently taken away from those who should be solving the real problems the business faces every day on the front lines. That decision making has moved up in the org along with those who have risen in the org.
Now, we don’t have a group of peers sharing the problems and juggling opportunities and making decisions about what issues to resolve and how, taking responsibility for them (success or failure) together. Instead, we have decisions about product strategy communicated directly down from the top as absolute and final.
If a decision results in some kind of success, predictably those at the top will take the credit for that decision, confirming that the product strategy aligns with the business strategy — that’s if they see a difference in them. Unfortunately, if a decision results in failure of some kind, the top will be blamed for it too. Nobody below in the organisation will think twice about taking any responsibility for any of these decisions — why would they? They had no say in it!
After a while of this kind of dis-empowerment, and probably after a few courageous run-ins from frustrated people pushing back up the chain of command, the people at the bottom slowly get used to only doing as they are told, and not bothering to take responsibility for problems they encounter.
“It is not part of my job to care about that issue, is it?”
These people just get used to escalating problems to someone above who has been incentivized to bother about it, and who will have to take responsibility for it. In a way it’s what they are being taught to do and conditioned to do in this kind of culture. But the founders at the top are unaware that is happening below them. The founders just assume that everyone in the company cares as deeply about the business strategy and product strategy as they do.
But instead of creating missionaries who take responsibility for, and care about producing a product strategy to align with a business strategy and grow the business, they’ve created mercenaries who largely only care about their own needs, and who focus on keeping their heads down doing what satisfies them within the bounds of what they are told to.
So, why do the founders move up into higher positions and take with them the decision making?
Largely because of an ingrained old-world belief: that going up the org holds higher status and authority. And partly because of that increase in status and importance they are naturally most knowledgeable about the business. So, they believe that they are best placed to be making the big decisions themselves. Who else is better qualified to do that? Certainly not those who came into the business later than, or lower than them in the organisation, right?
But, what’s really happening here is that the founders are moving out of their respective areas of expertise — i.e. the banking domain, or technology domain — and into roles where they have little experience or little capability: running a profitable software business.
The particular tech founder in this story had two pitfalls: firstly, they assumed that their knowledge of technology and of banking make them best placed to dictate and operate this software business strategy, and secondly, they assumed that they are best placed to control the product strategy and represent their customers’ voice far away and from the top of the company.
This is a very dangerous and risky position to take for a tech product company. But yet, so tempting and so common for a founder to do.
Rather than expanding their influence at their current level where they have high competence, they choose to move into an area where they have lower competence and more influence. As the principle says, they have reached a level of incompetence.
The impact of this is really bad for the company. The company suffers twofold because of it. Firstly, they lose a highly competent and effective individual contributor who is also very influential at this level in the org, but worse, they gain a less competent but more senior person, with a wider-reaching influence at a higher level. This tends to have a double-whammy negative impact across more people under that new senior person.
But, why does that happen so readily?
Well, the aged Victorian-era ideology that managers are more valuable and superior to the workers in a company, and that hard working highly-valued workers ought be rewarded by being promoted into a manager’s position? This may have been effective when the workers were doing menial rote work in the industrial revolution, but is certainly not the case for highly intelligent people doing complex creative knowledge work nowadays.
Not only that, but when it comes to creating innovative software products, higher level ideas are no better than lower level ideas. Wherever and whomever product ideas come from, most of them are not going to work regardless of how well informed or entitled those people are!
This is where most tech companies go very wrong indeed!
Disconnected ideas from above
Now, take someone who is influential and successful at any given layer in an organisation, and move them up to a higher more influential level in the same organisation and try to convince yourself that that move does not make their ideas and opinions more potent and influential to those below them. Yes, even the ideas that won’t work will be seen as better when they come down from higher up in the org.
No matter who you are or how much integrity you have, your ideas are going to be heavily biased towards your own personal and limited experiences and influences immediately around you.
Furthermore, as you rise up an organisation, those ideas are likely to remain unchallenged by those below you in an organisation, no matter that those people may actually be far closer to the market and their customers.
The founder in this story hasn’t yet realized that he has completely and inadvertently dis-empowered the product teams below him because of these factors.
Moving up the organisation is moving further away from the real customers, the market and their ever-changing behaviors. Designing new and innovative products (software or otherwise) is inherently and continuously creative work — it requires continuous change and good amounts of uncertainty. You can’t actually plan it or predict it, you can’t crystal ball it — but you can certainly delude yourself in doing all those things of course — and it’s so tantalizing to do just about anything to get a bit of certainty where you can.
The hardest realisation in product development is that you can’t actually know what’s really needed or actually works in the market unless you work in that market day in and day out. When you’re isolated from it all at the top of the organisation, all you can do is make intelligent guesses based on limited, low fidelity data that is filtered on its way up to you.
Combine that with a further distancing from the constant changes in technology that are vital for future tech innovation. Your new ideas really aren’t that great anymore! Sorry, but deal with it!
Using your position in authority as power (even if it is not intentional) to impose your ideas as if they were absolute truths is a sure way to destroy potential business value. Business value that would otherwise be created by those innovators closest to your customers.
You are simply not best placed to be making those decisions so far from the innovation front. Oh yeah, and frankly your expertise and experience in banking makes little difference when it comes to knowing what is actually going to work and what is not going to work for your customers.
Your guess is just as good as mine.
To be a good idea, it has to be proven and refined. It needs to be qualified, prioritised, tried, tested, measured and improved upon, long before you can declare that it actually worked. Few ideas actually ever get that far, and few can be bothered with the rigor to go that far. It is just far easier to apply your biases and assume it is a good idea.
Some businesses just won’t scale
In our story, the founders start off with a great idea for a new product, and their hard work is rewarded: it takes-off in the market. But as the company grows and the founders become separated from the teams doing the discovery and development work, they don’t notice the fundamental shifts occurring as they’ve changed role. When they were just four founders doing everything they could to get their start-up off the ground, they were making all the mistakes and decisions and coming up with all the solutions, and they were rewarded for doing that with confirmation in the market.
So, as the company scales, they naturally think that all they have to do is keep doing that at a larger scale with more people, and that has them falling into the trap of distancing themselves from the work and moving out of their areas of effectiveness that made them successful in the first place.
For a while, their approach will look like it’s succeeding. The founders keep coming up with new ideas and dishing them to their product teams to build. Their ideas are implemented slavishly and the product retains its market position for the time being. This arrogance wears thin on the innovators — the product manager, the engineers, the designers — and they lose engagement with the company and the culture starts to change.
“The product must be valuable to customers” the founders think, because all these new features and business value stem from their ideas and deep knowledge and expertise in the banking domain. And everyone in their executive bubble seems to love it. No one is brave enough to say otherwise!
But behind the scenes, the product and engineering teams are overwhelmed with ineffectual demands coming from the top. They are being beaten up by road-maps, and schedules and being overworked and demoralised just churning out more and more unvalidated ideas. No one is actually looking after the health and integrity of the product itself.
No one cares if the ideas are actually implemented effectively or whether they deliver on what was originally expected. Nor actually paying attention to the actual paying customers and what is really working and what is not. How could they? they are far too busy with busy work. The founders get into the routine of constantly having to have new ideas to feed the machine. What else could they be doing, right? Isn’t that what leaders of product companies should be doing? More features, more customers, more money?
No?
It’s subtle at first, but slowly customers disengage too, and look elsewhere. Paying customers are not being heard, the experience of the customer is getting disjointed and bloated, business value and innovation opportunities are being squandered, and eventually the integrity of the product as a whole is weakened or destroyed over time. The product has likely become a swiss army knife of features that tries to do everything, and everything rather badly. Eventually, either competitors will move in and take their market share with a better more targeted, sharper experience, or customers will start moving towards slowly away to using other kinds of products, long before the founders realise the tide has turned against them.
Unfortunately, it’s highly likely by this time, that the founders will conclude that it’s the people below them that have been irresponsible and remiss with the business and the product, and no doubt, a good old fashioned reorg is in order to fix it all up again — only to be repeated over again a few years later.
Tips for enlightened founders and tech leaders
Execution is everything: Yes, your ideas at the start of your business (or for that matter, at any time) have a lot of value as ideas. In fact, at the beginning, ideas have the most value they will ever have. They represent a leap in innovation, a differentiator, an opportunity, an aspiration, inspiration to others.
However, as your idea is realised and as it starts to materialise, the value of your idea diminishes precipitously as it is forged and moulded to the market. The integrity of the idea that goes forward is challenged, and forced to change, and reshape, and re-brand, and re-position and re-form to the constraints and pressures of market reality. Real-world market constraints etch its new form and your aspirations necessarily adjust to the real reachable market. In short they change.
But the idea is still unproven.
What counts now is swift execution and adaptation. Ideas can be copied, stolen, adapted, bargained with. How you take those ideas, learn from them, adapt them and turn them into real business value for your customers is ultimately the more valuable part that is far harder to beat or copy. Business value that you can’t possibly know exists before you build it and before customers use it, and will only be actualised on how you build and they use it.
Build an idea wrong or poorly or incomplete, or build it in a way that users don’t understand how to use it, or find it hard to use, is all as good as useless for your customers and your business. No matter whose idea it is.
You won’t realise your ideas right the first time and won’t reap all the business value from them the first time you release yr implementation of it. You need to innovate, experiment, refine, measure and optimize it — maybe several times. For that you need help from intelligent motivated people with ideas and experiences of their own. Not help from them doing it for you, at your will, help from them doing it with you guided by the strategy of the business.
These people are your innovators. For many founders, this is not a time to move up-market in your own company away from the capability and competency of doing that. It is a time to increase your influence in your company helping and teaching others to do that around you and sharing your ideas. You will gain more effective power and influence in your market, from your company, by increasing your competency hierarchy than you ever will by increasing your division of labor or status hierarchy.
You are running a tech company now: You have moved from executing in a banking domain, into running a software business. You are no longer a bank then, you are a tech company. Your tech is what makes or breaks your business. You need to understand that medium more than you understand banking.
You now live and die not by doing better banking, but by providing better products and services to your customers that solve real problems that the bank can’t solve for them — using tech.
You find those problems for your customers, and you innovate solutions that you find works for them. That is what tech companies do, not what banks do. Not because banks can’t do those things, but because banks don’t need to. Their business model and market position is already well established. Yours is forever changing, you may not even have one yet.
Assuming that your prowess and domain expertise in one area, like banking, makes you an expert at being a tech company leader is simply “intellectual arrogance”. (Taking your effectiveness and expertise in one domain and assuming it is transferable into another domain). Tech companies simply don’t command product strategy from a few industry experts from the top of the company. Banks may do.
Tech companies recognize that products are best built by the people closest to the customers of the product, that it is a team sport, and that it requires diversity in expertise and innovation to exploit advantages in new technologies.
Tech companies drive business strategy from the top of the company, there they define outcomes that will drive the business forward. Product teams then define the product strategy that meets the business strategy, and they deliver the product that delivers the outcomes. You simply can’t do all of that effectively from a small group of people at the top of the company.
You need the power of many diverse people working together to achieve that at any scale.
Tap into your collective intelligence: Finally, if you are going to hire intelligent people to do difficult work for you, then they will expect to exercise and use their intelligence in their work.
They will want to do this by learning for themselves. By telling them what to do, or worse, how to do it, you are literally robbing them of any responsibility to get it done right. You’ll simply create “order takers” like the troops in the opening photo, people who only do what they are told, when they are told, how they are told. That’s not innovation at scale.
Now, know this. Whenever you do that (tell someone to do something), each and every time you do it, you take all the responsibility for it getting done right. You take all the responsibility for making the absolutely right decision all by yourself, and with that all the accountability for all the right ones and for all the wrong ones. They have nothing to do with it, and want nothing to do with it.
Do you like people pointing the finger at you when you make a wrong decision? Why put yourself under all that pressure and carry all that risk when you have others around you to share it with? When it is shared, there is no one to blame, and learning from mistakes is far easier and more sustainable.
If you are even remotely aware of yourself and your limitations, that you are fallible and that you often make mistakes, and that your biases often cause you to make the wrong decisions, especially when it comes to what other people need or want. Particularly when it comes to managing complex markets and opportunities. Then you are going to want to work with a diverse set of intelligent people as your peers who can see your blind spots and build on your ideas to find better ones, that otherwise you wouldn’t have thought of, for the customers that you serve.
If not, product development is probably not for you, my friend.
This article was conceived and co-authored by Asha Scott-Morris and Jezz Santos, borne out of a desire to communicate to leaders of tech companies (existing and new) the importance of empowering and growing the people who are your best innovators and your best chance of creating a successful product business.
(Funnily enough, while they were were both working in a bank.)
