10 things Project Managers wish Developers understood

Well I've been very busy the past few months - most of it adapting to a new role as a Project Manager - technically I'm called a "team lead" or a "director" or a "senior manager" - depends who you ask, but when it comes down to it I manage the dev team to a project plan in cooperation with a product manager.

Being on the "other side" now for a while it's been a real eye-opener. It's definitely true that it's hard to relate to someone until you've walked in their shoes for a good bit. Having worked with project managers several times before, I've always wondered about why things were a certain way - ways I thought I would have done things differently.

Well not anymore - now having "walked the walk" I thought I'd blog about the things that most developers on a team won't realize until they are the person in charge.

10) Information Overload: I wish I could focus on one thing at a time but I've got a million people coming at me from all directions.
There's product managers, support, management, customers with their needs, developers, other team's manager, architects and developers. That's a lot of relationships and information to manage so don't be surprised when you encounter the following type of interaction.

Developer: So, you remember that issue with the GUI last week?
(subtext: that really critical issue I finally figured out the solution to?)

Manager: Which issue is this?
(subtext: I just spent three hours replying to emails to 14 different people and I'm wiped)

9) Work Pressures: The Manager can get too excited or stressed by the pressures and try to "tell you the solution". Push back (gently) if it doesn't make sense.
When you're the manager and don't code - you get all the responsibility (worry) about meeting the deadlines but very little control over it.

Those managers who have spent time as developers sometimes like to think we can just give other developers the answer. But that doesn't work - developers are a creative and (for better or worse) egotistical bunch (me included) and we want to impress our bosses rather than just take orders.

I've learned to ask guiding and information-seeking questions rather than suggest solutions e.g.

• "So how many files are impacted by this change?"
• "How will this SQL change impact performance?"
• "How will the GUI change impact our key user flows?"
• "So if we fix this bug, what are the odds we might break something else?"
  

8) Project Risks: New technology = Risk
Anytime you kick off a new big project, developers love to use new technology - but the effort can't all be about new technology - with new technologies come risks to the project. There may be efficiency gains but do they outweigh the risks?

I've had managers who just said "No" to new technologies, but they didn't understand the desire of most developers to improve themselves and learn the hottest new technology (e.g. Ajax) / framework (e.g. Spring). It was so demotivating. Also there's often some productivity gains to be had from trying new technologies so it's a short-sighted idea to adopt a blanket "no".

I've also had managers who only said "Yes" and then the project got bogged down in technical issue after technical issue and didn't deliver the functionality anywhere near on time as the developers had a large learning curve (or several curves) to overcome.

As a developer I understand how developers love to learn - but as a manager I have to balance the motivation of my developers with the goal to deliver a functional product.

7) Productivity: The best managers insulate developers from the craziness that goes on in middle management - bad specs, crazy ideas, changes in priority, too many meetings.
You think your pointy haired boss is nuts - you should see the people he/she works for! :-) The problem with modern day software is there's so many teams involved - the dev team, the QA team, support, client relationship, consulting and everyone's got their own viewpoint, their own goals etc. They see either bigger pictures or completely different pictures entirely.

Some developers have some idea that this goes on - if you do thank your boss - they're buying you time to be productive and do the things you love - Code!

6) Capitalism: The reason this company exists is to make money - sometimes you have to do some apparently silly things to get the money.
Customer's aren't always logical, they have their own goals, their own viewpoints (seems to be a theme here). Sometimes the Sales folks have to commit to things to get the deal. They sound reasonable enough unless of course you have to implement them!

Yes you have a right to be ticked off at folks who oversell - but then again the company you work for is (hopefully) there to make money. The Sales folks are the "rainmakers" so the best you can hope for is to build a constructive relationship whereby they consult with you about what's possible and what's a stretch.

5) Doing the things we don't like: We have meetings because they're needed
I know meetings interrupt your favorite activity - coding - but they really can't be helped in some cases. I need to know that you're aware of what's going on - frankly I have very little insight into how things are going until things are nearly done.

Fortunately as a now sometimes-developer I use tools like FindBugs, PMD, Checkstyle etc. to check on the code and use Unit Tests and Code Coverage to see how's the quality roughly holding up. But all those are proxies for the real thing - the quality of the product from a user's perspective.

So how else can I quickly get to know how things are going - meetings. Sorry!

4) Information Overload II: I can't be expected to remember EVERYTHING.
I forgot we promised to meet to talk about "that" question. I wanted to put a reminder in Outlook but I got interrupted twice and then I was called to my boss's office - I forgot. Be gentle on your manager - they're really trying (or should be) - if I make a mistake let me know. Keep us in the loop - just find the right moment.

3) Information Overload III: Hold off on the details - First tell me why I should be concerned
Developers come in all shapes and sizes - there are the ones who bottle up all information, stay heads down in the cube and only come out when they're done. The scary thing there is you don't know they're done until . . . . well . . . they're done. I can manage that one pretty easily - I try to "ping" people and check-in. Hopefully not too often.

The other side are the developers who think you want to know every piece of minutiae and that you understand the impact - for example:

Developer: "So you know that new Finder class team X implemented? Well they created a new Factory method which isn't thread-safe. I mean they're nuts don't they know that our thread pool will etc. etc. . "

Manager (who was deep in figuring out critical dependencies in the project plan): (thinking) is he gonna think I'm a moron if I say "Huh?"

It's better to say what the impact is and hold off on the details e.g.
"I think our new multi-user scenarios are going to have some problems with the new code from team X".

That gets to the point (there's a problem) and stops me from having to think too hard (why should I care about thread safety in a particular class) - you should be able to tell from the smoke already coming out of my ears? :-)

2) It's not all about you (the developer)
I was guilty of this one for a while when I was just a devleoper. I really thought that of all the issues faced by the team mine were the most significant. I'd get peeved when issues I felt were important were being ignored. But the reality was I wasn't aware of many of the points listed above. Wow, perspective is everything.

1) It's good to be the King
No it's REALLY good :-) Previously as an Architect or lead software engineer I had a position of influence but little power. Now I have people reporting to directly to me. I control their reviews, their raises, how much they work and how late, which project is next. I still consider myself an "Architect" at heart and I love being in the code - but it's nice; knowing the technology, how developers are often motivated etc. and now to finally REALLY have a big say in what gets done and how.

For example, there's some really complex code we've written lately - quite fragile unfortunately due to it's (necessary?) complexity. As the developer I probably would be too lazy to write the full set of unit tests or wouldn't have the time. As the architect I'd know that we need to do that but very often I could never convince the project manager to let the developer spend the time. Now I'm project manager and can read the code coverage numbers as well as know many of the user scenarios.

So I had the developer write about 40 unit tests covering a very comprehensive range of scenarios. It took about a month to get them all done (ouch!). But in the process we actually found three new bugs. Ultimately though we've mitigated a lot of risks that were in that component.

Now when new bugs come in from the field or from QA, we fix them more quickly and then we can quickly re-run the unit test suite. We also add unit tests for that new test case we just discovered. Now I as a manager I know when the unit tests run green - that despite the code complexity, we're in pretty good shape from a risk/quality point of view.

It's a balance of course - we've discovered more unit tests we need to write for this component (based on how our users are using it in beta) but we're under the gun for the next few weeks in another area so we'll get to it - but not yet.

It's also good when it comes to hiring time - too few managers know how to spot a good developer - having been a developer and spent a good deal of time on screening questions and interview techniques I feel that I and the team are pretty good at identifying strong folks. I usually do the screening so that the developer's on my team only spend time interviewing really strong candidates who don't just "talk the talk" or have keyword-heavy resumes and don't really have the talent to back it up.

Postscript: I'll also write an article coming from the other perspective - things that developers wish managers knew.