On leaving Sapient and 3 lessons learnt

A few months ago I left Sapient, the company where I had worked for 15 years.

Whaaaaat? You left Sapient!?!?

A career of business cards
A career of business cards

That has been the most common response I’ve gotten, and it’s understandable as 15 years is a long time, and being a “Sape” had in many ways become part of my identity. As I wrote my farewell email, it struck me how many people I wanted to thank for the help and support in my career who are no longer at Sapient. So thank you to the innumerable people I have worked with over the years for your advice, support, encouragement and laughs – in ways big and small you made an impact on my career and my life.

As I move on to a new chapter in my career, I took some time to reflect on what I learned, and want to share the 3 I feel are most impactful. These are by no means unique observations about Sapient, nor unique to Sapient. However, in my 20 years of professional experience, including other consultancies, two startups, and dozens of clients, finding a organization with these attributes is rare.

 

Culture

You cannot talk about Sapient, especially in the early years, without talking about culture. We were obsessed with building a culture that would build a great company. How we chose to define our culture is interesting in itself, and is the subject of an HBS case study. What your culture is should be unique to each company and relate to your business context and purpose. However how you craft, promote, and use your culture is what I want to highlight here. My observation is that corporate culture is either what you get or what you do. Meaning, if your culture is a set of values that hang on the wall, rather than a shared set of expectations and values that you use every day to make decisions and shape behaviour, then you aren’t crafting a culture, and you will simply get the culture that your employees bring in with them. To make a culture a cohesive force I believe you have to use it daily, you have to talk about it with your teams, you have to visibly use it in your decision making. And most difficult of all, you have to, as we used to say, reject non-fits like a virus. Sounds harsh, but time and again I have seen people of great skill and experience who were culturally poisonous retained in organizations well past the point where the damage they were doing was greater than the benefits they brought to company. No doubt this is a hard decision to make, but forcing the conversation is the difference between believing in your culture as an asset versus a slogan.

Openness

Openness means different things to different people, but in the context of Sapient it meant being direct and generous with your feedback to others, and more difficult, open to hearing the generous amount of feedback you were going to get. Every day. I believe this was essential to developing a learning organization, where at our best we were in a state of continuous improvement for years. We would debrief as a team not just at the end of an iteration, but after every client presentation, meeting, or checkpoint. During our intense workshop sessions we would debrief at lunch and the end of day. By debrief, I mean we went around the room and critiqued ourselves not just as a team but each other. Now, some feedback and coaching experts will tell you that constructive feedback should be given one on one, not publicly. And that works for individual coaching, but we were trying to raise the game of the whole team, and it worked. If everyone heard everyone else’s feedback they could learn from each other. It requires a culture of trust at the team level for sure, and it wasn’t for everyone, but if you had “purple in your blood” as we used to say, it was what you expected.

People

Growth Model
Growth Model

Like many companies Sapient certainly focused on hiring bright, talented, ambitious people. And being in Cambridge, MA certainly gave us access to lots of that kind of talent. But it was a focus on people, and in particular people growth, as we used to call it, that I feel accelerated  the growth of the company. Almost all companies today say people are there most important asset. But executives and managers at many companies don’t behave that way. At the time, Sapient made a decision to aggressively manage the growth of the entire company.  So what does that mean? It meant in our case not just the feedback intensive culture and openness discussed above. It also meant constantly looking at our team, whether it was a project team, an account team, the office or region’s leadership, and actively looking for, or creating, opportunities to push people out of their comfort zones. Because we believed (and we experienced) that is where people grew the most. It was our own take on that old adage that sometimes the role makes the person. And that is so unlike most of corporate America in my experience, where if we need a new leadership role the most likely place to look for it is outside.

What was also really different is we used to talk about it as a whole office, and I remember we’d draw the simple diagram to the right on the board to explain, we are choosing to live right on the edge of growth and failure, because that is how we are all going to grow the most. And just as importantly, when people struggled or failed, that had to okay. It meant we knew where they needed coaching and support, and at that moment, it’s critical to dial it back a little and give them the support to work on those growth areas. Was that perfectly executed? I am sure not, and I may have been lucky in the people who I reported to, but nonetheless, that was definitely my experience for the bulk of my tenure.

So that’s my two cents. Disagree or have something to add, leave a comment.

Sad Truths About Project Rescues

This tweet got me thinking about the many project turn arounds I have seen over the last 20 so years. We’ve all seen the scenario play out time and again. The business pushes for more scope, faster delivery, and lower budgets. The project teams (I’ve seen this with both creative and IT teams) feel tremendous pressure to acquiesce to these demands. Even if the project manager makes a valiant defense of a rationale budget, scope, and timeline eventually they get worn down or overridden by their management and the inevitable happens. Management is promised a project the team knows in their hearts to be unrealistic, and everyone begins slogging away, hoping for a miracle, hoping for some break. Maybe some key elements on the critical path will come in early. Maybe the clients/sponsors will sign off on key deliverables within the planned 2 reviews. Almost never happens. If this is an IT project the odds are even lower, due to the vicious cycle of late and over budget projects which convince business sponsors that they need to dictate tighter budget and timeline constraints, knowing they will be missed, which in fact causes more projects to fall behind if not fail.

Then you have a project in Trouble. A project that is Red. And often, at least in the organizations I’ve worked with, people are brought in to to turn things around. I have had several of these put on my plate over the years, and the formula for success is usually very straight forward: tell the truth around what it is going to take to get the project done, or how much scope needs to come out to hit the time/budget. Yes, there are plenty of other things to do like look at the team structure, review and question the scope, re-vitalize the team, rebuild business confidence, look for efficiencies, etc. But for some reason that must be deeply connected to the human condition, when you first come on to turn something around, people are able to listen to reason. Even when what I am saying and calling for is exactly what the previous manager said, it was only once the project was in real jeopardy that the team was listened to.

And that last bit is exactly what I have found to be the key to success in turn-arounds. Listen to the team. Actually sit down with them, as many one on one as possible, and get them to open up about the project, what’s working, what is not, where they see the risk. For more thoughts on taking on a project in flight, see my previous post on the topic.

As for avoiding the situation, I would love to hear what others have found to be successful. And I would love to hear more pithy quips like the one that got this post started.

5 Simple Rules for Joining a Project Underway

Note: this is content migrated from a blog I no longer maintain “The Grumpy PM” and was originally posted on March 21, 2009

Okay, there’s really nothing simple about joining a project as the PM when the project is already underway. You’re going to need to jump right in and keep the project on track while you ramp up on everything about the project.

However, while you could probably write a small book or a long article on this topic, I have found that five is the magic number as far as the limit of “action items” or feedback points you can give someone and hope that they would retain it. Three is probably better, but I am hoping my readers are brighter than that. [;)

1 – Invest in Relationship Building
Take the time right up front to meet with all your team leads and key stakeholders one on one. Have an agenda going in, but try to keep the meeting informal and ask open ended questions to get people talking: ask each how they feel the project is going, what is working well, and what could be improved. You want to get several things out of this meeting – you need to quickly build rapport and find areas of common interest you can leverage to begin to build relationships with those you haven’t worked with before; you want to see what areas are highlighted for improvement, so you can direct attention to them; perhaps most importantly, you want to try to sense how people are feeling about the previous PM no longer being there, which is probably why you would be joining after the project started. While the urge will be great to bury yourself in the project charter, scope statement, WBS, and project schedule, resist, RESIST!

2 – Get the Up to Speed, ASAP
In direct juxtaposition to the above, you will need to ramp up quickly on the project, but don’t do it at the expense of rule 1 above. Ideally, you can get access to the project repository/library/whatever and gain an understanding of what the project is about, but if you have to do it after hours or on the weekend, it is an investment well made. I usually go for the project charter, scope documents, schedule, and risk register. You need to demonstrate competence and confidence to all the stakeholders you interact with in that first week or two, when everyone will be judging the new PM, and the team will be deciding if they are going to rally around you. As you review, make a list of questions you want to ask of team members and stakeholders as you meet with them.

3 – Trust the People on the Team
It may be the hardest thing to do sometimes, but you are going to have to trust the people already on the project to do the right thing. They have history on the team, they (should) know what they are doing, and you aren’t going to succeed without them. More than this though, you need to show them that you trust them, by word and deed. In relationship to point 2 above, tell the team that you don’t know everything, they are the project experts and you am going to rely on them. When an issue comes up or decision needs to be made facilitate the decision making process, but get the people with the project tribal-knowledge, so to speak, involved. Another thing that seems to work with most people is to ask them to explain aspects of the project they are the expert on.

4 – Do Something to Shake Things Up
I am not a psychologist, so I can’t put this in proper technical terms, however I have found a significant, positive mental burst of energy and motivation can be had from the team by make some changes right away. It can be how meetings are run, how reports are presented, or even something like changing around how people are physically seated. Go for some low hanging fruit that you know will benefit delivery or the project. Certainly, you will be approaching the project with a fresh set of eyes, and you should try to bring enthusiasm with you to the assignment. Share your observations and ideas with the team in an engaging and motivated fashion.

5 – Resist the urge to blame the other guy (or gal)
I can’t remember a single project where I have jumped in after it was started where people on the team didn’t blame issues on the previous project manager. Don’t be that guy, it’s shows a clear lack of accountability for the project you now are responsible for, and it is unprofessional. Be proactive and identify all the deliverables, action items, issues, etc. assigned to your predecessor and put them on your to-do list. Stay classy PMs!