What makes a project "Big"?

I got rejected multiple times on job interviews for valid reasons. Sometimes that was about me lacking specific hard skills, concrete experience in some area or misaligned goals between the company and me. Sometimes the other candidates were better than me.

However, there was one time when rejection felt like I had never worked on a “big project”. The hiring manager came late and unprepared. He asked a few random questions and a few about the size of the DevOps Team that I collaborated with. The interview ended very quickly. Because of the form of an interview, my first idea was to email HR saying thank you and letting them know that I wouldn’t like to continue the process to save a little bit of my time.

After that, I hosted many job interviews for candidates applying to companies I was hiring for.

I observed that most people use the phrase “big project” when doing self-presentation. I started realizing that the perception of size is always relevant to our own experiences.

“Big” usually means “the biggest I took part in”. With that definition, everyone participated in something “big”.

When describing my experience of working with more than 50 teams, I sometimes refer to “the biggest one” but not to the “big one”.

That made me think that many hiring managers are looking for a single dimension when referring to their understanding of the word “big”. But sizes may come in different shapes and colours.

Big team

Following the Scrum Guide or Amazon’s 2-pizza size team, we tend to refer to a typical team size of 5-8 people. That makes an 8 people big team - a big one.

The biggest team I led was approximately 40 people. That was an anti-pattern, which we eventually split into multiple teams. Still - that was an excellent opportunity to work with a big single team.

Also, a long time ago, when I was a project manager working for a software house. I had an opportunity to manage up to 8 projects at the same time, with 8 different teams of a size between 1 to 8 developers each. That meant 8 contexts at the same time. And this is where I learned that it is effortless to promise 8 things to 1 person but amazingly hard to promise 8 things to 8 people - 1 promise per person.

Still, my favourite size of a single team is between 4-7.

How shall we calculate the team size in the role of manager-of-managers? Is it through the managers that they are managing? Or by the total number of people working in the teams of their managers?

And how it calculates for a team building open source project, which is being used by thousands of engineers world-wide?

Big project

The size of the project might be described in its length, number of teams working on it, budget, scope, whatever. A project might be about releasing a minor feature in the next 2 weeks. A project might be about sending a rocket to the Moon.

When I was a project manager, my projects were usually a couple of months long. However, the biggest one was about 2 years long, with pretty much-fixed scope, quoted upfront.

While the agile continuous approach for building something (to hopefully slice it in a way that enables early value delivery), or short Shape Up projects, got popularized, many of us started referring to 6 weeks projects as big ones.

We may also take that dimension of projects to the levels of programs. A program is a collection of related projects managed and coordinated to obtain benefits and control that would not be possible if they were managed individually. The biggest program that I participated in had about 300 engineers involved.

My experiences might be big comparing them to something developed by just a few teams. But also extremely small comparing them to Elon’s plan to go to Mars. Did I even work on a big project?

Big product

I worked at 3 product companies. One of them had just 40 customers with a few hundred users. The other one had nearly 10 000 customers paying for a SaaS license. And the other one had hundreds of thousands of paying customers with over 80 million end-users.

Reading this information can lead to the conclusion that the last product was the biggest. The first two were built by small companies with 25 people, and the last one by 4000+ people big company.

The first one was super stable, enabling our customers to feel happy and employees to make a living. The second one was during the growth stage, achieving much Year-over-Year progress in revenue, net income, and customers.

First and third had a huge number of features. The second one had a small number of them.

Which was the biggest? Is it worth it to keep scaling or remain stable?

Big business domain complexity

Domain-Driven Design brought us a better understanding of why it is worth understanding the domain’s complexity and why it is worth collaborating very closely with domain experts. I am not a DDD expert, but I know DDD is a good thing. This is a no-brainer.

Side note. That’s still super surprising why we need DDD to encourage engineers to talk to users; we need continuous discovery habits to encourage product managers to talk to users; and we need design thinking to encourage designers to talk to users.

On the other hand, we can compare the product I’ve been working on with millions of users to the one written in Delphi that we developed just for 40 customers.

My experience is the following - from the business domain complexity perspective, the product we built for just 40 customers was the most complex. Tech stack was Delphi, PL/SQL and C#. That was the very first job of my life. A lot of analysis, a lot of collaboration with customers, and a lot of days and nights spent in factories, warehouses and hotels.

After the Delphi-based product, all the projects and products I’ve been working on, which can be easily considered as the ones of larger scale, were much much much much simpler from the business analysis perspective.

Still, comparing the business domain complexity - how can we compare my experiences to the business of manufacturing cars? I bet building cars is much more complex than what I have ever been doing.

Big tech stack

For the purpose of this article, I divide the tech stack into 3 groups: legacy (e.g. Delphi, Cobol, Firebird), boring technology (e.g. Java, C#, PostgreSQL), exciting technology (e.g. Rust, Golang, Neo4j).

By default, we may judge people working on legacy ones as dinosaurs; the ones working on boring technology as enterprise folks; and the exciting group as underdogs or startups.

Languages themselves do not say too much about their scale. One system can be run on the infrastructure maintained by 5 Platform Engineers, the other one by 200 of them.

When I got rejected on a job interview a few years ago because I explained my experience of working with a team of 5 DevOps Engineers, that was automatically considered by a hiring manager as a small scale. But is a platform run by 5 DevOps Engineers supporting a few hundred engineers or millions of users worse than a poorly optimised unstable platform run by 50 Platform Engineers and 30 Site Reliability Engineers?

The other area of this dimension is the number of technologies being used in a single project. Different sides of it are about full independence in choosing the technology by the teams or by having a standardised set of technologies at the company that engineers can pick from. That might be about picking the best technology to solve a problem.

One project I worked on had more than 10 million daily active users during peaks. But again, it is not easy to clearly define which tech stack, platform or DAU/MAU metric might be considered the best.

“Big” in that dimension may go together with reliability and maintainability.

Big company

The smallest company I was at was about 20 people big. The current one is about 4000+ people big. The biggest company I collaborated with was 50000+ people big.

Again, the number of employees can tell us something. But, it says close to nothing about the company’s culture, ways of working, or a level of architectural coupling in the area the specific person is working on.

And I cannot tell if the project for 50000+ people big one was easier or more challenging than for 20 people big company. In the enterprise environment, the challenge was in alignment, synchronisation, knowledge management, and decoupling. In a startup environment, the challenge was satisfying customers and deciding what not to build.

Does the size matter?

There are many dimensions of size. Input/Output Operations per Second are cool, so the height of a tree you can climb is.

If you’re a hiring manager looking just for a definition of “big” understood through a single dimension, then most likely, your biases will make it harder for candidates to show their strengths.

If you’re a candidate saying about a “big project", try to explain it using real numbers.

Am I bias-free? Do I ask perfect questions? Amos Tversky and Daniel Kahneman may have an answer for that.

Bonus interview question

The question I like for job interviews is:

“What’s your skill/experience/characteristic that you believe is worth sharing with us, but our job interview process made it hard to present it?”