The Art of War

You are not alone. You work with people – and no matter how well we communicate, we have different opinions and beliefs.

"The Ancient Art Of War" video game (1984)

You will try to make the best decisions, but don’t expect your assignees to always agree with them. No matter how many arguments you will raise or the time you will spend thinking on it – your engineers will not always agree with your conclusions. Yes – you probably have more experience them, possibly more technically qualified, and so on… and you can still be wrong. After all – disruptive technology achievements are all about doing something different. Your decisions making process is not an obvious one – many time there are endless possibilities.

If you hired the right people – they will have their own opinions. On everything. For many dilemmas, their diverse knowledge might exceed yours. It’s a good thing!

Yet – you are the manager. You are the decision maker – and you will make the final call.

Some managers think that working in a team means reaching a consensus. Those managers will get frustrated when they will fail to convince their reporting engineers that their decision is the ‘absolute right’ decision. Sometimes – their will get pulled to endless convincing sessions until the engineers get bored / give up / just say ‘you are right’. In other cases – they refusal to accept their absolute truth will be conceived as mutiny… and they will think it is impossible to work with those engineers: “I know he is SOOO talented … he just so stubborn. It’s impossible to work with him! I think he is not suitable for my team!”

If you raised an A team – you recruit A people. You are not necessarily smarter than them – and not always agree with them. But it’s enough if they acknowledge you are the one that decide on the strategy, it’s OK to not agree – as long as you respect the chain of command.

Saying something like “I understand what you mean” followed by your own words explaining their argument respectfully. And finishing with asking they will go and continue according to your directions is much more respectful then wasting their time in endless arguments. It’s enough for you to ‘win’ simply because you are the managers that cut decisions. You don’t have to win because everyone thinks your decision is the only way to go.

Try to listen to your engineers. Let them explain their reasoning, their view. You might actually get convinced and change your mind, or minimally acknowledge its possible you are wrong.

Disruptive design paradox

Everyone knows SW design is important. Taking the right decisions in the beginning of the project is a key to its success. But the reality of the disruptive team is ruled by lack of information on the nature of the problems, and the available tools. And on the other hand – this same lack of information drives higher manager’s nuts – they will want to see something quick. They will not want you to wonder around for weeks exploring possible designs in ordered process. 

There are two known extremes:

• An ordered process where there are requirements, design and implementation stages, meeting and documentations - when time’s allowed
• A chaotic process where the engineers just jump into the code and play with it

Many think the 1st way is the ‘right way’ – and explain in shame how they are working according to the latter because they don’t have enough time. Maybe it’s even someone else’s fault?

In reality – there are many in-between possibilities. Conducting a 2h brainstorm on a module, where the team explores possible designs will have a great benefit – even if most of this design will never materialize. You will define and get some common language. And if someone in the future will need to implement a module – he will have a vague context on its role within the big picture. Define the interfaces and modules; assign meaningful names (commonly known patterns and new metaphor inspired ones). Everyone should try to imagine they are indeed designing the long term implementation. At the end – you might simply pull your camera-phone and capture the diagrams from the whiteboard. Possibly everyone will now go back to the crappy work – but it will almost always be worth it

On other cases – the team might only quickly implement the abstract interfaces. Defined interfaces are ½ of the benefit of proper design. 

If the decision making is still hard – consider making 1-2 pilot efforts: where engineers take concepts at full steam for a few days. A good approach will usually ‘feel good’ after only few days of implementation! (“Jon implemented it last night – it’s more or less working today! Man it is so much straight forward this way – why didn’t we do it earlier?!”)

For some reason – many times I face strong resistance to this simple process: “why are we wasting our time in designs?! There is no time!!!” or “This is a waste of time… let’s take a 2 week break and make the design properly!” or “you don’t have time for that – I need to show this demo working by tomorrow!”

The manager’s role here must be the responsible one. Try to see how to push away the pressure a bit to allow the rapid design stage to happen as it almost always worth it. Yes – your role here is to look beyond the words: think what will actually happen, what will work, who can accept what, and suggest your superior on alternative timelines that you think they could accept. Your reporting engineers must know you have the ‘full picture’. You can bring the hysteria to a sane level. You are the leader – and in time of crisis – you work according to your strong narrative. (The product, the real needs, the real goals) This will be the ‘real picture’ and it can be reflected both upwards and downward in the command chain.