Sign in / up

back to article Your CIO is now a venture capitalist and you work at their startup

Chief Information Officers are about to start behaving like venture capitalists, complete with an “I don't care if nine things I try fail so long as one goes really well” mentality. And what's more, their bosses will love it when they do so. That's one of the findings from consultancy Deloitte's 2014 Tech Trends report, …

COMMENTS

House rules Send corrections
This topic is closed for new posts.
  1. Pete 2 Silver badge

    The wrong people in the wrong place

    > a willingness to engage in small, experimental, IT projects rather than the larger endeavours

    I have only worked in one startup - and that hit the wall after 6 years.

    However, comparing the attitudes there with those in larger, established companies I can't see the concept of "internal VC-ing" working very well.

    For a start, the factors that attract workers to large companies: stability, lack or slow change, lots of structure guidelines processes and procedures and a nice easy 9-5 are not the features you get in startups. You also find that a lot of the large-company workers are willing to trade a lower salary and prospects for all the factors listed above - plus a pension.

    In startups you want exactly the opposite sort of individual: self-starters, working 5 - 9 (a.m. to p.m), a JFDI attitude to problem-solving, and no two days being the same. People who thrive in that sort of environment will not usually be found working for MegaCorp. (They'll in the industrial unit down the road).

    And finally you have the shareholders. People who invest in large, stable companies want large stable returns - not a 90% failure rate. So it might be trendy for CIOs to embrace failure and be able to excuse it with one, occasional, win. However, would they last long enough in the position to deliver that one win in ten? And if they were "VC" material, they'd probably use the large company as a training ground - financing all their costly mistakes and then when the success does come along, be off like a shot "to spend more time with their money" and open a startup of their own.

    If large companies want innovation and want it quickly, they usually simply buy the relevant VC-funded startup and assimilate their technology. Much less risk, appears on the books as "growth" and can you can see what you're getting into before you open your wallet.

    5 1
  2. Ken 16 Silver badge

    self-serve checkouts example?

    “Retailers have done several generations of self-serve checkouts. The customers who appreciate that have enjoyed being a part of that.”

    Please provide detailed references on which customers have enjoyed being told to take their bag out of the bagging area before quoting that chap as an authority on anything.

    11 1
    1. P. Lee
      Reply Icon

      Re: self-serve checkouts example?

      Worse is the voice-based gratuitous self-advertising: "Thank-you for shopping with ..." constantly being repeated by the checkouts. It makes me want to scream, "I hate you! I hate this shop now far more than when I walked in! I regret whatever impulse made me come in here!"

      4 0
      1. frank ly
        Reply Icon

        Re: self-serve checkouts example?

        Is it wrong of me to start giggling when it says, "Please wait; the assistant is coming." ?

        4 0
  3. jake Silver badge

    Whatever.

    I never met a CIO that grocked technology. CIO and senior member of the technical staff are completely different thingies.

    0 2
    1. Anonymous Coward
      Reply Icon
      Anonymous Coward

      Re: Whatever.

      You're lucky. I have...and he's ex-NSA.

      1 0
  4. Novex
    Holmes

    This is old news. Back in 2006-07, I was involved on a project for an NGO that was doing 'small, innovative and a bit risky' that was welcomed by the users, until the powers that be decided to outsource everything to Indian-offshored big I.T. suppliers. Apparently the users hated the result of that offshoring because all the responsive work we were doing at our small scale was effectively killed off by the bureaucracy of the outsourcers. Oh, and while I'm at it, we were also doing three month release cycles back then too. Funny that Google and Mozilla decided to 'follow our lead' ;)

    3 1
    1. Matt 21
      Reply Icon

      ...and you in your turn were copying something we were doing in the early 90s and I doubt we were the first either!

      1 0
  5. Corinne

    "..... is a recognition that legacy systems effectively impose a debt on an organisation. The overheads associated with keeping old apps alive impose costs on a business and also hinder its ability to change quickly.

    “If you implement a major piece of physical infrastructure, full lifecycle costs are in the accounting treatment,” he said. “We don't do that in IT so we use misleading return on investment calculations.”

    I'd quite like to know what projects he's been working on, as I never found this. In my experience organisations fall into 2 camps - projects that must pay for themselves in cold hard financial terms, and those who don't.

    Those who don't may track project costs, but haven't done a full CBA at the start of the project at all, just a costs estimate. Those who DO require financial payback from a project perform a proper full Cost Benefit Analysis right from the start which usually has a section on lifetime running costs including maintenance, and a comparison with the "do nothing" option which should always be part of a project proposal or feasibility study. This isn't just a tool for big monolithic projects, but can be scaled right down for even the most piddling little projects - only time it isn't really worthwhile is for stuff coming in under about £50k.

    5 0
  6. P. Lee

    "legacy systems effectively impose a debt on an organisation"

    and change is massively expensive.

    Whaddayaknow? Stuff costs.

    Actually that's not true. I don't think these people know what a debt is. The older an app is, the longer you've had to amortise the cost leaving you debt-free. Once you've paid for the app, you have a sunk cost, but not debt.

    Unless you use Office365 and you've got macros as your business process. Then you can have an old application and still have to pay for it every year. Whoohoo!

    I reckon batch-processing is the way of the future. It's incredibly cheap because it is very efficient and very easy to programme. Massive amounts of money go on gui's for real-time apps. Just Say No! ;)

    1 1
    1. Corinne
      Reply Icon

      Re: "legacy systems effectively impose a debt on an organisation"

      "The older an app is, the longer you've had to amortise the cost leaving you debt-free. Once you've paid for the app, you have a sunk cost, but not debt."

      Not strictly true. The older an app is, the more chance that it's no longer fit for purpose because a) there may be legislative changes (think financial services) or b) the world has moved on. To update or add to the legacy apps can be a tricky business as usually the underlying OS and/or supporting software have been changed over the years, so everything needs to be updated to the latest version. Which usually has it's own quirks that have to be allowed for leading to a complete rewrite. Even minor updates can be troublesome as for very old software there are fewer and fewer people who are experts.

      Add in to that the complexity of a system that's been added to and tweaked multiple times over the years to allow for necessary changes, or even things some marketing wonk thought were a good idea at the time, with maybe imperfect documentation of the changes, and suddenly you can have a complete nightmare on your hands.

      1 2
      1. Trevor_Pott Gold badge
        Reply Icon

        Re: "legacy systems effectively impose a debt on an organisation"

        You think financial systems. I think industrial control systems. When your industrial hardware is 35 years old then a 35 year old piece of software is still entirely fit for purpose.

        Comparing the Allan key to the socket wrench doesn't help much in the real world. IT is huge. So many tools exist, each for their own purposes and each with their own lifespans. I need to replace drill bits on a regular basis; some times several times a year. But that old clawhammer that my dad bought when he was a teenager still works exactly as intended.

        0 0
        1. Corinne
          Reply Icon

          Re: "legacy systems effectively impose a debt on an organisation"

          Which is why you do a CBA for any proposed change. I hate change for the sake of it, there has to be a genuine reason why you do it other than "but it's the new trendy in thing this month" or "everyone else is doing it".

          In the case of the industrial control systems or the claw hammer, the existing tool is fit for purpose and you wouldn't get any benefit from changing it. In the case of somewhere like a retail environment, if the competition has carried out an upgrade that has brought them more customers then chances are the change is worth doing. So all very dependant on the circumstances like so many things.

          0 0
        2. James 100
          Reply Icon

          Re: "legacy systems effectively impose a debt on an organisation"

          That's fine as long as nothing at all changes - and you don't get bitten by Y2K-type bugs. If that 35 year old system's connected to a network, though, you need to consider security - which is exactly why so many places are panicking about SCADA security now, because a lot of those systems aren't as isolated as people assumed decades ago - or they were isolated once, but need to integrate with other systems now.

          Can you actually get parts for that 35 year old computer now? The guy who set up your code 35 years ago probably isn't going to be working much longer, even if you can still get hold of him. I knew someone a while ago working on moving a factory control system from a big old Vax with a hundred serial ports (each connected to a different bit of the production line) to a Linux machine with Ethernet-serial converters. (They did actually retain the code, but updated for the new platform.) Of course, he's retired now - and will that code still run properly a decade from now on future Linux systems? Sooner or later, it'll need another update.

          0 0
This topic is closed for new posts.