4 ms·

For enterprise software companies, the numbers matter, as they're roughly proportional to revenue. For example, if I'm in build mold, I may scale my non-engine

For enterprise software companies, the numbers matter, as they're roughly proportional to revenue. For example, if I'm in build mold, I may scale my non-engineering organization as: - Each salesperson I hire a million dollar quota - Every 2 need a Sales Development Rep - Every 2 need a Sales Engineer - To generate pipeline for them, I need X dollars of marketing spend per salesperson (scales linear) and this will require a marketing department of Y people. - Every $2 million in revenue requires a support person - Management is 1 employee out of 5 - Every $2 million in revenue requires engineering support overhead of another body. - Every X employees requires an additional head in Finance and HR. These #s are all made up, but it's a way of thinking why people use headcount as a proxy for revenue, especially when revenue #s are private. This is much less true in consumer focused companies, or resellers.

rjzzleep 9y ago
Does it? Revenue is != profit though. This is where it bothers me. Startups start out by taking a share of the enterprise companies lunch by doing things that enterprise companies can't because of the structures they built. At some point when startups get successful they flip a switch a switch and try to become more enterprisy. They might get a "real" CEO, one of the big performance metrics becomes by how many hundred people you can grow the company per year and at some point if they make this transition successfully the company will start to stagnate. Back in the days when I went to some Erlang user group I was complaining about how I could solve a problem and rather than solving the problem the guy wanted to grow the engineering team to 20 people(from 5) some government contractor said that I don't get how the system works. You think that solving the problem is the key performance metric, but the actual metric is how many people the manager manages. One of the comments I saw below is true though. They grow the numbers and then they don't have proper management to fill the gaps. But what's proper management to begin with? If they "invest" in their people they will promote their earliest employees to director of xyz. Congrats, now some random crappy junior javascript developer is now your Director of Engineering and it will be legitimized by the $10000 Leadership 1 weekend course he got at Stanford. He will do 1 on 1s with you and try to talk about your future. But here's the problem though. Where do you get good management? Anecdotal evidence, I once sat at a dinner table and next to me was some old school business guy with his friend, a senior management guy at another company who recently got fired, saying that the worst thing you can do is hire middle management that is weaker than you. He will always try to keep the lower tier below himself. I'm supposedly in a leadership position in my company, yet the thing that no one ever wants to hear in upper and mid management is fixing issues. Ironically I recently did a PMP certification to see what the fuss is all about(granted, it's not really a management certificate). Nothing I saw in that formal guidebook aligns with what I've seen in real life. So if you can't get good management from other "enterprise" companies, and you can't get good management from your early employees and you can't get it from training, then why strive for that model to begin with? It seems like the only rational explanation for all of that is to pump up to numbers so you can aim for a nice exit on the ipo.
- mathattack 9y ago
  Revenue definitely doesn't equal profit. Headcount is easier to measure than revenue, which is easier to measure than profit. :-) A rule of thumb I've heard for SaaS startups is after they reach $50MM in ARR, Revenue + Margins should equal 40%. So if you're growing 20%, you should have profits of 20%. If you're growing 50%, it's ok to lose 10%. Just a rough rule of thumb.
- majormajor 9y ago
  > This is where it bothers me. Startups start out by taking a share of the enterprise companies lunch by doing things that enterprise companies can't because of the structures they built. It's a tradeoff. I don't think it's realistic to, outside of consulting or similar model stuff, build a company that can continue to run at peak efficiency even as the world changes. Internal small exploratory teams and a willingness to cannibalize yourself can help a lot here, but may hit a wall at some point (e.g.: what can Apple build next for future massive growth?). It's something like: Startup starts small enough to exploit how the world has changed since the big companies built their processes, and start undercutting those companies. Then they have to grow their delivery capacity to build out the rest of the features to capture the rest of the market, but this means more devs, more management, more sales, etc. That makes those of us in the "but it's less efficient" camp uncomfortable, but it's also explicitly what we're being paid for: figure out a way to grow this opportunity to be something really big. At some point it's unlikely that it can be your baby anymore. Then the world changes enough, and somebody else does the same thing to that startup. Satellite/cable TV is an example: from very innovative at the time, to the dinosaurs lumbering around today. The biggest thing I've seen correlated to good management is caring (if not about the people under them, at least sufficiently about the product so that they will do what's necessary to empower the people under them to get things done right). Hard to identify in a day of interviewing, though.
- klodolph 9y ago
  > You think that solving the problem is the key performance metric, but the actual metric is how many people the manager manages. Both metrics are wrong. "Solving the problem" might as well be translated as "how well the engineer engineers", and it's just as bad a metric as you might expect. You want to measure impact on the company bottom line, in the long and short term. It's just not easy to measure this metric, so we come up with a bunch of proxy metrics which we optimize for, each of which can easily lead to its special type of dysfunction.
kakwa_ 9y ago
Well, at least for the purely engineering part (aside from sales), I've seen the contrary more often than not. Earlier I my career, I've seen projects understaffed with tight deadlines. When management finally released that the said deadlines could not be met, they hired really fast, and not carefully, a bunch of people to try to reach that deadline. Those new people needed to be on-boarded, trained, and sometimes put aside because they didn't have the required competences. In the end it put us even more behind schedule than before. I've also worked at former startup bought by a big company, with more than ample resources. Yet there were tons of issues. Many teams having huge difficulties to communicate with one another, tons of features in the roadmap but very few made it into production and those in production were barely working and were a pain to keep up, the core functionalities of the product were slowly rotting away, long, annoying and not understood processes just cluttered everything and pieces of knowledge/information spread more like rumors with all that entailed of inaccuracies and wrong ideas... I could not shake the feeling that with fewer people, we could actually have had a better and faster output. It may be an extreme case of scale-up (in term of headcount) gone bad, but I'm pretty sure I'm not the only one with a story like that... I'm a fervent believer that flat organizations are way better, you can discuss directly with people, the pain points and challenges are clearly identified and solved together. In the end everything goes way faster and it's far more rewarding as an employee to work in that kind of environment. The issue is that past a certain headcount, flat organizations don't work anymore, however, when designing our products, maintaining the headcount as low as possible should really be a big item in the requirements. Growing the headcount for growing the headcount seems ludicrous from a purely technical point of view. But I can understand that a larger headcount might make a company more credible and valuable from an external eye. I understand it but I'm far from a big fan of it.
- tormeh 9y ago
  >Well, at least for the purely engineering part (aside from sales), I've seen the contrary more often than not. >Earlier I my career, I've seen projects understaffed with tight deadlines. When management finally released that the said deadlines could not be met, they hired really fast, and not carefully, a bunch of people to try to reach that deadline. Those new people needed to be on-boarded, trained, and sometimes put aside because they didn't have the required competences. In the end it put us even more behind schedule than before. The parent is talking about enterprise software, where costs per customer are very high. These companies live on contracts. They may have a core product, but each new customer requires a lot of development. These kind of organizations can scale linearly because each customer basically gets its own team. Consulting is the extreme version of this.

rjzzleep 9y ago

Does it? Revenue is != profit though. This is where it bothers me. Startups start out by taking a share of the enterprise companies lunch by doing things that enterprise companies can't because of the structures they built. At some point when startups get successful they flip a switch a switch and try to become more enterprisy. They might get a "real" CEO, one of the big performance metrics becomes by how many hundred people you can grow the company per year and at some point if they make this transition successfully the company will start to stagnate. Back in the days when I went to some Erlang user group I was complaining about how I could solve a problem and rather than solving the problem the guy wanted to grow the engineering team to 20 people(from 5) some government contractor said that I don't get how the system works. You think that solving the problem is the key performance metric, but the actual metric is how many people the manager manages. One of the comments I saw below is true though. They grow the numbers and then they don't have proper management to fill the gaps. But what's proper management to begin with? If they "invest" in their people they will promote their earliest employees to director of xyz. Congrats, now some random crappy junior javascript developer is now your Director of Engineering and it will be legitimized by the $10000 Leadership 1 weekend course he got at Stanford. He will do 1 on 1s with you and try to talk about your future. But here's the problem though. Where do you get good management? Anecdotal evidence, I once sat at a dinner table and next to me was some old school business guy with his friend, a senior management guy at another company who recently got fired, saying that the worst thing you can do is hire middle management that is weaker than you. He will always try to keep the lower tier below himself. I'm supposedly in a leadership position in my company, yet the thing that no one ever wants to hear in upper and mid management is fixing issues. Ironically I recently did a PMP certification to see what the fuss is all about(granted, it's not really a management certificate). Nothing I saw in that formal guidebook aligns with what I've seen in real life. So if you can't get good management from other "enterprise" companies, and you can't get good management from your early employees and you can't get it from training, then why strive for that model to begin with? It seems like the only rational explanation for all of that is to pump up to numbers so you can aim for a nice exit on the ipo.

mathattack 9y ago
Revenue definitely doesn't equal profit. Headcount is easier to measure than revenue, which is easier to measure than profit. :-) A rule of thumb I've heard for SaaS startups is after they reach $50MM in ARR, Revenue + Margins should equal 40%. So if you're growing 20%, you should have profits of 20%. If you're growing 50%, it's ok to lose 10%. Just a rough rule of thumb.
majormajor 9y ago
> This is where it bothers me. Startups start out by taking a share of the enterprise companies lunch by doing things that enterprise companies can't because of the structures they built. It's a tradeoff. I don't think it's realistic to, outside of consulting or similar model stuff, build a company that can continue to run at peak efficiency even as the world changes. Internal small exploratory teams and a willingness to cannibalize yourself can help a lot here, but may hit a wall at some point (e.g.: what can Apple build next for future massive growth?). It's something like: Startup starts small enough to exploit how the world has changed since the big companies built their processes, and start undercutting those companies. Then they have to grow their delivery capacity to build out the rest of the features to capture the rest of the market, but this means more devs, more management, more sales, etc. That makes those of us in the "but it's less efficient" camp uncomfortable, but it's also explicitly what we're being paid for: figure out a way to grow this opportunity to be something really big. At some point it's unlikely that it can be your baby anymore. Then the world changes enough, and somebody else does the same thing to that startup. Satellite/cable TV is an example: from very innovative at the time, to the dinosaurs lumbering around today. The biggest thing I've seen correlated to good management is caring (if not about the people under them, at least sufficiently about the product so that they will do what's necessary to empower the people under them to get things done right). Hard to identify in a day of interviewing, though.
klodolph 9y ago
> You think that solving the problem is the key performance metric, but the actual metric is how many people the manager manages. Both metrics are wrong. "Solving the problem" might as well be translated as "how well the engineer engineers", and it's just as bad a metric as you might expect. You want to measure impact on the company bottom line, in the long and short term. It's just not easy to measure this metric, so we come up with a bunch of proxy metrics which we optimize for, each of which can easily lead to its special type of dysfunction.

kakwa_ 9y ago

Well, at least for the purely engineering part (aside from sales), I've seen the contrary more often than not. Earlier I my career, I've seen projects understaffed with tight deadlines. When management finally released that the said deadlines could not be met, they hired really fast, and not carefully, a bunch of people to try to reach that deadline. Those new people needed to be on-boarded, trained, and sometimes put aside because they didn't have the required competences. In the end it put us even more behind schedule than before. I've also worked at former startup bought by a big company, with more than ample resources. Yet there were tons of issues. Many teams having huge difficulties to communicate with one another, tons of features in the roadmap but very few made it into production and those in production were barely working and were a pain to keep up, the core functionalities of the product were slowly rotting away, long, annoying and not understood processes just cluttered everything and pieces of knowledge/information spread more like rumors with all that entailed of inaccuracies and wrong ideas... I could not shake the feeling that with fewer people, we could actually have had a better and faster output. It may be an extreme case of scale-up (in term of headcount) gone bad, but I'm pretty sure I'm not the only one with a story like that... I'm a fervent believer that flat organizations are way better, you can discuss directly with people, the pain points and challenges are clearly identified and solved together. In the end everything goes way faster and it's far more rewarding as an employee to work in that kind of environment. The issue is that past a certain headcount, flat organizations don't work anymore, however, when designing our products, maintaining the headcount as low as possible should really be a big item in the requirements. Growing the headcount for growing the headcount seems ludicrous from a purely technical point of view. But I can understand that a larger headcount might make a company more credible and valuable from an external eye. I understand it but I'm far from a big fan of it.

tormeh 9y ago
>Well, at least for the purely engineering part (aside from sales), I've seen the contrary more often than not. >Earlier I my career, I've seen projects understaffed with tight deadlines. When management finally released that the said deadlines could not be met, they hired really fast, and not carefully, a bunch of people to try to reach that deadline. Those new people needed to be on-boarded, trained, and sometimes put aside because they didn't have the required competences. In the end it put us even more behind schedule than before. The parent is talking about enterprise software, where costs per customer are very high. These companies live on contracts. They may have a core product, but each new customer requires a lot of development. These kind of organizations can scale linearly because each customer basically gets its own team. Consulting is the extreme version of this.