How Organization Size Influences Developers’ Decision-Making

We’ll start with a statement that’ll surprise no one: The right technical decisions for a small company and a large company don’t match up.

Patterns and processes from the gradient of organization sizes aren’t always broadly applicable. It’s like building a chair by hand versus setting that chair up for mass production — each method requires different skill sets, needs, and goals. Scale introduces change.

Here we take a closer look at how size meaningfully impacts developers’ decision-making. Let’s dive in. 

A Note on Size

Our three categories here — small, medium, and large — are solely size-related. It’s tempting to pull in a word like startup as a synonym, but that’s more of a phase than a unit of measure. A ten-person, ten-year-old company probably isn’t a startup; a three-year-old company with hundreds of folks might be.

Small Companies

Kicking off on the small end of the spectrum, it’s hard to define exactly where a small company ends and a medium one begins, but we’ll use 50 people and/or $10M in revenue as the threshold. Above that, characteristics from the medium category have an outsized influence.

The One Word Summary: Opinionated

Small companies don’t have the time, capital, or headcount to do everything for everyone. The software they build (and use) has to prioritize what’s most important — and is often differentiated by what it doesn’t do.

Something like The Joy of React’s edtech approach fits in perfectly here: It has a narrow, specialized scope, includes the author’s (practiced) opinions, and uses unique learning exercises. On the other end of the React training spectrum, Codecademy’s React courses stick to a more consistent presentation and are a drop in a very large content bucket. Small and unique versus large and scalable, each with their own merits.

Technical Characteristics

A small organization’s approach to software usually includes:

Methodology

• In most situations, shipped code is better than good code. Time helps you sort out what’s worth optimizing, abstracting, and which patterns to follow. Pre-optimizing the wrong things is a drain on limited resources.
• Code is created, changed, and removed at a rate that documentation usually can’t keep up with.
• Talk of deadlines includes today and this week.
• Methodology can shift in a hurry and has room to be reactive. Put another way, the ship steers easily. Newcomers can affect process pretty much immediately, and may be hired to do just that.

System Selection

• The world is your oyster. At this scale, third-party tools that charge per seat or per use will be inexpensive (or free).
• As a small fish, though, these third-parties typically won’t offer customization.
• Further, some libraries really don’t make sense yet.
• Until there are more people and pieces, you’ll have fewer hard requirements (or disqualifiers) when it comes to libraries, frameworks, and languages.
• There isn’t much friction (relatively speaking) when swapping out third-party options, should the need arise.
• A simple spreadsheet may do the job better than a subscription service with a price tag.

The Tech Lead Role

At this size, a company’s tech lead is in the code, either alone or alongside a small team. For a tech company specifically, it’s the height of the software team’s power. There’s a disproportionate focus on getting the product or service ready, and fewer seats at the leadership table. All eyes rest on implementation.

For now, the lead is making big decisions with little data to fall back on. Whether it’s creating something completely new or managing a growing platform, experience and intuition are more readily available than user insights.

The Caveat

When does a small company act bigger than their headcount? When they’re helping one or more enterprise customers.

It isn’t a complete paradigm shift (lest you lose all the upside of being a small, nimble, opinionated organization) but there’s an adaptation to the communication, documentation, and acceptance criteria of the larger entity. That may mean using Jira instead of GitHub Issues, Confluence instead of Google Docs, or other bends in the process to meet customers where they are.

Medium Companies

Now we’ve entered the realm of organizations with their own HR departments.

The One Word Summary: Balance

Medium-sized companies have something that works, however flawed, and really don’t want to cede ground. At the same time, there’s growth on the table and assumptions to correct. It’s a tightrope act of resources, opinions, and expectations.

A good example here rests with the folks at 37signals and their until the end of the internet policy. To avoid upending change-adverse customers, they continue to support old versions of Basecamp (with some well over a decade old).

Technical Characteristics

A medium organization’s approach to software usually includes:

Methodology

• “This is how we’ve always done it” is something people say.
• Without documentation, decisions (and their context) start to fade away — or, you’re over reliant on a part-developer, part-historian teammate.
• Concerns like the future and technical debt are agenda items at virtually every meeting. And there are a lot more meetings, too.
• Changes take a little longer — technical debt, delegation, approval — so progress relies on being more proactive than reactive.
• Deadlines increasingly target this month and this quarter.

System Selection

• It’s a little bit easier to qualify third-party tools, languages, and frameworks. You’ll have a better sense of requirements, disqualifiers, what you want to hire for, and how pricing matches up with overall value.
• At the same time, third-party providers are now looking for multi-year commitments. Between contracts and complexity, it’s much harder to change direction on services you don’t manage.
• With a higher headcount, per-seat costs suddenly look expensive.
• Those spreadsheets hiding on employees’ machines or in share drives may be important enough to surface as a tool or product.

The Tech Lead Role

At this stage, the tech lead spends a lot more time delegating than implementing. They usually still have a sense of the code, what’s in there, and how it all fits together, but their efforts are better spent elsewhere (no matter how much they want to jump back in).

There are new worries: How hard is it to hire for our tech stack? What does onboarding look like? How do we pull all of this institutional knowledge out of our heads?

Keeping with the theme of balance, the lead is locked in the endless resourcing struggle that is maintain what we have versus improve with a rewrite.

The Caveat

The great rebuild. It’ll eventually be high time to make a major application update, and that’s when medium organizations put their small company hat back on for a while. At this size, there’s a cascade of consequences; any delays to the new platform force the old one to stick around longer — and it’s usually being neglected in favor of building the new one.

Large Companies

“Oh, you work at Company Y? Have you met Sarah in accounting?” If your go-to answer in these situations is no, the organization has probably crossed the large threshold.

The One Word Summary: Requirements

This kind of scale means that changes impact a large number of customers or staff. There are more opinions, more committees, more regulations, and a larger exposure to lawsuits to contend with.

Technical Characteristics

A large organization’s approach to software usually includes:

Methodology

• There are many policies. No one’s quite sure where most came from.
• Documentation keeps decisions from being forgotten, but there’s a lot of it worth forgetting.
• Onboarding (both staff and vendors) is a big time and expense sink. There’s security training, audits, approved devices, IT departments, and so on — all relating back to the idea of requirements.
• Small changes add up, invoking the legend of the American Airlines olive.
• Deadlines become initiatives, and they’re measured in years.

System Selection

• If you’re evaluating a paid, third-party tool, you’ll almost always have to press the “enterprise sales” button and wait to talk to someone. Expect many, many more sales meetings.
• As a big fish, though, those third-parties will often offer some custom features to meet your requirements (counter to what a small organization sees).
• Clearing a new outside vendor or subscription will take extra effort. Think more approvals, procurement, security screenings, and other steps that tie back into all of those policies.
• At this scale, you could bring some services back in house. Maybe an LMS or CRM from scratch actually makes sense: Would control over features, integrations, data, and the roadmap be worth the time, effort, and staffing?

The Tech Lead Role

Here, the tech lead is a politician. They’re in the room when objectives are set, watch those objectives proliferate down, and spend time shielding the software team from shifting priorities and new requests. Actual hands-on coding is either relegated to the past or to their free time.

Maintenance, marketing, and sales all draw a lot of attention and, at this size, it’s easier for the tech lead to “lose” an argument. Compromise enters the chat.

The Caveat

Bringing this concept fully back to the beginning, a large organization will eventually aim to break through the policy red tape and tap a new offering to get the “small company” treatment. Fewer hoops, less oversight, and more aggressive deadlines in the name of innovation.

Scaling Technical Decisions

The best tool, the best approach, the best foundation: all subjective, and all influenced by a company’s size.

To wrap this one up, two additional thoughts:

• Growth isn’t necessary, or a constant. An incredibly successful company can be right-sized in the small or medium categories.
• The right team members — especially the tech lead — are also subject to size. The lead developer of a five-person shop and the CTO of a 20,000-person enterprise draw on very different skills.