The document discusses the experiences of an individual in the IT industry and provides examples of problematic approaches to managing projects and resolving conflicts. Several anecdotes portray a manager with unrealistic expectations who lacks consideration for proper processes and documentation. Overall, the examples illustrate dysfunctional methods of communication and decision making that could undermine effective teamwork and software development.

1. 2012 Edition
My experiences in the IT industry

2. 1. Start the meeting with..
„How is it going?’
2. Eh why CAM so many
bugs are coming?
3. We need to discuss about
GP?
4. MIP and CRM is done?
5. BT resource: Is BOAP
mapping done?
6. Who will test? “PMs will
test”
7. What about Yuri 7-8 bugs
8. Eh… why is he taking this
much time?
9. Quotes: “I’ll conceive
Elizabeth”

3. 1. Apply OIL to your head
2. Stoop low and walk
3. Call a meeting, early in
the morning for status
4. Note that a print out is
required for the meeting
5. Transform from a manager
into a technical lead
immediately
6. Just say that “I am giving
you ALL my powers”
7. Don‟t smile, don‟t be
jokey and show
seriousness in your
thoughts and approach…

4.  Process:
Developer says “I
need a business
requirements
document, before I
start the
development
process.”
 Authority:
Manager says “Who
gives requirements
here? Just do as I
say, documents can
be done later!”

5.  First ask about the JINX
(gist) of the issue!
 Invite your favorite
developers and show an
inspiring YouTube video.
That‟s 20 minutes well
spent.
 Talk with mouthful of cup
noodles and enjoy the
reaction.
 Invite developers for lunch
and then go alone...
 Ask developers to join for
CAB ride and then tell them
to PAY.
 Place your arm on team
members shoulder and say “I
fired that guy”
 Invite fasting developers for
lunch and eat mouthful of
food.

6.  Step 1: First develop a
demo, then get
requirements and then
deploy and test. OR Just
deploy then develop then
get requirements and then
scrap the whole thing.
 Step 2: Instruct Team lead
to draw a SDLC process.
 Step 3: As usual, developer
must and should provide
documentation.

7.  Call meetings without any
agenda. If someone is
late just ask “IF HE
WANTS MERCEDES TO
COME FOR the meeting”
 Never take meeting
minutes, since it’s a
waste of time.
 After meeting you must
forget everything, since
it was out of context
from the current issues.
 Any random drawing
becomes a design
document.

8.  His experience is more than his age and remains
constant.
 His joke sounds funny only to himself.
 His imagination is different from the actual
implementation (Reality distortion)
 Sees Green when everyone sees RED.

9.  Typical conflict resolution …
 Step 1: Give a dashboard, if
dashboard exists, then go to
Step 2.
 Step 2: Give a report, if reports
exists, then give another report
to compare the reports, else go
to Step 3.
 Step 3: Return to Step 1. Exit
when the meeting is complete.

10. Developer‟s idea (if works) is managers idea.
 Labeling and version
control
 For multiple developers to
work on a project/source
file, label the code for
development.
 Use Clear Tone as a
version control product.
A bug becomes a feature when management likes it… “Anyone
can vote” becomes a feature.

11. Emotional quote…“At the bottom of your “I fired Sree”
heart, you know that SOAP web services is
not a effective solution, but you would “Eh why…”
still code for it.”
“Where are we going for lunch…”
“I am a technical guy.. I know BizTalk by heart. ”
“I am very cunning and political”
“I’ll conceive Elizabeth”
“Do you know how to write a select statement…”
“Why was I not informed about this…”
“My role is that of a lubricator”