Respecting Team Diversity

I talk about team diversity in my training.  With a world filled with individuals, we have to learn to respect the differences of others.  If you don't, I think you will live and work in a lot smaller world than me.  More importantly, if you don't respect the differences of others, I'm a lot less open to have anything to do with you.   It doesn't matter if we're dealing with functional roles on a team (developers vs. QA), race, gender, or religion.  Respect the differences of others or keep your narrow minded thoughts to yourself.  Actually, that's not right.  Communications is good.  Tell everyone what you're thinking so we know who you are. I have two examples where lack of respect for diversity was clear to me but not others.

Scenario 1:  The Cut Scout Pack Leader

My son is a cub scout.  We have raised him to respect everyone, regardless of their many differences, to include gender, color, or religion.

The other night, we received an email from our son's Cub Scout Pack leader.  It probably would not have bothered me so much if not for the fact that the pack has scheduled events on Jewish holidays and then rescheduled events around Christian holidays.  Let me be clear that on a den level, the leaders have been very good in speaking to the boys in more general terms. "Be respectful, whatever your faith".  My hat is off to these fellows.  I appreciate that they go the extra mile.  So here is the email we got from the pack leader:

Hello Pack,

This sunday is scout sunday February 5. Please wear your class A uniform with pride in church that day. If you would like to participate but do not attend church regularly. I offer up New Market Methodist church on north alley just off 874 behind main street in New Market.  Their service is at 9:30 and 11:00 am.

A scout is reverent. This is one of the points of the scout law, and the reason for scout sunday.

I read no mention of what a boy should do if he attends a temple, synagogue, or mosque. I guess they are just out of luck.  I think it was the last two sentences that put me over the edge.  "A scout is reverent. This is one of the points of the scout law, and the reason for scout Sunday."

Actually, reverent is defined as feeling or showing deep and solemn respect.  Clearly something the pack leader lacks for other religions.

Scenario 2: The CIO

Back in the day, I was the Manager of Software Engineering.  My team was amazing and I would do anything for them.  One particular item of note was the fact that probably 90% of them were from India.  Now, I say I'm German but I wasn't born in Germany.  When I say my teammates were from India, I mean they were here on H1B visas from India.  Why is that important?  Because, as far as I was concerned, I needed to respect their cultural differences and try to accommodate them in any way I could.

So, who was the person who lacked the respect (or understanding) of their cultural differences?  The CIO just could not understand why the team would rather have Diwali off instead of Christmas.  He didn't understand how offensive it was when he said to order lunch for the team and recommended I just order "a couple different kinds of meat sandwiches".

Do you know someone who lacked respect for diversity?  What did you do?

Image Source: Pictofigo

Motivate Your Team

You should be looking for ways to motivate your team every single day. You could bring them donuts or bagels. You could give out monthly awards or public recognition. You could also give them a pep talk.  All it takes is one minute of encouragement to change their day for the better.  So, here is your pep talk for today.  Take 55 seconds, watch the video, and I challenge you not to have an awesome day.  This kids could be the next Tony Robbins!    

Team-Based or Value-Based

I'm currently reading a book about Systems Analysis and Design.  In a chapter discussing Agile Methods, one of the statements really rubbed me the wrong way.

The Agile Manifesto is a set of team-based principles...

For the last 6 or so years, I've assumed the Manifesto was a set of "value-based" principles.  That is, at its core, Agile is about delivering value or eliminating waste.  What I like about the Manifesto is it leaves a lot to interpretation.  It doesn't spell thing out to the N^th degree.  But, I'm very curious what the community thinks.  How would you describe the principles?

Please leave a comment.  Tell me what you think.

---

Zombie (Team Member) Motivation Techniques

What skills do you need to lead your zombie army?  Sorry, what I meant to ask was, what skills do you need to lead your team?  Motivation techniques can be as unique as the individual. There are a lot of people out there who identify themselves as project managers, those tasked with managing inanimate resources (time, scope, budget...zombies). Though those skills are necessary, there is a need for skills to lead teams and manage stakeholders.  I'm talking (soft) skills to lead, manage, and inspire human resources.

Provide Feedback

You can't expect your team to operate in a vacuum.  As a team member, imagine if your manager provided an annual review and then didn't provide feedback to you until the next annual review.  That would be a clear failure on the part of the manager or leader.  I believe managers and leaders are obligated to provide continual feedback to the team.  Now, if managing a zombie team member, no feedback is needed.  They'll keep searching for brains until someone either shoots them in the head or decapitates them.  Either way, providing feedback will probably only result in you being chased by a horde of flesh eating zombies.

Recognize Performance

Let's look at this from both a positive and a negative perspective.  If your team is not doing a good job, you need to recognize their performance (both as a group and individually) and give constructive feedback so they can meet your expectations.  If they are meeting your expectations, you need to reinforce what you like so they can continue to meet those expectations or exceed them.  Recognizing zombie team performance is like watching someone win a pie eating contest.  They eat (brains).  Put another brain in front of them and they'll eat it.  Repeat ad nauseum.  How well they perform is limited by nothing but time.

Negotiate

Don't be an unreasonable person.  Recognize that some team members will not feel comfortable with some goals set for them.  Win-win negotiations should help you arrive at the desired outcome.  With constant feedback and motivation, believe any team member can reach any goal you set for them.  Note, don't set the bar too low and give them a false win.  Do not believe in "stretch" goals.  Negotiate realistic outcomes.  Most importantly, don't negotiate with zombies!  Zombies are like terrorist, except they have a green skin tone and look at you like an opened can of Spam sitting in the hot sun for a week.

Motivate and Persuade

Have you heard the idiom you can catch more bees with honey than you can with vinegar?  Get to know each of your team members personally and find out what motivates them.  What's important to them; coffee, family time, or recognition?  You may buy one team member a coffee gift card, tell another to go home early, or thank another publicly in a meeting.  Everyone has something that motivates them.  If you ever order lunch for the team, make sure you consider everyone (individually).  When you set schedules, try to consider individual family obligations.

Respect

Respect is fundamental in any relationship.  You will get the very best from people if you have mutual respect.  I once had a superior ask me if I wanted my team to respect me or to like me.  My response was OR?  Why can't they do both?  Teams will respect you if they know you would never throw them under the bus to protect yourself.  Take the hits from management if you don't reach a goal.  Protect the team at all costs.  As a result, the team should do everything they can to prevent that situation from happening.  Zombies are not team players.  They want your brains and they will throw you under a bus at the first opportunity.  Don't judge them. They know not what they do.

Summary

If you're going to be a project manager who is managing people, you need to have good soft skills.  That is, you need the ability to engage and interact effectively with your team, obtain acceptance, build consensus, and provide assistance, direction and leadership.

I'm a strong believer that if you treat people with honesty and respect and your motives are good, it will come back to you.  That means be genuinely concerned about the well-being and happiness of your team.  Listen to them and guide them.  Whatever the business side expects of you will get taken care of.  Your team will rise to the challenge.  I've known project managers who lacked some of these skills.  Either they didn't provide feedback to their team or they were unreasonable or demanding.  The team was miserable, productivity went down, and that manager blamed the team.  It was a vicious cycle.

Sometimes, you just have to do what you know is right and face the consequences.

Sometimes, you have to fight the urge to eat brains.

Photo: flickr user frogmuseum2

The Hateful Cycle of Apathy Hits a Nerve

Have you ever stuck your neck out and get no support?  Did the trust among that team start to break down? I've seen it happen first hand and Geoff Crane wrote an awesome post over at Papercut Edge about it.  He called it the too-common cycle of apathy. The post hit a nerve with me. At my previous engagement, the Engineering Department was used to being railroaded by management. Promises were always made on their behalf and they found themselves working long hours and weekends. If they didn't make the goals, those who made the promises would never take ownership. If goals were miraculously accomplished, the same person(s) would jump into the spotlight. After I was brought on board, I didn't have a problem looking a Director or CIO right in the eye and telling them I disagreed with them. Sometimes they backed down and sometimes they didn't. But everyone at that company knew I was honest and would speak up if I didn't agree with something. Everyone knew I was looking out for my people, my department, and my company. I believe positive change rolls up hill, just as sh*t rolls down.  Though I'm no longer with that team, I have no regrets for backing them up and providing support when they needed it most. Those who bullied so many are no longer there either.  Though there was an attempt to silence my voice by decapitating my team, others in the organization saw through the ruse.

I think sticking your neck out is worth the risk. If I think you're right, I'll support you.  By doing that, I build trust with my teams. With trust, my teams will do anything for me. With that, anything is possible. What can I say, everyone is happy but the party you had to confront in the first place. Yep, it's certainly worth it.

Thank you Geoff for getting me fired up.  Now go check out his site!

image courtesy of Papercut Edge

Mitigated Speech and Project Negotiations

Try this

Mitigated speech is a linguistic term describing deferential or indirect speech inherent in communication between individuals of perceived High Power Distance. The term was recently popularized by Malcolm Gladwell in his book, Outliers, where he defines mitigated speech as "any attempt to downplay or sugarcoat the meaning of what is being said". He described 6 degrees of mitigation with which we make suggestions to authority:

1. Command – “Implement this”

2. Team Obligation Statement – “We need to try this”

3. Team Suggestion – “Why don’t we try this?”

4. Query – “Do you think this would help us in this situation?”

5. Preference – “Perhaps we should take a look at this an an alternative”

6. Hint – “I wonder if we will run into any issues by following our current process”

As I observe the command and communication structure between a PMO and its members and contractors, I have the opportunity to witness mitigated speech every day.  Being direct (command) doesn't always work.  People need to learn to be flexible in their requests and negotiations if they have the hope those in power will implement new strategies.  Additionally, learn to read those around you to know what degree of mitigation you will use IF you intend to use it.

As I read Outliers, I started to think of the relationship between mitigated speech and Appendix G.8 (negotiation) of the PMBoK.

Negotiation is a strategy of conferring with parties of shared or opposed interests with a view of compromise or reach an agreement.  Negotiation is an integral part of project management and when done well, increases the probability of project success.

The following skills and behaviors are useful in negotiating successfully:

• Analyze the situation.

• Differentiate between wants and needs - both yours and theirs.

• Focus on interests and issues rather that on positions.

• Ask high and offer low, but be realistic.

• When you make a concession, act as if you are yielding something of value, don't just give in.

• Always make sure both parties feel as if they have won. This is a win-win negotiation. Never let the other party leave feeling as if he or she has been taken advantage of.

• Do a good job of listening and articulating.

To summarize, stride to be a win-win negotiator and be aware of the mitigated speech you are using to conduct your negotiations.

How To Effectively Manage An Offshore Team Of Developers

There are probably two primary reasons you would go with an offshore team. (1) Your customers are also offshore, or (2) you're hoping to save money on development costs.

I'm going to assume your reason is number (2).  Though this post is brief for such a complicated topic, it should give you some things to think about.  Yes, you can certainly save a lot on development expenses. Then again, it can come back to bite you in rework expenses if there are communication issues.

How do you bridge the language barrier? (1) You need a go-to guy or gal who speaks the same language as your developers but will be working at your location. This is a must. Your probability for success is going to go way up by ensuring there is no breakdown in communications.

How do you receive the quality of code you need? (1) Use continuous integration (2) Use test scripts to understand requirements (3) Use short iterations (4) Have regular builds (5) Separate teams by functionality (not activity)

How do you communicate? (1) If you can afford to send/bring someone (an ambassador) over to work with the other team at the beginning of the project, do it. (2) It is critical that your "go-to" has a daily meeting with the team. Select a method that allows each side to see one another. (webcam/Skype) (3) Have everyone use Skype (VoIP) and/or a chat client for one-on-one communications. (4) Keep a Skype connection open between the offices. (5) Use wikis or other collaborative solutions for common project information. (6) Stay away from email, unless it is for formal communication. Information is going to get lost along the way and it will take longer to clarify.

Remember to use parallel communication methods, not serial.

Free Project Team Organization Worksheet

Project Team Organization

Today I'm going to write about (and provide) a free Project Team Organization worksheet to complement the Project Charter Template so many have downloaded. Both files are free for download, modification, and distribution. [Team Organization Worksheet] [Project Charter Template] When using the Project Team Organization worksheet, note that there are 4 sections:  Structure, Roles and Responsibilities, and a Responsibility Matrix, Project Facilities and Resources.  I'm going to focus on the first three.

Step 1: Describe the organizational structure of the project team and stakeholders, preferably providing a graphical depiction (organization chart).

Step 2: Summarize roles and responsibilities for the project team and stakeholders identified in the project structure above.

Step 3: Complete the responsibility matrix for each of the project roles. As a graphical depiction of a more detailed perspective of responsibilities, the matrix should reflect by functional role the assigned responsibility for key milestones and activities.

Step 4: Describe the project's requirements for facilities and resources, such as office space, special facilities, computer equipment, office equipment, and support tools. Identify responsibilities for provisioning the specific items needed to support the project development environment.  Hey, you're people need places to sit and equipment to get their work done.

With preliminary approval, copy these values into Section 3 of our free Project Charter Template. Upon Project Charter approval, apply the identified team members to activities in Microsoft Project or your selected Project Management application.

Another thing I would recommend is leverage the data from this worksheet in your Communications Management Plan.  You've already identified people and their roles or responsibilities.  The most important thing to remember is do what makes sense.  This planning worksheet isn't required to do a Charter.  It's supposed to make things easier for you and lower the risk of not knowing who is on your team and what they are responsible for.

[Team Organization Worksheet] [Project Charter Template]