6 ms·

I agree with everything you say, but that response, like the junior engineer, focusses on the technology. So give people six months not a weekend -- there's a g

by rfrey 10y ago

I agree with everything you say, but that response, like the junior engineer, focusses on the technology. So give people six months not a weekend -- there's a good chance they still won't be Uber. The success of many companies, and probably all of the unicorns, has nothing to do with technology. The tech is necessary, of course, but so are desks and an accounting department. Internalizing that has been difficult for me as an engineer.

malux85 10y ago
I know - but I was talking to a junior engineer, and I was concentrating on the technical aspects to inspire him. I expected him to go off and actually attempt building it, that way he would get some more experience. And he did! He went off that weekend and wrote a proof of concept route planner, it was great to see him learn something new and complex
- Shivetya 10y ago
  many a junior engineer who persist on the idea its easy, can be done quicker, cheaper, and such, also rarely have the needed dedication to see it through especially when it takes longer than expected, missing requirements are identified, and such. I have seen multi million dollar projects hit the same snags, horribly under scoped all because Mr Easy didn't think about asking all of was needed. They saw the tree and missed the forest
  - paulmd 10y ago
    Proper project scoping (or to rephrase: identifying the true core business needs) is truly one of the hardest problems in tech. Over-scoping makes you end up with a ponderous system that doesn't serve core business needs very well, while underscoping can lock you into poor initial decisions that cripple your ability to expand into other related functionality. What's the expression? "Plan your system for 100x growth, but build your system for 10x growth". Something like that except for functionality rather than scalability. That and supporting the system. Junior engineers tend to think about building the tech, which is honestly the easy part. Keeping it working until the last of your customers are finally ready to upgrade 10 years later is harder than junior engineers tend to think.
    - LouisSayers 10y ago
      Ha!even this sounds like a mistake to me. How about "Make the simplest thing work for one person.". Make sure they get some value, and then iterate and repeat. Once you've clearly solved the problem at hand then start to scale, optimise etc That is of course all after you've presold the solution. I know it's not always easy to do this, but that really is part of the challenge. There's still too many deathmarch projects lead by people trying to do things 'the right way'. If you're working on a new project for the love of science, please make sure you're releasing something valuable every single week if not every one or two days!
api 10y ago
Sometimes it is the tech... just not in obvious ways. You have to look beyond the basic spec. Uber and Lyft are not just taxi apps. They are massively polished. When I use them I am astounded at how good they've gotten the UX and then I shudder at how hard that must have been across two mobile platforms and in the presence of very unreliable networks. I've ordered an Uber with no cell Internet using barely usable coffee shop wifi from a block away. Then you have scaling, which brings up or creates issues you just do not see at smaller scales. Big O type considerations and weird edge cases that only come up once every billion transactions start mattering. Then there is all the big data stuff. These services do tons of route optimization and analytics. So yeah marketing, sales, fund raising, management, etc. also matter but tech often matters as much or more. It's just that junior engineers usually only see the tops of icebergs. This is why despite decades of pure biz people saying "tech doesn't matter" you still rarely see founding teams succeed without at least some tech founders but you do occasionally see even lone tech founders make it. (But those tech founders do have to know or be willing to learn the non tech stuff!)
shubhamjain 10y ago
> Internalizing that has been difficult for me as an engineer. Technology exists largely to accelerate the pace of development and of course, it's never a sole driver of any business. There is no reason why you can't create a small-scale uber with call centres and excel spreadsheets but I doubt it would reach the scale and impact of what Uber is today. Granted that, it's hundred times easier to figure out to technology than business, I won't trivialise role of engineering because it's something allows a business to near its global maximum.
danenania 10y ago
It has a lot to do with the technology. It's not the only or even the most important factor, but it's still one of the most important. I think a big part of the disconnect being discussed originates in the myth that CRUD-based apps are fundamentally easy. This simply isn't true. The challenges of building a modern, complex, scalable CRUD app with good UX and a maintainable code base are not 'less than' challenges rooted in algorithms or bit bashing. Doing it well enough and fast enough to be competitive in the market is HARD.
mbesto 10y ago
> The success of many companies, and probably all of the unicorns, has nothing to do with technology. This is 100% true and unfortunately gets distorted from the financial backers who pump them up for unicorn status. Quite a dichotomy: "Software is eating the world!" "The hard thing isn’t setting up an organizational chart. The hard thing is getting people to communicate within the organization that you just designed."
- 0xdeadbeefbabe 10y ago
  > The success of many companies, and probably all of the unicorns, has nothing to do with technology. So why not look at failure then?
  - dragontamer 10y ago
    Its harder to learn from failures than to learn from successes. Success has the false-positive issue. Failures have the false-negative issue. Cargo-culting false-positives is going to be less harmful than cargo-culting false-negatives. (X Company didn't use stack-ranking and then failed. Clearly stack-ranking is bad for companies)
    - 0xdeadbeefbabe 10y ago
      Maybe. Just to muddy things even more, some successes are failures. Have you ever met a billionaire who said, "I was lucky" and left it at that?
    - richie5um 10y ago
      Yeah. At least with a success you have a data point that it could be successful - with a failure, you don't even know that.
  - michaelbuckbee 10y ago
    It's not the technology success/failure axis in question, but how much weight to give it relative to other factors. AKA in predicting overall success would a team with low tech expertise, but high sales expertise be have a better chance?
n_time 10y ago
> The success of many companies, and probably all of the unicorns, has nothing to do with technology Have you considered broadening your personal definition of technology past computing and engineering? From Wikipedia: > Technology can be the knowledge of techniques, processes, etc. or it can be embedded in machines, computers, devices and factories, which can be operated by individuals without detailed knowledge of the workings of such things. Technology is the creation of systems. Those systems run as much on the users of that technology, and the members of the organisation supporting it, as they do inside of microprocessors.
markonthewall 10y ago
>The success of many companies, and probably all of the unicorns, has nothing to do with technology. Most of the unicorns are founded with engineering talent coming straight from Stanford, MIT, Harvard, UCB, Waterloo etc. you name it. Making a company successful is as much about economics of scale than raw engineering and of course, both are closely related in this day and age. Engineering shapes what and how your products feels like in real-time (= understand very short code-to-production lifecycle). It might not be politically correct to say but I am not here to make you feel better. Anyone who has actually been in a team at a company that has exponentially grown will tell you the same: your chances to ever survive that "first wave" of users is directly proportional to your ability to hire the best, which of course is a lot easier when they are your current or former classmates. That's not to say there aren't companies founded by people not going to the schools mentioned above or that engineering talent is only available at these places. It is obviously not the case. However, the density of talent at top-schools is absurdly high. And this is a game changer for most early stage companies and even more so for soon-to-be-unicorns.
- wangchow 10y ago
  Probably why a lot of professors say that University is often about networking opportunities just as much as it is about learning. But aside from knowing talented people, it takes visionaries to generate fantastic outcomes. Walt Disney for example stopped drawing cartoons himself early on because he had better artists around him. However, he had the vision that ultimately brought the best out of each artist.
jcoffland 10y ago
> The success of many companies, and probably all of the unicorns, has nothing to do with technology. Execs love to think this but it's just not true. Top heavy companies waste money. It's true that tech of not the only ingredient but for a tech company it's critical. Good tech is not a commodity. Top-tier engineers are worth as much as a good CEO. That is if you want to remain lean.
bunderbunder 10y ago
At a previous job, we had serious development bandwidth issues. The company was trying to solve that by hiring more developers, and all it was doing was making things worse. The root cause of the development bandwidth problem was that we wasted vast amounts of time and energy on building misfeatures. And we built so many misfeatures because we had way too much development capacity in relation to our product planning capacity. So the BAs didn't have enough time to fully develop ideas before sending them to engineering, and were instead stuck throwing things over the wall when they were still half baked. All these half-baked ideas took time to build, and then they took time to fix after they bombed on the market, and they slowed everything else down since every new feature is something you have to ensure still works when you make a change in that part of the software. Day in, day out, we were taking on technical debt to cover our design debt bills. So then we tried Agile, and man oh man did that make things worse. 'Cuz now instead of just lobbing things over the wall, the BAs had to be actively involved in every sprint. There goes any opportunity to sit down and concentrate, because now you've got a nattering horde of 20 developers all trying to get clarification on last week's decisions, which leaves less time to make this week's decisions, which means next sprint things will be even more sketchy and ill-defined. The correct solution would have been to hire more business analysts, and they key thing we needed from those business analysts wasn't instructions on what to build. It was instructions on what _not_ to build.
- amag 10y ago
  > The company was trying to solve that by hiring more developers, and all it was doing was making things worse. You don't mess with Brook's law!
  - knightofmars 10y ago
    I second this. Additionally, get a grip on your queues! I have yet to find a better text on how to properly manage software projects than, "The Principles of Product Development Flow: Second Generation Lean Product Development"[0]. [0] https://www.amazon.com/Principles-Product-Development-Flow-Generation/dp/1935401009 https://www.amazon.com/Principles-Product-Development-Flow-G...
  - deleted 10y ago
SilasX 10y ago
I'm not sure you agree with the parent if the parent is saying "no, it's not possible, because the tech is so hard", and you're saying, "it's not an issue of technology, but the business side".
notyourwork 10y ago
> Internalizing that has been difficult for me as an engineer. I suspect this is because everyone wants to not only feel as part of something but they want to make an important contribution. I venture to guess accountants at Google do not feel they make a difference to search. The culmination of parts is what makes the company whole and all those parts are required. Its hard to accept you are not as important as you wish you were. Its a great step in the maturation process of one's professional career though.
kelnos 10y ago
> The tech is necessary, of course, but so are desks and an accounting department. > Internalizing that has been difficult for me as an engineer. After I got over that particular hurdle, I would still think: Ok, so "build it and they will come" is not a thing, got it. But still, engineering is most important by far. Without sales, support, marketing, or legal, you still have a product, just one that is adopted slower. Without engineering you don't even have a product to sell in the first place. And that's true. But in the end it's just splitting hairs. It doesn't matter. Over the longer term, no successful, scalable business is ever going to exist solely as an engineering team. Every job function has a purpose[0] and gets you where you want to go faster; in some cases, lack of certain non-engineering job functions will make it impossible to even do certain things. So sure, you can bootstrap a product with just a few engineers and nothing else, but unless you're ok with it being a niche-market product that you spend all your waking hours working on, an engineering-only org is never going to cut it. [0] With the obvious exception of those people hired to satisfy the latest management fad du jour, or to give the CEO's deadbeat nephew something to do with his time.
throwmenow_0139 10y ago
I thought like those junior devs for a while, too, and I agree to your sentiment. The feeling that the CEO I was working with was doing mundane tasks was astonishingly - he even said that he could to his whole job using his smartphone. But after trying to do the business stuff myself I realized that no one in all of this process is irreplaceable - finding a good software developer may not be easy, but it's also not easy to find a good CEO. This is important to realize that software developers shouldn't see themselves as some type of elite. The main problem is that junior devs don't realize that 90% of business is based on networking and being friends with people who are in middle management and want to increase their reputation in their big corp. You don't get big clients because you're a genius hacker, most of the time those B2B applications are simple CRUD apps. You won't get that $500k because you simply didn't play golf with the key partners. I'm not even exaggerating, I've seen that the best deals are made in ones "spare time". Maybe startups are another breed than the software companies I know, but don't drink the cool aid and don't assume that technology is your main differentiator. It's working with people all along. I think it isn't even about scaling high-performance systems, it even starts with the mindset of those who think that software developers are entitled in some way, usually junior devs and people who never did any real business work.

by rfrey 10y ago

malux85 10y ago

I know - but I was talking to a junior engineer, and I was concentrating on the technical aspects to inspire him. I expected him to go off and actually attempt building it, that way he would get some more experience. And he did! He went off that weekend and wrote a proof of concept route planner, it was great to see him learn something new and complex

Shivetya 10y ago
many a junior engineer who persist on the idea its easy, can be done quicker, cheaper, and such, also rarely have the needed dedication to see it through especially when it takes longer than expected, missing requirements are identified, and such. I have seen multi million dollar projects hit the same snags, horribly under scoped all because Mr Easy didn't think about asking all of was needed. They saw the tree and missed the forest
- paulmd 10y ago
  Proper project scoping (or to rephrase: identifying the true core business needs) is truly one of the hardest problems in tech. Over-scoping makes you end up with a ponderous system that doesn't serve core business needs very well, while underscoping can lock you into poor initial decisions that cripple your ability to expand into other related functionality. What's the expression? "Plan your system for 100x growth, but build your system for 10x growth". Something like that except for functionality rather than scalability. That and supporting the system. Junior engineers tend to think about building the tech, which is honestly the easy part. Keeping it working until the last of your customers are finally ready to upgrade 10 years later is harder than junior engineers tend to think.
  - LouisSayers 10y ago
    Ha!even this sounds like a mistake to me. How about "Make the simplest thing work for one person.". Make sure they get some value, and then iterate and repeat. Once you've clearly solved the problem at hand then start to scale, optimise etc That is of course all after you've presold the solution. I know it's not always easy to do this, but that really is part of the challenge. There's still too many deathmarch projects lead by people trying to do things 'the right way'. If you're working on a new project for the love of science, please make sure you're releasing something valuable every single week if not every one or two days!

api 10y ago

Sometimes it is the tech... just not in obvious ways. You have to look beyond the basic spec. Uber and Lyft are not just taxi apps. They are massively polished. When I use them I am astounded at how good they've gotten the UX and then I shudder at how hard that must have been across two mobile platforms and in the presence of very unreliable networks. I've ordered an Uber with no cell Internet using barely usable coffee shop wifi from a block away. Then you have scaling, which brings up or creates issues you just do not see at smaller scales. Big O type considerations and weird edge cases that only come up once every billion transactions start mattering. Then there is all the big data stuff. These services do tons of route optimization and analytics. So yeah marketing, sales, fund raising, management, etc. also matter but tech often matters as much or more. It's just that junior engineers usually only see the tops of icebergs. This is why despite decades of pure biz people saying "tech doesn't matter" you still rarely see founding teams succeed without at least some tech founders but you do occasionally see even lone tech founders make it. (But those tech founders do have to know or be willing to learn the non tech stuff!)

shubhamjain 10y ago

> Internalizing that has been difficult for me as an engineer. Technology exists largely to accelerate the pace of development and of course, it's never a sole driver of any business. There is no reason why you can't create a small-scale uber with call centres and excel spreadsheets but I doubt it would reach the scale and impact of what Uber is today. Granted that, it's hundred times easier to figure out to technology than business, I won't trivialise role of engineering because it's something allows a business to near its global maximum.

danenania 10y ago

It has a lot to do with the technology. It's not the only or even the most important factor, but it's still one of the most important. I think a big part of the disconnect being discussed originates in the myth that CRUD-based apps are fundamentally easy. This simply isn't true. The challenges of building a modern, complex, scalable CRUD app with good UX and a maintainable code base are not 'less than' challenges rooted in algorithms or bit bashing. Doing it well enough and fast enough to be competitive in the market is HARD.

mbesto 10y ago

> The success of many companies, and probably all of the unicorns, has nothing to do with technology. This is 100% true and unfortunately gets distorted from the financial backers who pump them up for unicorn status. Quite a dichotomy: "Software is eating the world!" "The hard thing isn’t setting up an organizational chart. The hard thing is getting people to communicate within the organization that you just designed."

0xdeadbeefbabe 10y ago
> The success of many companies, and probably all of the unicorns, has nothing to do with technology. So why not look at failure then?
- dragontamer 10y ago
  Its harder to learn from failures than to learn from successes. Success has the false-positive issue. Failures have the false-negative issue. Cargo-culting false-positives is going to be less harmful than cargo-culting false-negatives. (X Company didn't use stack-ranking and then failed. Clearly stack-ranking is bad for companies)
  - 0xdeadbeefbabe 10y ago
    Maybe. Just to muddy things even more, some successes are failures. Have you ever met a billionaire who said, "I was lucky" and left it at that?
  - richie5um 10y ago
    Yeah. At least with a success you have a data point that it could be successful - with a failure, you don't even know that.
- michaelbuckbee 10y ago
  It's not the technology success/failure axis in question, but how much weight to give it relative to other factors. AKA in predicting overall success would a team with low tech expertise, but high sales expertise be have a better chance?

n_time 10y ago

> The success of many companies, and probably all of the unicorns, has nothing to do with technology Have you considered broadening your personal definition of technology past computing and engineering? From Wikipedia: > Technology can be the knowledge of techniques, processes, etc. or it can be embedded in machines, computers, devices and factories, which can be operated by individuals without detailed knowledge of the workings of such things. Technology is the creation of systems. Those systems run as much on the users of that technology, and the members of the organisation supporting it, as they do inside of microprocessors.

markonthewall 10y ago

>The success of many companies, and probably all of the unicorns, has nothing to do with technology. Most of the unicorns are founded with engineering talent coming straight from Stanford, MIT, Harvard, UCB, Waterloo etc. you name it. Making a company successful is as much about economics of scale than raw engineering and of course, both are closely related in this day and age. Engineering shapes what and how your products feels like in real-time (= understand very short code-to-production lifecycle). It might not be politically correct to say but I am not here to make you feel better. Anyone who has actually been in a team at a company that has exponentially grown will tell you the same: your chances to ever survive that "first wave" of users is directly proportional to your ability to hire the best, which of course is a lot easier when they are your current or former classmates. That's not to say there aren't companies founded by people not going to the schools mentioned above or that engineering talent is only available at these places. It is obviously not the case. However, the density of talent at top-schools is absurdly high. And this is a game changer for most early stage companies and even more so for soon-to-be-unicorns.

wangchow 10y ago
Probably why a lot of professors say that University is often about networking opportunities just as much as it is about learning. But aside from knowing talented people, it takes visionaries to generate fantastic outcomes. Walt Disney for example stopped drawing cartoons himself early on because he had better artists around him. However, he had the vision that ultimately brought the best out of each artist.

jcoffland 10y ago

> The success of many companies, and probably all of the unicorns, has nothing to do with technology. Execs love to think this but it's just not true. Top heavy companies waste money. It's true that tech of not the only ingredient but for a tech company it's critical. Good tech is not a commodity. Top-tier engineers are worth as much as a good CEO. That is if you want to remain lean.

bunderbunder 10y ago

At a previous job, we had serious development bandwidth issues. The company was trying to solve that by hiring more developers, and all it was doing was making things worse. The root cause of the development bandwidth problem was that we wasted vast amounts of time and energy on building misfeatures. And we built so many misfeatures because we had way too much development capacity in relation to our product planning capacity. So the BAs didn't have enough time to fully develop ideas before sending them to engineering, and were instead stuck throwing things over the wall when they were still half baked. All these half-baked ideas took time to build, and then they took time to fix after they bombed on the market, and they slowed everything else down since every new feature is something you have to ensure still works when you make a change in that part of the software. Day in, day out, we were taking on technical debt to cover our design debt bills. So then we tried Agile, and man oh man did that make things worse. 'Cuz now instead of just lobbing things over the wall, the BAs had to be actively involved in every sprint. There goes any opportunity to sit down and concentrate, because now you've got a nattering horde of 20 developers all trying to get clarification on last week's decisions, which leaves less time to make this week's decisions, which means next sprint things will be even more sketchy and ill-defined. The correct solution would have been to hire more business analysts, and they key thing we needed from those business analysts wasn't instructions on what to build. It was instructions on what _not_ to build.

amag 10y ago
> The company was trying to solve that by hiring more developers, and all it was doing was making things worse. You don't mess with Brook's law!
- knightofmars 10y ago
  I second this. Additionally, get a grip on your queues! I have yet to find a better text on how to properly manage software projects than, "The Principles of Product Development Flow: Second Generation Lean Product Development"[0]. [0] https://www.amazon.com/Principles-Product-Development-Flow-Generation/dp/1935401009 https://www.amazon.com/Principles-Product-Development-Flow-G...
- deleted 10y ago

SilasX 10y ago

I'm not sure you agree with the parent if the parent is saying "no, it's not possible, because the tech is so hard", and you're saying, "it's not an issue of technology, but the business side".

notyourwork 10y ago

> Internalizing that has been difficult for me as an engineer. I suspect this is because everyone wants to not only feel as part of something but they want to make an important contribution. I venture to guess accountants at Google do not feel they make a difference to search. The culmination of parts is what makes the company whole and all those parts are required. Its hard to accept you are not as important as you wish you were. Its a great step in the maturation process of one's professional career though.

kelnos 10y ago

> The tech is necessary, of course, but so are desks and an accounting department. > Internalizing that has been difficult for me as an engineer. After I got over that particular hurdle, I would still think: Ok, so "build it and they will come" is not a thing, got it. But still, engineering is most important by far. Without sales, support, marketing, or legal, you still have a product, just one that is adopted slower. Without engineering you don't even have a product to sell in the first place. And that's true. But in the end it's just splitting hairs. It doesn't matter. Over the longer term, no successful, scalable business is ever going to exist solely as an engineering team. Every job function has a purpose[0] and gets you where you want to go faster; in some cases, lack of certain non-engineering job functions will make it impossible to even do certain things. So sure, you can bootstrap a product with just a few engineers and nothing else, but unless you're ok with it being a niche-market product that you spend all your waking hours working on, an engineering-only org is never going to cut it. [0] With the obvious exception of those people hired to satisfy the latest management fad du jour, or to give the CEO's deadbeat nephew something to do with his time.

throwmenow_0139 10y ago

I thought like those junior devs for a while, too, and I agree to your sentiment. The feeling that the CEO I was working with was doing mundane tasks was astonishingly - he even said that he could to his whole job using his smartphone. But after trying to do the business stuff myself I realized that no one in all of this process is irreplaceable - finding a good software developer may not be easy, but it's also not easy to find a good CEO. This is important to realize that software developers shouldn't see themselves as some type of elite. The main problem is that junior devs don't realize that 90% of business is based on networking and being friends with people who are in middle management and want to increase their reputation in their big corp. You don't get big clients because you're a genius hacker, most of the time those B2B applications are simple CRUD apps. You won't get that $500k because you simply didn't play golf with the key partners. I'm not even exaggerating, I've seen that the best deals are made in ones "spare time". Maybe startups are another breed than the software companies I know, but don't drink the cool aid and don't assume that technology is your main differentiator. It's working with people all along. I think it isn't even about scaling high-performance systems, it even starts with the mindset of those who think that software developers are entitled in some way, usually junior devs and people who never did any real business work.