David Knott 16/01/2020 David Knott 16/01/2020

Architecture as balance #5: fruitful frustration vs fruitless moaning

Have you tried the red button / green button exercise?

It’s one of the simplest and quickest team exercises I know: all the team members simply write down three ‘red buttons’ (things which immediately make them angry and which undermine their motivation) and three ‘green buttons’ (things which are guaranteed to excite and motivate them). They then share them with the rest of the team.

(I have to credit the learning company IDG for introducing me to this exercise through a great leadership programme which we now offer under the name Fusion within HSBC.)

The power of the exercise is that it reveals the diversity of motivation and potential sources of conflict within the team: whenever I’ve done the exercise with a team, I’ve always found people saying something like, ‘But I never knew that wound you up!’ or, ‘If I knew that you enjoyed that type of work so much, I’d have let you do all of it!’ The exercise also gives people permission and a vocabulary to remind each other why they’re heading into conflict: ‘You know that’s one of my red buttons.’

David Knott 26/12/2019 David Knott 26/12/2019

Architecture as balance #4: finding the time

Last week, Manoj Chugh asked me for my view on how architects should balance their time between strategic and tactical priorities.

I suspect that Manoj’s question was motivated by the feeling we all sometimes have, that there is simply not enough time: we set ambitious strategic goals and have lofty intentions to realise them, but those ambitions get overtaken by the sheer quantity of decisions we must take and problems we must solve every day.

I can’t even pretend to have a perfect or comprehensive answer to this problem. I could try to point out that strategy and tactics should not be enemies, because good tactics are just the actions which are taken to implement strategy. However, even when strategy and tactics are perfectly aligned, it is easy to feel as if there is just not enough time to get everything done.

I think that we have to accept that this is just part of life as a technology architect (and many other technology roles). If our job is to figure out how to deploy rapidly changing technologies in the service of customers and of business goals, then the number of things we could do will always exceed the number of things which we can do. In this case, then the best we can hope to do is to make the best possible use of the time we have.

David Knott 21/11/2019 David Knott 21/11/2019

Architecture as balance #3: what do you do when ‘tactical’ means ‘irrational’?

Let’s spend some time with the glass half empty.

In my last article I claimed that tactics and strategy do not need to be enemies. Strategy defines goals and sets priority and direction; tactics comprise the actions that implement the strategy. On a good day, technology architects remember that strategy doesn’t happen without tactics, and successfully align the two.

But not every day is a good day. Too often, architects find themselves in situations where someone is trying to justify a design choice or course of action on the basis that it is ‘tactical’, when the architect knows that this is just code for ‘please go away and stop bothering me’ or ‘I know this is a bad decision but I’ve got to go along with it’. These situations are not resolved by remembering the proper relationship between strategy and tactics: they are resolved by hard choices and difficult conversations. Dealing with them is not the most fun part of the job, but if we don’t deal with them, then we are not really doing the job.

David Knott 14/11/2019 David Knott 14/11/2019

Architecture as balance #2: strategic vs tactical

Technology architects frequently ask me how they should balance tactical choices with strategic goals. Sometimes this question is asked in a grand, enterprise context: how is it possible to transform a complex enterprise while maintaining service and delivering immediate change goals? More often, though, it is asked in a very narrow, specific and personal context. How do I get my team to stop picking bad solutions and justifying them because they’re ‘tactical’? How do I get my project manager to let me design a proper solution, when they won’t provide the time, money and resources to do a good job? How do I convince people that they should adopt the ’strategic’ solution when it’s so expensive and hard to implement?

Almost all technology architects face these problems almost every day, and if any of them claim to have solved them once and for all, then you should go and read their blog. I can’t offer a perfect solution, but can offer some thoughts which might be helpful. These will come in two instalments: this is the first, which deals with some common conceptual mistakes made by technology architects.

David Knott 12/09/2019 David Knott 12/09/2019

Architecture as balance #1: elephants vs building blocks

Q: How do you eat an elephant?

A: One bite at a time.

This is an old joke, and one that technology architects are very familiar with. We spend a lot of our time dealing with big, open ended questions and big problems. How do we make this legacy system respond to digital needs? How do we integrate this acquisition and realise efficiency gains without breaking the business? How do we turn this disruptive force into a competitive advantage?

One of our most basic techniques is to break the big problem down into smaller pieces: to eat the elephant one bite at a time. We progressively refactor the legacy system into micro-services. We figure out the processes, functions, systems and data of the acquired entity and map them to the integrated state. We get to grips with the fundamentals of the disruptive force, and work out the best places to start putting it to work in our current enterprise.