The Art of Project Management: Expert advice from experienced project managers in Silicon Valley, and around the world
TOPICS:

Part 4 of 6 on Teamwork: Bottom Lines – A tool for achieving interpersonal teamwork

A friend once emailed me with a burning question about “A Situation” with a particular team member. What had started out as some displays of mild to medium recalcitrance – the team member resisting some advice in preparing for a design review, then being pointedly late on a couple of key deliverables – had spread to an underlying feeling of tenseness in every interaction. He really didn’t know where it was all coming from, and thus what to do about it.  But nobody would say that this pair was working together well as part of the team at this moment!

This request made me stop and think about the various tools I’ve picked up over the years for getting to the bottom of such issues. One in particular I’ve found incredibly useful for making discussions of differences less personal and easier to resolve is having a discussion of personal working-together “Bottom Lines.”     This approach was introduced to me by a colleague years ago, and I can safely say that its use salvaged a fraying professional relationship and has kept us from killing each other ever since.


More...
The concept of “bottom lines” first acknowledges that each person has important likes and dislikes, ways of working, preferences for all kinds of things. These bottom lines can be anything from whether you will accept work phone calls over the weekend to how you want to be communicated with or tasked. Some of these items are mandatory: If those bottom lines are not met, the working relationship could be seriously impacted. There’s no right or wrong – just what people need to work productively and happily such that they can and will make their maximum contributions to the team’s goals.       This conflict resolution approach simply aims to get each person’s “bottom lines” on the table and figure out how to meet each other’s bottom lines if at all possible.

For instance, when I first started working with a consulting colleague 10 years ago, I started getting pages and phone calls on Sunday evenings. The guy was single with no kids, and worked all the time. I, on the other hand, worked lots of hours but had a 2-year-old daughter and was in no way interested in having family time disrupted on Sunday nights. I started getting mad and tense and short with him over this issue, and pulling back from some project discussions I should have been in because I just didn’t want to deal with him. (Sound familiar?  Classic “teamwork” issues: people stop appearing, participating, contributing because something has them steamed and it’s easier to duck out of sight.)   I didn’t use the “bottom line” terminology yet, I just new it was a serious fundamental issue for me:   “I can’t stand for anyone to except me to just take an interruption for work at any old time I’m with my family.”   If he needed me to answer my phone without fail on Sunday nights, then I wasn’t going to work with him.
When I finally got mad enough to raise the issue, he immediately suggested that we have a bottom lines discussion.  We had a two-hour meeting, sitting outside on the Stanford campus, relaxed and free form, listing and discussing our bottom lines: what ABSOLUTELY had to be there, or not, for each of us personally, for us to be able to work effectively together?   Turns out his Sunday calls were not so much about getting me on the phone directly on Sunday nights. But he did have a bottom line about responsiveness. He went crazy if he didn’t know for sure that he’d be able to get me when something was urgent, or have me respond within a certain period if it was less urgent. So, we worked out a communication system for prioritizing communication and handling emergencies and committing to response times : ensuring we both got what we needed.   There were a few other subjects like that:  min and max work hours we were each after, minimum notice for putting me on a plane anywhere, how each of us wanted to constructive feedback on any work or teaching: details of how we’d work together well as a consulting team.

Here’s another personal example, a  bottom line actively in effect to this day:   It’s a bottom line for me that if someone reaches a roadblock on something that had a critical “must make it” deadline associated with it, they are to tell me immediately. Not, “Oh she’s so busy, I don’t want to bother her with this.” Not, “Oh it’s not critical, I’ll just take longer to finish it.” Not, “Well, it’s not finished to her requirements yet, so the right thing is to not let her see it until it’s perfect.” It is an absolute requirement that I be told as soon as they think the deadline is in jeopardy. I can deal with changes and delays if I’m given the heads up.   I absolutely hate it when I don’t have an accurate picture of progress and my options are removed by non-delivery and non-notification until it’s too late!   It’s the kind of thing that makes me write someone off as “someone I can’t work with well.”  But of course, all that is often needed is making this preference clear!

I suggested this technique  to my friend with the recalcitrant team member.  I thought the two of them might be experiencing some unwitting but huge “style” conflicts. You know, when one person’s way of talking, assigning tasks, whatever, is like fingers on a chalkboard, enough to send the other person over the edge!    For example, could the engineer be taking the project manager’s questions about status or conducting design reviews as micro managing?   “I just can’t work with anyone who thinks they have to get in my technical business by asking such detailed questions. I know what I’m doing!”   Whether or not my friend thought it was reasonable to be asking for the information, the other person obviously didn’t, and every time he violated the guys’ bottom line, he was probably getting written off as a desirable teammate and manager-deserving-of-my-time.    The bottom line discussion would be a neutral way to raise the issue.  I told my friend he could even give the person examples like this so he’d  feel it was safe to open up a bit and be honest.  Asking what he prefers and can’t stand would communicate respect and hopefully get him to explain what was really going on, so they could hopefully find a mutually acceptable approach. 

The key is that when you do this together – each person getting to express the things that really matter or tell the things that really make them crazy – it can get past negative interaction issues fast.  Just the relief to be able to be honest about something that is SETTING YOU OFF or MAKING YOU CRAZY.     In this case, my friend did go try it  – and learned to his utter and absolute surprise that they other guy just DIDN”T LIKE the exact way my friend tended to talk to him (“always in a rush, terse and abrasive and disrespectful, and with no explanations of the whys of your  recommendations.”).  Well!.  My friend’s communication style evidently made him feel picked on, and as a new guy to the company, he was especially sensitive to being “told”, like he had no mind or expertise of his own, rather than “worked with” collaboratively.    He was able to express two bottom lines to my friend:  “I need to hear why, from your experience, you’re strongly recommending that I do things a certain way, and I need not always get cursory communication in “drive by” mode.”  They agreed to set up a regular talk to compare notes and look ahead every couple of weeks during the project.  My friend agreed to explain the whys.  His bottom line requirement back was that the guy truly listen to the new ideas and not get defensive at being suggested new ways to do things.

Important point:  The bottom line discussion HAS to be followed with concrete action.   You’ve gotten some great information just from talking to each other. You should be able to see where any key mismatches in your expectations and theirs were generating conflict; where you weren’t meeting their expectations. And you should have a much better understanding of each other’s critical bottom lines, to help form a more solid foundation for working conflict-free.  So first identify easy wins – things that can be changed right away to honor the bottom lines. Set an informal check-in point a short time down the road to compare notes on what you’ve each changed, and agree on whether or not things are working better, whether or not the conflict has been handled.  

Overall I’ve found this technique to helps team members  move  themselves from the pain and discomfort and tension of conflict to a better foundation for working together and each making their important contributions to the project.   Rather than stepping back as I did to avoid interactions with my colleague, they can use the bottom line discussion to collaboratively resolve the areas of conflict   –  and get on with the project.  

Share

About the Author

Cinda Voegtli, Founder, President, and CEO of ProjectConnections, has over 20 years of project management experience in start-ups, rapidly growing companies, and large corporate environments. Her portfolio includes a wide variety of activities: developing products; managing projects; building organizations; and implementing and improving project management, portfolio management, and development processes. Her project experience includes communications and medical systems, IT application and infrastructure, industrial automation, desktop software, facilities construction, biotech drug development, and aerospace/government programs. Cinda has held director and VP-level positions managing budgets of up to $50 million across large portfolios of projects in technology development companies, and has provided senior management consulting to clients such as Hewlett Packard, Lam Research, Pacific Bell, Dow Chemical, NASA, FAA, Nellcor, Aviron/MedImmune, and Mobil Corporation. She is a Past President of the worldwide IEEE Engineering Management Society, an author and speaker on engineering and project management, and co-author of a Fortune 500-targeted book on rapid product development. Her specialties and project loves include projects involving technology development (high tech and IT); applying PM to short iterative web and marketing projects; adjusting PM and development processes to work on everything from simple, small projects up to large messy complex projects. Why she's still in project management : "Because there is nothing more satisfying than getting a bunch of incredibly different people rallied around a business goal to successfully execute a messy uncertain complex project together." Best project advice she has ever received: "Make the process work for the people, not the other way around." cvoegtli@projectconnections.com
Creative Commons License
Note: This work and all associated comments are licensed under a Creative Commons Attribution-Noncommercial 3.0 United States License.

Leave a Reply

*