Time to Market: Where Business Meets Technology


Time to Market: Where Business Meets Technology

Trained engineers like me love to use all the new technologies evolving basically each day. Continuous Deployment, Docker, K8s, Isito – fill in any other current buzzword – solve problems on different levels of our engineering process making us move faster and faster. They automate tasks (we hate repetitive things anyway), ensure better quality e.g. due to reduced manual errors or make our environment more resilient. But, if you do it for a living, developing software is not a purpose on its own. It must generate business value to pay our salary. For it is obvious that using all that technology and tools improves a lot of our day to day work. Nonetheless, there are lots of managers, salespeople, etc. (on all corporate levels up to the top) who miss some of the biggest benefits which we can provide for them by using all our loved tools. This blog post is for all of you who struggle to convince your boss and supervisors of all the advantages of a working ecosystem composed of modern technology, agile methods, and modern organisation structure.


Building an ecosystem

In the end, technology, method and organisation structure are just a vehicle which is used to deliver products with value to our customers. We want to deliver fast and in good quality providing the right features. In fact, we try to minimize time to market to provide value to our customers as quickly as possible. Years ago, there always was the choice to deliver quick and dirty or slower and in better quality. There is no longer a trade-off between delivering fast AND in good quality. Good companies achieve both due to high automation and modern technologies which are applied alongside cross-functional teams to ensure ownership. Everything must work together smoothly. There is no point in buying a race car (high initial expensive and fast, e.g. microservice architecture) and driving it at a speed of 5 km/h (e.g. long release cycles of several months, no agile development or slow requirements engineering without customer feedback which is applied to improve the products).

You are only as fast as the slowest part of your process which you obviously must tackle first. Cross-functional teams (#DevOps) provide a good approach to have everything needed for functional ecosystem by having everyone in one place. These teams must be enabled to solve all their problems on their own starting with requirements engineering to running their systems. Often, dependencies are a problem – in a technical manner or within the organisation. These figures can be both a view of an organisation, or an IT system. Problems will stay the same.

Would you rather change or add something in figure 1 or in figure 2? Where do you think it is easier to get things done faster and with less trouble? Moreover, these systems tend to have some overloaded nodes. As engineers, we know how systems under load behave:


At some point, the system performance does not degrade linearly with load anymore. At a certain point it literally breaks. This is also true for people in an organisation. Compare the two figures applied to people and to services. They look pretty much the same. If the utilisation is going too high, everyone must wait long for answers. Combining this with lots of dependencies, everything is slowed down having each node (system or person) waiting for another one. There is a great article about this topic published by HBR.


Waiting costs your money

The costs of code that sits around idle in the repository are a thing that some managers get wrong. Imagine a new feature that has been developed ready for production within only weeks. When ready it just uses up disk space in the GIT repository while waiting to be deployed in production for two months. You’ll end up with a clear lose-lose situation for you and the customer. You have invested money that does nothing – it does not create any value for you and even worse it does not create value for the customer.

Would you buy your new sports car two years prior to being able to use it? There are some points wrong with this behaviour:

  • It does not generate value for your customer
  • It costs your money (you could have done something different with it that would effectively generate revenue -> opportunity costs)
  • There is no feedback from your users – did you develop the right feature?
  • It gets even worse: you build the wrong stuff and other features depend on it – in the end, you can trash both
  • The market and your users move within these two months – it may well be that the feature has no market fit anymore
  • Code is not like good wine – it does not get better at age – you need to maintain code that does not even generate value (technical debt)


So, speed up.

  • Keep your team utilisation at 80% maximum! It will allow you to provide room for unplanned work and to improve response times.
  • Reduce dependencies! They are mostly bad – both in your software architecture, and in your organisation. There are better ways to e.g. cover compliance and security topics than routing everything through one point.
  • If there are dependencies, document them well, make them work with older versions or use versioning! APIs and any interaction with other departments – everything else will make you wait for someone else slowing you down.
  • Enable the teams to solve their problems on their own! Given the current technologies, there are ways to give them everything they need to develop and run their services.
  • No trade-offs needed – you can achieve both quality and speed.
  • Get your f*ck out there! Waiting for long manual testing, infrastructure, servers or the full moon does not provide any value. It costs your money. It is 2019. There are ways to fulfil these needs automatically and reproducibly (#InfrastructureAsCode, #DevOps, #Cloud, #CanaryDeployment). Learn to trust them!


Seems obvious? Then remember it next time when someone needs permission for something from you or you have to wait for another department to deliver something! Remember it every time something must be reviewed or approved by some role that does not add any additional value and thus slows you down! Waiting for testing resources from another team? Think about some different approach to testing! Waiting for a test environment because your servers hav not been delivered? Check the cloud!


There is no excuse for not enabling teams and not empowering them with full ownership of their services and products. Topics like security, compliance, testing or infrastructure are solved and can be automated like everything else. Technology combined with the right organisational structure will give your time to market a big boost, reduce costs and increase the satisfaction of employees and customers at the same time. So, now it becomes a Win-Win situation. #NoExcuses


Rene Schakmann, Head of Technology at viesure