Hacker News new | comments | show | ask | jobs | submit login

Kind of agree with you and OP, so let me add to the discussion with the caveat that YMMV etc. Some of these points may overlap with comments by fellow HNers in these threads.

In any organization as a prospective customer, there are three forces at work that matter to a consultant: users, decision makers and finance folks. Ideally, the decision makers appoint a dedicated person (or team) who mediates users and finance guys to create a coherent road map for the system to be built. What tends to happen in practice is a combination of chance, human errors and conflicts in priorities.

To survive, we must understand ourselves as consultants, the terrain and the opposing forces (anything that prevents money getting deposited in the bank).

Consulting is a business => the individual consultant must shoulder quite a lot on himself:

* Advertising himself

* Finding work

* Meeting prospective customers

* Writing proposals

* Closing the deal

* Writing a contract

* Defining the scope of work

* Nailing what is to be done and what is to be avoided

* Constructing components of software

* (In worst cases) baby-sitting customer's devs / ops

* Testing his modules

* Getting money in his account

So, when we talk with customers, there is inherent pressure in closing the deal versus precisely defining everything. Icing on the cake: back of the mind, you might worry about milkman's bills and the birthday gifts to be brought for your kid's friends. Always have a good runway: six months seems optimum. Technically, even three months should suffice, but it is insufficient for the edge case when these three things hold true simultaneously:

* You've to walk away from a customer in the middle of a project, and

* Dry sales pipeline, and

* Unexpected crisis at the personal front: very close friend in need of money for surgery etc.

God be with you.

Now, back to the main track. The key is to first understand the priorities of stakeholders. The contradictions are easier to grasp once we put ourselves in the individual's shoes:

* [Convenience] The users want everything including the kitchen sink,

* [Accountability for the risk] They want it yesterday but won't commit to it on paper since you're in early sales stage,

* [Cost] The finance folks want stability and the most economical price,

* [Availability] The decision maker prefers to spend the least of her time to be spent on this activity, except when it's her pet project.

These roles may be played by different people or the same person.

Again, we don't have to agree, but acknowledge that things are meant to be imperfect. Most people are actually decent and rational. Now, somehow, the consultant must figure out a good path. To begin, he should have a good handle on:

* The industry in which the customer operates, e.g. BFSI, Energy, online marketplaces, food, fashion etc.

* The nature of the market: oligopoly, crowded, emerging et al.

* The level of Govt. regulation: HIPAA? PCI?

* The customer's position: among top tier, mid-size, small firms.

* Customer's customers: helps to track the wind.

* Standard pain areas in the market.

* How customer's competition and partners survive the pain, specifically the differences among the customer's approach and the competitor's ones.

* The financial health of the customer: if possible, try to talk with their existing suppliers in other arenas (e.g. the guy who supplies printer cartridges, the cleaning lady etc.).

Based on that, assuming we've landed a hot lead, say that we want to convert it to money. There will be a lot of conversations over the phone, e-mail, chats, face to face; what is to be left out of those conversations is really context sensitive. The important parts are:

* What problem we're going to solve for all stakeholders?

* How we're going to solve it?

* Communicating our approach and progress on a timely basis.

* Improving Vulcan skills: like money, expression of anger is a great servant but a terrible master.

I leave out the details on the development process, since it depends on the individual.

Here are a few things which worked for me marvellously in certain contexts and doomed in others:

* Setting expectations by explaining the cone of uncertainty in the estimation process. Always be prepared for some customers, who deliberately mislead you that they don't understand the mumbo-jumbo, projecting ignorance as a shield so that they can ruin you on payments. Mostly you should refuse such customers, unless you're in an extreme crisis on multiple fronts.

* Writing use cases for the modules / systems I was supposed to work. Most customers say that they don't want any time spent on "documentation," to which I reply that writing a document is not "typing" but "nailing the thoughts to deliver higher quality work."

* Creating mock ups using sketching tools (even Excel/LibreOffice can be good enough, if one is pressed too much for time) in the absence of UX designers on the team.

* Writing test cases before writing my code. Helps to ease the integration.

* Optimizing lazily: progressively refining the artefact (document / mock up / test / code).

* Knowing the expected value of each task: (amount of money * satisfaction * improvement in reputation) / (e-mail tennis * stakeholder's understanding of requirements * payment latency * time spent)

Finally, reducing it to just one sentence: be nice, believe in yourself and humanity, be multi-dimensional and please heed Guy Kawasaki's advice about reading voraciously and omnivorously.

Edit: formatting.




I rarely comment here, but your excellent post deserves to be recognized. I'm someone who has thought a good deal about starting a consulting company but never managed to convince myself the risk/reward numbers would work for my life situation. Your richly detailed and honest perspective is much appreciated. Thank you.


Your words widened the smile on my face. I agree with you about the risk/reward numbers.

Should you be comfortable, I'll be very glad to keep in touch with you. My e-mail is on the GitHub profile.


Awesome post! One thing I find is really important is to charge 'properly', which at first seems like exurberant fees. My friends think I'm rolling in cash because of my 'rate' but when you outline all of this stuff up here, you can see where it all goes. I don't do much better than when I worked full time, but I have the potential to work harder and make more money. But the extra super hard work doesn't' seem worth losing the life balance (and well, the nice parts of contracting, i.e. TWO WEEK HOLIDAY, even though it really isn't).


Happy to learn that the post resonated with you. I appreciate it.

Once a VP at a customer told me that a diamond is just a piece of coal that shines under pressure.

The quest to become a jewel in the market can be a powerful initial thrust to work as a consultant. Combined with the opportunity to work in a diverse set of technologies and business domains turns to be a pretty compelling force.

Re: compensation, tptacek and patio11 have shared some great thoughts in the past.


Awesome list - deserves a nice little blog post of its own that I can bookmark.


Thanks for the kind words.


Really great advice, would you mind if I put it up on pastie (obviously with attribution to you) so people can bookmark it?


Thank you and everyone for the words of encouragement. I've posted it on Medium: https://medium.com/p/23a07cb0d5ea


What stops you from bookmarking it on hn?

https://news.ycombinator.com/item?id=6443135


Great list! Mostly works for projects in general, too! Agree that there needs to be a blog post of its own for that.


Commenting to save this for myself (fellow consultant) -- thanks for the detailed list. :)


You're the most welcome, :)

I'm curious about any differences in conulsting approach to data science compared to software products: estimation strategies, what works etc.


Ditto to the first part, commenting to save or myself.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: