The Hitchhiker’s Guide to Technology in Enterprise

“Innovation comes from saying no to 1000 things.”

Steve Jobs

The past decade of my career has been spent focused on enterprise, first in supply chain with time in procurement, finance, quality, manufacturing, strategic sourcing and employee training. This experience was followed with a brief stint as a developer for a startup in 2017. Now, back in enterprise, at the intersection of supply chain, operations, technology, etc., I find myself with a unique vantage point at the convergence of these industries.

As an individual, I’m enthusiastic about discovery and innovation, from the fundamentals of mathematics to the incremental improvements in a user interface design that drive unanticipated waves of change. However, without question, enthusiasm is not a guarantee for success in innovation or change, and, as Steve Jobs aptly put it above, true innovation exists among a multitude of declined opportunities.

The guide below is composed to ensure that startups, large technology companies, and enterprise, not only say yes to the right opportunities, but, more often than not, “no” to the sea of erroneous ones that risk diluting or completely absconding the resources needed for that narrow path of truly innovative direction. While I believe this information to be objective and carry an intrinsic value to my audience, it is born entirely of my own experience gained insight and thus does not reflect the opinions of my current or previous employers; it’s what I have gleaned over the years as to what separates success from failure. Not only filtering the opportunities to discover those of true promise, but also shortening the agonizing time period between the two possibilities of success or failure for relevant parties.

1. Understand and communicate the differentiators. Under every broad category of technology, there still exist unique approaches. Regardless of where a technology sits within the Gartner hype cycle, on either side of the table, both startups and enterprises need to thoroughly understand what differentiates a company within a category. For example, blockchain is an overarching technology that has several categorical elements: consensus mechanisms, privacy methods, interoperability, decentralization, etc. To the technology company in pursuit of providing modular options, a buffet of choices without thoughtful recommendations accompanied by solid rationale appears to lack understanding of the enterprise environment. Likewise, an enterprise that seeks to find anything that falls into a major category too broadly risks misallocation of time and resources. So, although an enterprise organization may only aim to be an end user of the technology, paramount to success is the understanding of these differentiators because in the future, differentiators very often become tradeoffs. Not necessarily tradeoffs within the developing technology itself but tradeoffs in the organizational resources: cash, internal time, adaptability, etc., which leads into the next point: the big picture.
2. Big Picture. Within each area of technology, there is an entire world of communities. From artificial intelligence to data science to robotics, you could spend an entire lifetime exploring a small subset of a category and never reach the end. However, in the context of a larger enterprise system, these smaller categories can look like a blink of an eye. That is not a comment on relative importance but a comment on technology relationships. No technology will solve all enterprise problems as a pillar unto itself. Both technology companies and enterprises need to find the fit and relation between each suite of solutions to target the larger picture of a strategic business plan for the enterprise. When a technology fits within a strategy, its relative prioritization is inferred. If you try to prioritize a single category of technology, finding the fit within a larger strategy is far more challenging.
3. The burden of proof. Proof of concepts, proof of value, prototypes, and other names that encompass small trials can be a great tool or a great weakness. While these endeavors offer the opportunity for a technology to be viewed and tested prior to full commitment, these projects are opportunities to fail as well. Failure is often not encountered as technical short comings but rather rationale short comings. Enterprise is bound to take an objective business opinion on the efficacy, cost effectiveness, and larger strategy around a technology. Technology companies need to fully understand how they will be evaluated — as the demonstration of working technology is simply not enough in most cases. How is this reconciled? Quantification.
4. Quantify the statement of work. The absolute best guard against semantic and conversational misunderstandings is quantification. Numbers are a universal language. A common mistake is the inference of a binary element in the statement of work, such as “Installation,” will be interpreted correctly by both sides. What were the timeline expectations? Was this faster or slower than other options? By how much? The occurrence of an event does not translate to success, it only means that it happened. Contractual agreements on proof of concepts and initial projects need to be rigorously quantified on a comparative scale that allows for defined interpretation of success rather than a recognition of occurrence. Without this, both institutions are looking at a checklist for their common language, which is not an indicator of anything other than the binary occurrence of events.
5. Access Expectations. A simple one. Both parties should not expect access to all the enterprise systems they would like to ultimately have in the first stages of a project. Access through a VPN to an enterprise system as a third party vendor is almost unheard of these days, and the ability to install software in production environments is limited at best. Digital security should be involved and give clear limitations and expectations for the organization to work within for proof of concepts on a policy level, not varying individual approvals. An understanding of the implications of this should be evaluated and considered for the success of the project — what differences will be encountered at different levels of access?
6. Clarity on development timelines. As large organizations start to invest in more and more early stage companies, technology development timelines should only increase in importance to both parties. Both parties need to be clear on expectations of developments in the future. Technology companies should give dates, show progress, and demonstrate increasing competence and adaptability. Enterprise should plan proof of concepts, scaling, and possible adoption accordingly. An ill-timed project in the development timeline of a company’s planned product could not only lead to failure to scale but also leaves both parties with less time to focus on better solutions or readying themselves for better solutions.
7. Solving problems versus finding use cases. In short, the existence of a use case does not imply that there exists a worthy problem to be solved. Many technologies can be used across a broad array of use cases within an organization. However, as the saying goes, “To a hammer, everything looks like a nail.” In large enterprises, both sides of the table can easily find use cases, but keep in mind that the focus should be on solving problems.
8. Cost Rationale. How should a project be priced? Rather than a broad comparison and guidelines, what both organizations can focus on is rationale. Why is the cost what it is? Giving an overarching fee for the entirety of the project without explanation leaves little room for discussion or future scale cost implementation. Without a breakdown of rationale of costs, fees look arbitrary. Similarly, asking for cost reductions arbitrarily also lacks understanding of real value.
9. Terms. Intellectual property. Payment. Liability. All should be discussed and clarified. Both organizations should be clear on the level of interest in the work though while wading through legal. A long legal discussion from enterprise does not necessarily indicate a lack of interest. However, the more pre-work both parties have had around the acceptance criteria as a policy beforehand rather than a one off, the faster these discussions will go. Plan and prepare rather than react.
10. Ethical and Environmental Context. More than anytime in the past, every organization from startups to the largest enterprises on the planet have more than business plan. They have a mission: ethically, in terms of labor, diversity, and inclusion, and environmentally, in terms of climate change and lower carbon initiatives. The more aligned and open all organizations can be around common mission driving goals, the opportunity we all have around better the world we live in. Here, I simply encourage all organizations be bold and have the conversation — what more can innovation do around the problems we all want to solve?

Technology has yet to find a formula towards the best technology consistently winning out in the widest adoption. In many cases, we have even over-engineered more complication into processes that worked better with less technology, and still, we have arcane systems that are vulnerable, inefficient and begging for innovation. We are not going to innovate our way out of that challenge, but with better emphasis on the ten points above, I emphatically believe we will make more progress.

Questions? Comments? You can reach me at karenscarbrough@protonmail.com.