7 ms·

I'm honestly not that surprised about the size. In my experience, efficiency and the number of engineers have not necessarily correlated. For example, I used t

by M0r13n 5y ago

I'm honestly not that surprised about the size. In my experience, efficiency and the number of engineers have not necessarily correlated. For example, I used to work for a company with about 500 employees (relatively large by German standards) and now work for a competing company in the same industry with less than 150 employees. The core engineering team only consists of a dozen engineers. The output is noticeably larger. The number of new features and especially the stability is significantly better. It is noticeable that due to the small team, each project has one or two "heroes". They are responsible for most of the commits and know the system inside out. These "heroes" have been working on the same or similar systems for over 30 years in some cases and have experienced a lot in their careers. As such, they can bring experience and advice that is just out of reach for others. Given the choice, I would always prefer a small team over a large team.

yodsanklai 5y ago
> Given the choice, I would always prefer a small team over a large team. I think that's one of the conclusion of the "mythical man-month" book.
altacc 5y ago
Having worked in a range of companies, there is definitely an inverse correlation between company size and speed, especially for individual teams. At 500 people you're well into enterprise level organisation, where a lot of processes are put in place to minimize the amount of damage a single person can do to the organisation. That also puts a speed limit on those efficient and knowledgeable contributors. Some companies spend a lot of time & energy trying to implement operating models that try to overcome this but actually end up putting in place more decision processes & oversight. Sometimes the real solution is to reduce control and let the efficient teams lead the way. But then what would all that management do to fill their days...
- mywittyname 5y ago
  I think this is more correlated to maturity than size. It's just that size is highly correlated to maturity. I've been in large companies where I was the admin/owner of their AWS account. And I've worked at companies with 200 people where I have to submit tickets to get anything created in AWS. The major difference was how mature the product was.
  - necheffa 5y ago
    I work on a suite of products over 50 years old that have been incumbent for about that long and still have a submit tickets to get just about anything done.
  - closeparen 5y ago
    My current employer has a nice balanced approach to this: everything is a code review. I may need a gatekeeper to approve my change, but I can always submit it. It’s also safer this way. Not even the proper owners should routinely be on production shells or tools with live write access. They also go through peer review with each other. Once the infrastructure is in place for that, it makes sense to open up.
emerongi 5y ago
As long as the core system is built on solid engineering, this definitely makes sense. From my experience in a deadline-constrained environment, things end up being slapped together until they "just work". Adding new features gets more and more difficult and if you're still constrained by deadlines, then the solution is to hire more, which is effectively a brute-force solution to meet the deadlines. Output per employee gets smaller, but total output should grow by some marginal amount.
- allcentury 5y ago
  Absolutely. This is also when bigger and more pervasive bugs enter the conversation. Decisions that kicked the can 2 years ago are now a big problem and no one team can fix it.
jawns 5y ago
Heroes are a red flag for me, as a manager, trying to build a resilient team. Which is not to say that you can't have a range of experience levels. But what happens when those heroes are unavailable? Maybe they're out on vacation, or medical leave, or they eventually retire or leave the organization because they're tired of propping it up? Heroes tend to be a single point of failure.
- throw1234651234 5y ago
  I understand your point, but what managers fail to understand is that someone usually "carries", i.e. is actually responsible for the success of the product. I have even seen it be a manager...once.
- civilized 5y ago
  You're right up to a point, but I've seen far worse red flags. Like companies that can never acquire these heroes in the first place because no one competent would work there that long. As somebody else mentioned, these companies end up regularly throwing millions at consultant projects that always fail. In other words, they pay a hefty premium for shitty temp "heroes" that give them less than employee heroes would have given them. You see this a lot in the traditional finance sector, where managers don't appreciate tech workers and relentlessly fuck themselves over trying to save a dime.
  - jgilias 5y ago
    Yeah, somewhat counterintuitively treating tech as a cost center will inevitably lead to wasted funds. But hey, that just makes incumbents die faster and give way to organizations treating tech as an investment. Which are the ones you want to work for as a tech person anyway.
- gen220 5y ago
  If you have good trust and communication within a team, the scenarios you describe are surmountable. Every strength is a weakness, and every weakness is a strength. IME, heroes are no more a red flag than pretending that good engineers are interchangeable. It depends on the context. The expected outcomes of these teams are different, and that’s OK. If you’re a very small company and don’t have a couple heroes, you won’t build anything important. If you’re a very big company, the heroes that built it left years ago, and you need resiliency more than new heroes (unless the business is going sideways and needs saving).
commandlinefan 5y ago
> efficiency and the number of engineers have not necessarily correlated Often inversely correlated...
bluedino 5y ago
I worked at a place that made a group of loosely-related websites. Basically different spins/themes on the same products. There were 4 of us on the development team. There were 10 websites. Some new, some in maintenance mode. I quit after a few years, and about 3-4 years later they went on a hiring spree. Tripled the number of developers. Refreshed some products, discontinued some, and some went into maintenance mode. They still had around the same 10 websites, but 12 developers. The products didn't get better. The products didn't get made any faster. They didn't have any less bugs. My wife actually works there now, and when she tells me about the issues they have I laugh a little bit. It's all the same problems we had back then. Invites don't work. Teams doesn't work. Uploading profile pictures has issues. Entering data doesn't work. Registration is broken.
- ratww 5y ago
  I had a somewhat similar experience with a large tech company. Grew from <100 to 600 in a few years, but in the meantime they weren't even able to update the homepage. Not even the content changed, in almost three years. Everything was convoluted and over-engineered. The whole thing was rewritten from scratch twice, and when I left there were plans for a third rewrite from scratch. COVID destroyed the company: there were zero customers. But the website still struggled to stay online. That's when I decided to leave.

by M0r13n 5y ago

yodsanklai 5y ago

> Given the choice, I would always prefer a small team over a large team. I think that's one of the conclusion of the "mythical man-month" book.

altacc 5y ago

Having worked in a range of companies, there is definitely an inverse correlation between company size and speed, especially for individual teams. At 500 people you're well into enterprise level organisation, where a lot of processes are put in place to minimize the amount of damage a single person can do to the organisation. That also puts a speed limit on those efficient and knowledgeable contributors. Some companies spend a lot of time & energy trying to implement operating models that try to overcome this but actually end up putting in place more decision processes & oversight. Sometimes the real solution is to reduce control and let the efficient teams lead the way. But then what would all that management do to fill their days...

mywittyname 5y ago
I think this is more correlated to maturity than size. It's just that size is highly correlated to maturity. I've been in large companies where I was the admin/owner of their AWS account. And I've worked at companies with 200 people where I have to submit tickets to get anything created in AWS. The major difference was how mature the product was.
- necheffa 5y ago
  I work on a suite of products over 50 years old that have been incumbent for about that long and still have a submit tickets to get just about anything done.
- closeparen 5y ago
  My current employer has a nice balanced approach to this: everything is a code review. I may need a gatekeeper to approve my change, but I can always submit it. It’s also safer this way. Not even the proper owners should routinely be on production shells or tools with live write access. They also go through peer review with each other. Once the infrastructure is in place for that, it makes sense to open up.

emerongi 5y ago

As long as the core system is built on solid engineering, this definitely makes sense. From my experience in a deadline-constrained environment, things end up being slapped together until they "just work". Adding new features gets more and more difficult and if you're still constrained by deadlines, then the solution is to hire more, which is effectively a brute-force solution to meet the deadlines. Output per employee gets smaller, but total output should grow by some marginal amount.

allcentury 5y ago
Absolutely. This is also when bigger and more pervasive bugs enter the conversation. Decisions that kicked the can 2 years ago are now a big problem and no one team can fix it.

jawns 5y ago

Heroes are a red flag for me, as a manager, trying to build a resilient team. Which is not to say that you can't have a range of experience levels. But what happens when those heroes are unavailable? Maybe they're out on vacation, or medical leave, or they eventually retire or leave the organization because they're tired of propping it up? Heroes tend to be a single point of failure.

throw1234651234 5y ago
I understand your point, but what managers fail to understand is that someone usually "carries", i.e. is actually responsible for the success of the product. I have even seen it be a manager...once.
civilized 5y ago
You're right up to a point, but I've seen far worse red flags. Like companies that can never acquire these heroes in the first place because no one competent would work there that long. As somebody else mentioned, these companies end up regularly throwing millions at consultant projects that always fail. In other words, they pay a hefty premium for shitty temp "heroes" that give them less than employee heroes would have given them. You see this a lot in the traditional finance sector, where managers don't appreciate tech workers and relentlessly fuck themselves over trying to save a dime.
- jgilias 5y ago
  Yeah, somewhat counterintuitively treating tech as a cost center will inevitably lead to wasted funds. But hey, that just makes incumbents die faster and give way to organizations treating tech as an investment. Which are the ones you want to work for as a tech person anyway.
gen220 5y ago
If you have good trust and communication within a team, the scenarios you describe are surmountable. Every strength is a weakness, and every weakness is a strength. IME, heroes are no more a red flag than pretending that good engineers are interchangeable. It depends on the context. The expected outcomes of these teams are different, and that’s OK. If you’re a very small company and don’t have a couple heroes, you won’t build anything important. If you’re a very big company, the heroes that built it left years ago, and you need resiliency more than new heroes (unless the business is going sideways and needs saving).

commandlinefan 5y ago

> efficiency and the number of engineers have not necessarily correlated Often inversely correlated...

bluedino 5y ago

I worked at a place that made a group of loosely-related websites. Basically different spins/themes on the same products. There were 4 of us on the development team. There were 10 websites. Some new, some in maintenance mode. I quit after a few years, and about 3-4 years later they went on a hiring spree. Tripled the number of developers. Refreshed some products, discontinued some, and some went into maintenance mode. They still had around the same 10 websites, but 12 developers. The products didn't get better. The products didn't get made any faster. They didn't have any less bugs. My wife actually works there now, and when she tells me about the issues they have I laugh a little bit. It's all the same problems we had back then. Invites don't work. Teams doesn't work. Uploading profile pictures has issues. Entering data doesn't work. Registration is broken.

ratww 5y ago
I had a somewhat similar experience with a large tech company. Grew from <100 to 600 in a few years, but in the meantime they weren't even able to update the homepage. Not even the content changed, in almost three years. Everything was convoluted and over-engineered. The whole thing was rewritten from scratch twice, and when I left there were plans for a third rewrite from scratch. COVID destroyed the company: there were zero customers. But the website still struggled to stay online. That's when I decided to leave.