Brant Cooper
Brant Cooper, the New York Times bestselling author of The Lean Entrepreneur and CEO of Moves the Needle, and Etienne de Bruin, the Founder of 7CTOs, discuss how CTOs shield their organization in various ways. From protecting intellectual property, compliance to risk management, the most impactful competitive advantage is how the CTO helps address the market by organizationally reinforcing innovation.
Brant starts the conversation by questioning the fundamental role of the CTO in uncovering this information. What does it mean to be a CTO? Is it to manage the technology house, or should CTOs get involved in business strategy and help the organization achieve goals? Within modern business management, we assign the chief officers of different groups to limit their role to within their domain responsibilities, whether intentionally or not, and give the CTO the position to bring all those components together, which in Brant’s opinion, is wrong.
Today the C-suite needs to be its own agile team, not based upon hierarchy, but leadership, with the ultimate mission or objective of moving the corporation forward. The CTO gets to weigh in on Marketing, Business, Legal, and HR; for example, the same way the Chief Marketing Officer gets to weigh in on things to do with technology. It’s about how we structure the organization, and according to Brant, the C-suite needs to be more agile. CTOs can build; however, the most considerable risk to companies is not just intellectual property. Sure, intellectual property is crucial, security is too, and perhaps in previous times, technology was, in fact, at the core of all business in that if we build it, we can sell it. But there’s been a modern shift. CTOs should no longer be primarily concerned with the operating processes of their group, and they need to be more involved in the strategic discussion of where business is going.
Etienne agrees with this vision. To Etienne, it’s not favorable to compare product versus engineering in the sense of “what needs to be built” versus “how it gets built at a tech level” because they bleed into other areas. He goes on to say that although it’s essential not just to be the expert in your domain but also to focus on your actual field of expertise, it’s the collaboration that’s perhaps even more important. It’s almost functionally irrelevant to where you come from when focusing on what happens next because that’s where a different level of discourse is needed. This is precisely why Etienne believes the CTO should be more involved to help leverage competitiveness.
Brant continues speaking to this vision of CTOs helping to leverage competitiveness by focusing attention on agility. He explains that although we hire and promote based on expertise, it’s the experience in the business world, managing people, and being a leader, for example, gets you in the C-suite. Once you’re there, you shouldn’t get pigeonholed back into where you came from. Brant gives the example of ING Bank in the Netherlands. They are known for their innovation by restructuring their leaders around the C-suite and business units for everyone to get more broad experience. Within this process, you could be the CFO for some time, then a CIO, then the CEO of the Spain location, for example. So although there needs to be an element of expertise within your domain to get you up to that level where you truly achieve it, it no longer matters where you’re from in terms of your expert background. Because if someone was to become a CEO, they need to know a bit about all of those functions.
When speaking about agility, the CTO and engineering side have the most experience in this realm. The entire organization needs the positive aspects of agility, but where can you find this? Again, it goes directly back to the CTO. The CTO and engineering domains are most agile in the sense of being open and responsive to change.
Next, Etienne shifts gears and wants to pick Brant’s brain regarding competitiveness in getting to the market quicker. Can we do this by listening more to customers, being more agile, responding to customer needs? Brant explains that it’s all about customer insight and, perhaps even more critical, insights into those customer needs. Many companies pretend they know their customers but automate feedback instead of talking to actual customers. Brant believes understanding the customer does not mean blindly doing what the customer says, however. More profound, the most crucial information needed to uncover is why the customer is asking for what they’re asking for. This will give insight into other opportunities. For example, maybe your customers are using your current product in a way that wasn’t intended, so there could be a different market opportunity based on that information.
According to Brant, the more we understand what’s driving the customer and their aspiration, the more the product engineers and marketers can best aggress their genuine need, which is the real way to win within the competition. Brant brings up “needs” in his new book Disruption Proof: Empower People, Create Value, Drive Change. He mentions need management within product portfolio management and this idea that outside the ethos of customer-centricity and the core of the business, needs don’t fundamentally change over time. What does change is how companies address those needs. So if you think, what are the needs that my current company builds solutions for? Then, one can manage and evaluate how those needs will be addressed over time.
In Peter Drucker’s book, Innovation and Entrepreneurship, he talks about when the baby boomers headed to college. Because of the large population of students, the higher education industry responded with products and services to address the significant need. But from a product portfolio view, you’re meant to think, how can we extend this? And so, the focus became expanding such products and services under the assumption that the need will be the same or higher. But there became an issue when future, smaller generations came along, and there were still those same growth targets for products and services. So when it comes to needs, it can be a demographic or technology approach. It makes us look at our products based on time horizons. The needs we are addressing don’t change. We can look at different market opportunities based on who else has those needs in addition to our existing market, however.
Etienne adds that if engineering is how things get built, in terms of competitive advantage and time horizons, how things get made will be affected by innovation, change, the future of everything, so who better to have those discussions than the engineers. That’s why he wants CTOs in such conversations from the get-go. Brant agrees and further explains that R&D, Engineering, Marketing, for example, all different groups, need to be thinking about time horizons, not just the Innovation group. The C-suite needs to be looking at needs to figure out how various departments work together to prepare for those different stages of growth. Etienne agrees that the C-suite mindset should encourage the CTO to be part of the much more significant time horizon, such as helping forecast where the organization will be in the future.
Etienne is curious about what type of culture is needed to empower the views of the many within the organization. He is interested in learning about the relationships companies should have with service providers or attorneys to help cultivate different conversations about what is considered competitive? Brant believes everything starts and ends with proper communication flow.
A company itself is not agile if only one department or side is agile. The shift is when the power lies from the edge. Agile is what empowers teams on the edge. Today each department knows what is going on, but the communication flow doesn’t come to the edge and back up to leaders. The communication flow doesn’t come across the company either; it doesn’t flow from Marketing to Engineering or Engineering to Marketing, for example. In a larger organization, we are siloed, so the information isn’t going up the chain or across the company, and that can’t be fixed until we all become more agile. And more importantly, we then need to implement a very purposeful communication structure so that management and leaders get the information they need to correlate what the priorities are or if those priorities need to be changed. Then that information flows back down in terms of resource, allocation, and mission.
Brant believes that middle management is put into a tight squeeze. They are supposed to manage agile teams; however, the leaders haven’t changed how they manage. So middle managers feel the pressure and get top-down pressure to do things the old way as well as bottom-up pressure. So they are caught in the middle. Frequently middle management is left without training and isn’t empowered to understand their role. Brant believes the next area of focus for the future will be on the skills that middle management needs.
Brant believes this is happening because of organizations using old-school KPIs and OKRs. These “old-school” metrics are task-generated and measure the amount of work people complete when we need information about progress towards the desired outcome or learning metrics in an agile world. These metrics help us learn how to make progress so that the calendar does not dictate the percentage breakdown. Instead, it’s the actual percentage toward the true mission.
Piggybacking off of old-school metrics, another old-school technique that Brant believes should end is product launches. He thinks the product launch is dead, old, and bullshit. Instead, he considers it old-school product management. It’s managing by the calendar, not by percentage done. As a product manager, head of product management, and marketing and business development executive for a start-up, Brant remembers launching a hardware platform when the product was not fully complete, and therefore, the customers found many problems. So, they worked exclusively with those early adopters and iterated on the product until they had a solid shippable version. At that point, they then started the marketing and sales.
The old-school idea of the big launch is bullshit, according to Brant. There is no reason you can’t create a classic non-lean start-up approach, which is not launching to everyone but instead focusing on your early adopters. Who are the three customers working with you to finalize a shippable working version that helps solve problems significant enough that they would be willing to pay you decent money for it? And once you’ve done that with a handful of customers, you can start rolling out the marketing and selling plans. The big launch does not help you; it’s BS. So we need to stop doing it. And this solves the problem of what we are measuring. Because that early on, it only measures the progress towards a minimum viable product. And we don’t know what’s viable until it’s in the market to some degree.
Etienne and Brant then discuss trust and uncertainty when going to market. Brant explains that it’s normal to see an uptick in uncertainty as we get towards the market; we suddenly notice an increase of uncertainty around whether we are building the right thing, understanding the marketing, understanding the selling, what the customer needs, and so on. The more uncertainty, the agile teams become more cross-functional, which is how you get the alignment between different teams. Because as you increase uncertainty, each agile team comprises representatives from each group; Sales, Marketing, Engineering, for example, and it’s their responsibility to figure out the unknown when launching a new product. There’s a shared responsibility to getting a product out to market instead of the traditional linear siloed way where a product is released and launched, and if Sales can’t sell it, they blame Marketing, and if Marketing can’t market it, they blame Engineers. It’s a vicious cycle of dysfunction. So if you have a responsible team for going to market, it would be a cross-functional team.
Etienne challenges this idea and explains that even with cross-functional teams, there can still be collaboration issues, though, because, within cross-functional teams, there will still be team members concerned with only their expertise within the realm of their own domain. Brant explains that true agile teams are responsible for the actual release versus representing their group of expertise. Perhaps this is idealistic, but the idea is to focus on the mission at hand.
Brant continues by using an analogy of a special forces team to kill an enemy and how their main goal is the mission at hand. Special forces are mission-driven and mission-based, and folks on that team have the right skills needed to drive the mission forward; specialized trained people with the right mentality regardless of hierarchy in service to the task at hand. Companies have those people, according to Brant. But, unfortunately, those people are most likely wasted within the organization and made into managers because that’s the old-school way of promoting valuable employees. So if we put an individual like that on a special forces team, they will work with different parts of the organization to accomplish the mission and drive it forward.
Etienne then transitions before concluding the conversion into discussing agility and innovation. He questions how to navigate agility and innovation at the same time. Business never seems ready to form a mission around an idea. So how does one empower that? Brant believes it comes down to rules of engagement. There’s a culture, ethics, and regulations, which apply to business when it comes to innovation. Companies need to have ways for employees to feel empowered when ideas are a dime a dozen. Is the employee willing to do the groundwork to provide evidence that the idea is a valuable one? How passionate are they about the idea? Are they ready to run a lean start-up experience that will provide data on this idea in support of it? Creating an idea or innovation infrastructure is a great way to empower employees. Because then, there is a standard process that each individual with an idea must work through to show solid evidence of its purpose.
