Michael Koby

Commitment is a funny word these days.  Most people do not understand what it means to be truely commited to something (or someone).  Commitment can in some cases be interchanged with “loyalty” from time to time, but in the case of today’s discussion, commitment means “commiting to an act or trust” (m-w.com).

In consulting your commitment is important.  Your commitment to your job, your client, and even yourself are all extremely important.  Without commitment, a client would not know if you can be trusted to complete the job.  Future clients will look at your commitment on other jobs to determine if you are worth both their time and their money.  So to remain commited is important.

But being commited to a project is not everything.  There is a commitment to a certain level of work.  Since you are in effect, selling yourself (or your firm) you need to consider that when you turn in work.  The higher quality work that you turn into your client, the better it looks for all those involved.  Your client will appreciate the high quality of work, and this can lead to future engagements.

Commitment is something that can be difficult to physically show.  Since everyone works differently, some people can still turn in a higher quality work but look like they are slacking.  Some people can deliver the highest quality 8 hours a day, while others need a break every now and then.  This does not mean that someone who looks like they are not working is not delivering high quality work.  So you have to consider this when you’re working.  However, perceptions are powerful things.  If you look like you aren’t working then most people will assume you are not.  So perceptions are something to keep in check when you want to display proper commitment.

How can you as a consultant display commitment to your project(s)?  First and foremost, you want to turn in your deliverables on time or ahead of schedule.  You also want to turn in quality work.  Your work is a reflection of you.  If you are not turning in your highest quality work then you are doing a diservice to everyone (including yourself).  Turning in work ahead of schedule is a great way to demonstrate commitment, but turning in an inferior product in hopes of beating the schedule will only cause you more work in the long run and if you do it enough it will give your client a bad perception of you (and/or your firm).  Most clients would rather you deliver a higher quality product a little behind schedule then the would an inferior one ahead of schedule.

Another thing you can do is to occasionally check in with your client boss.  Ask them how they feel you are doing or if there is something you could do better.  Be careful not to ask too often, as this could give them the impression that you are only worried about “looking” good rather than actually being good.  Checking in every couple of weeks (or between deliverables) is a good way to keep a gauge on how you’re doing.

You can combine the occasional check-in with random checks on your work.  Show the client what you have and where you’re going.  Give them a chace to know what’s going on as well as make important decisions about the direction of your deliverable.  This ensures that the client is aware of where you are within the schedule and can even make changes to that schedule if he feels that he can get something better if you work a little longer on it.  Most Aglie development methodologies do something like this, so if you are in an evironment that is utilizing agile you will probably already be doing this.

Another thing to consider when discussing commitment is the fact that sometimes the client will ask you, the consultant, how long something is going to take.  When this happens you have a couple of options.  The first is to defer an answer until you have a better understanding of the project or deliverable.  Don’t delay too long though, as it can look like you are stalling.  The other option is based on your past experience, if you know you can do the work in a set amout of time then let them know how long it will take.  If something comes up that is going to delay your orginal estimate make sure you tell the client the moment you are made aware of the impact.  Unless your client is just completely unreasonable, this shouldn’t cause a problem.  You can not predict every single thing that could happen in the course of a project and you should not be expected to be able to.  But you are expected to communicate effectively.

As you work on a project make sure you are giving that client your highest commitment.  Some days can be hard but always try to get something accomplished.  Your goal is to deliver the highest quality work to your client(s) and to do so you must be commited to them and your work.

You should specialize in application development.  A couple of weeks ago, we looked at the pros and cons of specializing as a consultant and how can hurt you long term (see Consulting Consultants: Why Specialization Can Hurt).  But after I wrote that I began thinking about my own skill sets and how I can greatly improve my abilities and make myself a better consultant.  My conclusion is what we will be looking at today.

In the article I linked above I touch on something.  That something was the idea of specializing in a programming language.  Because learning one can help you easily learn many and it can keep you billable and relevant as a consultant.  There is more to specializing in a programming language than learning more than one.  There is the logic that comes with learning how to develop and program applications that can be transferred to other areas and other platforms, services, and architectures.

You see there is a theory (or theories) and practice behind application development that will pretty much never change on a grand scale.  The idea of “Object Oriented Programming” and the theories and “best practices” behind it have not really changed over 20-25 years.  The concept of requirements building, architect-ing an application, and coding have pretty much stayed the same over the last few decades.  Sure there are new theories and ideas but the general rules stay the same.  There are different methodologies, concepts, and paths one can take in doing development.  Many of these are transferable across languages and remain extremely similar regardless if it is C++, C#, Java, or even Python.

This is why specializing in a language and and application development can give you that specialization “credit” but keep you transferable between technologies.  Programming is an incredibly logical process and that process can be applied to anything that requires problem solving abilities.  Then on top of that if you understand, lets pick Java, if you need to learn C#, the overall concepts behind application development do not change, just the syntax for developing the logic and algorithms.

I am definitely still of the opinion that you should not specialize too much on one technology and platform because that causes you to (in many cases) want to use that technology/platform to solve all the problems you encounter.  I think that a good consultant understands several tools (even if they are not experts on those tools) and can determine the best solution for the problem at hand.

However, I do think there is some value in specializing in a particular programming language (with the intent to learn others) and understanding development concepts, theories, and methodologies.  You start with one a single language and then move through the others as you need to.  The .Net platform is not always the best solution (neither is Java, Python, or C) but a solid understand of a single language can help you move across others with ease.

There is always a need to, as a consultant, to oversell yourself to some degree.  Especially if you are a freelance consultant and not working for a consulting firm.  The desire to answer “Yes” to every “Can you do” or “Do you understand” question can be overwhelming when you are trying to land clients, jobs, and projects.  The question always exists about when you should be honest and when you should exagerate your skillset.  For this week’s Consulting Consultants I want to look at a couple points on both sides.

When it comes to doing an interview or talking to a client, you want to be as honest as possible.  The main reason for this is because if you set an expectation, it is your responsibility to follow thru on that expectation and deliver upon it.  You want to give your client the impression that you can fix their problems but you want to do it in a way that lets them know what you can and can not do.  Everyone has their strengths and weaknesses.  If you are honest with your weakness upfront it sets a resonable expectation and in some cases can let them know they might need to look for someone else that can do the things you can’t do.  If you have a realistic client, this shouldn’t be a problem.

So what about the exaggeration part?  Surely we should do a little bit of overselling, right?  Well, not always.  This depends on what you intend to oversell.  It would not be a good idea to tell the client that you can work on a technology you have never touched before.  This puts you into a place where you have to go deep into a technology in order to learn enough to be able to deliver on the promise.  As a consultant, your output is your biggest selling point.  If you can’t deliver your best work, it will show, and it could cause the client to look elsewhere for new projects.  However, lets say that you are a C# developer but you have no experience with LINQ (a new 3.5 feature) but your client is looking for someone with LINQ skills.  What should you do?  Well, if you have sufficient C# skills, LINQ is probably nothing more than a day’s worth of learning.  You can either a) tell the client you are familar with the technology or b) tell them you have not done any real work with the specific technology but since you already have the other C# skills, learning LINQ would be no big deal.  The idea would be to not tell a client looking for BizTalk skills that you have that skillset when you in fact do not. Lying will really get you no where, and it usually doesn’t take long for someone to discover a fraud.  If you don’t have that skillset and the client asks, it is almost always better to tell them that you don’t have it.  Bold face lying will only end in your reputation being destroyed and having no one hire you.  The idea is balance.

One of those two responses is a flat out lie, while the other does two things.  The second answer gives the client honesty while telling them you are willing to do what you need to ensure you are able to get the job done.  Some clients might turn you down, reasonable one’s will probably take you on knowing you’ll learn what you need to get the job done.  The basic point here is to try to be as honest as possible but sell the client on yourself.  Honesty with a client lets them know that you are not in this to just make money but to ensure they get the best consultant for their money.  It also shows them that you are an honest guy which can go a long way with some people.

People generally equate honesty with a strong character.  Someone who will own up to their mistakes.  Someone who will tell them the truth when asked a question.  You can be both honest and tactful, very possible.  A little exaggeration can’t hurt when you do it at the right times and to the right questions.  But do not let an exaggeration equate to a lie.  Ruining your credibility (or that of your firm if you work for a consulting firm) will do no one any good.

Over the past couple of weeks, the subject of specialization with reference to consulting has come up among my colleagues.  It is a subject of much debate so I figured that now might be a good time to look at specializing and explain my points of view on the matter.  I am of the opinion that specialization as a consultant will do more long term damage to your career than not specializing.

Sure, specializing looks like a great road to go down especially on a technology that doesn’t look like it’s going anywhere soon.  However, for the sake of this argument lets consider the Microsoft .Net product stack.  How many .Net developers do you know?  How many really good ones do you know?  If I was to venture a guess, I’d say you know a lot of .Net developers.  This makes the .Net developer a commodity of sorts.  The more people that can do what you do, the worse off you are.  Especially if those other folks can do it better than you.

This can be extremely harmful if that single technology or technology stack is all you know.  You are so deep in it that it’s crazy.  But if you are are asked to look at something else you couldn’t do it with confidence and value.  However, specializing can make you easily billable on a technology (stack) that is in high demand but once that technology becomes outdated or something better comes along you are stuck being non-billable until you can learn something else.

Another reason that specialization hurts is that it makes it really easy to fall into the “one solution for all problems” trap.  You start to think about ways to make your current specialization fix a problem it has no business fixing.  You end up trying to fit the square peg into the round hole.  It just doesn’t work and it really doesn’t actually solve the problem.

So how do we avoid specialization?  Well, it can be hard to and I’m not saying that you should never specialize in anything.  I actually thing specializing on a programming language is a sound idea.  Especially if it’s object oriented based and compiles in some way.  Doing so makes it easy to learn other languages when you need to in a pinch making it easy for you to jump around.  But I think that getting your hands on whatever technology you can is only going to benefit you long term.  If you can play around and get to understand different technologies at least at a surface level, it helps you to understand different ways to solve problems and gives you a better understanding of what tools work best for what kinds of jobs.

Surface knowledge helps a lot.  It can help you to understand how different technologies can connect together to create a solution.  It can help you understand a lot more technologies overall because you understand so many, at least a little bit.  So keep this in mind as you sit down to learn new things.  Think about something you don’t understand and attempt to understand it.  The more technologies that you have a surface understanding of, the easier it will be for you to dive deeper if you need to, because you’ll already have the ground work laid.