Idea or Execution: What is the Key to Success?

There is a John Doerr quote you may have heard, “Ideas are easy. Execution is everything”. To put it in a slightly different way, mere ideas are cheap. While finding good or truly exceptional ideas is uncommon these days, their value remains somewhat limited unless they are combined with the correct blend of execution and strategy, it takes a team to win. 

Execution done well is expensive, and like many things worth pursuing, it is difficult, and it requires persistence, grit, teamwork, flexibility, and many other attributes done well to achieve a common goal. However, prior to the execution phase, there needs to be a great idea generated, it sounds simple enough, but like a great idea and flawless execution, neither one is fast and easy. 

Taking a step back and revisiting earlier points, the distinction between good, or even exceptional, ideas and mere ideas is crucial. Revolutionary ideas that reshape the world result from a confluence of timing, intellect, expertise, experience, and an individual’s unique perspective, unparalleled by others. Reflecting on personalities like Elon Musk, Jeff Bezos, Steve Jobs, Bill Gates, and Henry Ford, these names exemplify such visionary thinkers, listed in no specific order, simply emerging in my thoughts. 

There are countless products and services, that once they are launched and offered in the market, we ask ourselves, why didn’t I think of that? These products and services appear to be straightforward after a company and its founders and teams have put in the long hours to bring the ideations to life, and to offer you something you truly need, and that simplifies, eases, or improves your life. 

Let’s go back to the first sentence, and revisit these questions: 

Are the ideas easy? 

Is execution everything? 

For me, the challenge often lies in conceiving a genuinely impactful idea—something that genuinely addresses a need or introduces a solution one might not have realized they lacked until its implementation. Human perspectives are as distinct as fingerprints, with diverse outlooks, opinions, and beliefs guiding our evaluations. Each individual processes the world in a unique manner, leading to distinctive approaches to identifying problems and conceiving truly exceptional solutions. The ease of generating ideas, I believe, resides in the eye of the beholder who spots an opportunity, connects the dots, and sparks a brilliant concept.

I think most ideas create a lot of activity, but not the huge impact or outcome a company is looking for. As mentioned above having an idea by itself is cheap, it’s all in how you can execute or implement the idea, which includes challenges around product, marketing, sales, financing, and engineering for example.   

Instagram was not the first photo-sharing app, Facebook was not the first social network, and Amazon was not the first company to sell books online, but with a great idea, they moved on from ideation, and onto the execution and implementation phase which was crucial to get right.  As I said above, the implementation or execution phase takes a lot of effort and the right blend of strategy, and timing among other aspects to get right to make any new idea a success. 

Undoubtedly, execution is pivotal, from my own perspective, it isn’t the sole determinant. In fact, I view a juncture where the power of the idea and the efficacy of execution intersect. From that juncture onward, seamless execution is imperative to realize the idea’s potential. However, it would be an oversight to claim that execution holds greater complexity or significance than conceiving a brilliant idea. Rather, it’s a delicate equilibrium. The specific demands of each idea and its execution may vary, but both elements remain inextricably linked on the path to achievement.

In summation, the landscape of technology and business leadership is marked by the interplay between ideas and execution. John Doerr’s timeless wisdom underscores that while ideas might flow effortlessly, their true worth is unlocked when they are skillfully brought to life through execution and strategic insight. This harmonious synergy, orchestrated by determined teams, propels endeavors toward success.

The journey begins with the inception of remarkable ideas, driven by a confluence of timing, intellect, experience, and unique perspectives. Visionaries like Elon Musk, Jeff Bezos, Steve Jobs, Bill Gates, and Henry Ford exemplify the capacity to reshape the world by combining these elements in extraordinary ways.

However, true transformation happens when these ideas transition from the realm of thought to the realm of action. Execution is the crucible where ideas are refined, tested, and transformed into tangible products and services. Instagram, Facebook, Amazon, and countless others stand as testaments to the pivotal role of execution in shaping industries and societies.

While execution commands its due significance, it isn’t the sole protagonist of this narrative. The convergence of a brilliant idea and effective execution sets the stage for success. The notion that execution trumps idea generation fails to recognize the inherent balance between the two. Every idea holds its unique demands, as does its execution, and the ability to navigate this intricate dance dictates the course of accomplishment.

In the grand theater of innovation, ideas provide the script, and execution brings it to life. The world’s most transformative accomplishments emerge when these elements coalesce seamlessly. Thus, as technology and business leaders, our pursuit should be twofold: to conceive ideas that transcend the ordinary and to master the orchestration of execution, guided by the understanding that these elements are not competing forces, but rather essential partners on the path to realizing monumental achievements.

Rethinking DevOps and Engineering Teams?

Knowing where you are headed, and where you have been

Today you may have pilots/POCs (proof of concept) that have skipped critical phases such as MVP (minimum viable product), and MMP (minimum marketable product), in other words, you have pilot/POCs that went straight into a live production environment.   

Perhaps you have other scenarios where the pilots/POCs made it to the MVP stage, but the cross-functional teams necessary to support were not included or kept, whether this was done due to time or budget constraints isn’t always completely clear. At the MVP stage, you should understand the ultimate objective and the problems you are trying to solve for customers. Additional team members will likely need to be brought in to represent the various areas such as security and the Ops/Infrastructure service. The security and service functions help to define the non-functional elements which support this live production environment, beyond simply the Pilots/POC environments. The security functions are particularly important to ensure that you are aligned with specific data privacy/compliance requirements, in addition to following and implementing various best practices around how you will store and transmit the customer or other protected-sensitive data. 

You may also have prior scenarios where you have taken your pilots/POCs to the MMP stage. Customers who were actively using a particular product or service, but as with the MVP stage, the security and Ops/Infrastructure service teams were not included, or the staffing wasn’t adequate to support running/growing a live environment beyond the POC.  

Team Approach and Alignment 

The above section is important to cover first, as I think it helps to communicate where you may want to go next with teams which also includes DevOps-Platform, engineering, and security resources.   

As you continue ramping and perhaps even preparing for additional Pilots/POCs with your current fleet of Products and Services, you need to plan how your teams will do the work, and specifically what types of work they will be doing.  I will cover this in greater detail below, but essentially, you need to be able to break down these larger projects/problems into micro tasks that fit within an agile team. There are too many different domains, and subdomains that exist today within any given Product/Service – infrastructure and systems the team supports today.  

  • Teams/Squads with experts for each of the POCs 
  • Active Stakeholders which include Product Owners or the equivalent  
  • The team will have general software developers/engineers, and platform (IT Operations/Security) engineering resources partnered together to accomplish various work items, tasks, etc as deliverables in each sprint. Sprint reviews help the teams, which include the various stakeholders, leadership/management, and other stakeholders with visibility, accountability, and communication.    
  • Documented, evolving but clear service workflows, escalations, and interactions with the other teams. 
  • Current and ongoing documentation    

Near-Term Decisions

  • Backfilling/hiring for your principal/chief engineer/arcitechture role(s)
  • Consider moving to one centralized platform to track your work, store and update documentation – maybe its Notion, Basecamp, JIRA, etc.    
  • Moving to one ticketing system for Development, Security, and Service-related issues – maybe JIRA Service Management or something similar.  
  • Communication platforms (Slack, Teams, etc) 
  • RD time – Friday afternoon or another time when team members can work on CIs, other low-hanging fruit work items in the backlog 
  • Do we want teams to use Tribes, Squads, Teams, and Departments? The goal is ultimately to have smaller teams following agile.  
  •  Platform Engineering/DevOps Teams and Topologies 

Long-Term Issues and Decisions

  • Solutions to help teams manage the unplanned work coming in 
  • Leveraging some RD time, enablements  
  • Reducing the amount of context switching issues between projects, tasks, products, customers 
  • Reducing Longer lead times
  • Teams managing/handling platform/system support/break-fix, need a better way to identify, log and track, prioritize with the best and available resources. 
  • Teams/Resources managing/handling implementation/migrations, onboarding, and ongoing support, same as above, need a better way to identify, log and track, prioritize with the best and available resources. 

Other Potential Issues 

  • The engineering teams can become too large 
  • Systems can become monolithic 
  • Work can become blocked across software engineering and service/operations resources 
  • Teams/members become too specialized which can create dependencies 
  • Software/platform/systems can become too large and complicated
  • Documentation becomes nonexistent or not kept up to date 
  • Original/Key team members leaving an organization taking critical knowledge and specialized skills and domain knowledge 
  • DevOps resources may face a large number of requests from the various engineering squads/internal customers.  As those product squads – software engineers all advanced and leveled up, the requests coming in can became more domain and subdomain specific.   

Proposed Team Structure – Includes Software, Platform, and Engineering Resources

  • Using more of a micro team/squad approach, project/work items can be organized into two-week agile sprints and required team members – resources can be bundled/grouped to accomplish a sprint goal. Having available DevOps FTEs, for example, could be assigned along with another engineering resource.
  • The smaller/micro teams help with frequent, focused communication. 
  • Instead of a centralized DevOps person/resource, having more of an embedded platform engineering/ops embedded into dev teams/squads. It will take some time to find the flow that works, but this really will depend on what works for the various teams.  
  • More focus on the domain and subdomain skills and knowledge required. 
  • For each of the potential solutions products and services defined platform required, and the services needed to run, scale, and secure the solution.     
  • Responsibilities for building, deploying, supporting, and retiring a specific service within a business. More business and customer focused. 
  • The teams below will exist in some part to reduce the number of disruptions, distractions, and overload that’s placed on the stream-aligned team.  
  • External/temporary help-support/services to help the teams quickly upskill or implement other best practices to support the stream-aligned team. 
  • Provides specialized services such as machine learning, and analytics/reporting components.  
  • Working with the team leads, and principals to discuss a new team topology and approach.   
  • Based on the adoption and effectiveness of this new approach, we would then consider whether to roll out a similar team structure for other teams within an organization.