Breaking Down the Wall Between Tech & Business

On the 28th of October 2021 I had the pleasure to moderate a CTO Roundtable session alongside Daisy Perryer. The main theme of the session was ‘how to break down the wall between agile teams and a business?’ 

During the short introduction round it quickly became clear why the participants were eager to discuss the topic. The group consisted of highly experienced people with, in general, two different paths: some started in tech and switched more and more to product while others made the opposite journey. You could even state that most of the participants are moving continuously in this earlier mentioned gap on a daily basis.

Below is a summary of the topics that were discussed and the conversations that came out of the original talking point. 

Always start with goals

It is only possible to make sure we (IT and Business) talk about the same thing when we make the goals of what to achieve crystal clear. Without having the same understanding of what we want to achieve and who we are doing it for, the chances of the technical solution being the one we need are very uncertain. 

We often need to make sure we delay the tech talk more than we often do. We first have to ensure the strategy, product vision and objectives are clear and understood by each and every person involved before thinking about architecture and functional solutions.

Technical innovation should serve business innovation

A recognised pattern was that there is a tendency to regard technical innovation leading instead of business innovation. This can result in over engineered solutions that have no positive impact to our end users whatsoever. It is so important that in general technology should serve business goals and not the other way around.

Internal techradar

The IT industry is characterized by new shiny tools every day. There is an ancient saga that there are more new JavaScript frameworks than babies being born worldwide on a daily basis. (This could also be something I entirely made up by myself.) From an IT leadership perspective you would like a healthy balance between the benefits of new tech, a proper engineering culture and serving the business goals right. 

A very suitable way to organise this could be an internal techradar. On this radar all used/allowed tech of the company is plotted and you are free to use these. Whenever people have a good argument of how new technology could help business goals they can add this to the radar.

Hypothesis driven development

After creating goals, and making sure we all understand them clearly and concisely, it is important to make sure that there remains a connection between these goals and the solutions. A great way to make sure this connection is and remains there is hypothesis driven development. It is a controlled way of doing experiments. What do we need to achieve and how to measure whether we are effective? Important ingredients here are success/fail criteria and the way we can learn from them.

Hard to validate goals and assumptions

Creating products is about making assumptions on a way to reach your goals a lot. But making assumptions without validating them can be a very bad thing. It’s like throwing spaghetti to the wall but not checking what sticks.

It sounds very logical that measuring the effects of each feature should be measured and followed up but this validation is harder than it sounds. The impact of one feature can be difficult to pinpoint because of other features and other surrounding things. Even the weather or the news could have an impact on how a product is being used. Overall we all would love to validate more but we also have to be honest and see that there are some restrictions.

Do not talk about non functionals

In order to align the technical capabilities of a product with the expectations from a business perspective, there are also requirements that are non functional. Some of these can play a crucial role in aligning the technical solution with business goals over time. Questions like “how many and what kind of users do you target? How fast do you expect this amount to be growing?” Often these non functionals are not communicated.

A very interesting point was raised that we maybe should stop regarding them as something different than ordinary requirements. They are just as important as other requirements and should be embedded in the goals in order to build the right things the right way.

Wrapping up

The more interesting a session is, the more subjects I have to read about, products I need to check, insights I have gathered I write down. In this case I have many of these scribbled down  in my notebook. I really like the balance between validating your own observations and being inspired by others and their ideas and points of views very effectively during a roundtable like this.

If you are interested in speaking at our next event, or attending one don’t hesitate to contact Third Republic or even the host Daisy Perryer directly.