Efficient

Definition: Achieving maximum productivity with minimum wasted effort or expense

Effective

Definition: Successful in achieving a result

The two terms are often used interchangeably but are actually very different in an extremely important way: one is about resources, but the other is about speed. Knowing this distinction can really help to know what to do when you need more of one or the other. To illustrate, let's first start with an analogy...

An Analogy

A sports car is highly effective in transporting you from point A to point B. You can put the pedal to the metal and blaze down the highway at 100 mph to your destination. However, this comes at the cost of efficiency: sports cars are notoriously performant but inefficient:

They are highly precise machines prone to breakdowns and expensive maintenance.
They require high-quality fuel and consume it voraciously.
Regardless of the type of car, at higher speeds you will see poorer and poorer efficiency: the incremental gain from 80 mph to 90 mph consumes a lot more fuel than from 10 mph to 20 mph as the engine struggles against both extremely high wind drag and internal friction.

They are also very poorly adapted to transporting much mass at all; they’ve been optimized to carry two persons and very little else. If you’d like to ferry some luggage around, you’re much better off with a minivan taking one load than making three trips in your Corvette.

The most efficient way to move is probably with a budget hybrid vehicle. If you have cargo, it’s probably a truck. But the most effective? Possibly a Lamborghini.

How This DISTINCtION Applies to Software Teams

I bring up this distinction because I'd like to point out a new way for you, as a leader in software development, to be more intentional about how you invest. In any team working on any problem, you may observe similar phenomena, depending on how you are organized.

In organizing a larger team against one urgent project

Having a larger team work on one problem together is an intentional way to obtain a deliverable sooner, such as when a project is urgent or time-sensitive. In that respect, it is analogous to stepping down on the gas pedal and sustaining higher RPMs.

In such cases, you may have more “cooks in the kitchen” than is normally comfortable. There will be some wastage as people will wait for one another, context switch between tasks or different conceptual areas of a project in order to grab at the next available opportunity with urgency. There will be more overhead in the coordination and synchronization necessary to ensure high coherency in the design and correctness in the implementation; all of this is necessary to avoid a “swiss cheese” result rather than a solid, crystalline product that is usually the result of a single (or a few minds) highly focused on a challenge. Opportunities to take on unrelated, smaller initiatives will likely be missed.

In general, applying larger teams will come at some expense (quality, missed opportunities), but will shorten the turnaround time of a project to a point. The shortening is not linear: you will pay a higher and higher cost to go faster. Timing is also important: adding more people to an already late project will typically make it even later.

Regarding high-value but non-urgent projects

On the other hand, some projects may be:

Speculative in nature, where there is a great deal of potential but uncertainty of success. Or...
Certainly highly valuable, but over a long time horizon (with value being delivered progressively over months and years).

So, you may ask, for such important projects with longer time horizons, what is the appropriate response? What can you do right now?

You can't throw a huge team at it. It is really difficult to justify organizing a large team behind these (in order to accelerate them) because doing so comes at the risk of missing many more immediate opportunities of known value sitting on the table. Given that they aren't urgent, there is no need to pay the extra expense for acceleration.
You can't sit on your hands and do nothing. To invoke an old proverb: “The best time to plant an apple tree is five years ago. The second best time is today.” So, given the potential payoff later, it is equally inappropriate to dedicate zero effort towards such projects!

So, what is the correct initial investment? My answer is: a small, steady, and committed one. If something is so valuable and so important, but you have time, it is best that you take the time to do it efficiently and do it with high quality. You must, however, commit to it, or else you will never realize the potentially significant benefit in the later phases. Begin by dedicating just a few people to a problem and provide the space to focus, go deep, and develop it. Minimize distractions (context switching). The commitment to a milestone enables the development of a foundation, which pays dividends as the delivery of value accelerates over time. The phenomenon can be observed as taking the shape of an “S” curve …

The S Curves

In my experience, on many projects you can observe a foundational period where architecture is built but little value is delivered, followed by a steep ramp-up (where an array of features are steadily and incrementally added that exploit the architecture and its inherent benefits), followed by tapering to a plateau (as the architecture is exhausted, new features are more “bolted on” than designed; inconsistencies, bugs, incompatibilities between features begin to slow development to a crawl).

The answer to such plateaus is typically a significant re-architecture to unlock huge new realms of value and to re-enable aggressive development.

Simplified_ Thoughts on Efficient vs. Effective.png

The phases of the curve are analogous to the four seasons: spring (the early, seedling stage), summer (high growth), autumn (harvested; beginning to taper), and winter (stable; very hard to grow).

This is a simplified model, but an illustrative one. In practice, the S curve phenomenon is even more challenging for a software product development team because it must be effectively managed on two levels:

Time & Resources. The size of the S curve is in your control, but you must make careful compromises based on your time horizon and resources available.
1. Early on, a small startup must necessarily start with a small curve in order to sustain itself to the point of being able to execute a large one.
2. Later, a large company must deal with transitioning from a tapering, legacy S to planting the seeds and ramping up the next technological curve. Companies which fail to adapt will eventually plateau their businesses.
Multiplicity. Teams often deal with multiple curves at the same time as significant products are actually systems-of-systems: comprised of numerous linked subsystems, each with their own independent maturity lifecycles.

In this light, I'd say that in order to sustain aggressive growth, one must:

Periodically make small & proportionate investments in next-generation architecture where future demand is expected
Monitor current position on the curve (both overall and on subystems)
Follow-through on ripening opportunities by organizing larger teams to harvest the fruits of the investments.

In Conclusion:

When/where you need to accelerate, do engage bigger teams, but beware the high cost.
To plant seeds for future needs, consider organizing small, efficient teams.
Look ahead. Take stock of the health of your system and its capacity to grow with the needs of the business. Then, assess investments you’d like to start to making today so that in 6-12 months you can be ready to take advantage, harvesting the fruits. You don't want to scramble to catch up later, or forever "kick the can down the road" on things.
"Right-size" your architecture. When you are designing, check that your architecture is “well-fitted” to the future demand, thereby finding the sweet spot between under-engineering and over-engineering. Estimate the size of your S-Curve to help inform your decisions.