Speed vs. Throughput: Finding the Right Balance

If you are a race car driver, your goal is to go as fast as possible, and you optimize for maximum speed. But if you are trying to move traffic across town, the speed of one car doesn't matter so much as the overall number of cars you can get to their destination as quickly as possible across a freeway. The same principle applies to to business and engineering teams specifically: balancing speed and throughput is essential for success.

In the fast-paced world of startups, striking the right balance between speed and throughput is critical. While speed focuses on how quickly individual tasks are completed, throughput emphasizes the overall capacity of a system to handle tasks over time. Optimizing for one often impacts the other, and understanding this interplay can lead to more effective and efficient operations. Engineers love efficiency!

Speed & Personalities

Speed, for our purposes here, refers to how quickly tasks are completed. An example of optimizing for speed is having employees concentrate solely on their current assignments without any distractions. This approach ensures that tasks are completed swiftly, as employees are not burdened with additional responsibilities.

For instance, in a software development team, if devs focus only on coding without being involved in meetings or other ancillary tasks, the speed of development increases. The team delivers updates and features rapidly, responding quickly to market demands or client requirements.

However, this single-minded focus on speed can have drawbacks. As the workload increases, the need for additional staff becomes apparent. Hiring new employees is a time-consuming process that requires current employees to shift their focus from their primary tasks to onboarding and training new hires. This diversion can temporarily reduce speed and efficiency. Successfull companies have more than one engineer, so this is a commpon occurance.

Throughput: The Bigger Picture

Throughput, on the other hand, is about maximizing the overall capacity of the system or team. It involves considering not just how quickly individual tasks are completed but how the system or team can handle an increasing amount of work over time.

To enhance throughput, businesses must invest in processes and infrastructure that support scalability. This might mean taking some time to hire and train new employees, even if it temporarily slows down current operations. The long-term benefit is a robust system capable of handling a higher volume of work.

In a push for throughput, mistakes can be made however. Syncronous activities (meetings, reviews, etc) can slow down the team, and the team can become bogged down in process. This can lead to a decrease in speed and throughput.

Balancing Speed and Throughput

The key to being effective lies in balancing speed and throughput. Prioritizing one over the other can lead to inefficiencies and missed opportunities. Here are some strategies to achieve this balance:

1. Flexible Resource Allocation: Allow employees to focus on their core tasks but also involve them in processes like hiring and training in a structured manner. This approach ensures that current operations continue smoothly while preparing for future growth.

2. Process Optimization: Streamline hiring and onboarding processes to minimize the time taken away from core tasks. Use technology and automation to reduce the manual effort involved.

3. Scalability Planning: Invest in scalable infrastructure and systems that can handle 10x increased workloads without significant delays. This includes both human resources and technological tools. Do not invest in tools for 100x and 1000x workloads, as they will slow you down.

4. Continuous Improvement: Regularly review and adjust processes to find the optimal balance between speed and throughput. Use metrics and feedback to identify bottlenecks and areas for improvement.

5. Cross-Training: Train employees to handle multiple roles. This not only prepares the team for scaling up but also ensures that operations can continue smoothly even during the hiring and training phases.

In conclusion, while speed ensures that tasks are completed quickly, throughput focuses on the overall capacity to handle work. By balancing these two aspects, businesses can achieve both immediate efficiency and long-term scalability, but it requires a thoughtful approach and continuous evaluation.

Your privacy is the aggregate of your decisions to cede knowledge, power and control over you to another. These decisions can be in the affirmative or the negative, implied or explicit, remembered or forgotten. Example to follow.

This works both in the singular (you as an individual) and in the collective (you as a group). Privacy is essential to personal liberty and collective democracy. It is the essence of power.

This is about Power

The more a company knows about you, the more power it has to shape your daily life. That power is exercised on the spectrum ranging from the benign, such as showing you a shoe ad, to the consequential, like selecting your job, your housing, or helping to shape what candidate you support in an election. — authors of the California Consumer Privacy Act (CCPA)

You may not want an app to spy on you and send your location to a dozen data brokers who then send it to hedge funds to determine stock trades (unless you got the stock tip along with — or in place of — those companies).

There is a gradient between the unknown company surveilling you for leverage, and a partner you trust with your life. In a relationship, such transparency is often a fundamental building block of trust. You want someone else to have the knowledge, perhaps to act in your absence or to better tend to your needs. You demonstrate trust with the knowledge that it will be rewarded as your relationship grows.

Sometimes you just wish Netflix knew the books you read on your Kindle so you could see a better personalized selection when you turn on the TV. The largest companies in the world want to own everything so they can make this happen. But wouldn’t it be valuable if the products and services you already own, the brands you know and trust, could communicate better with your permission?

There are brands you love (the Nascar, NYT, Nike, etc), that have to trade in the back alleys for your data. But why not have a direct connection?

The Privacy Paradox

An overwhelming majority of people say they want privacy (85% from our surveys), yet continue to act in ways that appear opposite to those interests when online. And it should not come as a surprise, either. The landscape online is designed to manipulate you to their own ends. When you arrive at a website or open an app for the first time, it is you all alone against several, sometimes several thousand, employees working to move you along a sales funnel that is best for them.

So as an individual, don’t feel guilty. Online celibacy is not a realistic choice, and we certainly don’t advocate it. You need someone that is on your team, someone that will look after your needs.

Collectively, our push to legislate for more equitable control is working. GDPR, CCPA, etc are all laws that are helping, yet more is needed.

Decisions

So, what are these decisions anyhow? When you visit a website or use an app, they typically have a Terms of Service and Privacy Policy that you agree to. Visiting often involves some form of implied consent, and creating an account will push you through an explicit one.

Oh, but there is more — much more. You may not have read that 1400 word (1400 page?) policy that opts you in for other things, more decisions made on your behalf. One click to agree at Google, and seventy two clicks to undo it.

Laws may force companies to offer privacy decisions when you first encounter a new website, but you likely don’t know this company, and shouldn’t trust them yet, but the big button saying accept all works while the others surprisingly do not. So you click it, and you don’t know the ramifications. And, wow, it is hard to find a way to undo it all.

Management

Privacy is a collection of decisions, and thus is never binary. So how do you manage them? You can’t manage that which you do not know. So you start with an inventory. And you can use all the tracking and data compilation to your own advantage.

Looking at your browsing history and your list of accounts can give you an inventory of your implicit and explicit agreements, respectively. Logging into your primary accounts gives you access to your the consents on record, and the ability to change them. Ideally, you change the same setting across lots of sites all at once.

Trust

Most companies force you to either trust them completely and give over everything they ask for, or get left on the street without them. But you actually have quite a range of options going from nothing (no account), to "have by data but do not sell my data", to "have only some of my data and for only so long", to "have all of it forever". But they don’t make it easy.

Not only are you not getting much value from your data, but neither are the brands and services you trust.

In evaluating great engineers, I've noticed they often fall into two primary types: fast and slow.

Fast

Fast engineers are a favorite among product teams. Their speed in coding and deploying software is well aligned, especially in smaller organizations where the focus is solely on product output. While they excel in getting tasks completed quickly, this rapid pace can lead to significant technical debt.

In scenarios like marketing experiments, having a team of all fast engineers is ideal. Much of the code developed for these tests is temporary and discarded later. Yet beware, successful experiments can solidify quick and dirty code into long-term use.

Slow

Conversely, for areas dealing with payments, sensitive personal information, and similar critical functions, a team of slow engineers is preferable. A more apt term for these professionals would be 'meticulous'. Precision and attention to detail are crucial here to avoid errors, especially those involving customer finances. These engineers focus on thorough testing and minimizing mistakes.

Tension in the Middle

Ideally, most teams should balance both types of engineers. This mix fosters a learning environment where each group appreciates and learns from the other's approach, gradually moving towards a middle ground and pulling the benefits of both into the codebase.

More Dimentions

While this categorization simplifies the complex nature of engineering skills into a linear spectrum, it serves as a useful framework for explaining the concept to those outside the engineering field. But there are more dimensions to consider. Contact me with the ones that you find valuable!

Engineering Liquidity: Navigating Startup Team Dynamics

In the realm of startup engineering, understanding the balance of team sizes and their functions is critical. As highlighted in my previous post about the complexities of team scaling, maintaining a certain limit on engineering resources can be advantageous. Particularly in projects where speed trumps throughput, like in greenfield experiments, a lean team can be a key to swift progress.

When we shift our perspective to a broader view, the priorities change. In this context, throughput becomes critical and so as the company grows, so too will the engineering team.

There are decicions on how to organize an engineering department. An essential element in this context is the 'liquidity' of engineering talent, and the stored value of their work. For instance, in consumer startups with diverse platforms (such as web, mobile web, iOS, Android), skipping organizational steps can be fatal.

Functional Teams in Startups

As startups expand, they often (and should) form teams based on functional skill sets. We see the emergence of backend, frontend, Android, and iOS teams. These groups, comprising individuals with similar expertise, tackle diverse challenges. The methodologies they develop for tasks like testing and deployment not only shape their immediate workflow but also leave a lasting imprint on future team processes. These functional teams store value in their processes. It requires a certain liquidity of engineering talent with similar skills to unlock this value. Apple, thriving with its functional organization to this day, is a prime example.

Embracing the Matrix Organization

Matrix organizations are favored by founders and top executives for aligning with their vision and approach to product development. For early-stage engineering leaders, recognizing the right moment to transition to this structure is key. It hinges on the availability of engineering talent and the maturity of the processes created by the functional teams.

A premature shift to a matrix organization, especially in a consumer startup with multiple clients, can be detrimental. It might not falter immediately but can lead to long-term challenges. This structure, if implemented hastily, can inadvertently undermine the value of an entire engineering organization.

I recall a consultation with a CEO whose engineering department was in turmoil. Their team had dwindled from 80 to just 8 engineers, plagued by various issues like code quality, morale, and broken processes. My immediate diagnosis? They had grown rapidly, lacked technical leadership at the helm, and prematurely adopted a squad paradigm. They never solved the functional proceses that were required to build, test, ship, and scale. There was no team to address these issues. The fallout was, indeed, catastrophic.

Functional teams build foundations. They create processes that can be replicated and scaled. They are the building blocks of a matrix organization. Without them, the matrix organization is a house of cards.

The Value of Engineering Leaderhip

The allure of a matrix organization for product engineering is undeniable, particularly for management. It allows for teams to be organized around product features which occupies their view of the company. Each team is integrated with a dedicated product manager. This setup simplifies the workflow for product managers, who otherwise would have to coordinate with multiple functional teams for a single feature. In startups, where management often doubles as the product team, the appeal of this model is even more pronounced.

Great engineering leaders know when to say no, or at least, 'not yet'. Not until an engineering liquidity and functional value has been built out.

I first encountered the concept of the "rule of ones and threes" from a military officer during a teenage visit to Washington DC. This principle offers a framework for organizing military units of various sizes—a concept I find parallels with in the growth of startups.

The Growth of Startups

Startups don't begin with thousands of employees. They start small and expand gradually. Let's examine this growth, marking each point where the team size triples.

Coming from an engineering background, I'll focus on engineering teams, but these ideas are applicable across all teams and the company at large.

Communication as an Example

In a startup, the engineering team might begin as just one person. Communication and processes are incredibly simple at this stage – think something, and the whole team (you) knows it. This is peak efficiency.

As the team expands to three, seated close together, communication remains informal. One person's comment is easily overheard by others. It's a natural evolution, with little need for structured processes.

However, when the team grows to ten, not everyone can hear each other, and even if they could, it would be overwhelming. Noise-cancelling headphones become the norm. This shift necessitates structured communication, like daily stand-up meetings, introducing formal processes.

With a thirty-person team, stand-up meetings become cumbersome and often irrelevant to most participants. It's time to form smaller, focused teams and introduce company-wide chat for both internal and cross-team communication.

At this size, tech leads or managers effectively become a new team, discussing matters with less noise. They face similar challenges as their teams grow, albeit on a different timescale.

As the company expands and hierarchies deepen, there's a need to reintegrate flattened communication channels, such as previously mentioned team and company chat software as well as All Hands meetings.

This pattern of growth and reorganization occurs within specific divisions, like engineering, and across the company as a whole. Sometimes, these triplings overlap in superposition and create additional stresses.

Looking Ahead

Anticipate the tripling. The shift from old to new patterns can be stressful, but not shifting will be worse. Depending on your team's dynamics, you might either get ahead of these changes or wait until the need for them becomes evident. Either way, having a plan is crucial.

Efficiency vs Throughput

Individual efficiency may decrease as the team expands, but the overall throughput increases. This is akin to the shift from developing for single devices to large distributed systems in engineering. You'll encounter more synchronization and overhead, but the outcome is greater overall productivity.

This is my first post, so I decided to go with one of my favorite observations: inversions. It is a fun lens to look at an industry — to take the basic premises and completely flip them. Based on my previous experience with forums, my favorite example is Twitter.

In the old days, the best way to chat from your home was to use a BBS: a dialup modem from your home to someone else’s, back before your parents would use CompuServe, Prodigy, and AOL. From then to now, online communities were driven by creating a chat “room” around an idea, and then bringing people there, and then posting your thoughts for the others to read. Wether it was a chat room with live people there to read the messages you posted, or forums (message boards), didn’t matter.

What mattered, was that people joined the room or forum. It could start small and grow. But it also often failed if it got too big, so instead you had lots of them. Traversing all the boards took a toll. You might say it wasn’t web-scale.

So, what if you inverted the basic premise? No rooms, only people posting. You could create rooms, in a sense, by grouping people whose posts you are reading.

This whole experiment wouldn’t work in small numbers. It would have to be big. And it would later be named Twitter (and, ironically, they know a lot about web-scale).

The whole “follow” rather than “join” also works if you invert the experience of reading a lot of blogs. Instead of having a list of sites to visit every day, you follow people on one site, and you have Medium. Now this inversion has been done in other ways, mainly via RSS readers and similar like Flipboard, Feedly, etc., but Medium did to blogs what Twitter did to chat and forums.

What expectation did Snapchat flip? What other messaging invariants can be changed? Of course, messaging isn’t the only place to find inversions. Think of some others!