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)