Whenever I’m acting as a coach, a facilitator or a consultant for a team there’s one thing that struck me every time – how much being a practitioner helps me in performing in the role. And when I say a practitioner I think about doing similar work as the teams do on a daily basis, and not only coaching, consulting or facilitating. It’s like doing my regular stuff except it is a bit different. But then, I’m solving similar problems every day, am I not?
Personally, I could imagine myself being full-time consultant, although I believe I’d lose something this way. On one hand full-time consultants are exposed to more different environments as, well, this is what they do – they visit different organizations and work with them. On the other, consultants come, consultants go – most of the time they don’t hang around to see the final results of their work. After all it isn’t their responsibility to make the change stick.
However, when I think about consultant versus practitioner perspective the biggest thing that still keeps me on practitioner’s side of the fence is fear of disconnection. At this moment whenever I’m “selling” you something it is likely verified in the organization I work (or have worked) for. Been there, seen that, done that. You can trust me.
It’s not that I read this trendy book or my company is selling training of that method. It’s not that I spent much time on conferences listening to all those published authors, thought-leaders and whatnot who are extremely knowledgeable but are also long gone from real jobs, you know, the ones that produce something tangible.
I really touch the crap. And live with it. So whenever I’m wrong there’s no one else but me to clean up the mess.
So what I’m thinking about here are two things. One question is for consultants that are reading the blog (I know there are quite a few of you): how are you coping with the issue of disconnection? Or maybe it is just non-issue?
Another question would be for those of you who are considering hiring some help to sort things out in your organization: would you prefer a consultant or a practitioner and why?
I’d be glad to hear as many voices as possible, so if you are considering commenting the post but not really sure, please do – you’ll earn my infinite gratitude. And you definitely want it because it is exchangeable for a beer when you meet me.
Subscribe RSS feed
Follow on Twitter
Subscribe by email
7 comments… add one
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)
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 .
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.
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.
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)
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.
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.