Comments

7 responses to “Practitioner versus Consultant”

1. 

   July 24, 2012

   Torbjörn Gyllebring

   I’ve come full circle doing a “practitioner -> consultant -> practitioner” transition over the last 7 years and your thoughts pretty much sums up my thinking and reasons.

   My preferences are:
   1) Grow practitioners
   2) Hire practitioners
   3) Use consultants to do 1 or 2

   I wouldn’t ever recommend “hiring a consultant to sort things out” it abdicates responsibility
   and simultaneously manages to put said consultant in a position where they’re unlikely to succeed.

   Consultants have their place and can bring immense value through their knowledge & fresh perspectives but at the end of the day, the sorting out remains the responsibility of the organization.

   (If I return to consulting this I’ll carefully stress these points, anything else simply leads to frustration for me and back-sliding for the org/team when I leave)
2. 

   July 24, 2012

   andrew fuqua

   Certain things I’ve been practicing for so long I don’t worry about them, like XP and unit testing. Other things I can get better at by consulting, such as mentoring and coaching and training. For the other stuff, I deliberately practice and study. And there are some other things that I’ve come to accept that I’m not going to become an expert at. I acknowledge those as weaknesses and seek the help of others . But you’re right, it is something to continually evaluate, weigh and balance .
3. 

   July 24, 2012

   Josh Nankivel

   I’ve had a similar struggle, but with being a full time trainer as opposed to a consultant. I did training full time for a year but very quickly felt the same as what you describe Pawel. I wasn’t actually doing this stuff anymore, and started to feel like a phony pretty quickly when I realized it had been so long since I had actually done myself what I was teaching other people to do.

   So for me the best is a balance. I do both at reduced levels, which allows me to work with new people and enjoy teaching which I love, and keep my feet planted firmly on the ground with product development too.
4. 

   July 24, 2012

   George Dinwiddie

   For me, the practitioner role is developing code–programming and testing. For you it’s probably managing, so there may be some differences.

   When I first started consulting, I billed myself as a player-coach. While this kept me fresh as a practitioner, having to deliver code can interfere with the consulting/coaching. It’s hard to make two things first priority.

   At the moment, I’m just consulting/coaching. And, yes, sometimes I miss the practice. At other times, I get enough practice pairing with people on their code and working on small projects of my own.

   The flip side is that, yes, I do get a broad exposure to lots of contexts. This exposure has pretty much cured me of the “best practice” syndrome. Context always matters.

   I sometimes stay with a client quite awhile, giving me continuity with them to see how the changes progress. There is no “final result,” though, even as a full-time employee. The results are always “so far.”

   Being an outsider has it’s benefits, too. I can ask “stupid” questions. I’m not conditioned to accept (even to the point of overlooking) aspects of the status quo that employees take for granted. These advantages wane over time, of course. As Jerry Weinberg says, the cucumber gets pickled more than the brine gets cucumbered. I suspect that an intermittent engagement, short periodic visits, would delay this and give the client more value (and for less cost), but it seems to be a hard thing to sell to clients. They almost always want a solid block of time.

   Bottom line is that there are intermediate points between consultant and practitioner and there are hybrids. I move back and forth as seems appropriate. Probably no stasis would seem right for long. I do know several consultants who have gone back to being employed practitioners recently. Consulting isn’t for everyone, or perhaps they just need a time period where they do that.
5. 

   July 25, 2012

   Kurt

   This is something I have been thinking a lot about lately too.

   It seems practitioners just get to stick their teeth in to more interesting work too. As a practitioner I feel I can improve things a lot, simply by doing things. Consultants have to go through the rigmarole of convincing others that their way is wrong (but not directly of course, they have to use tricks), and they should do it another way. The typical company that is getting a consultant in is probably right at the beginning of their journey, so the consultant is pretty happy to get some sort of Scrum-But and unit testing going. Whereas a practitioner can slowly and steadily keep working at it, they develop a deeper knowledge of the company culture, and if there’s some blocker as far as improvement goes, they can still deliver normal value. Plus they are there at those sporadic intervals where important decisions can be made, or opportunities for kaizen arise. A consultant doesn’t sit there billing hours until these sporadic events occur, and he can’t occupy a team’s time too much either. He just comes in now and then, and has probably missed all the critical decisions and kaizen opportunities.

   I am slowly coming to the opinion that it is pretty much an anti-pattern unless the customer knows exactly what they want, and it can be delivered in a chunk of time. Like a specific product needs setting up and configuring, or there is some new concept that they need training it. Or there is a specific problem that can be solved by the consultant (rather than by the consultant trying to convince others to do things differently)
6. 

   July 25, 2012

   George Dinwiddie

   Kurt, you paint a pretty bleak picture of consulting. I can tell you that I don’t use tricks to convince others that they’re wrong. That’s not my role at all.

   As Pawel puts it, I’m there “help to sort things out” but Torbjörn has it quite right that “the sorting out remains the responsibility of the organization.” My job is to help people make informed choices. Some of that involves teaching. Organizations often bring me in when they want to go in a new direction but aren’t exactly sure how. Switching to agile software development is a common such direction. Sometimes they need ideas–they’re trying to do something and feel they’re stuck. My experience with many different contexts can help them. Sometimes they need fresh eyes because they can’t clearly see what they’re doing. Habits are powerful, but also mostly unconscious and invisible. Sometimes they need an outsider to help facilitate dialog within the organization, to speed up the accommodation of change, and to help them include everyone in a change of direction. Usually my work includes some mix of all of these things.

   Important decisions are made every day. Many of them seem small, and may escape your notice. There is plenty for a consultant to observe, even if not there full time.
7. 

   July 27, 2012

   Allan – Stainless Steel Cable

   I absolutely can not imagine consulting on anything that I am not an active practitioner in. It’s the experience that a person from the field brings to the table that you know you can listen to them. An anecdote from a similar situation helps relieve uncertainty. You have to be one to be good at the other. With respect.