Written by Last year I was sitting with a colleague. Our intense, time crunched project had finished and I was giving my feedback to her. She had done a great job, had been highly reliable, and it had been clear for me from early in the project how to manage her in order for her to succeed. She made the comment that I was the best project lead she’d ever had. This comment was echoed a couple of times before and after that, in that environment.
While everyone likes to get kudos (ignoring self-loathing curmudgeons) every now and then, this was a new environment for me and to be getting it so emphatically took me by surprise. Some time later, it started to become pretty clear to me why they had said this. Why it was probably more genuine that I had expected.
There is a classic formula for disaster, very CMMi level -1 (nod and wink to those in the know on that), in the application project space. The first is selling at all costs, and having those involved in the sale not directly accountable for the overtime and issues of the delivery team. This “win win win” thinking gets to trump everything else by mantra, with that mantra being “win the business, and we’ll solve everything else later.” I have never seen this not come back to haunt the project, ever. The standard implied assumption is that the technical folks involved are over exaggerating the issues, or that they simply fear the unknown. Only a handful of times have I ever worked with a set of folks who understood the principal of the book Blink, where while their heads didn’t want to believe the technical guy they had involved in trying to secure the business, their guts listened and the plan got changed. Too often any agreements made between the sales and technical folks is sacrificed by the sales folks in the final contract. Very often the sales folks seem to believe, or at least advocate, that the final language or provisions are either equivalent to those agreed to with the technical team or are superior because the language is ‘more loose.’ I can’t remember any team ever saying “thank goodness we had that loose language in there,” because at the end of the day, you don’t want to pull the guns out and start shooting at the customer. All you did was build in vagueness and confusion from the outset.
So how to avoid this? I have to go back to my silicon valley days to really think of how this was done well. The notion that the different parties involved (sales, business and technical) got to own parts but more importantly, if any one wasn’t happy things could not move forward was key. The idea that everyone had to really think things through, identify collective issues and then be involved throughout the delivery process was also key. Probably the most important thing was that the technical delivery folks (and in one company I worked with the technical and the delivery teams were not the same folks) were really supported. The idea of “working people to death to make it work” was being viewed as not a solution. Maybe that’s because we worked crazy hours as the norm, so there weren’t any extra left to give.
My singular piece of advice is not to exclude the technical representative, or trump them, when it becomes inconvenient to the business/sales folks. This one thing happens the most. It’s like being a junior partner, and ultimately fixing the mess will lay with you.
The second, which happens in larger organizations, is putting people in charge who are from the Configuration School (SAP, PeopleSoft, other packages). Application development is not the same beast. I was working on a bid a while ago where we had a configuration project manager, and former architect for a configuration system, involved.
At first he was of the opinion that technical stuff and project management was the same, whether it was for SAP or a large .NET project. Over the couple of weeks that we worked together, and lots of talking together, he came to realize that it’s quite a different thing. For example, simple assumptions for how long a “simple issue” can take to resolve within the two different domains was very different. He brought up an example of a configuration issue and explained how it was really time boxed, there was no reason for resolving that type of issue to be able to take more than 1.5x the amount of time shown in a special spreadsheet. However, when I presented the .NET scenario for a similar issue, there he realized that things were indeed different. Because we were building the entire underpinning system for that code with other code we had written, what seemed to be simple on one level may be simple in principal but because of the implied assumptions made during design and implementation, it may simply not be possible to do, period. This took some time to really sink in, but afterwards we were able to get along much better in the planning and preparing for the project.
My advice on this front is normalizing the knowledge basis of the members of the team. This is done by really talking through who you are, who they are, where your skills and experiences lay, and building up a body of knowledge on all fronts as to why you are here. Then it starts being about identifying and neutralizing the default prejudices. Or more specifically, about figuring out in an upfront manner where the trust is and where the “I’m sorry, but whatever number you tell me I am going to assume that really it’ll take 30% less than that to get the job done.” This won’t solve things, but it’ll reduce the opportunities for disaster.
The last thing is about respecting the word No. Early in my career I was given an opportunity to step up and be a team lead on a huge project. I had only been out of university for a year, but had been running my business for a couple of years by that point, and now I was at a Big Consulting Company doing Big Work in ‘the valley.’ The project was 60 people, about 14 million dollars, and we were building an ecommerce site back in ’98. The project had schedule ninjas and spreadsheets flying everywhere, we had developers working around the clock and I was thrown in to bring control and order to one team, and then another.
I learned there to say No, with a capital N. It’s hard to be in front of your management team, in front of the customer’s CTO (for a world recognized company), and to be put in the position where your management team is effectively trying to get you to lie and commit that you will do the impossible, so that when you fail, it will be your head on the spike. I skated that day, using all of my political and business acumen, to present the real situation while avoiding calling my managers outright liars. They were not happy, the customer officially wasn’t happy, but the CTO sought me out later and told me that I was the only person right now from “that team” that she trusted.
Our management team was not happy that the project was running late, and that while the specs kept getting changed even before the files had finished saving, we the programmers were obviously to blame. My fellow team leads and I did something that I would have never dreamed, and it started with me making a glib comment that we should strike and shut the project down to get the attention and power we needed. That day, and for the two or three after it, I learned what it meant to put your principals on the line and be willing to be shot instead of shooting your fellow man. Our plan worked, and things got put online. I got moved shortly after things started to stabilize to being an architect on a huge project.
Ultimately the project failed because the damage was already done and the customer ran out of money. I took that less of saying No with me, and I had to use it at Microsoft and I have had to use it since. Sometimes saying the Gandolf “You shall not pass” is right beyond measure, and having the nerve to say “If you don’t like it, you can fire me. This will give me a great story for my next job interview” when you actually mean it (even if you are scared out of your mind) can bring both strength to your team, but your manager as well.
See, one of the things that I’ve learned again and again is that power really comes from the individual batteries that present them. If you don’t provide sufficient push back, if you don’t say what is right by you AND if you don’t listen to those providing push back and listen to what is right by them, then you only allow the traditions of the past to prevail. More than once I’ve had a manager who said “You know, you’ve given me the excuse I need to go back and push this the right way. I’ll have to blame you, but we can get it done.” Often if you don’t take a stand to make things right, you prevent others from being able to do the same.
All too often we have large companies start throwing managers and spreadsheets at a problem without actually really addressing what the problem is. Too often these days I see managers get swapped out, because while the team is working around the clock, every weekend, if someone above thinks that the horse is not being whipped enough they get swapped out. This is very short term thinking in terms of the relationship with the customer, with the team, and ultimately with the grassroots of the customer who work side by side with the team.
I think of a line that came out one day, which has been repeated back to me. A member of my team was struggling with an issue and at one of our daily morning huddles that I run, I told that person and the team “You don’t have a problem, we have a problem. So ‘we’ are going to solve it.” The idea that a team is there to back each other was new to them, and that is sad.
