My Perspective on Remote Work

The proclamation by Marissa Mayer last month, informing Yahoo employees that working from home is no longer an option, really seemed to bring an important conversation front and center. The memo that started this firestorm stated in part -

"To become the absolute best place to work, communication and collaboration will be important, so we need to be working side-by-side. That is why it is critical that we are all present in our offices... We need to be one Yahoo! and that starts with physically being together."

I've worn a lot of hats over the years.  In each instance, there has been a common goal:  Be as successful as possible.  Being "successful" is unique to every situation so that's why I include "as possible".  But when you add happiness to the equation, what does that mean?

If you are in a job where you are rapidly iterating a product and continuously collaborating with others on your team, being face-to-face or side-by-side with your teammates will provide an opportunity to be as successful as possible.  Being collocated is no guarantee for success but being distributed (dislocated) is going to certainly limit your chances.  Leaders should focus actions more on making their companies, projects, or products successful and less on trying to make employees or teammates happy.

Now, don't get me wrong.  I'm not saying we shouldn't be empathetic to the needs of others.  I'm just saying there comes a point when you need to look at the costs and the benefits of remote work.  If the team is not realizing its potential, because one or more of them are working remotely (because they want to and not because they have to) we have a misalignment of goals.  Why would they sacrifice potential success for their personal comfort?  Well, businesses are trying to find ways to incentivize their employees. They hope that by incentivizing then, they will be happier and more productive.  But see, that is part of the problem. There is a belief that the incentives will make them happy.  Happiness is one of the byproducts of satisfying work, which can be derived from feelings of mastery, autonomy, and purpose (link to talk by Dan Pink).  I believe (in some cases) the work-from-home incentives will have a negative affect.

When companies hire us, they are NOT hiring us to make people's lives better.  They are hiring us because there is value locked up in these companies and they are unable to produce.  They are hiring us to help them unlock that value.  Period.

What's one of the first things I would propose if I coached teams at Yahoo? Bring the team together, face-to-face or side-by-side.  The only thing I disagree with in the Yahoo memo experpt  is where it states "…we are all present in our offices…"  I propose they get out of the private offices and into a team space.

Balanced piece about the pros and cons of working at home on Fast Company

Image Credit: Pictofigo

Favorite Project Management Quotes

There isn't a week that goes by that I don't hear some awesome quote or analogy.  I put as many as I can into my mental back pocket, hoping for an opportunity to pull one out at a moments notice.  When you're stuck for a quote or analogy, to help someone understand what you're trying to say, do you ever ask yourself what's that awesome quote that I just heard the other day? Here are 10 that I keep handy.  Are there any quotes you would like to share?  Please add them to the comments section.

---

• Because the needs of the one... outweigh the needs of the many. - Star Trek III: The Search for Spock, Captain Kirk.  I like to use this quote when explaining the contrast between egoism, utilitarianism, and altruism (servant-leadership).
• The more they overthink the plumbing, the easier it is to stop up the drain. - Star Trek III: The Search for Spock, Scotty. I'm admittedly a Star Trek geek.  I've used this once when trying to articulate Lean thinking.  I also segway into the untrue but compelling story of the Million Dollar Space Pen.
• The thing is, Bob, it's not that I'm lazy, it's that I just don't care. - Office Space, Peter Gibbons.  I like to use Office Space quotes, particularly when referring to empowered teams and while drinking from my Initech coffee cup.  Mmm'kay? Greeeeat.
• Luck is not a factor. Hope is not a strategy. Fear is not an option. - James Cameron.  This quote was on the back of the LeadingAgile t-shirts we all wore at Agile 2012.  I still have strangers walk up to me and ask about its origin.
• That which does not kill us makes us stronger. - Friedrich Nietzsche.  I think of this quote during almost every run I take.  After taking an inventory as to my physical condition, I have a mental debate as to stopping or keep pushing forward. I keep pushing forward.
• We keep moving forward, opening new doors, and doing new things, because we're curious and curiosity keeps leading us down new paths.- Walt Disney.  I've told my son over and over again to challenge the status quo (I don't call it the status quo because he's seven) and when given the choice, try new things.
• When we go into that new project, we believe in it all the way.  We have confidence in our ability to do it right. - Walt Disney  The power of positive thinking and an empowered team.
• Plans are of little importance, but planning is essential – Winston Churchill.  Another almost identical quote came from Dwight D. Eisenhower: Plans are worthless, but planning is everything When I talk about the Agile Manifesto and how we should be responding to change over following a plan, this becomes one of my most commonly used quotes.
• Stable Velocity. Sustainable Pace - Mike Cottmeyer.  This quote appears on the back of the LeadingAgile running shirt. It has become the unofficial motto of my life, as it applies to work, family, and running
• We don’t need an accurate document, we need a shared understanding - Jeff Patton. I was attending Jeff's session at Agile 2012, when I heard him say this.  It really resonated with me.  I don't know if the quote was scripted or impromptu.  Regardless, when I recently quoted him at a Project Managment Symposium in Washington DC, I saw over 400 project managers nodding their heads.

This post was originally published on LeadingAgile

Social Norms at Work

I recently gave a talk in Michigan on the topic of servant-leadership.  Unfortunately, servant-leadership is something that is painfully absent in so many organizations.  Just a few years ago, it (servant-leadership) was not something I had even heard of.  Going back and reviewing the PMBOK made me realize two glaring omissions.  There is a lack of content on stakeholder or team engagement and there is a lack of content on leadership.  Fortunately, in the last few years, I have enjoyed books by authors like Clay Shirky, Seth Godin, Dan Pink, and Dan Ariely.  I've also met and interacted with some amazing people in the Agile community.  I now interact differently with my peers, as a result of these experiences.  I now apply my social norms at work.  What are social norms?  They are patterns of behavior in a particular group, community, or culture, accepted as normal and to which an individual is accepted to conform. We all go to work and we all get paid to do it.  Too many times, we take things for granted.  We don't question the things we do or the things that happen to us.  I'm pretty sure this is based on conditioning over a long period of time.  Perhaps we need to start treating those we work with more like those we socialize with.  Next time you interact with a fellow employee, ask yourself if your behavior is socially acceptable.

Social Norms

Within an organization, where we are working with other people, things can get twisted.  Some exhibit bad behavior and believe it's somehow forgivable because we're all getting paid.  Well, I don't think that's acceptable.  It's very interesting to see the same people behave differently, when not in the office environment.  Why is it some people forget basic manners or common courtesy, when in an office environment?

Case in point, I hold the door open for people, regardless if I know them or not.  I see this as socially expected behavior.  Socially, I expect a thank you.  To say I expect it is a slight embellishment.  Outside of the office, I still expect a thank you.  Unfortunately, at the office, I've started to accept not getting any reciprocation.  There are a few people in my building that I don't personally know but I still hold the door for them.  They won't make eye contact with me and they won't say thank you.  When the situation is reversed, these same people do not hold the door for anyone.  But, I refuse to accept their behavior.

We all need to strive to understand and empathize with others. People need to be accepted and recognized for their special and unique qualities.  Assume the good intentions of your coworkers and don't reject them as people, even while refusing to accept their behavior or performance.

Drawing:  Pictofigo

HT: Business Dictionary

Manipulate or Communicate

I'm always looking for ways to communicate with team members, vendors, and customers.  When trying to understand the range of communications, I recently reassessed what I thought the opposite of communications was.  I no longer believe it is silence. Rather, I believe it is manipulation.

2 Examples:

[1] Buying a Vehicle

You go into an auto dealership. You want to purchase a new vehicle.  You want to pay the lowest price as possible and the dealer wants to make the highest profit possible.  Rather than coming to the table and negotiate based on this mutual understanding, both sides try to remain as silent as possible.  Both sides are trying to manipulate the other, in order maximize the outcome in their favor.

[2] Getting a New Job

You apply for a position with a new company.  You are interviewed and the company believes you are a good fit.  As soon as salary is discussed, the manipulation traditionally begins.  Both sides are trying to manipulate the other, in order maximize the outcome to their respective favor.

How it should be

In the case of the auto dealer, they should be honest about their cost of the vehicle.  They should explain how the dealership and sales person will be paid.  They should ask the buyer what their needs and wants are.  Is it cost or is it the make/model (scope)?  The key here is everyone needs to be honest! I'm not a pessimistic person, but with a (sales) relationship like this, I feel there will always be manipulation involved.

When negotiating salary with a new company, the relationship is different.  Hopefully, both parties want a long term relationship built on honesty.  I propose the applicant tell the potential employer exactly what they are currently being compensated, including benefits and bonuses.  The applicant should explain their motivation for seeking new employment.  Were they being paid too little; Were their benefits too expensive; Was their work/life balance all out of sorts?  Was the previous job just unfulfilling?  The new company should take this into account before making an offer.  They should explain the range of compensation to be offered.  Both sides need to be frank and honest. I recognize this is one of the most uncomfortable conversations you ever have.  That's why I believe both sides should be honest and over-communicate.

How it applies to a project or program

In the previous two examples, both involved negotiations and communications.  From my perspective, these can all be win-win scenarios if we are honest and over-communicate.  Over the weekend, I participated in a live web interview with Peter Saddington from AgileScout.  I stressed the need for over-communications on projects and gave 3 examples on how to do it.  You can over-communicate by using information radiators, daily stand-up meetings, or by having an open-door policy (with rules) with other meetings.

Information Radiators

Use burn-up, burn-down, kanban, or task boards in both executive work areas and team work areas.  I would recommend displaying enterprise (program) level information where all of the executives can see it.  I would recommend displaying team (project) level information where all the teams can see it.

Short Feedback Loops

Have daily stand-up meetings for each of your teams.  Have daily "scrum-of-scrum" or "team-of-team"  meetings to roll information up to an enterprise level.  There is no excuse for anyone to NOT know what is going on every day.

Open Meeting Policy

For all of your meetings, have some simple rules.  Understand that some people are allowed to talk and some are only allowed to listen.  But, all should be informed.  Now, I recognize not everyone should attend a Retrospective meeting or Executive Board meeting.  But, everyone should know what the outcomes are.

Let's face it, the enterprise wants to get as much productivity out of its employees as it can, in order to reach its tactical and strategic goals.  In order to do that, you need empowered teams who trust each other.  You need free-flowing communications.  I'll say it one more time. Be honest and over-communicate.

Just One Agile Thing

I met with the Agile Influencers of DC, on Friday night.  The focus of the conversations for the evening was Agile Adoption.  One of the questions asked (I'm paraphrasing here) was

If you were on a project, and you could leverage just ONE "Agile" THING, what would it be and why would you choose it?

This is a little like the first episode of Surviver but it is a good exercise to make you think about what you find valuable in Agile. Would you choose the use of information radiators? Perhaps you favor retrospective meetings?  Or perhaps, you love the use of cross-functional co-located teams?

When I was asked, I chose empowered teams.  Look back at the Agile Manifesto and one of its principles.  Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

I believe if you build a team of professional and empowered people, you increase the probability of project success.  Give your people some general rules to follow and have the faith they will make the right decisions.  It beats the hell out of trying to control them!  Empowering them also gives you more time to help them when they really need you, rather than making trivial decisions.

So, what would be the one thing you would choose?  Why?

Like the image? Find it at Pictofigo

---

Team Building Techniques - 5 Stages

Ladder

When I think of team building techniques, the one place I didn't think to look was the PMBOK®. In chapter 9, specifically 9.3.2, the PMBOK details Tools and Techniques of Developing Project Teams. For those out there studying for the PMP®, this might be a good time to write this down or print the blog post. The PMBOK lists 5 stages of development that teams may go through, usually occurring in order.  What PMBOK lists is relatively academic.  It won't actually help you with team building.

Those stages, with the exception of the last are based on the Tuckman ladder[1].  Forming – Storming – Norming – Performing. It's a model of group development, first proposed by Bruce Tuckman in 1965, who maintained that these phases are all necessary and inevitable in order for the team to grow, to face up to challenges, to tackle problems, to find solutions, to plan work, and to deliver results.

Why PMI found it necessary to add the last one, I can't tell you.  But, in the event you think it may appear on the PMP exam, here is what PMI thinks you should know.

Forming. This phase is where the team meets and learns about the project and what their formal roles and responsibilities are. Team members tend to be independent and not open in this phase.

Storming. During this phase, the team begins to address the project work, technical decisions, and the project management approach.  If team members are not collaborative and open to differing ideas and perspectives the environment can be destructive.

Norming. In the norming phase, team members begin to work together and adjust work habits and behaviors that support the team. The team begins to trust each other.

Performing. Teams that reach the performing stage function as a well-organized unit.  They are interdependent and work through issues smoothly and effectively.

Adjourning. In the adjourning phase, the team completes the work and moves on from the project.

The PMBOK concludes by saying a Project Manager should have a good understanding of team dynamics in order to move their team members through all stages in an effective manner.

Two stages I think they missed include  Empowering and Supporting.  If PMI can insert Adjourning into this list, with the sounds of One of these things is not like the others in my head, I think I can add my two stages.  Still, if you want to pass the PMP, perhaps you should just stick to their list.

[1] Tuckman, Bruce, 1965. Developmental Sequence in Small Groups. Psychological Bulletin No. 63. Bethesda, MD: Naval Medical Research Institute.

Image source: Orange Country Register