The manager’s narrative

When facing disruptive technological challenges there is an overload in the amount of information and possibilities. Any excessive hop between the doer and the decider is painful. This is true even for the smallest hop between the team leader and the engineer. Essentially this means the latter will have to make frequent decisions on daily basis. But… weren’t the manager supposed to do that?

"Wink of an Eye" / Star Trek 

Some managers lead using mare charisma. But even this will not help their reporting engineers make the right decisions unless they will get a wider picture on the team’s goals 

One repeating pattern in history happens when a group of people face similar problems and challenges. In many cases – the mutual concerns leads the individual into grouping, and looking onto one another. That makes sense. But times change, so are the problems and difficulties. The groups that last the changes are the one that also follow some abstract idea that gives repeating reasoning over the changing periods. Those ideas can be occupational related (Such as medieval guilds) but in many cases, the narrative is disturbingly artificial. Think of religion. Think of nationalism. This is a human pattern – and it can also be used for the good of mankind. 

The strongest forces in the global industry aren’t technological or financial – instead, they are sociological aspects, such as ideas and trends. 

The conscious manager should try to define and seed the team’s narrative, a higher order abstract and noble target that will fuel the day to day activities. The best narratives are those that are not even related directly to a specific person or company. 

In many cases – the narrative can be described by portraying a believable future: 

• Camera phones will be extensively used to takes high quality pictures (For image quality algorithms research) 
• Man-machine interaction will resemble human interaction (For NUI – gesture interface research) 
• Let people enjoy video on their cell phones (For video streaming systems creation) 
• Plain fun (For game design) 

Do not settle for only seeing the short term goals: 

• Optimize algorithms to reach specific CPU consumption at bit-exact results 
• Implement drivers to all processing blocks created by our VLSI team 
• Meet the deadlines at all cost 

Having a good narrative will fuel your constant decisions and leadership. It will allow you to look beyond coming release pressure and evaluate your work and the competitors in the right glasses – where all are working to fulfill the same goals. 

The power of language

Words have power. 
The names of your modules and features have high importance. Yes – of course it will lose its technical meaning eventually, once it compiles, but the name of the module will have a strong influence on what will people think should be the module’s purpose, or how it will evolve over time 

Captain Blood (1988)

When a module implements a common practice – try to pick the common name to it (See Design Patterns / GoF). Use adaptors, containers, parser, transmitters and receivers – so users will know what to expect. This way the discussion will enjoy the prior experience of the team, and you will talk in higher level – instead of losing focus on obvious technical details. 

The real fun begins when there is no obvious name for your new creation. In those cases – metaphors are your best friends. Picking the name to match a successful metaphor will literally create a new language in the team and outside it. It will also make your design human readable – as it will tell a story. The most successful names indeed live far beyond the implementation, and will be reappearing on future designs, marketing requirement documents and even in customer’s discussion.

Looks Like a Duck?

Alley Cat (1983)

Every once and a while I needed to create something new. In reality, though, it never seemed so: there were past work done in related field. People were thinking of it, writing code, and might also think they did the best possible work there. Those people do not seem stupid, right? In fact – they might even seem geniuses at this time! After looking at their work, I found it extremely hard to understand the theory and code design. Hmm..  If that is the case – they are clearly far smarter than me. The only logical conclusion I had, is that I should be extremely careful, avoids making big changes in the design, and spend the team’s best minds and effort in understanding and maintaining this puzzling gold. Thankfully, at some point of time I woke up and understood the legacy code and theory. In many cases - it was crap, made hastily by (usually smart) flesh and blood people - just like me. But the time it took me to acknowledge this reality, was far too long and expensive

Control console of a Russian nuclear power plant - don't touch!  

No one wants to do unnecessary work. And managers will always strive to consider a model where the feature is already implemented and only some slight maintenance is enough. The decision to implement something from scratch is a scary one: it will take time, and if you don’t care for the details – then why would you thinks it will be better this time? If it works 80% of the times – maybe just make small fixes?

When you need to take ownership on existing work you are instantly transformed into the underdog. Just a day earlier, you were the genius technical authority managing your previous tasks. Today you woke up to be the stupid manager that does not understand the basics. This challenging period is where you will need to utilize your crap smelling abilities

• Don’t just jump directly to the code or API references. Try to find some paragraphs that tell ‘the story’ of the module and its usage, or even someone that could explain its logic. If he cannot explain it to you in simple down to earth words it’s a bad sign.
• It is really rare to find technical ideas that are too hard to be explained to an engineer. If you and your team try hard to grasp the basic concept and still don’t see core idea – it’s a bad sign
• Can you find sense in the interfaces and naming?
• Unreadable codebases are common. Try to send an engineer to reverse engineer it – or even do it yourself. Take a sheet of paper and sketch the different classes and their relations. Try to recreate the design diagrams: class diagram, instance diagram, sequence diagrams, etc. If that is too hard – it’s a bad sign
• Code with many dead branches or undocumented states and if statements
• Did you analyze some large and complex modules, that after a week of trying to understand its work – you discover it’s doing a trivial task? ( Such as (a+b)/2 )
• Think what it will need in order to implement it from scratch. You can take an hour and sketch some quick design diagrams and see if it makes sense. If the decision is extremely hard – consider sending an engineer to a ‘pilot’ where he will implement it from scratch in a few days. It might be that once you observe the pilot work you will already feel it is better. Taking hard decisions is easier once you get this information

No matter how much I will discuss it – this repeating dilemma is related to your wisdom and experience. You can’t fix that by reading a book. My 2 cents here are the suggestion you will acknowledge the critical issues on crap smelling, and consciously work to tune your natural instincts - and try to improve over time.

I certainly don’t suggest you treat every legacy code as crap that requires rewrite. Instead, try to find your own balance, and acknowledge the effort you will need to make before taking such a critical decision.

1x1 meeting: from ‘Me and You’ to ‘Us and Them’

People communicate differently when they are in a crowd than in a 4 eyes meeting. Nothing can replace the connection and integrity of intimate conversation. This is the place where the employee will reveal his true problems and his ambitions.

"Dr. J and Larry Bird Go One on One" Video Game (1983)

No matter how nice and polite we act, in most conversations, the employee and manager will act as they are the ‘me’ vs. ‘organization’. Both might be careful in choosing their words – as they know there would possible be unintended outcome for those long terms relations. They will both play the game.

The ‘me’ vs. organization tension is here to stay. Our job plays dominant role in how we percept ourselves - our modern ‘status’. We all want to be acknowledged on our professional abilities, and afraid to reveal our weaknesses. After all – no matter how many masks you have – we all remained the same children we always were…

Every employee draws this line between ‘me’ and the organization. As a manager – a fruitful 1x1 meeting is the one where both parties understand they are on the same side of this line. It must be safe environment where you both can focus on the benefit of the employee. It’s a ‘WE’.  Remember the employee will have his own benefit spot in his mind anyhow – no one can take it away from him. As a manager – you can choose to join him. Understanding this will actually help maintain the employee, as he will acknowledged that his worries are acknowledged

This is not all manipulation: you should really do your best to look at your employee present past and future from his eyes. In many cases your powers will not be sufficient to fuilfil the employees personal ambitions. The best practice is to truly discuss it and even suggest possibilities that might seem to be against your own motivations: like recommend how eventually he will reach his goals – even if that involves leaving the team. In most cases – the employee will not actually leave – but will instead get the safety feeling he was really looking for.

When discussing technical stuff – you will discover the employee now can better understand your own goals and motivations. He will understand why he sometimes need to do dirty work, fly abroad or stay late hours. He will not do that just because he is expected to do so. He will do it as he will sympathize with the team’s goals, or even share your narrative.

In a 1x1 meeting an employee will understand why he needs to give his share of the dirty work.

• Show him the team’s tasks
•  Ask him what he wants to do
•  Do your best to let him fulfill his wishes and develop his own derived goals

He might well understand that he have to finish with the ugly bug he was crying over for the past week in order to reach the ‘gold’ – the tasks he feels will bring the most value, interest or even fun (Yes – our work should be fun too)

Foreign affairs

Taking

Humans are territorial beings.
You make stuff, proud of it, and want to be credited for your work (Especially if you are good at it)

However, I saw managers sometimes taking this the wrong way: obscuring information on the activities, refusing to cooperate or even share code. On the other hand, you will see managers that will get frustrated pull their pointing finger demanding to get ‘A’ from that team or ‘B’ from another team… and on schedule – preparing the blame for their unavoidable failure on meeting their assigned tasks.

M.U.L.E. a multi-player managment video game (1983) 

Every task on your responsibility that requires deliveries from other teams is a possible point of failure. You cannot avoid it completely – but you certainly need to try. Assuming no one delivers you on time – can you still achieve your goals? What is the minimum that will still allow success?

Imagine you write an application based on the companies infrastructure – but you got some blocks missing. You should discuss it with the fellow teams and see if they can help and it will actually fit your requirements. If not – think if you can solve the problem internally. If you fear duplication – you should even more fear details falling between chairs.

“You cannot provide me this infrastructure element on time? No problem – we will hack something internally in the meantime…”

Now if the infrastructure team leader might get angry on that - it’s a great sign! This means you are both on the same side! Feel free to tell them you will be more than happy to switch to their implementation once they have it working – and assuming it will cover all your requirements.

“But… if they will implement it, it will take 1 task off my Gantts – so my guys can do other stuff!”

Auction (From M.U.L.E)

If you will actually begin to count the integration time, definition time and risk that will be caused due to misinterpretation of your requirements or refusal to follow them you will discover that it will still worth it.

“Am I working alone here?”

No you are not! You use many modules that are developed externally – but you choose them if they fit your needs. And those are usually available before you decide to use them. Those that are not created yet – are a serious risk. Not necessarily because they are complicated – but because actually working with them successfully will involve several other people (Minimally – the other team leader and engineer).

Giving

On the other hand – I recommend you always keep absolute transparency of your activities to the other teams. Let them know what you do and what you plan to do. Let them see you work. Usually they will reflect their own requirements and thoughts that will allow the team to make better decisions on the go.

In one of the companies I work before – the fear of exposing the HW spec was so great that it was moderated from most engineers – in the fear it will fall into the wrong hands. I always said that is someone will get this spec and manage to implement it in a sensible way after reading it – he is fully deserves the trophy… and I will be grateful if I could get it too ;)

In two sentences:

• Give everything
• Assume you will get nothing 

M.U.L.E in Wikipedia
Planet Mule (Remake)

Heroes of the proletariat

The engineers. They are the engine of the industry. They are the creators of the modules, the implementers. 

From "The Girl in the Fireplace" Dr. Who (2006)

In the 19^th century the European great engineers built smart clock mechanisms, they mastered the art of mechanics engineering to a level that probably will never return. Today’s engineers sit in front of a computer, use IDEs to write code and debug it. Essentially both groups are the same – they create new and complicated machines. Modern engineers simply build much complicated machines, and they manage to do it mostly because they have far better tools.

The creation process is a noble act: You imagine something that does not yet exists and you make it come true – that’s cool!

This entire introduction is just to be sure you will not take the engineers too lightly. Maybe for some commodity work a programmer is a programmer. But for the disruptive team, each engineer is really a special entity, which utilizes his ideas, imagination and experience.

Following their manager’s narrative – the engineers should be able to make decisions. I usually prefer to assign responsibility covering every aspect of the task to the engineer – even if he is new at his job. It is better to assign it to him and help continuously, then working in an environment that your absence cause everything to stall or collapse.

The downside to this is that not every engineer is a manager. On top of that – no matter how smart is the engineer – most of the time he is floating in the virtual world of his code. He is not really in the room. Therefore – you should carefully balance the amount of assistance and responsibility you assign according to the person’s capacity. But don’t get too alarmed by this warning à you should continue and strive to assign as much responsibility as possible to your engineers.

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.