The Idea Velocity of an organization is defined by the time the organization takes to ship a well-defined idea into a customer’s hand. As such, Idea Velocity is a high order metric that an organization’s leaders should strive to optimize. In this blog post, I capture my take on significant attributes that directly impact an organization’s Idea Velocity.
There are three key dimensions of a technology-centric organization – Engineering, Org Structure, and Culture. Let's take a look at how organizational attributes in each of these 3 dimensions affect Idea Velocity.
Underlying Architecture - Functionally Decomposed System
A functionally decomposed system is made up of several loosely coupled, small subsystems or microservices working in coordination. Microservices offer a simple mental model, can be owned by an individual or a small team, and can be iterated with a high degree of confidence. As such, they avoid complex intertwinings typical of a monolithic system.
Microservices is a popular architectural approach to achieving functional decomposition. While following this architectural pattern, one key question to answer is – how do you break down your system and come up with boundaries of your different services?
Answering this question is the key to success, but it is far from easy. I have come across several guiding principles concerning breaking down a system, but the following principles resonate most:
- A bounded context is a good candidate to be a service.
- Keep in mind the transactional context of your business. You do not want to split a business logic that needs to run as a transaction into two different sub-systems.
- A service should be an independently deployable entity that can go down and be rolled out independently of other services.
Functionally decomposing a system comes at a significant cost for it introduces complexity in several new dimensions, such as the following:
- Introduces new failure modes, making the failure domain of your system far more complex. Each service has its own failure modes, and the components that form that service can fail independently. It becomes essential to understand how different failure modes of each service affect the overall system.
- Debugging & monitoring become significantly more involved.
- Having multiple services that can be rolled out independently and simultaneously requires non-trivial investment in your software deployment pipeline.
- Introduces new operational concerns, such as service discovery.
One must ensure that the benefits, which are often not immediately realized, outweigh the cost. I once met a CEO of an organization who had waited too long to decompose their system. Upon doubling their engineering workforce, their productivity was cut in half as team members were contributing to a complicated monolithic system without understanding it completely. As a result, their system grew in complexity as productivity plummeted.
CD is a groundbreaking engineering practice that I have experienced and seen evolve. Those who see CD as just running a build server are missing the point. CD is an entirely new software development and delivery paradigm. It is a key engineering differentiator that is vital to the success of Idea Velocity.
Experimentation ( A/B Testing ) platform
A functionally decomposed system and CD infrastructure allows organizations to rapidly ship an idea with a great degree of confidence. Experimentation platform takes it further. It allows you to ship multiple versions of a change to customers simultaneously or ship a change to a specific segment of customers. The ability to measure the impact of a change in a controlled manner further adds to the confidence of shipping a change. The following experimentation methodologies are several that are commonly used: A/B/N testing, causal inference, and multi-armed bandit.
If you ship rapidly, you will eventually break things. Fear introduces resistance and will slow you down. One key element in addressing that fear is have a good test coverage and run those as part of your CD pipelines. Another key is to have comprehensive monitoring in place for the failure modes of your system and subsystems. It takes significant efforts to understand the failure domain of your system and come up with a thorough and efficient way to monitor it.
If your system and its components are designed to be observable and you have a monitoring infrastructure that is collecting and alerting on the observed metrics, you will be in a much better position to ship with confidence and to diagnose a production issue, if/when they happen.
A very common cause of decreased productivity is interdependencies across teams. We all have known the Squad/Zone model that came out of Spotify, for some time now, which I see as a great way to approach engineering org structure and culture. However, I think most organizations still define teams around functions and not around core customer values, which creates significant issues. In delivering an experience to a customer, an organization may take contributions from several functions to ship and iterate that experience. If your teams are organized around functions, they are wasting valuable time in inter-team collaboration. Org./team structure should be around core values or customer experiences. Further, teams should be autonomous and have minimal dependency fan out.
However, if you go to extreme lengths in creating independent teams, you will end up with a different problem. Ben Sigelman names this dilemma “Hippies vs Ants”.
“There’s always a temptation to allow each service team to decide on a language, a stack, and a set of primitives that feel familiar or appropriate to them. This is well-intentioned, as it seems to maximize the autonomy of the distinct service teams. But in a microservices deployment — especially at scale — we must also facilitate cross-cutting concerns like deployment, load-balancing, service discovery, security, and observability. If we encourage our two-pizza teams to make entirely independent decisions about each of these critical aspects, we are left with a monstrous challenge when operating our distributed application, especially as teams disband and services go into maintenance mode.”
For example, you want different engineering teams to be aligned in their operational architecture dimension. Such an alignment can be introduced by having foundational (horizontal) engineering team(s), such as - Developer Platform, Core Infrastructure, Product platform. These teams build tools, libraries, offerings for cross cutting concerns. Whereas, individual service teams can enjoy great degree of freedom in other engineering dimensions, such as , technical architecture.
As a manager, I firmly believe that I get the most out of my team when my team elects to give their most and my primary business as a manager is to facilitate and encourage that. I focus heavily on hiring people for their attitude and in my ability to lead and encourage them.
The key cultural ingredients for optimizing your idea velocity are a Sense of urgency, shared ownership, camaraderie & user empathy. Culture does not iterate like software does. It evolves slowly. Define your core values and repeat them over and over again in all-hands, offsites and other forums. Operationalize the culture and build it to last.
There is nothing more fulfilling to me than working in a team that seeks the truth, is full of gratitude and learns & moves fast.
Note: This was original posted by Satyarth on November 12, 2018 on LinkedIn. It was editted for this audience. You can view the original post here.