13 ms·

I've never worked for a true unicorn but I've been in companies that got a sudden success and grew way too big way too fast. I think you can tell from the insid

• sandworm101 6y ago
  >> You have man-years worth of work going nowhere as projects get scrapped mid-development. That's better than seeing man-years go into features that get deployed. I witnessed one successful control system company spin up a team of new hotshot UI engineers, all right out of the best schools. After months of work the team "updated" the product. Withing hours the call center was hit with hundreds of "You changed the g-dam menus!! Put them back NOW!!". The trick is to squeeze your long-term UI project in the same update as some routine security fixes. Then the clients are forced to learn the new system.
  • staticassertion 6y ago
    Or do A/B testing and incremental rollouts?
    • brianwawok 6y ago
      A/B tested products are terrible. Please don’t do that to an actual product people pay money for. “On this page, 12% more users clicked save if the save button was green instead of blue”
      • staticassertion 6y ago
        Bad A/B testing is bad. Incremental rollouts are not bad.
  • seankimdesign 6y ago
    That's more of a failure for the ux and product vision than it is a failure of project management. The trick isn't to just roll out new changes slowly, but to involve the users and figure out what needs to change and how.
    • sandworm101 6y ago
      >> roll out new changes slowly. That really depends on your customers and the product. In this case, control systems, incremental changes are definitely not the way to go. Imagine if your car made an incremental change to the position of the brake pedal every time you turned it on. In such situations you don't babystep. You announce the change ahead of time, provide your customers with transition training, and make the change as scheduled. In the case of "adaptive" menus in control systems, imagine if the elevator in your building rearranged its floor buttons so that the most requested floors were always at the top. Total chaos. People learn where their button is on day one. After that ANY change is going to go badly no matter what the UI engineers say. That UI should be carved in stone for the life of the building.
      • jdhn 6y ago
        Were there any dedicated UX people involved? To me, a UI engineer is someone who works exclusively on the front end, and would implement the work of the UX designer. They wouldn't actually do the designing and research themselves.
    • Drakar1903 6y ago
      This is one of those cases where that Ford quote about a faster horse is relevant. Many people will be happy to just have what they have now without thinking how it could be better.
  • matt_morgan 6y ago
    I'm not saying anything about anyone's intent, but replacing "man-year" with "person-year" is a painless, traditional-grammar-friendly way to go gender-neutral.
    • lumberingjack 6y ago
      You need to me more accepting of people words what he said was fine maybe he prefers traditional grammar and you just need to accept people
    • irthomasthomas 6y ago
      I presume all the developers are men? as in members of mankind... All people are men.
      • arcticbull 6y ago
        This is going to sound stupid but at some point, it's less important what's right and more important how something makes people feel.
        • SenorSourdough 6y ago
          Language is fluid. The thing that was "right" to say 500 years ago wasn't right 100 years ago, and what was "right" 100 years ago wouldn't be right now. There are clear arguments for why encouraging people to think about the gendered language that they use and how it perpetuates gender roles would be beneficial in combating sexism. The arguments for maintaining existing language because it is currently the most popular tend to be pretty thin.
        • wolco 6y ago
          When you move into how people feel are we introducing inequality? People feel at different rates. Some can go into a rage in an instant while others can be a rock. Are we rewarding the primate brain over scientific obvervations when we choose to accept personal feeling as the gold standard? Should we be encouraging one over the other?
      • 6y ago
  • bashinator 6y ago
    > The trick is to squeeze your long-term UI project in the same update as some routine security fixes. Then the clients are forced to learn the new system. Is this sarcasm? Seems like a really user-hostile attitude if not. Admittedly, my personal point-of-view is that the majority of UI updates are make-work for engineers and PMs with at best no value added, and at worst negative value created (as you experienced).
    • thejynxed 6y ago
      It's a funny joke because everyone from Microsoft, IBM, and Apple to Canonical and the GNOME Project has been guilty of this in the past.
      • bashinator 6y ago
        Oh god you're right
  • mschuster91 6y ago
    > The trick is to squeeze your long-term UI project in the same update as some routine security fixes. Then the clients are forced to learn the new system. Fuck people doing this. Especially extremely radical design changes such as Twitter's and Facebook's "redesigns" that they force down the throats of their users. Or Microsoft.
  • rockostrich 6y ago
    > The trick is to squeeze your long-term UI project in the same update as some routine security fixes. Then the clients are forced to learn the new system. No, the trick is to iteratively change the UI in a way that's easy for the user to get used to.
• specialist 6y ago
  "...you can tell from the inside when a company loses its way." Those example pathologies you listed are SOP at all the mature orgs I've worked at.
  • wrkronmiller 6y ago
    Do you think the degree to which a company succumbs to one of these "pathologies" matters? Is it a matter of timing (i.e. becoming successful faster than they become moribund)? What do you think differentiates a company that becomes "mature" vs one that flames out?
    • freeone3000 6y ago
      Mature companies, notably, make a profit. Not a future profit, not an expected profit, not profit-discounting-advertising, a right-now end-of-year no-accounting-tricks more revenue from sale of goods than expenditures from all sources. I'm going to take a page out of the IRS handbook, and say that they have made a profit for the last three out of five years, in fact. Let's take that a step further and say that they've existed for five years. Their primary method of financing operations is not private equity, but public equity or loans. Once a company looks like this, it's pretty well set.
• hintymad 6y ago
  Well said. That's exactly what happened to many unicorns, including Uber.
• lumberingjack 6y ago
  Sound like what happened at Intel
• deleted 6y ago
  [deleted]
• closeparen 6y ago
  >suddenly you have tons of teams working on what seems to be fairly niche aspects of the company's product At scale it tends to be worthwhile, even necessary, to engage fully with the complexity of all those "niche" aspects. When you don't understand how something could possibly take so much effort, it's possible all the people working on it are idiots and you could do it better in a weekend. (When you spot situations like that, think of them as startup opportunities...) It's also possible they're doing a good job hiding the complexity from you.
  • munificent 6y ago
    I think there is a lot of truth to both your comment and the parent comment. Everyone underestimates the complexity of systems they aren't personally familiar with. Ask the average person how many parts are in a modern automobile and they'd probably guess too low by an order of magnitude. But it is also true that large organizations get weird when money is easily available. You get a Cambrian explosion where without selection pressure to ensure people and teams do real, useful work, everything starts to seem like a good idea. Determining which organizational complexity is essential and which is accidental is likely the quintessential hard problem of business.
    • neumann 6y ago
      This is a very nice description of what I've noticed moving to a large organisation. There is also a lot of busy work. As the organisation grows, communicating and negotiating between groups requires extra effort that often ends up being the role of a new management level, and groups have self-preserving incentives to stay relevant leading to lots of entropy (busy work, repeated work, hero projects that are just there for internal branding). As someone who has recently been put in this level of management I spend a lot of time having to negotiate out of new project initiatives invented more to attract exec attention or satisfy a rogue execs dream project. Makes me really look forward to moving back to working in a smaller company.
    • ethbro 6y ago
      > Determining which organizational complexity is essential and which is accidental is likely the quintessential hard problem of business. Three questions. (1) "What would the impact on our business be if we built the best possible, state of the art feature here?" (2) "What would the impact on our business be if we half-assed a solution in a quarter of the time?" (3) "What would the impact on our business be if we utterly failed?" (Usually, the different between 1 & 2 is negligible. Sometimes, between 1 & 3. Don't ask people to justify success. Ask them to justify why we should spend any more time than slightly-above-failure.)
• skywhopper 6y ago
  For what it's worth, this isn't unique to unicorns. Almost company successful enough to get to the scale of tens of thousands of employees likely has huge amounts of waste within it. The situation you describe of niche projects being scrapped after several person-years of effort had been invested, incomprehensible management hierarchy, and no coherent strategy perfectly matches my first job out of college, a year at Sprint in 1999. Me and two other new hires spent a year doing next to nothing on a team of 20+ building a complicated Java service with a purpose I never understood, but which had been going on for about a year, with half the team made up of contractors. Pretty sure I never wrote any actual code, though I did have to fill out time sheets every week. I had two managers, neither of whom I ever talked to. After a year, I got a 15% raise and a promotion. Then soon after I found another job and quit, our project got cancelled, but everyone on the team just got moved to other teams doing similar "work".