Why Big Companies Move Slow

Big companies have resources, talent, and market reach, but compared to small start-ups with less resources, talent and reach they often seem to be slow and lumbering.   Is this the inevitable result of becoming a large company?  Many companies are slow but in a different sense from the big-versus-small comparison.  Large company velocity takes into consideration "scale" and can still move nimbly and quickly within that context, but the complexity of scale often overwhelms the organization resulting in them becoming a slow and lumbering company.

Scale

To be fair to large companies, comparing launching something between a start-up and a large company isn't an apples-to-apples comparison because there's often a lot additional requirements placed on a companies that has reach a certain scale.  Some of these requirements come externally (e.g. government regulations) and some internally (existing user base, supporting existing infrastructure and use cases). 

It isn't lost on the employees how cumbersome internal requirements can be:

Having had to work on these systems, there are often valid reasons behind the requirements, but it can still be hair-pulling frustrating sometimes to have to consider all the additional requirements for what seems like a simple singular task.  Objectively, though, the team within the large company might have a higher velocity then a team in a small company because for a given feature A, one had 10 requirements to meet while the other only had 3.

This doesn't mean that big companies are not slower than start-ups because many big companies looses their nimbleness due to self-inflicted wounds because of the complexity of increased scale:

• Complacency
• Hesitancy
• Bureaucracy: Navigating the corporate maze can feel like a full-time job (though, let's be real, some structure is necessary).

Complacency

The mantra of "If it ain't broke, don't fix it." can take hold at large companies especially those that have had success.  This often comes from the top where the leadership is more comfortable keeping the status quo because things are going well and don't want to risk destabilizing the business.  This isn't limited to just mature companies but can happen with growth companies.

No matter if the decision to just stay the course is correct or not, if the sense of complacency from the top seeps into rank-and-file then the culture of complacency will take hold.  

Hesitancy

Fear stiles innovation and at large companies there can be a perception that more is at stake at both the company and individual levels.  This hesitancy occurs at all levels of the organization.   The CEOs might fear how a change will impact their bottom line and individual might fear how it will affect their prospects at the company.

Bureaucracy

When a company grows (a good problem to have!), bureaucracy sets in but bureaucracy itself isn't a bad thing.  The truth is that when a company scales up it is going to become more complex and it will require organization.  A small 3 person start-up doesn't need any process to communicate effectively, but a 100 member engineering org will descend into chaos without some agreed upon method for working together.  Large companies often organically evolve into a matrix organization with defined roles and responsibilities, but fail to recognize the that they went from a single node to a graph of nodes.  Company leaders continue to try to optimize each node and they ignore the edges connecting the nodes.  

Big companies will have more people who can handle things at the node level while it is mainly the leadership who can affect the edges.  The irony is that leadership often focus more on the nodes while their teams struggles to navigate through the edges. 

Possible Solutions

So, how do we combat the corporate slow-down? While this isn't a complete solution, here are some strategies:

Embrace Small, Nimble Teams: Have small and empowered teams that can move nimbly.  Give the team autonomy to solve the problem which helps against complacency and hesitancy.  The small team also reduces need for a lot of process within the team for coordination.  It is key for leaders to communicate with them on expectations, be transparent and show trust and support.  Leaders should also focus on handling coordination between teams.    

Provide a "Guide": Shield engineering teams from excessive corporate overhead. Dedicated project managers (not just program managers who push the burden onto engineers) can handle the administrative load.  This is to address bureaucracy.

Focus on External Competition: Internal rivalry is a distraction. Aim for external benchmarks.  This addresses complacency and hesitancy when there is an external opponent to focus on.

Leadership Support: Leadership should recognize that they created a matrix for the org and the teams don't need help at the node level but the edge traversal.

Maintain Momentum: Long projects can drain morale. Celebrate small wins and define clear milestones.

Instill Urgency: Set targets based on external market realities, ensuring team buy-in.

The key is to recognize that speed and agility aren't just startup perks. They're essential for any company that wants to thrive in today's fast-paced world. By addressing these challenges head-on, we can unlock the true potential of big companies and empower them to innovate at the speed of change.

My Favorite "Management" Books

Besides the books that I’ve previously listed, here are some books that are more focused on management rather then software engineering or technical project management that I’ve found to still be good reads for engineers.

The First 90 Days gives advice on how to transition into new roles with case studies on do’s and don’t. I found it useful in helping to develop a learning plan for myself whenever I start on a new team or in a new role.

Who Says Elephants Can’t Dance isn’t a “how to manage” book or even a “How Louis Gerstner manages” book. It’s presented more as a story of IBM’s turn-around. I like to read this book when I feel frustrated about a company to remind myself that change can happen even in the largest of companies.

Additionally, here are some books that’s been recommended to me which I have not yet read but I thought that I’d pass along:

• Debugging Teams (formerly Team Geek)
• The Five Dysfunctions of a Team (Manga Edition)
• The Adventures of Johnny Bunko

A company is the people who work for it.

I ran across this article through Hacker News by an entrepreneur who had sold his previous company and realized that he needed to start a new company. The author definitely has that entrepreneur spirit of wanting to take action on ideas, but a few of his statements are also examples of the negatives views adopted by many who are in management and leadership positions.

"I hated having 85 employees. It had become a little hell. I needed to get away and clear my mind."

How sad to hear from their leader that he hated having to deal with them. Being in management and leadership positions means having a degree of power over the employees, but it also comes with a responsibility for those employees. Employees are people and not just pawns to fulfill the manager's whims.

Before accepting the job of a manager, think about what that position means because it can be very different from what your existing role is.

When to grow an organization vertically vs horizontally?

I believe that a lot of good solutions to problems that a business is trying to solve comes from the rank-and-file. A technology company, for example, get some of its most innovative solutions from the engineers who are hired to build the company's products. When a company is at the stage where its focus is on building its products then it should focus on growing horizontally to maximize its efficiency. A good example is Google where they have been in the mode of building up their product. It makes sense that they have a fairly flat organizational hierarchy since the problem they're solving now is how to build a better search, how to monetize search, how to come up with new technical solutions, etc. Having a large set of talented engineer maximizes their chances of success.

At some point, however, the organization starts to move beyond just building the product. As the rank-and-file grows, a new problem emerges: organization. How does it organize all the ideas, thoughts and interactions between the different pieces? This is when a company needs to grow vertically. Managers are there to provide the necessary organization, structure and guidance so that the company can continue to maximize its potential. This also means that there is a max height to the organization at different stages since there is only so much organization that is needed and when that height is exceeded is when we see the high level of ineffective bureaucracy.

Sometimes I see an organization grow in the wrong direction because they fail to recognize the problem that it needs to solve. Instead of growing horizontally when trying to deliver products (This doesn't mean that throwing more ppl at a problem means it'll get solved faster or better. Growing horizontally could also mean empowering existing employees to come up with solutions), a company starts to insert multiple layers of management. This might be fine if it was trying to solve organizational problems but since it isn't these additional layers becomes more a hindrance then benefit.

Engineering Manager

The American Society of Engineering Management describes the discipline of engineering management as:

Engineering Management is the art and science of planning, organizing, allocating resources, and directing and controlling activities which have a technological component.

Engineering Management is rapidly becoming recognized as a professional discipline. Engineering managers are distinguished from other managers by the fact that they possess both an ability to apply engineering principles and a skill in organizing and directing technical projects and people in technical jobs.

Of course, this description throws another wrench in the roles within a technology company. Where is the line between technical product management, technical project management and engineering management?

Technical Product Manager

When I go to the bookstore, I see plenty of books in the technology section on software engineering and technical project management. However, there are very (if any) books about technical product management. Why is that? Technical product manager seems to be common enough in Silicon Valley, but there seems to be a lack of printed literature on technical product management. A search online, however, turned up many blogs about technical product management and what the position means.

Personally, I believe that technical product management is very different from regular product management or at least it is a specialized subset of product management. The problem that I often see is when a technology company don't see the distinction and when product management and project management gets confused.

This lack of clarity in companies also has a negative impact on its people. When a company hires a product manager (non-technical) for what is really a technical product manager role, the person simply won't be set up for success.

What baffles me and makes me wonder is it only in the tech industry that job roles are so unclear?

Meetings

I love meetings, I hate meetings, I love meetings... Okay, okay, I have a love-hate relationship with meetings. There are three types of meetings (no, it's not the good, the bad and the ugly) that I've found myself in. The first type of meeting is the useful meeting where the right people get together and figure out a solution to a problem.

The second type of meeting can also be useful which is the information meeting. This type of meeting is when one person needs to pass along information to a group of people followed by a discussion or questions. Type 2 can be tricky, though, because it can easily become an useless meeting if the information being given out is ill-prepared or not useful. Also, don't drag out these type of meetings for too long 'cause people have a limit on how much they can take from one person droning on-and-on.

The third type of meeting is the bad one, and unfortunately, the most common one that gives meetings a bad name. This is the meeting that someone has in order to show he's doing something to justify his existence at the company. There is often no true purpose at this meeting or to collect the people there together, yet it seems to last forever. Sometime this can be disguised as type 2 where the person talks forever on a topic that nobody needs to hear about and probably could've been done more efficiently in an email. There is often a lot of people in these meetings but no clear action items results from it. People might say something just so they can meet the "I participated" criteria but there is very little investment by the group. Occasionally there is one person who tries makes it his soapbox, but given the lack of interest by the group who soon just wants to get out it doesn't result in any positive action. In the end, everyone leaves feeling that they just lost a few hours of their lives.

My point? Make sure there is a clear purpose for calling a meeting and make sure you stay focus on the topic to be addressed/solved. If it's for information, get to the point and keep it clear.

How true this is...

from Death by Risk Adversion