The Fickle love of Project Managers
But some of my best friends are project managers... really they are! But whenever I talk with them it always takes me back to my first date with the cute redhead (love you Charlie Brown) and you're meeting her parents for the first time. Yeah they shake your hand, laugh at your jokes and give you a pat on the back. And this might go on for a number of dates, but man... that first night that you bring her home late and KABOOOM!!! You just brought down the Wrath of Zeus on your scrawny teenage self and all you did was buy the little redhead dessert... because SHE wanted it.
Sometimes you can't win.
And that's what it feels like with Project Managers, they have a wide range of emotions that never quite make you feel like they really... love you. How does this manifest itself you ask?
Nirvana - Ahead of Schedule
Welcome to the Nirvana Project - because that is where your PM is - they love you, their graphs are all lining up, project milestones are being hit ahead of time. You'll notice a definite change in the mood of your PM; emails are now cheery reports on progress, status meetings progress in minutes with time to talk (and ask) about weekend activities. Invitations to lunch or going to get a coffee are extended... because hell... you're ahead of schedule. And finally, in their IMs they will even start using - emoticons :)
The only other time you might witness this type of "love" is when you are on a project that is not managed by the PM. In which case, you are not in the cross-hairs and phrases like "if you were on this I'm sure it wouldn't be behind" get thrown around.
Note: A milestone that is not on the project plan that has been hit does not constitute being ahead of schedule as this milestone never existed, this does not count as being ahead of schedule but rather work that might have interferred with the completion of the said schedule.
The Calm - On Schedule
Alright so the project's on track, people are working hard, not always skipping breaks, maybe taking shorter lunches, but no one is on their way to burnout city. The bugs are coming down - things are looking solid. This is sometimes referred to as the calm before the storm. Things are going well, everyone is tempering their excitement and running through the infinite checklists in their heads to make sure they haven't missed anything or forgotten something - "Wait did he? Yes he did... Oh and is she... Started work on it today". It's an uneasy truce, everyone thinks you can get there but there are questions... and doubts. The coffee invitation is still there... but now you're paying.
Reassurance - Slightly Behind Schedule
And now things aren't going the way anyone planned. We were doing so well, but that one bomb dropped and now we're feeling the pinch. Now's the time for YOU to step up, you now your PM is running through all distribution and calculations in their head trying to figure out how much they really are behind - is it a blip or is it a burp? No one knows and you're both confused. The best thing to do here is reassure your PM - you'll get to the bottom of it, put in some OT, figure it out and give him some quantifiable data (cause PMs looooove data). You can come out of this in two ways; one get the data, get back on schedule and gain some serious trust from your PM or you can flub it and lose some serious trust. In any case this is that moment I spoke of at the beginning - you brought their daughter home late (not by much), but it's still late - and they want answers - "stopped to fill up on gas is good" - "stopped to grab some weed is good". This phase is also known as the "Tipping Point". Recovering from a bad tip is very hard.
Fubar - Behind Schedule
Okay, so you're behind schedule, waaay behind schedule. And there is a slim chance you could get back on schedule, but its highly unlikely that its going to work - and at least everyone agrees on that. Meetings are tense, words are exchanged, its hard to imagine that just a few months ago you were laughing about how far ahead you were and how things were going so well... you were buddies, hanging out, chilling in break room... you have the photos to prove it. But now it's just grunts in the hallway, rubbing of the temples and long drawn out discussions. Yeah, it's time for the Fubar. In some cases, its not the fault of you or your PM but your PM will feel the pressure first, after all it's their job, their baby and there is a massive amount of trouble. I've seen PMs take this in stride and step up to show a lot of leadership, unfortunately I've also seen a lot more beatdowns and interrogations then I'd like to remember that really got us nowhere. The last project I was on actually had one of those Dilbert moments where we were all chewed out for an hour and then at the end got a "Keep up the great work guys, we're almost there". That's sad and its not the way to do things. The best success I have had when faced with a Fubar is to take the PM aside, just the two of you, take their baby and walkthrough what's going on, work the plan and put Humpty Dumpty back together again. This sounds like your run of the mill common sense, but some PMs just don't know - they don't know the initimate details of what you're trying to do, just the end goal and if in 10 minutes of talking with them you see their eyes widening, then you know you are making headway. They might hate you now, but you've got a glimmer to win them back. Just like that Dad that is yelling at you for bringing his baby girl home late, tomorrow morning you'll be out in his driveway tomorrow morning washing his car.
I've said it before and I'll say it again, I could never be a full-fledged project manager. I do some PM stuff but it doesn't hold a candle to some of these guys. The inspiration for this blog came from a PM I've been working with for the last few months - he's managing two very large, complex projects; one is ahead of schedule, ticking off the checkpoints, doing some extra work in between, all signs point to yes and the other is way behind and really trying to get going. Seeing his face change as he discusses each project is an amusement in itself.
The Architecture can't do that
This my friends is the Kiss of Death in software development. Want a surefire way to suck the air out of the room in seconds? Utter this line at your next feature review meeting. I love watching the room - scanning from developers to product managers to dev managers to sales to anyone else in the room - they are all looking at each other waiting for someone to jump in and offer some kind of an olive branch to let them breathe again. In the worst case, Sales starts to blame PM who starts to blame the Dev Manager who, if they are having one of those horrible days and is completely ignorant of the software suite, might look to the developer for answers.
The problem here is that it's the not the architecture of the product that can't implement the new feature(s). Of course it can, its software, you have IDEs, you built it, you can change it. Maybe you built it against some crazy convuluted design pattern that only Sara and her sister have full working knowledge of and they just bailed on the company and you really don't have a grasp on how it works or maybe its that the feature is so new that what you currently have in your software suite is completely irrelevant to solving the problem at hand?
These are not the faults of software architecture.
I've seen the look a developer has when he mumbles this statement for the first time, I've BEEN that developer who mumbles that statement for the first time. It's not a deer in the headlights look, it's a look of resignment where the developer starts to calculate all the different possibilities of what is being asked in the feature and they are evaluating it against what the system has and then factoring in how much time they have (there is a calculation here somewhere) and then it hits them - I can't give you what you want, when you want it without creating some steaming pile of dung that will do this and only this and become the bane of our existence for now and ever more. And the architecture takes the rap because it cannot quickly absorb the new features as fast as we thought it could, Widget A does not plug gracefully into the framework, instead it kludges in and requires a little finesse. Is this all bad, no not entirely, if this was the complete focus of your application/framework then yes this would be a bad thing, but in this case it is not you (as the developer) are trying to build a feature for a product for your company.
In the end, the problem is the delivery model.
No matter the role you play in feature delivery of a software product, when you hear someone mumble this answer your first thought needs to be to stop what you are doing and get to the bottom of the real issue (DANGER WILL ROBINSON! DANGER WILL ROBINSON). What really is the problem? Did we cut corners on the last release and now we are paying for it? We can fix that. Have we pushed out critical bugs that need to get fixed before we think about this? Are the expectations too heavy in too tight a timeframe? These are all questions that have nothing to do with the architecture and everything to do the management of the software.
When you dig into the reasons behind "The Architecture can't do that", it rarely ends up being the actual architecture but rather something else altogether that you never would have thought to be the issue in the first place.
Transformers 2: Revenge of the Bad Software Release
You'd have to be under a rock to know that the latest Transformers movie was just released 2 weeks ago and has made a ton of money to date (before being smashed by Harry Potter last weekend). At around the same time, some of the actors, writers and directors part of TF2 have all been panning it as a horrible film - it sucked, we knew it when we were making it, but we did it anyway, etc. But at the time, none of this criticism was out there and that movie went on to make a ton of cash (mainly because we thought it would rival the first one and improve on some missed points - yeah I'm a huge Transformers fan).
So here's my question, if everyone working on the movie thought it was bad, why release it?
Take the above scenario and apply it to any software release you are working on - your last release has a ton of bugs and loads of incomplete features, if it was your money you would have never bought it. What? You did a release that you are now panning AND you are doing this after I (your faithful customer) put down my money to purchase said software (which we all know software costs a lot more than a movie ticket). Taking that kind of response in our field is quite the kick in the gut to your customer base and will woefully hurt the trust account you have established with your customer - "Why should I believe you now?", "Can you really tell me that this is the piece of software that it going to make me happy?"
Time, resources and market demand are always going to be the key drivers pushing you to releasing early to get your product out the door - build that buzz, get that first sale, get feedback on that new feature, deliver on a customer promise - it all has a purpose and you will never release a piece of software that does not have something missing and does not have bugs in it. But the one thing you must, at all costs avoid doing is shipping a piece of software that you are not proud of. If you do not believe that the work you and your team has done is the best to your and their abilities, then it shouldn't be released, if you want your customers to believe in you, and remember the only they are going to be able to do that is through your software, then you better believe in what you are pushing out the door. Otherwise you're going to have a "Revenge of the Fallen Customer" on your hands where your own team criticizes it, your customers don't like it enough to not come back and renew their warranties and in your next release you're desperately trying to bring them back saying that is the what is should have been.
The clearest case of this happening in our industry was the release of Windows Vista and later Windows 7, critically panned since Day 1 Vista was a black eye to Microsoft, I don't know the numbers, but I definitely know a lot of work was done to win customers back with Windows 7 and there have been many a report of Win7 being what Vista should have been when it first went Beta before being released.
A Manager's #1 Job
As a software manager, I'm responsible for a lot, I go to meetings, I run project and feature development, I interview new employees, work with my team through design meetings and yes from time to time I still do some coding to keep me honest. But at the end of the day there is one piece of my job that is the most important and if I don't do it all others would fall by the wayside. No it's not status reports, team meetings, enterprisey design like architecture stuff or anything else really related to technology... no its something much simpler - the professional growth of every member of my team... and no... this is not done through annual performance reviews.
So why's this so important? Well the hallmark of a great team is when they can execute without their manager around, that means the ship stays on course and keeps heading North, maybe making some well-thought out corrections along the way, but they get there. This is not an easy thing to do and cannot be done overnight, it involves a two things a) working with everyone as a team so everyone understands the skills that member A brings to the table and b) working with everyone individually - you know where you want your team to be and now YOU need to push them in the direction to get it done. So how do you do this?
Hire the Right People
If you hire bad people, you WILL get bad results. That little voice going off in your head, it is little now, but if you hire this guy, the moment he screws up the first time (like maybe being 10 minutes late) that voice is going to become a blaring siren, Game Over, time to move on. Trust your gut instinct, at the end of the day you might get pressure from HR or others to just "make a hire" but at the end of the day, they are not the one that has to work with this person for a hopefully long time. Chemistry is important in an interview, some people get very nervous, what's the best way to relax people? Get them to talk about their accomplishments, then dig in some very open-ended questions so you see how they think. Remember you are not looking for someone like you, but someone to complement your group, fill the gaps you have and bring some extra-added value to your team. At the end of an interview if you're not willing to fight to get that guy, then you don't really want him, so move on. But if he is a great fit for your team well then the real fun begins.
Challenge Them
I have not many a person in my life that does not want to try something different or new at some point in their lives. People might have different thresholds for when they want to do this, but at some point they will. It is your job to get them to identify when they are getting close to that point and give them the boost they need to motivate them for the next big thing. I am constantly asking my team if they are happy with what they are working on, is there something else they want work on, etc, etc, not because I like job sharing or copious knowledge transfer but because I want them to enjoy what they are doing and I want them to keep pushing themselves to be better. If you are not challenging your team, then they'll get bored and start looking elsewhere and then you're done for.
Give them Feedback
Everyone wants to know how they're doing but what everyone doesn't tell you is - "Hey can you tell me when I really blow it so I know not to do it next time?". Yeah sorry, no one is going to stand up and tell you that... but if you don't tell them when they screw up they are never going to get better and really bring their game to the level you need it to be at. I'm not advocating telling someone they are a piece of garbage with no future, but if mistakes are made on a feature you gotta put them in the shoes of your customer or support group? If code blows up because it was sloppy you need to point them to it and hard - "Look I know you wanted to make it faster, but really 45 threads? That was the silver bullet here?". The key is to give them feedback in a way that you clearly indicate the bad but at the same time highlight how you know they can get there and then give them the opportunity to do it. They will get mad at you, most likely they will cross their arms when discussing it and look like they want to leave... the keepers are the ones that go away and cool off and come in on Monday with new ideas looking to get better, these are the guys you want to hold onto because you know they want it as bad as you.
Back in the early days when I had just became a manager I made a massive misstep by hiring someone I knew was not a good fit, but I bowed to the pressure and hired them... six months later I sent them packing, I ignored my instinct and wasted 6 month's of their time and mine. I can now look at every person in my group and tell you I am at a different stage of growth with all of them, some are ready for the next challenge, some are chewing on feedback and some are doing a kick-ass job day in and day out while helping others on the team grow. It goes counter to popular culture, but I'm willing to miss a few dates to see a guy work through a problem and come out the other side better for it because the next project he's on he'll do it better then if he never had the opportunity to try at all.
Anyway you Want It
A day doesn't go by without someone coming up to me asking "Can we do this?", "Does the SDK let us implement Feature X?", etc, etc. Everytime I get this question I always give the same response - "Is that something you want?". From there it can devolve into some back and forth about API limitations, how we have built things to date and what our partners can do, blah, blah, blah. In all honesty, I hate these questions because it is essentially putting ME into the position of creating YOUR scope and limitations for what YOU are trying to achieve but tying it back to ME so that I initiated the limitation (and sadly I have been in these meetings). But on a higher-level, I always ask myself why people feel the need to constrain themselves so early in a project that it hampers the ability to deliver a great solution? So - the answer I give to any questions that sound like this is always the same - "Yes, I can do anything you want"
Now the initial response to that answer, is sometimes a chuckle or blowing it off but I always come back to it. I am a firm believer that I (and anyone for that reason) in my profession can really achieve this. I build software in a variety of different lifecycles (Keeping the lights On, Service Releases or File > New > Project), it doesn't make a difference to me, but based on what I know, I can create anything you want. Now could I build an Army Training Simulator? Well not overnight, but over X amount of time and with some learning and hardware yeah sure I could figure this out.
But here's the deal - I'm not going to be your limitation, I'm not going to be the guy that shrinks your vision or tells you what the API can do. Whether I'm your software developer, Dev Mgr or Product Manager, I'm not that guy. I worked with a Product Manager once who wanted to read through the SDK docs we were using to see what the limitations were and drive his requirements off of that. I wouldn't give them to him (nevermind the fact he could have downloaded them), and it ticked him off. And when I had to justify my position on this stance it was because I didn't want to give him a sandbox to play in where everything was safe and known, we were building a new product and I wanted fresh ideas and fresh features brought to the table. I'm the technical guy, so let me deal with the fall-out on that end, you be the requirements/PM person that comes up with the RockStar vision that is going to inspire everyone to want to make it work.
I know most are thinking - yeah but what about Time and Money (see Army Training Simulator). Yup, you are never going to get away from those two absolutes when it comes to building software, but there is no rule saying you can't come up with the dream and push it to the next release right? If Time is your limiting factor, but you have the money to spend on it, then get people on it now for the next release? If Money is the great limitation, then shelve it for a later date, that's OK.
Fast-Forward to now, I am handling both roles - Dev Lead and PM. I've just finished writing the bulk of the requirements for our next release and even with the knowledge of the APIs we use - I threw everything out to my team - this is the dream, this is Feature Perfect, to make this release rock, this is what I want. Now the next step, let's work on how we are going to get there. The worst thing I could have done is immediately constrained things for them to the point of them not being able to inject any creativity or innovation into the end solution. At the end of the day that is what everyone really wants - new ideas, new approaches, better designs - not the same old thing that worked before.
Oh and in case you were wondering, yes the title of this blog is from the Journey song - Any way you want it