This document provides advice for software consultants working directly with clients. It emphasizes the importance of gaining client trust by understanding their needs and business domain, suggesting alternatives tactfully rather than saying no directly, being prepared to answer questions about practices and estimates, avoiding surprises, and communicating technical topics clearly for a non-technical audience through demos and examples rather than jargon. The overall message is that consulting requires diplomacy and relationship-building more than just technical skills.

1. Being a Consultant Developer
- Prasanna N Venkatesan
Not a tech talk !
1

2. Disclaimer:
All the below menoned points are my experiences, views
and opinions.
Got out of working in di erent kind of projects. Purely O Shore without client interacon. O -Shore TW dev team
along with Client Dev Team, at client's place and as a tech
consultant.

3. So What??
What is the big deal, anyways?
I am gonna code where ever it is. Sounds perfect, but
the only problem here is that the challenges you are
going to face is there is slightly different and the way
you are going to react to them is gonna be the
deciding factor.
To start with, talking to with TW BA about a
functionality is not the same as talking with a client.
Even arguing with BA @ the client place will not give
good impressions.

4. Gain the trust and confidence of the client that you
know what you are building.
The client side BAs and Program managers are
experts in their fields. You can't simply walk into the
place and ask them to change everything.
Best place is to start is to understand about the client,
understand the product they are planning to build,
understand why they need it. Get a high level
overview of what you are building. You don't need to
be a BA to do these, developer has to get these
context too.

5. Be Subtle in expressing yourself !!
If you want to change some business flow or suggest
a new one be subtle in expressing it.
Most of the times the argument whether a feature is
an MVP or not will arise.
It's more of a how.

6. May be due to some tech difcules or due to some
other reason, you may not like what the client is
asking for. Instead of saying a direct 'No' try to
understand what the client needs and try to suggest
alternaves.
It gives Client more confdence on you and a straight
'No' will defnitely upset him.

7. Queson their pracce but don't be adamant in
changing them.
Most of the mes the client pracces around
Code CheckIn, Tesng, Working on Stories,
Deployment, Environments will arise.
Remember 'Rome is not built in a day'

8. If you queson them, then beter be ready to be
quesoned about the pracces.
Understand what you are doing and you should
be ready in explaining it to a stranger at any
me.
Most famous queson that I get is always
around velocity, story points, esmates etc.
Don't shy away in answering them.

9. Don't try to surprise a client. It may have a
posive impact or negave impact on the team.
The client may lost trust in you, and always think
you are working on something else rather what
has to be done.
Surprises may turned out to be a shocker.
Never try to surprise, don't work secretly, always
keep the team informed about your work.

10. Tech suggestions form HackerNews??
Suggest Tech Alternaves. But be sure and ready
to be quesoned.
Don't be random about the technologies. Read it
in HN and proposing it to the client?? Nah..
Try out the tech and show a demo, that might be
more helpful and more appealing than just
random suggeson.

11. If there is a problem, Don't panic.
Its quite usual. And keeping yourself cool will
help you to concentrate on the problem, and
also relaxes others around you.
During panic never get into a blame game rather
focus on what has to be done. Be more
construcve.

12. Don't confuse !
“You are just too confusing” - Most of
the client have this for us.
All your tech jaargons, explaining
things in a non-business way will
make the client to lose interest on
what you are saying.
Understand the audience and try to
speak accordingly.

13. Brace yourself for this
Can you elaborate more on this in mail?
Improve the vocabulary, and be more precise.
Know the audience, and compose accordingly.

14. And for this too !!
Be ready to present what you have done.
Most of the times, it will be to demo the app that you
have built. Be confident, prepare for the demo and
execute the plan.