As someone who’s done projects for over 30 organizations in my career, I’ve run across a wide variety of development methodologies. Most folks know by now that when an organization says they are “doing SCRUM” or “doing Agile” what they really mean, is that they are cherry picking practices that work for them, and avoiding those that are uncomfortable.

As a consultant, it is often not possible to help organizations with their development methodology without some initial wins. Who would trust their guitar technician to restore their 1960s Martin without first making sure the person can do basic repairs? It is during this initial first effort, whether as a technical lead at a product company or a consultant where we have an opportunity to lay the groundwork for future development process improvements. This post is about some key interpersonal skills that when used well on even small projects, will hopefully help you win the trust needed to move on to higher value process improvements.

Establishing Authenticity

If we want the best chance of organizations we do work for getting the most value from us, it starts with establishing an authentic relationship. This means from your initial conversations all the way through the conclusion of the project, you should get to know the people you will work with on a personal level. If you don’t show any interest in people outside of the work, it’s less likely that they will come to you when something’s really bothering them. And it is often personality conflicts, or issues in a person’s life, that block progress more than any technical hurdle.

Setting Expectations for Change

In 20 years of software development, I have yet to see a single SCRUM team get into a sprint and not have changes be necessary. The User Acceptance Criteria may have had some holes. The test plan wasn’t robust enough. The team didn’t think about compliance regulations. The list of opportunities for this to come up is endless.

Rather than bringing this up for the first time as it happens, I communicate at least once a week, in front of my entire team, a reminder that we as a team will run into issues. I remind them that we are humans, and humans can’t be expected to remember everything needed about a system through conversations.

I’ve spent heaps of a client’s money that insisted on a fixed bid design before starting development (no, I was not involved in the statement of work on this one), only to find that when engineering went to build it, 30% of the feature set that the product manager thought was part of the “minimum viable product” was still missing. This one’s solved by releasing early and often, but that’s another topic.

The key takeaway here is to be “real” with your client or immediate supervisor, and not leave them with rose colored glasses, thinking the process on your team will eliminate having to deal with changes.

Establishing Your Role

Whether you are a consultant or in a permanent position at an organization, how you work with those who you report to has a huge impact on the success of projects. In Peter Block’s famous book Flawless Consulting he outlines three roles in which one can interact with their “customer” on a project:

  • Expert: The expert swoops in, does something for the client, and then vanishes.
  • Pair of hands: The pair of hands mindlessly follows the client’s instructions regardless of whether they actually make sense.
  • Collaborator: The collaborator partners with the client to define the problem and create and implement the solution.

You want to get to the collaborative style, and start there if possible. I usually get an idea of how well this will go by bringing it up at the beginning of the project. Educate your client or immediate supervisor on these three roles and help them to understand the value of collaboration. If you get pushback, be prepared that what they probably want is an expert or a pair of hands. If you allow yourself to be relegated to this role, it greatly diminishes your impact.

Establishing Change Management Procedures

When changes do arise, as a technical person it can be tempting to bark “nothing new gets added in the sprint!” and I’ve certainly been there. In reality, new work often has to be added to a sprint to complete scheduled work within it. It is here where you can show leadership, helping the team to make the decision on when to add the new work and get it done in the current sprint, and when to push it to the next one. It is essential to establish change management procedures at the beginning of a project when other leaders at the organization are under the least pressure and most willing to hear advice on how to proceed.

Demonstrating Honesty

When you make a mistake, communicate it to those it will impact as soon as possible. But this too should be taken with a grain of salt. There is a right way to admit a mistake, where it is simply stated along with some possible ways forward, and a wrong way. The wrong ways I’ve seen this done (and done it myself!) is to admit the mistake, but either blame it on someone else, or to use positioning statements to trivialize the mistake. The first one is a problem because unless you are very careful, you can leave the dependent party feeling thrown under a bus. The second one is a problem because it leaves your client or immediate supervisor with a feeling in the back of their mind that you will not want to let them know about your mistakes. Both are bad for the relationship.

Positively Reinforcing Behavior Changes

When other people on your team begin to change their behavior to follow a process better, be sure to thank them publicly. If you are a consultant, thank people in front of their peers. If you are an employee, thank them in the most public way possible. This doesn’t have to be some big schmooze fest – just give credit where it is due.

Increasing the Regularity of Celebrating Progress

Insist that your team celebrates their releases in some way. If releasing multiple times a day, get together at least once a week! That’s one great team that deserves to celebrate progress! When people are reminded that they are doing a good job by getting out of the office and spending some time together (on the organization’s dime) it helps keep morale high as inevitable challenges are encountered. Especially if you are a consultant or someone new to the team, doing this will help other people accept you into their inner circle. This one is more important than you might think.


Have you used some of these approaches in establishing trust before making big changes with your company or clients? Leave me feedback below! Thanks for reading.

Category:
agile, consulting, process improvement
Tags:
, , , , ,

Join the conversation! 3 Comments

  1. This is great information. I especially like the part about the three different roles that a consultant can fill and how to establish the role expectations up front.

    I do have a question… You said, “The key takeaway here is to be ‘real’ with your client or immediate supervisor, and not leave them with rose colored glasses”. I agree completely. However, at what point do you do this when the sales process has given the client a deluxe pair of rose colored glasses in the beginning of the project? I’ve tended to be “real” very early, but sometimes that can hurt the initial excitement at the start of the project.

    Reply
    • Great question Kevin!

      I don’t like working on consulting teams where a sales person sets expectations without me unless they are on the leading edge of development practices, which is rare. In today’s world I think it’s that much more important that anyone in sales who is not doing the work themselves make no statements about schedule or practices without deferring to someone technical.

      The flip side of this is that technical folks can have a bigger impact if they learn to be a critical partner in the sales process. Unfortunately many programmers are introverts and don’t want to do this. Sales people understandably don’t tend to want to bring those personality types in front of a client early, so they need to partner with technical folks who are more passionate about the sale and the satisfaction of the overall engagement than just slinging code.

      When I don’t have this luxury (expectations were set without me), I have no problem being “Debbie Downer” from day one but it’s all about the tone when I deliver this message. I find clients and supervisors respect me more if I am brutally honest about the difficulty of whatever’s being asked as long as they understand that I’m telling them this because it’s just not reality to leave them with any other perception of the challenges down the road ahead on their project.

      I think the hard part sometimes is being OK with the client not feeling 100% comfortable. You can’t always please someone who needs results but disagrees with your approach when you know better. At some point all the whiteboarding and explaining runs out of steam and it comes down to how they feel about you as a person.

      Reply

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: