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.