Welcome!

Microservices Expo Authors: Liz McMillan, Pat Romanski, Carmen Gonzalez, Elizabeth White, Jason Bloomberg

Related Topics: Microservices Expo, Java IoT, Agile Computing

Microservices Expo: Blog Feed Post

Startup Scaling | Overcoming Five Key Operational Challenges

Scaling a startup from zero to $100M is 10% strategy and 90% execution

Scaling a startup from zero to $100M is 10% strategy and 90% execution. You’d never know that from reading the Web, because the advice you’ll find online is 90% related to strategy and 10% related to execution. This is the second post in a series that explores the challenges of scaling a startup through rapid growth and presents some tips and tricks I’ve learned over the years to smooth out what is an inherently bumpy ride. The first post in this series entitled Startup Business Growing Pains | Staying Focused examined the challenge of maintaining strategic focus amongst the chaos of scaling a startup. This second post leaves the 10% of strategy behind to explore five key startup scaling challenges commonly encountered in the softer, messier 90% of execution.

Startup Scaling Challenge #1: Passing the Hat
A while back, I published this article entitled Startup Musing | One Hat is Not Enough where I make the case that startup executives need to be prepared to wear more than one functional hat to be successful. As you scale your startup, however, you must carefully oversee the process of passing those hats to new executives and managers that join the team. This looks easy on paper (just draw up the new org chart), but it can prove extremely challenging in practice. While it is easy to pass the hat in form, it may not be easy to pass the hat in substance when the on-boarding of the new hat owner is arduous, i.e., big learning curve, lot’s of important internal relationships, and so forth.

As long as the old hat-owner offers greater knowledge and effectiveness in the relevant functional area, everyone in the organization will gravitate to her for decisions and support, regardless of what the new org chart says. The problem can be further exacerbated if the old hat owner isn’t all that willing to pass the hat in the first place or if the old hat owner is too willing and runs away from the responsibility faster than the new executive can get up to speed. Poor hat passing can result in confusion, frustration, conflict, executive turnover and ultimately poor business performance.

Hat passing is tricky business that requires the buy-in all of all those affected, a solid foundation of respect between the two hat-passers, and a thoughtful approach to managing the transition. Without these fundamentals in place as you are scaling your startup, you may find that you are dropping more hats than you are passing.

Startup Scaling Challenge #2: The Solution of an Unknown Function
A corollary to the challenge of passing the hat is the introduction of a new business function whose role is unknown to those who must work with it. For example, most B2B SaaS startups begin with a CEO and a bunch of engineers, then they add sales and marketing to take the product to market, then technical support and accounting as they gain customers and need to react to their needs, then product management, customer success and QA to develop a more proactive approach to steering the business. Depending on the business model, there may be other functions along the way like business development, partner marketing, channel management, etc. It all sounds very logical and straightforward to the seasoned startup executive. However, it can come as quite a surprise to less experienced staff who have never seen, heard or worked with this new function.

If you’re a junior engineer who has never worked with a product manager before and you’re used to taking instruction directly from the CTO, you will have all kinds of questions and concerns about this new species of coworker. It can even be quite confusing to the new product manager as the product management role at this startup differs from past experience. I’ve scaled multiple sales, marketing, support, and product development organizations and I can say for a fact that they were all the same in some respects, and they were all very different in others. In every case, the specific organizational roles and processes had to be tailored to the unique business strategy and environment of the startup at hand.

When you introduce a new function, don’t assume everyone understands what you are doing and why. Don’t even assume that everyone knows what it is. Some may think they know from past experience, but they still may not know what it is at your startup. Every new function should come with clearly defined roles and responsibilities and these should be broadly and consistently communicated to everyone in the new function and everyone who must work with it to make the transition a success.

Startup Scaling Challenge #3: Moving from People to Process


assing of hats and the introduction of new business functions are natural consequences of growth and the increasing division of labor required to manage a larger organization. The result is that work that used to be done by individuals and small teams must now be done by cross-functional groups. In my experience, this is one of the most subtle and treacherous startup scaling challenges. Subtle because it sneaks up on you. Treacherous because the problem and it’s potentially damaging results are always underestimated. You design your org chart, hire your new people, get the new team together and quickly discover that they have no clue how to work together effectively.

startup scaling

Take the simple process of creating a single Web page that describes your product. Whereas before a multiple-hat-wearing marketing director might write the content, create the design and even mock up the HTML before sending it over to your only Web engineer for implementation, your scaled up startup now has a product manager internally communicating the value of features and functions, a product marketer producing content for external consumption, a designer creating Web graphics, a Web team manager receiving these requirements, and a team of Web engineers from which to chose to assign the task, all of which are new and don’t fully know the code base yet. Just for fun, let’s say this transformation occurs over a one month period. See the point?

Moving from many individual contributors to cross-functional teams is an essential aspect of scaling a startup. Teams produce more for less when they are working to a well-defined, well-understood process. You can’t just throw a bunch of new people in a room and hope that they will figure it out, no matter how talented they may be. And, you can’t define new processes and make them stick overnight. Define maybe, make them stick no way. This is an essential difference between good startup managers and managers in more stable businesses. It is one skill to oversee the efficient operation of an existing team or process. It is quite another skill to consistently create new teams and processes out of nothing.

Here is my cheat sheet of how to quickly go from people to process…

  • Communicate strategic goals
  • Establish process owners
  • Define roles, responsibilities and workflows
  • Make a schedule
  • Focus on group deliverables over individual tasks
  • Control the hand-offs
  • Educate, educate, educate

What startup scaling rules of thumb have helped you go from people to process?

Startup Scaling Challenge #4: Tribal Knowledge
Underscoring all the startup scaling challenges above is the problem of tribal knowledge: those things that are sitting inside the heads of earlier employees that must be communicated to new employees in order for them to do their jobs. Tribal knowledge is traditionally communicated verbally through stories. Unfortunately, this method of communication is notoriously unreliable leading to misinterpretation, reality distortion, and group memory loss. At some point, effective startup scaling means writing stuff down where everyone can find it and making sure new people are trained on the essential accumulated knowledge of your business.

Personally, I like to take a minimalist approach to documentation. At most startups, folks are too busy to write anything down for future consumption and training, let alone read it. However, it’s essential if you want to avoid the frustration of watching your newest employees waste time reinventing things that you thought your business was good at already. I won’t attempt to define what you should document, as it tends to vary widely based on each startup’s specific strategic goals, stage of evolution, and operational challenges. I’m just going to say that no matter how Silicon Valley cool you are, no matter how agile you want your culture to remain, sooner or later you will reach the limit of tribal communication and you’re going to have to start writing things down to scale your business from startup to firm.

Startup Scaling Challenge #5: To Every Thing There is a Season
You can’t do it all at once, so you must choose very carefully what you will do today. In my opinion, this is by far the most difficult startup scaling challenge of all. As you scale your startup, you will find that you have a cornucopia of organization models, job roles, programs, processes, policies, best practices, templates, and so forth to chose from. The question is always: “Which one, right now?”

The flip side of this principle is that just because you are not doing something now, not following that “standard industry best practice” does not mean you are doing something wrong or that you have a problem. It may just not be the season. It’s a common startup scaling practice to hire experienced executives who have been there, done that at bigger companies to help you scale to the next level. And, it’s a common startup failure scenario when an experienced large company executive with little or no startup experience assumes that her job is to remake your startup in the image of her former company overnight. The proverbial hammer looking for nails. It requires both talent and discipline to scale a startup. Talent to choose the right thing to do next. Discipline to get it done and not get distracted by the thousands of other things whose seasons have not yet come.

Read the original blog entry...

More Stories By Joel York

Joel York is an Internet software executive and popular SaaS / Cloud blogger at Chaotic Flow and Cloud Ave. He is well known for his work in SaaS / cloud business models, sales and marketing strategy, and financial metrics. Professionally, he has managed global sales and marketing organizations serving over 50 countries, including local offices in the United States, United Kingdom, Germany, and India. He holds degrees in physics from Caltech and Cornell and received his MBA from the University of Chicago. Joel York is currently VP Marketing at Meltwater Group and Principal at the Internet startup consulting firm affinitos.

Microservices Articles
Modern software design has fundamentally changed how we manage applications, causing many to turn to containers as the new virtual machine for resource management. As container adoption grows beyond stateless applications to stateful workloads, the need for persistent storage is foundational - something customers routinely cite as a top pain point. In his session at @DevOpsSummit at 21st Cloud Expo, Bill Borsari, Head of Systems Engineering at Datera, explored how organizations can reap the bene...
"NetApp's vision is how we help organizations manage data - delivering the right data in the right place, in the right time, to the people who need it, and doing it agnostic to what the platform is," explained Josh Atwell, Developer Advocate for NetApp, in this SYS-CON.tv interview at 20th Cloud Expo, held June 6-8, 2017, at the Javits Center in New York City, NY.
The Jevons Paradox suggests that when technological advances increase efficiency of a resource, it results in an overall increase in consumption. Writing on the increased use of coal as a result of technological improvements, 19th-century economist William Stanley Jevons found that these improvements led to the development of new ways to utilize coal. In his session at 19th Cloud Expo, Mark Thiele, Chief Strategy Officer for Apcera, compared the Jevons Paradox to modern-day enterprise IT, examin...
In his session at 20th Cloud Expo, Mike Johnston, an infrastructure engineer at Supergiant.io, discussed how to use Kubernetes to set up a SaaS infrastructure for your business. Mike Johnston is an infrastructure engineer at Supergiant.io with over 12 years of experience designing, deploying, and maintaining server and workstation infrastructure at all scales. He has experience with brick and mortar data centers as well as cloud providers like Digital Ocean, Amazon Web Services, and Rackspace. H...
Skeuomorphism usually means retaining existing design cues in something new that doesn’t actually need them. However, the concept of skeuomorphism can be thought of as relating more broadly to applying existing patterns to new technologies that, in fact, cry out for new approaches. In his session at DevOps Summit, Gordon Haff, Senior Cloud Strategy Marketing and Evangelism Manager at Red Hat, will discuss why containers should be paired with new architectural practices such as microservices ra...
In his session at 20th Cloud Expo, Scott Davis, CTO of Embotics, discussed how automation can provide the dynamic management required to cost-effectively deliver microservices and container solutions at scale. He also discussed how flexible automation is the key to effectively bridging and seamlessly coordinating both IT and developer needs for component orchestration across disparate clouds – an increasingly important requirement at today’s multi-cloud enterprise.
The Software Defined Data Center (SDDC), which enables organizations to seamlessly run in a hybrid cloud model (public + private cloud), is here to stay. IDC estimates that the software-defined networking market will be valued at $3.7 billion by 2016. Security is a key component and benefit of the SDDC, and offers an opportunity to build security 'from the ground up' and weave it into the environment from day one. In his session at 16th Cloud Expo, Reuven Harrison, CTO and Co-Founder of Tufin, ...
DevOps is often described as a combination of technology and culture. Without both, DevOps isn't complete. However, applying the culture to outdated technology is a recipe for disaster; as response times grow and connections between teams are delayed by technology, the culture will die. A Nutanix Enterprise Cloud has many benefits that provide the needed base for a true DevOps paradigm. In their Day 3 Keynote at 20th Cloud Expo, Chris Brown, a Solutions Marketing Manager at Nutanix, and Mark Lav...
Many organizations are now looking to DevOps maturity models to gauge their DevOps adoption and compare their maturity to their peers. However, as enterprise organizations rush to adopt DevOps, moving past experimentation to embrace it at scale, they are in danger of falling into the trap that they have fallen into time and time again. Unfortunately, we've seen this movie before, and we know how it ends: badly.
TCP (Transmission Control Protocol) is a common and reliable transmission protocol on the Internet. TCP was introduced in the 70s by Stanford University for US Defense to establish connectivity between distributed systems to maintain a backup of defense information. At the time, TCP was introduced to communicate amongst a selected set of devices for a smaller dataset over shorter distances. As the Internet evolved, however, the number of applications and users, and the types of data accessed and...