Smart Contracts, Remote Teams, and the Influence of Blockchain

The Current State of Affairs

More and more companies are outsourcing their digital innovation projects, opting to partner with remote teams overseas that can outcompete the local market. That said, when working with distributed teams, some fundamental aspects of the working relationship may also change. Regardless of the risk of entrusting a long-distance party with product development – no matter how high the talent level is – it’s still important to reduce the business risk as much as possible the same way it is at home.

Systems still Operate in a Centralized Fashion, Mostly

In most agreements in this space today, parties engage in transactions with one another through a centralized broker or central system, and these are often external. In doing this, each party trusts the central system rather than each other. Although the practice is majorly tried and true, placing the trust on a third party to execute the business is inherently risky because it makes both main parties dependent on the third, not to mention it could also be unnecessarily costly.

Enter smart contracts.

Smart Contracts are a Blockchain underpinned software that stores the negotiating terms, contract verification, and subsequent execution of the agreed terms. These contracts are executed on top of the Blockchain using platforms like Ethereum, designed so that “applications run exactly as programmed without any possibility of downtime, censorship, fraud, or third party interference.”

In general, smart contracts offer a new way to remove trust issues and decrease costs by removing the need for a third party when fulfilling contract terms. Decentralizing the process using a smart contract makes it more secure, more cost effective, and faster.

Smart Contracts work and are executed entirely by triggers within the code, so there’s no human interaction during the execution process. This removes the need for the third party involved in more traditional contracts, saving time and money and reducing the overall risk of one side not holding up their end of the deal.

How does a Smart Contract help with remote teams?

For everyone involved in a remote work agreement, smart contracts enable easy transactions safeguarded by knowledge that the Blockchain technology authenticates them independently. For smart contract users, this means that when an agreed deliverable arrives and verified, the contracted supplier is paid automatically by the self-executing smart contract. In this way, the contract will also save time as suppliers won’t have to chase up payment of invoices for services since these are automatically completed via the smart contract.

Fortunately, the same thing applies when payment is confirmed for a product. That product can be transferred automatically to the buyer and its delivery information would be logged within the Blockchain. This provides a complete and incorruptible record of transactions logged on the Blockchain, all in chronological order.

Aside from the increased level of trust, smart contracts also give those involved:

  • More autonomy: There’s no need to involve a third party, and once everything is set up there is no need to jump back in to complete anything.
  • Safety and backup: Cryptography removes the risk of being hacked and as your documents are duplicated throughout each part of the chain, there’s no risk that they’ll get lost.
  • Accuracy: Decreased human interaction with the process removes errors that can arise from manual input. There is a complete and accurate record of everything that has happened within the contract so all components can be tracked.

The upshot

Smart Contacts remove the middleman, lower costs, and make the overall process of remote working agreements more efficient and safe. Expect smart contracts to play a big role in the future of work, as well as other areas as the technology matures.

Product Owners: Understanding who the real MVP is – Part Two

Part 2

This is the second of a two-part series on product owners, what they do, how they do it, and why they’re so often vital to the success of development.

Product owners have a huge number of responsibilities within their remit. While Part One detailed the context of a product owner’s duties and responsibilities with stakeholders, development teams, user stories and product backlogs, Part Two here will detail about intelligent prioritization, managing feedback, juggling multiple expectations and expectation management.

Intelligent Prioritization

Product owners will judge user stories based on their size and perceived value in order to prioritize the backlog as intelligently as possible. If two user stories are roughly the same size but one has more value then naturally the more valuable user story will take precedence in the pecking order. This applies to stories with similar value but one is smaller. The smaller one goes first.

How do product owners know the value and size of a user story? Short answer is that they don’t. It’s educated guesswork based on constant communication with stakeholders to find out what is valuable, and the development team may help estimate what is big and small in terms of buildout and implementation. In the end most guesses are relative to the current project, but the time it takes to get these right is time well spent.

The Feedback Loop

An efficient agile team needs to deliver early and often to maintain velocity. It can accomplish this by breaking down user stories into pieces. In an ideal scenario the most clearly defined stories are at the front of the product backlog, while the more nebulous ideas are at the back. These will eventually be rendered clear and into bitesize pieces in a process known as backlog grooming.


Image via

Backlog grooming usually involves the entire team in addition to a few stakeholders. In general, these meetings focus on dividing user stories, acceptance criteria, and estimations. It’s important that these take place because regular communication is what typically binds the agile process together. As the Agile Manifesto says, “Individuals and interactions over processes and tools.”

Juggling Multiple Projects

When a product is finished, the work doesn’t just cease. Unless an app, platform, or service is completely shut down, development teams rarely have nothing left to do. When handing over projects to others, they’ll need to review responsibilities and make sure processes are well documented. In other cases, they may hang on to provide maintenance and upkeep themselves.

For product owners, this means they’ll have to start coordinating on other projects while all the above takes place. This means they must also begin prioritizing work across multiple products with new stakeholders. Unfortunately for them, this means the product backlog might now contain user stories for multiple projects.

Extreme Expectation Management

As the project progresses, stakeholders and clients may ask when their product or feature is being built. In cases where the development team has no scrum master, then dealing with these timelines and expectations falls to the responsibility of the product owner. No matter who it is, somebody must manage these expectations of the clients and stakeholders. Product owners forecast progress using story burndown charts, which show the cumulative number of stories been delivered over time and allow them to accurately forecast output, or timings of deliverables.
Image via: Scrum Alliance

If a development team’s output is difficult to predict, then there will be greater disparity between the optimistic and pessimistic projections. The gap separating pessimism from optimism is known as the cone of uncertainty.
However, with burndown charts, a product owner is able to answer a stakeholder’s question of “How much of the product will be complete by June?” with a fairly accurate estimation of the minimum and maximum number of completed stories.

The Bottom Line

Without a dedicated product owner, any development cycle is at risk of spiraling into a chaotic mess of unprioritized, unbuilt features, an unorganized backlog, missed market-windows, unhappy stakeholders and an overworked development team. Product owners bring order and maintain communication for the agile development process, and their contribution to the final outcome of a digital product is immense. The responsibility is gigantic, and that makes product owners the real MVP.

Product Owners: Understanding who the real MVP is – Part One

Part One

This is the first of a two-part series on product owners, what they do, how they do it, and why they’re so often vital to the success of development.

A good product owner plays a critical role in agile development structures and separates mediocre development results from the great. To understand what product owners truly bring to the table, it’s important to consider how agile development works from their perspective.

The Context

A product owner has a vision about the desired end creation and the stakeholders (those affected by the product) have lots of ideas about what the product should do. The stakeholders’ needs are expressed neatly through user stories – a map or guide that arranges these needs into an easy-to-follow model to help understand the functionality of the system, identify holes and omissions in the backlog (more on this later), and effectively plan holistic releases that deliver value to users and the business. Typically a user story will follow this formula:

As a {type of user}, I want {to perform some task} so that I can {achieve some goal/benefit/value}
(Scrum Alliance)

The product owner is responsible for making sure user stories have actual value and are sufficiently prepared to be passed on to the development team.

Teams and Sprints

Any product needs people to build it. In agile software development, cross-functional and self-organizing development teams make the products. These teams usually works to release continuous iterations of a product during phases called sprints. Typically, sprints take around two weeks and the number of user story points released within each sprint is the team’s capacity. Teams may release around five to fifteen stories per sprint but this can change depending on the kinds of changes and stories the product requires.

Twenty user stories is generally the upper limit and this usually occurs in a web team with lots of small changes to do. Anything more than that is probably too much, unless it’s for maintenance teams to knock out a backlog of small defects. As a rule of thumb, exceeding the upper limit usually means the stories are not clear enough, the sprint is too unrealistic, or the definition of “done” is too weak.

Most individual user stories shouldn’t take more than half the sprint to develop and test. Having multiple stories that take up more than half the sprint at the same time is risky, and in that case all the other stories should be very small. For a two-week sprint, it’s better if every story can be completed in one to three days. (Adjustable for longer sprints.)

“Yesterday’s Weather”

The leading ailment of sprints is when stakeholders and everyone else with a vested interest in the project ask for more, and ask for it in waves. As the development team releases iterations, it’s only natural that the stakeholders become more inspired. Still, as much as it’s unreasonable to ask stakeholders to figure out all their ideas at the start of the first sprint, it’s just as frustrating for development teams to aim for targets that move. Imagination changes on the go, and ideas can’t always fit on a development team’s plate.

As a result, teams that have a capacity of five to seven user stories per week won’t perform well with stakeholders pushing ten. This kind of overloading can cause some serious miscommunications, misaligned expectations, and lower quality results.

The way to avoid this is a method known as ‘Yesterday’s Weather’.

The development team says, “The past couple of weeks we’ve been finishing around five to seven user stories per week, so let’s say six is our optimum number that we can work on simultaneously.” Six is now their work in progress (WIP) limit, which is the maximum amount of work that can exist in each status of a workflow. When they finish one user story they start on another one. Finish two, pick up two more, and so on.

Strict task limits force teams to focus on smaller sets of tasks, causing increases to throughput and reductions to the amount of work that hangs in the “nearly done” category. At a fundamental level, WIP limits encourage a culture of “done,” which can be satisfying for everyone involved. Additionally, WIP limits also boost the visibility of bottlenecks and other elements that stifle progress. Teams can then clearly understand what is being blocked, why and how that’s the case, and develop a resolution strategy. Minimizing the delay of blockages allows the entire team to keep a steady pace and workflow.

The Product Backlog

If a team gets too ambitious and breaks its WIP limit, fast can turn to slow, accuracy can turn into sloppiness, and output can start to leak or fall behind. The resulting consequence is the formation of unfinished user stories into a queue known as the product backlog.

This is often where the product owner becomes the center of attention because this queue needs to be both managed and prioritized, which was not an issue previously. At this point, the sprint planning meetings need to address the level of urgency on new and backlogged tasks at the same time. In doing so, product owners attempt to strike a balance of eliminating the backlog while also moving the overall development forward at the same effectiveness – which is not an easy task.

To ensure that the product backlog doesn’t get wildly out of control, the product owner must start to say “No” to certain stakeholder desires. If the product owner isn’t from the side of the client, he/she may not have the necessary authority to make these decisions. In such cases, it’s up to the product owner to successfully convince stakeholders to prioritize backlogged items. All of this potential conflict helps support the importance of sticking to the WIP limits.

This is the end of part one. Be sure to read part two on intelligent prioritization, the feedback loop, the juggling of multiple projects, and the management of expectations.

8 questions to ask before hiring a team of software developers

Digital innovation is risky business, particularly when it calls for finding outside software development help. Unfortunately, that’s usually the case, as few companies have teams of developers skilled in new technologies waiting around on the bench.

Finding a new technical partner is a challenging and time consuming task, with or without a background in IT. The right choice is often make-or-break when it comes to budget and market opportunity, and the wrong choice can be a crushing blow to the entrepreneurial spirit.

In an effort to combat this struggle, Digital Knights has evaluated hundreds of software development providers and collected a remarkable amount of data behind their successful partnerships. Of course, not everyone can replicate this body of work in their search for tech talent. When it comes down to it, most people that have the technical expertise to thoroughly evaluate prospects don’t have the time, and most people that have the time don’t have the expertise.

That said, while Digital Knights has developed its own winning formula for putting fruitful partnerships together based upon the intricacies of this data, any individual can get started with these key questions:

Is the team already established? Do they have a history of working together?

A tech partner with a team history of working together is going to be more predictable and efficient at getting started than newly formed teams. Groups of individuals that haven’t worked together previously have to find out how to work well together first before they can find out how to work well with a new parter or client.

What are their communication habits like?

First of all, language barriers are as real as the time it takes for a project manager to translate to a developer and back to the client – even in the same language. Besides ensuring that spoken language skills match up to avoid misunderstandings and delays from ambiguity, it’s also important to find out what kind of communication tools the team uses. If the team or the client is committed to using a specific communication tool or platform that the other is not familiar with, somebody has to learn something new.

Do they clearly document processes?

Clear documentation makes for high levels of transparency and, in turn, confidence and trust. It also safeguards both sides against potential misunderstandings that may arise about decisions and agreements made during the project at a later date.

Does their work style match the life-stage of the product?

Some teams are better suited for the creative phase, and others are fit for the large-scale execution. More often than not, an agile and fast-moving tech partner is more equipped for ideation and concept stages to build MVPs. Teams with more regimented styles, on the other hand, are solid bets for projects in the scaling and maintenance stages since they’ve been through it several times before.

Is their company culture a good match?

What are the working hours like for the team? How often and in what way do they supply feedback? Do they encourage professional development? Do they socialize together outside of work? None of these questions individually may be especially relevant, but taken together as a group allows for a greater sense of understanding and compatibility. Teams that operate in similar ways and have complementary cultures gel with the work environment of their clients far easier than those with clashing cultures.

What is the competition like? How does the team’s work produced, project success rate, and time of completion compare with that of others?

There are too many providers out there who stand on promises alone. A hearty competitor analysis will help weed out the red flags, and produce a few decent price quotes for comparison along the way.

Is their code up to par?

Examining existing code is essential, even for the non-technical. Enlisting the help of an expert or a friend is well worth the favor, as a code review is a sure-fire way to check that their work is clean, tidy, and sound. It may also hint at the level of experience they possess.

Have past clients been satisfied, and what was their experience like working with the team?

Testimonials and case studies only go so far. Asking for references and calling them up is a foolproof way to verify claims and ask specific questions. Ask those who have worked with them previously things like: Did they stick to budget and timeline? What can I do to prepare to work with them? What should and shouldn’t I trust them with as a tech partner? How did providing feedback go?

Utilizing these questions as a checklist is a great way to get started in the search for a tech partner. While it ought to provide a base of understanding for making informed decisions, this is certainly not an exhaustive list. Digital Knights welcomes anyone looking for a technical partner to get in touch for assistance, and naturally, the Digital Knights network of approved partners is a great place to look.

To read more about evaluating software development providers, read The must-haves to consider when choosing a tech partner.

Innovation culture: How to look like a corporation and act like a startup

Just about everybody familiar with startups knows they have a reputation of being hip, exciting, and more often than not, they’re at the forefront of the innovation conversation. Meanwhile, big corporations are no strangers to that conversation, but it’s their participation that carries criticism. A 2013 study by Accenture found that 93% of CEOs said the long-term success of their business strategy relied on innovation, yet only 18% felt their investments in innovation were paying off. Clearly there’s room for improvement.

For corporations today, it’s essential to have an internal culture that promotes startup-like innovation not only for attracting talent, but also for stimulating real business growth and staying competitive. That said, innovation culture itself is not so clearly defined. What does it look like? And is it possible to build one?

What is innovation culture?

First, it’s important to acknowledge that partial definitions about both innovation and culture seldom do the job in explaining how they fit together. Digital Knights places a very high emphasis on culture when evaluating software development companies, and the data collected through studying team after team has revealed that innovation culture does not come down to just one or two things. Instead, it’s the blending and facilitation of a set of principles that allow groups and individuals to be experimental without the fear of failure, and to take risks while being free from added consequences.

On the whole, organizations that are innovative usually share the same set of traits:

  • Innovation is encouraged at all levels with management cultivating opportunities for it to prosper.
  • Traditional business models are altered to encourage collaboration.
  • Time is prioritized and managed effectively.
  • Processes are in place, but flexibility and agility are more important.

Management drives culture change

“Most leaders are unaware of their power to change the culture of their companies and instead find themselves imitating trends and fads. Their company’s culture is created daily by what they themselves as leaders punish, recognize, celebrate, and reward. The adoption of new innovation tools will not help a company if its leadership team is still hanging onto traditional management practices.” – Forbes contributor and author Tendayi Viki

Arguably, the biggest influencer on innovation culture is the management team. Innovation calls for both regular and irregular creative thinking, and managers can facilitate this by creating an environment that invites any and all roles to share ideas and pursue the good ones. One example of a large company doing this well is Google’s “20% time” policy, which encourages employees to spend 20% of their work week on alternative projects that they want to tackle.

Digital Knights asked several of its approved development partners and they all agreed: If the client’s management team isn’t fully onboard with innovation culture and there’s little room to share ideas and feedback within the company, then the failure rate of that client’s projects will remain high.

All in all, the most crucial outcome of management buy-in is the adoption of this culture by the wider organization from the top down. Basically, if management doesn’t take the new way of working and thinking seriously, there is very little chance the rest of the organization will.

Innovation needs to go beyond the existing business model

The company structure of most corporations is not naturally set up in an open, transparent format that is conducive for innovation. Often, reorganization is required to promote a collaborative working environment where people within the organization have an equal voice to contribute to discussions and share opinions/perspectives, regardless of their experience, time at the company, or their role.

It’s already out in the open that a flat hierarchy is more favorable for creating the shared marketplace of ideas needed for an innovative culture, and according to McKinsey, “R&D leaders need to hire people who are willing to join multiple projects and to move from one to another as needed. Call them ambidextrous; call them system thinkers. These are people who want to solve problems that matter and that take them from invention to final product.” This means that in a lot of cases, the hiring process also needs to be reevaluated to accommodate individuals who are adept at thinking cross-departmentally.

Time is used wisely

Many large corporations that have their hands in innovation are prone to setting up innovation hubs/garages/centers/labs separate from their main core business. Companies such as Lufthansa, Vodafone, and Thyssen Krupp have established dedicated innovation hubs, garages or labs. While this is great initiative, the sustainability becomes an issue when staff who participate in these hubs have to fit their commitment around their regular 9-5 jobs. This means they don’t get the time and/or focus required to be truly effective, in addition to their likelihood to burn out. Teams within the Digital Knights network warn that this way of working poses risks to the overall project (and the budget) due to delays in communication and lack of equal commitment.

Alternatively, environments where employees are given allocated time to work in the innovation center within regular working hours have a much higher chance for success. When the focus is high and the time is ample, the overall dynamism allows solutions to arrive much quicker rather than hunting people out when needed and derailing momentum.

Flexibility needs to be a priority

An obvious and consistent barrier to corporate innovation is the bureaucratic measures, red tape, and other standard company procedures that cause significant delays to the innovation process. In order to operate in an agile way, companies must be prepared to challenge their existing methods and bypass them to stay competitive, no matter how difficult it may be. This is generally where large corporations fail because they are not up for the challenge internally. Teams within the Digital Knights network have said that a leading cause for corporate clients not moving as fast as their competitors is holding themselves up and waiting for multi-level approvals from within.

While corporations are typically large, slow moving beasts governed by strict processes, creating a culture of innovation in a corporation is still entirely possible. It hinges on management’s attitude and approach, prioritization of time, and flexibility of the business structure and processes. In the end, innovation is not just about having great ideas. It’s about having the freedom to come up with any idea, the encouragement to try it out, and little to stand in its way.

For more about innovation within corporations, read Speeding up innovation in a corporate environment.

How successful CIOs navigate the Innovation Process

‘Innovation is the process of pushing a new concept toward its implementation in the society with the objective of creating value. Uncertainty is the key unavoidable aspect of innovation.’ – Innovation Intelligence (2015)

Innovation, by nature, is risky business. The costs of getting innovation wrong and the resulting failure are well-documented by the countless tales of time lost and money wasted. So why does this continue to be an issue for entrepreneurs and corporations alike? What is missing that causes history to repeat itself, keeping good ideas from breaking through?

The biggest cause of innovation project failure

According to the elite software development companies in the Digital Knights network of approved tech teams, projects fail for a variety of different reasons, yet they all fall under one common theme: There is a fundamental misunderstanding and/or disregard of the innovation process.

Regardless of how stressful or time-sensitive the situation for product development may be, the innovation cycle doesn’t change. Each step requires proper attention for things to work; it doesn’t matter if there’s a first-time innovator or a serial entrepreneur behind the scenes, disrespecting the process and cutting corners will always incur consequences down the road.

The digital innovation cycle for product development

Innovation Process 2

The innovation process can be broken down into three phases of differing durations and comparable importance: Discovery, Validation, and Traction & Growth.
‘The Cycle can be thought of both as a sequence, moving from one of the segments clockwise through to the next, or as standalone segments that apply a focus to the collaboration efforts of members.’ – European Alliance for Innovation

Phase 1 – Discovery

Getting ready to build a product

This ideation stage covers all the market research, business planning, and product details necessary for developing a prototype or blueprint that provides a clear picture from start to finish. There is no sense in taking any action beyond brainstorming until there is a product idea with proper market validation and a viable business model. Successful products must solve real problems, and they must provide solutions that people will actually use. The existing market for the product must also be big enough to accommodate a new player, or the product must be significantly more appealing and useful than what’s already out there. Once all the proper planning is in place, the last prerequisite is to round up the initial resources or capital to build what’s necessary to get from phase one to phase two.

These initial steps lay the foundation for successful product development and it’s crucial that they are well-thought out. This phase doesn’t need to take more than 2-4 weeks, but it can make the difference between a year-long project’s success or its failure.

Phase 2 – Validation

Getting a product ready for market

Phase two is all about building upon that first blueprint or prototype developed in phase one. It entails hands-on work that focuses on iterating and pivoting in development sprints based on initial market feedback and learnings from the first rounds of tests. This is the phase where huge amounts of manpower are needed, the go-to-market plan is implemented, and the MVP takes shape. The development team will be heavily involved with back and forth movements until the first version of the product is ready for launch.

This phase can take anywhere from 3-6 months (or more) depending on how many pivots or iterations occur. If phase one is done exceptionally well, however, these are kept to a minimum. It’s very important not to rush through this phase because poor decisions will result in lost time and traction. After all, the product that reaches market needs to be functional and convincing in its most rudimentary sense–and still get there quickly. Later on, development of the wishlist of features desired by the wider stakeholder group will get started as the product evolves from phase two to phase three.

Phase 3 – Traction and Growth

Getting ready to scale up

This phase is where scaling happens. The growth cycle can take from one to three years and is all about reaching a point where the product needs only lean, continuous development and maintenance. The MVP will have established a solid codebase and presence in the market, and so it is simply a matter of making small tweaks, improvements, and building new features on the fly. Given there is no limit to the amendments, testing, and features that can be added during this phase, it often extends out past the 3 year mark as long as growth rates are still high. When the product maxes out its growth potential, it’s time to venture out with another idea back at phase one.

How a technical partner fits in

While the business development side of things is critical for developing the theory, it must be put into practice somehow. This means taking the steps to decide who will execute the plan and how. After deciding between risking software development with a pool of freelance coders, recruiting in-house engineers, or partnering with existing tech teams, it’s important to have a shared understanding of the innovation process before getting started.

Phase 1

A good development team has full product lifecycle and industry specific experience to be a strategic partner right from the beginning of the discovery phase. This team will act as an advisor, asking the right questions and suggesting solutions throughout the brainstorming process. Once the idea for the product is deemed viable and complete, it’s critical that the whole team can nail down the proper infrastructure and technical architecture required to develop the product so that it offers the best solution possible. Experienced partners will identify different – and in some cases better – ways to solve the problem than the original proposal. As the appropriate tech stacks and architecture are identified, the wireframes, user journeys, prototypes and mockups can be developed.

Phase 2

The development team is heavily involved in the validation phase of the innovation process, as nothing moves forward without the real, raw development. The hard work really kicks in here with the team implementing UX and dev sprints, usability testing, and quality assurance to ensure the first iterations are not only functional, but available for test in the market. The resulting minimum viable product is the most telling factor as to whether this product will be convincing to the end-user, gain attention in the market, and even attract investment.

Phase 3

The final phase is where the product is improved based on user testing feedback and where development of additional features can begin. As this phase progresses, the development team usually becomes leaner. The majority of the legwork is done and it is now a matter of maintaining and developing the additional features until the minimum viable product reaches its greatest potential.

The Digital Knights Advantage

Innovation Process 1

Getting the innovation cycle started with an experienced, highly talented technical partner is key for developing with speed, confidence, and most of all, successful end results. Tech teams within the Digital Knights approved network are verified for all phases of the product development, and Digital Knights provides several services and benefits to guide and accelerate innovation throughout the entire process.

These include:

Innovation Process Services

To learn how Digital Knights curates teams for a given project, read The must-haves to consider when choosing a tech partner for more information.

Speeding up innovation in a corporate environment

How do you not only make corporate innovation easy, but entrench it into the fabric of your company? Bring the spirit of startups into the corporate world.

The State of Play

In the 21st century market share is ephemeral. Just get in your time machine and go ask Blockbuster. They actually had a chance to buy Netflix – the nimble and disruptive new DVD rental platform founded by Reed Hastings. When Reed proposed that Blockbuster should buy Netflix for $50 million Blockbuster declined. Blockbuster filed for bankruptcy in 2010. Netflix’s market cap is now valued at $19.7 billion.

What we can learn from this is that Blockbuster did not have the vision or capability to adapt to the shifting sand beneath their feet. They didn’t realise that things move quickly in the digital world and those who cannot adapt fall from grace spectacularly. With the power of hindsight, it’s obvious that Blockbuster should’ve moved into a more online-centric business model and bring their huge customer base along with them. But they didn’t. In many ways business leaders in the modern era are subject to powerful forces of corporate survival of the fittest, with companies investing in R&D to better anticipate future climes and to avoid pulling a Blockbuster.

The above is a very extreme example, due to the polarity and public nature of Blockbuster and Netflix, but the scenario is hardly uncommon. This has led to the startup within a corporation. Keeping on top of technology and trends is etched firmly in many corporate playbooks nowadays, but how do you reconcile that in an environment where, in theory corporations can access today’s most promising talent pool, have the budget to try and fail, can theoretically out-innovate anyone else, but in practice, deeply ingrained processes, cultures and incentive systems tend to actively suppress innovation that threatens the status quo?

“Skunkworks were emblematic of corporate structures that focused on execution and devalued innovation.”

How Corporations Have Reacted

In the last couple of years, corporate giants such as Coca Cola, General Electric, American Express, MasterCard, and IBM have been tapping into the agility and unbridled creativity of the startup world by hosting innovation contests and funding the ‘best’ for internal startup projects.

Unlike hackathons, which, let’s be honest, are usually just PR exercises with no concrete outcomes, these companies are trying to create continuous innovation, and for the companies who can master it– the art of executing on core products while continually inventing new products and new businesses – they shift from skunkworks style innovation by exception and into innovation by design.

If corporations can pull it off, and infuse entrepreneurial thinking into the the ranks, the prize is talent.

“At least 90% of millennials say they would rather work at a startup than a corporate giant…”

Talent Acquisition

As someone who deals with startups, entrepreneurs, and corporates on a daily basis I can say that in my experience the startups are a younger crowd. Of course, age, wisdom, and experience are virtues and highly sought after commodities in the corporate world, but with that comes a perceived staleness that startups don’t have. Working in startups is hard work but somehow more attractive. Things move fast and there’s a lot of room for bringing your own ideas to the table and actually have a say on how things should be done. It’s not exactly hard to tell that millennials in particular are lured the “feeling of newness” that startups possess.

If corporates can tap into this intangible feeling of newness and manifest startup culture (hard to define, but characterised by creativity, innovation, entrepreneurial thinking), talent follows. Innovative companies like startups attract more talent than corporations, but this can come as compromise. The structured and regimented corporate environment can be attractive to people who want that security, and infusing entrepreneurial vigor means you can have the best of both.

Innovation Hubs > Skunkworks

Of course, it isn’t easy to create a startup within a company (sometimes called an ‘Innovation Hub’), and even then Innovation Hubs within larger corporates are constantly searching for quality & fast-acting boutique dev teams that can execute these MVP products being created. Replicating the haphazard moves of a 3-7 person outfit can be done within an Innovation Hub, better yet with the safety net that these hubs have with the funding from the corporate mothership.

“It’s marrying the stability of established industries with the iterative and agile nature of startups.”

If corporations can nail the startup within a business model, and actively allow the unit to create products that can influence the core offering of your business, then you get continuous innovation and avoid the Skunkworks, which – if we’re honest – are emblematic of corporate structures playing at innovation.

Failure as a Metric

Part of distancing your innovation hub from the Skunkworks model is being able to not only tolerate failure, but to embrace it and to learn from it. Silicon Valley celebrates failure because of how important it is to realise that things need to be piloted in the real world and if they fail they fail. There is no shame in failure, as long as you can call yourself more experienced after the fact. Evaluating things to death and discouraging risk is sure to turn off free radicals of innovation. Innovators must be given the room to fail and try again. It’s essential.

Technical Resources

“The default speed for a startup is breakneck, and it’s how continuous innovation is fostered.”

A startup’s agility from the development side of things is usually down to their methodologies. Corporations are slow, glacial entities. Breaking through the sluggish approval/moremoremore/more/ and committing to one or two week sprints effectively replicates the agility of a startup, and helps you build much more viable products that not only work, but do not miss market windows or become obsolete before they are even finished. The default speed for a startup is breakneck, and it’s now continuous innovation is fostered.

If assembling or outsourcing a tech team to build products your innovation team is coming up with, instill agile principles (or hire teams who already develop within the agile framework) to make sure the speed in which the innovation hub builds is like a legitimate startup or high calibre tech studio.

In summary, successfully creating a startup within a company that actually possesses the key attributes of a startup and can retain them within a rigid corporate environment is hard. Successfully marrying the iterative and agile nature of small companies to the structured and sometimes bureaucratic decision making of corporates means innovation by exception becomes innovation by design.

The Skunkworks is dead, but long live innovation.