Paul Hammant's Blog: Engineering led companies
Google again. Second time today.
Google is fascinating in that they transitioned from startup in the middle of the dot-com bubble to viable business (with the advent of ad revenue) in the early 2000’s without the founders giving away power. More, the founders are developers, though probably post-technical by now. In 2017, Google remains a technology company with business people onboard.
Most companies with a software development capability are businesses first and technology second. There’s a bunch of thinking around that, and some discussable examples like “is Uber a transport company or a technology company”?
So in regular businesses that consider technology to be unfortunate overhead rather than a differentiator, there is a risk that business will control software development and delivery to production in such a way that costs are higher. I am going to paint the worst example of that. The company does some form of trading and there’s a thing that needs to go to production, but there’s a problem. We’ll say the problem is “time”, and that the business person at some level above the software dev and ops teams is yelling “just fucking put it live” at some critical moment. Imagine that person standing up and finger waggling, with spittle flying. Imagine a wider group of people in the open-plan area around that are incrementally conditioned by hearing that outburst. In many business-led companies, IT-involved business people will prevail on engineering topics, and the org becomes characterized over time. Characterized to secretly accept cynical beliefs like “developers will take as much time as you give them”, or “testing is an overhead that comes after development and can be trimmed, especially if we tell developers to get better at estimating and take greater care not to write bugs”. Characterized to look at ways of hiring for cost not talent, including sweeping aside poly-skilled contributors for rigid mono-skilled people. Kevin Behr (my old CIO) called the effect “trader voice”, which is not to castigate an entire profession but to highlight the colorful language when used amongst the software engineering and IT folks re their science.
(Note: not all people that shout in the workplace are psychopaths, and not all psychopaths shout in the workplace)
Anyway, so what happens when “trader voice” happens inside a business led IT operation? Not enough to ensure that it doesn’t happen again. Same question but in an engineering led company like Google? The incident gets bumped higher and higher until a techie (Larry and Sergey if needs be) says “We don’t allow ‘trader voice’ to be used generally here. Especially to short-cut process, methodology, and rigor. You know, things that have been designed to ensure the best quality and ultimately the smallest overhead for the company”. That smallest overhead - provable via big data in Google. The rest of us - we have to explain it over and over as best we can, citing books, articles, established practices and so on.
From a business point of view, be thankful that Google isn’t in your vertical. From a development point of view - wish they were and that you worked for them (with options), though you might have to be deprogrammed yourself.