5 ms·

It all depends on who you're hiring and what you're building. Definitely applicable to startups and innovators coming up from the bottom. But, there are absolu

It all depends on who you're hiring and what you're building. Definitely applicable to startups and innovators coming up from the bottom. But, there are absolutely companies maintaining low-growth Clunky Java Accounting Application for Insurance Companies #574 for whom this approach is contraindicated. Those companies can hire relatively entry-level, average graduates, at commensurate salaries, and assign them highly structured JIRA tickets. Would they get better talent if their fronds tended more toward the SV model of compensation and autonomy described in the article? Absolutely. But in terms of marginal productivity or ROI, it's far from clear that it makes much of a difference to the financial performance of Cluky Java Accounting Application for Insurance Companies #574. That means massively overpaying for skills, or skill levels, that aren't really needed, or aren't needed enough to matter. No, it's not the kind of software development any of us want to do, and I think the audience for this post are for the most part in no danger of having to. But I think it's important to be honest about the fact that this sort of dimly-lit, cubicle-dwelling sweatshop software work _is_ a high percentage of software development occurring on the planet. For that type of company, following the "SV" philosophy would arguably constitute a dereliction of fiduciary duty. My view may be somewhat coloured by my exposure to medium to enterprise-sized companies in the telecom world, where a lot of the work is tedious, unimaginative and formulaic, using unexciting but established technology stacks, and so forth. But it still needs to be done, and there are companies who darken the skies with people to do it. Lastly, I incorporate by reference everything that has been said elsewhere in this thread about the nature of large organisations and the poor scalability of engineering-led company process. Most software work, by volume, doesn't consist of skunkworks innovation or the development of something new. Most software work is incremental, in many cases strictly maintenance mode, and caters to many stakeholders. Large organisations and big capital serve an entirely different purpose that is realised at points further along the technology and product lifecycle. In this comment, I merely chose to focus on (1) the problems of empowering "average" talent this way and (2) the poor prospectus for doing so.

jtdev 6y ago
Those companies will die...
- bigiain 6y ago
  I don't think so. At least not all of them. Agile is not always the right approach. For highly regulated or safety critical industries, it's quite likely to be the wrong approach. (On the other hand, Waterfall for B2C mobile apps or casual games is also almost always the wrong approach too...)
- abalashov 6y ago
  It's probably easy to believe that if you're developing a SaaS app on the Pacific Coast, but in actually-existing reality -- no, they won't. Their business processes and products are often sclerotic, and so are vulnerable to disruption by smaller, more nimble startups. That's the central premise of virtually all B2B software from the Valley. But they certainly aren't going to die. In fact, large companies and enormous capital are required to take things from a "disruptive innovation" to a household name, to say nothing of providing an exit for SV startups. So, they're a vital part of the biosphere and they're not going anywhere.
  - andrewjl 6y ago
    > In fact, large companies and enormous capital are required to take things from a "disruptive innovation" to a household name, to say nothing of providing an exit for SV startups. I think this is becoming less and less true, unless one is competing with the tech giants directly. In the past enormous capital investment was required to build out the minimum viable capacity needed to serve larger customers or market segments. Today you can rent that capacity. In the future more and more types of capacity can become rentable, such as logistics, compliance, manufacturing, etc.
    - abalashov 6y ago
      To make many things a household name, one has to compete with the giants directly. I am not necessarily referring to the 'tech' economy. Most uses of tech are not in the 'tech industry' itself but to fulfill ulterior aims in other sectors.
- sidlls 6y ago
hnick 6y ago
I feel like the article is mostly written from a product perspective. I worked in an area that was billed out by the hour, it was just complicated enough to require developers to do the work, but the work pieces were very quantifiable (add text to say xyz based on a business rule, show different images based on a rule, etc). It meant graduate programmers, immigrants with limited English skills, or others without much talent or drive would end up there. It's a good safe role for someone who just wants to get paid and go home on time (usually). It was very much a factory in the way the article says, but I feel like it has to be because of the nature of the work. I did talk to customers directly on larger projects but since I was building on top of internal systems and processes my role was mainly implementation/glue coding. Most of my frustrations were with our internal dev and IT who built and maintained the systems - over time they became more walled off, not less, which definitely impacted our work. And unfortunately as we were more 'client facing' any outages came back to bite us, not them, which was an annoying organisational dysfunction. They simply weren't incentivised to care as much as we were.

jtdev 6y ago

Those companies will die...

bigiain 6y ago
I don't think so. At least not all of them. Agile is not always the right approach. For highly regulated or safety critical industries, it's quite likely to be the wrong approach. (On the other hand, Waterfall for B2C mobile apps or casual games is also almost always the wrong approach too...)
abalashov 6y ago
It's probably easy to believe that if you're developing a SaaS app on the Pacific Coast, but in actually-existing reality -- no, they won't. Their business processes and products are often sclerotic, and so are vulnerable to disruption by smaller, more nimble startups. That's the central premise of virtually all B2B software from the Valley. But they certainly aren't going to die. In fact, large companies and enormous capital are required to take things from a "disruptive innovation" to a household name, to say nothing of providing an exit for SV startups. So, they're a vital part of the biosphere and they're not going anywhere.
- andrewjl 6y ago
  > In fact, large companies and enormous capital are required to take things from a "disruptive innovation" to a household name, to say nothing of providing an exit for SV startups. I think this is becoming less and less true, unless one is competing with the tech giants directly. In the past enormous capital investment was required to build out the minimum viable capacity needed to serve larger customers or market segments. Today you can rent that capacity. In the future more and more types of capacity can become rentable, such as logistics, compliance, manufacturing, etc.
  - abalashov 6y ago
    To make many things a household name, one has to compete with the giants directly. I am not necessarily referring to the 'tech' economy. Most uses of tech are not in the 'tech industry' itself but to fulfill ulterior aims in other sectors.
sidlls 6y ago

hnick 6y ago

I feel like the article is mostly written from a product perspective. I worked in an area that was billed out by the hour, it was just complicated enough to require developers to do the work, but the work pieces were very quantifiable (add text to say xyz based on a business rule, show different images based on a rule, etc). It meant graduate programmers, immigrants with limited English skills, or others without much talent or drive would end up there. It's a good safe role for someone who just wants to get paid and go home on time (usually). It was very much a factory in the way the article says, but I feel like it has to be because of the nature of the work. I did talk to customers directly on larger projects but since I was building on top of internal systems and processes my role was mainly implementation/glue coding. Most of my frustrations were with our internal dev and IT who built and maintained the systems - over time they became more walled off, not less, which definitely impacted our work. And unfortunately as we were more 'client facing' any outages came back to bite us, not them, which was an annoying organisational dysfunction. They simply weren't incentivised to care as much as we were.