Project Management Advice from PMs and Developers

July 10, 2007 9:09 AM

Project managers and delevopers, please give me advice so I can be awesome and give developers proper care.

I am moving from doing what is essentially project management for books into a position as a web project manager at a small ad agency. The folks who hired me know this, and they know I have a lot to learn about the new processes, workflows, types of team members, etc., and I should have some good mentoring. At the same time, I really want to do a great job and I really want to have good relationships with the developers.

So please tell me, developers, what do you like and dislike from your PMs?

Project managers, what are your hints? Any good links I should check out?

Thanks so much.

posted by dame to work & money (21 comments total)

As a former developer and current PM, I can tell you the following:

1) It's politically incorrect to say, but developers are statistically more likely to be introverted and different from "average people." That doesn't mean they're socially inept, etc, but you may need to do some feeling out to see what kind of communication they prefer. Some prefer email or IM, and dread face to face meetings, others are the opposite. Get to know your developers individually. While this does apply to all people and not just developers, I think it's especially relevant for devs because they're so often introverted, quirky, etc.

Side note: The firm I just started working at seems to almost exclusively hire socially adept developers who may not necessarily be extroverts, but they're affable and not "the stereotypical computer geek."

2) The absolute worst thing about being a developer is when PMs make promises on behalf of developers that they simply cannot deliver in a realistic timeframe. Involve your developers in your decision making and be very careful what promises you make to clients on cool whiz-bang features/functionality.

3) PMs are managers, meaning they need to make sure that the work gets done. However, the devs are usually not the "direct reports" of the PMs, and this sometimes causes a sticky situation. On one hand, the PM has every right/reason to dole out orders. On the other hand, as a dev sometimes my feeling was "you're not my freakin' boss, you're the manager of the PROJECT." Act as a team member, not a boss. You're taking care of the management/business minutiae so that the devs don't have to.

I could go on, but I think that's a decent start... good luck in your new position! I'll be keeping tabs on this thread for other perspectives, for sure...
posted by twiggy at 9:19 AM on July 10, 2007 [2 favorites]

If I were you I would be more worried about managing the clients!
posted by mrbugsentry at 9:28 AM on July 10, 2007

I was eating lunch but then was going to post...everything that twiggy just said. Down to the socially adept developers. The main thing is the relationship with developers. I would recommend sitting down with each of them when you start and getting to know their work style, communication preferences, etc. You may need to ask them for compromises, but at least you know where they are coming from.

I think the most important thing is that the developers understand that you are working with them, not against them. The more support the developers give me, the more realistic they are with timelines, the better I can help support them when things get crazy and the client starts yelling. I can deal with all that and let them focus on the work, and the ones I have the best relationship understand that, because they know "sweetkid deals with the crap, and I can just keep programming and doing what I love." But if they spend the whole time arguing with me and feeling like I am pulling a power play, we never get anywhere.
posted by sweetkid at 9:31 AM on July 10, 2007

twiggy has given great advice. One thing I'd add, that kind of tacks on to his #2 point, is to be very honest and humble about what you do and don't know about the technical ins and outs of the project you're managing. Don't assume that a feature will be easy to code, and definitely don't assume that you know how it should be done. As a developer, there's nothing more frustrating than having someone with little to no programming experience say something along the lines of, "it's just a simple if-then, right?"

Some developers will be more than happy to explain why Feature X is going to take so long to develop (because it lets them show off their expertise), others are just going to want you to trust them (because they don't like explaining to lay-people, because they think you won't get it, because they're too busy, because it really is that complicated, etc.). If you're honest with yourself and your developers about what you do and don't understand, they'll respect you a lot more and be easier to work with.
posted by vytae at 10:13 AM on July 10, 2007

Do. Not. Micromanage. Your. Developers.

I can't stress this enough, and it goes hand in hand with twiggy's #3 above. Know your role, and know that you're working with professionals who know how to manage their time and deadlines.

As a PM, yes, it's absolutely your role to make sure that work gets done. But please, speaking as a system analyst who works for one of the most evil PM's in history (at least until tomorrow, my last day!), let your people do their jobs. Hold them accountable, but don't dictate how they do it - they're as good at what they do as you are at what you do.

Give them milestones, make sure they meet them to your satisfaction (and that of your clients), but otherwise just let 'em work. They will love you for it, and the end result will be much better.
posted by pdb at 10:17 AM on July 10, 2007

nthing twiggy - he's spot on. Especially the bit about managers making promises without developer input. Nothing frustrates me more. I'm not god, I can't create miracles, so don't bloody promise them!

In my developer world, my good project managers keep me away from the clients and their inane chatter and let me do my work. Also, they aren't afraid to say no when the client asks for all the stupid things. Also, don't micro-manage. Daily reports on how things are going I can live with if i have to. Hourly is going to make me want to throw things at you.

Also, don't make your developers afraid to tell you when things are going badly or are behind schedule. Things take time, and sometimes issues crop up that simply cannot be worked out in the time I initially hoped. It's just the nature of the software development world (and is exactly why i double all my time initial best-case time estimates.) If you can understand that, you'll be ahead of most PMs. And as a PM, you're better off knowing as soon as possible when things are slipping, so the client can be managed more effectively.
posted by cgg at 10:25 AM on July 10, 2007

Thanks for all the great responses so far. I have managed teams of copyeditors, proofreaders, compositors, and indexers, and in general I prefer to supervise people exactly as much as they need and no more.

cgg (and anyone else), what do you think makes you more or less afraid to let your PM know when things are running behind?
posted by dame at 10:33 AM on July 10, 2007

As a (web) developer, the best managers I've had have gone to bat for me in situations where there were stupid client requests, unreasonable deadlines, provided a list of prioritized tasks that would only change in EXTREME situations and understood the importance of taking the time to create clean, maintainable code.

The worst managers I've worked with pretty much offered zero shielding from clients (be they external or internal), gave me every single task that a client ever had a thought about (telling me "oh, just work on these whenever you have free time"), and didn't give a shit whether I had time to do the job properly or just hack in a solution that appeared correct for the user.

I would bend time and space to make deadlines for the good managers -- for the bad ones, they already set me up to fail, so I didn't feel invested and thus didn't feel like it was my job to work beyond a 9-5 to make things happen for them.
posted by fishfucker at 10:46 AM on July 10, 2007 [1 favorite]

what do you think makes you more or less afraid to let your PM know when things are running behind?

It seems that often, letting the PM know things are running late is not an established part of the process. The fear comes from not wanting to upset the PM and/or client, and the culture of fear is often created by the PM or some other manager acting tyrranical instead of understanding.

What needs to be done is that communication on how on-task things are needs to happen early and often. Then, as things get a bit behind schedule, everyone is aware and it's not a big deal - it is what it is and you prepare for it.

The problem is when there is not constant communication, and a 20 hour task is at the 18 hour mark before the PM or anyone else knows it's only 1/4 of the way finished. People have a natural propensity at this point to just keep to themselves and bear down on the task, because they fear the horrible confrontation that will occur knowing things got SO behind and the PM wasn't warned about it, etc etc...

It's not the right way to react, but it's how many if not most people do.
posted by twiggy at 10:52 AM on July 10, 2007

Alot of good points here.

I've been developing and programming for 10 years. Here's what I'd add to the good advice here:

- do not be afraid to ask to have a development process or system explained to you. A good programmer/developer knows that you will be their ally if you have a high-level understanding of the development process

- I prefer that most communication be by email so that there are records, but face-to-face is OK too when things need fast resolution. Phone usually sucks, i much prefer email.

- minimise the amount of "drive-by" PM'ing (In our shop PM'ing is a verb ;) ). By this I mean don't just drop by unannounced and expect the developer to drop everything and service your request immediately. Goes double for shoulder-surfing. Unannounced disruptions should only be used in the most extreme of situations.

- DO NOT show up on Friday afternoon with an unscheduled must-be-completed-today task, unless it's absolutely business-failing-important. I have a special process reserved for people who hit me on Friday afternoons: I make sure that they and the sales rep and the client have to do QA and approvals Friday night or on the weekend. Again, goes double for long weekends or prior to vacation.

- avoid making assumptions; it's quite reasonable that the developer knows exactly what you want and they in return have told you what to expect and when. You have the right to inquire periodically if the above "contract" and schedule is still realistic, and you have to appreciate that any changes you or the client makes may impact the schedule.
posted by Artful Codger at 11:21 AM on July 10, 2007

what do you think makes you more or less afraid to let your PM know when things are running behind?

Aside from keeping communication open in general, there's not much you can do at first to let your developers know it's ok to be honest about this stuff. The key will be in how you react the first few times a project gets behind. You'll be new, wanting to make a good impression, and therefore extra stressed out that your project is off schedule. If you can handle this with aplomb, people will know they can trust you with that honesty in the future.

And how do you handle it with aplomb? First of all, by being calm. Go take 5 private minutes to panic and blame and shout in your head in your office, car, or a bathroom stall if you need it. Then put on your calm, confident, competent face and go figure out how to deal with the mess. This means honestly reporting the slippage to your superiors (if they expect that kind of thing), managing client expectations well, and most of all taking an approach of "how do we keep moving forward?" instead of "who do we blame?"
posted by vytae at 11:30 AM on July 10, 2007

Enthusiastically seconding all that's been said above, plus: Don't hold too many fucking meetings!

Get decisions made one-on-one or in small ad-hoc groups of only the direct stakeholders in the decision, and confirm decisions made by email. Don't waste hours with everyone in the same room just to repeat what everyone already knows.
posted by matildaben at 12:11 PM on July 10, 2007

Yeah, good stuff from twiggy.

Devs may call themselves Software Engineers but actually are more artists than engineers (the good ones, at least). Keeping that in mind will help you navigate all sorts of perils.

You will have to earn the trust of the developers. Until proven otherwise, they will expect you to represent the client's interests and not their own. I have plenty of experience with PM's who listen intently to customers but have no respect for the devs. Bad juju, that.

You will get information (estimates, etc.) as accurate as you can tolerate. Some PMs can't stand the truth so they are neve told until the last possible moment.

Which brings up another fear that devs have: estimates become deadlines in the hands of PM's. If I say I think it will take a week to write some code don't go running to the customer and say they will have it next Monday. That estimate:

1) Is a guess, the accuracy of which can only be determined after completion.
2) May not include meetings, interruptions, answering emails, etct.
3) May not include full testing.
posted by trinity8-director at 12:17 PM on July 10, 2007

Right now I am blessed with a great project manager; it makes the job much easier. He does several things which I would recommend in order to make your developers love you:

1) Give challenging tasks to your developers, and in general over-sell the difficulty of the tasks. Don't be afraid to ask for 2X as an ideal, as long as both you and the dev understand that it might only be possible to get X.

2) Be appreciative of what the developers deliver. If you received X in the situation above, compliment it like it was 2X. Treat the devs like they are candy!

3) As mentioned by the above posters, don't be afraid to say "No" to client requests. Even better, try to sell clients on the features that you and the devs know will be easy to implement. In general, when talking to clients about how difficult something will be, take your best estimate of the difficulty, multiply it by pi, and then give them that answer.

4) When showing off the results to the clients, don't be afraid to sell it. Don't mis-represent stability issues or schedule problems, but do make sure that the clients understand how great the features are that they are getting. When showing technical projects to non-programmers, it is very easy to miss all the work that goes into making some seemingly innocuous feature. I have completed technically difficult projects and received little credit for them because I did a poor job of framing the project and communicating its difficulty. Make sure that the client understands how cool/difficult the features are, especially if the client is non-technical.

The combination of these things really makes me feel that the project manager and I are part of the same team and have the same goals. I don't have to worry about political factors, and I know that when the PM goes off to a meeting he will be the dev's advocate.
posted by Balna Watya at 12:24 PM on July 10, 2007

Also, read the following books:
Rapid Development, by Steve McConnell
Software Estimation: Demystifying the Black Art, by Steve McConnell
Software Project Survival Guide by Steve McConnell
Manage It: Your Guide to Modern, Pragmatic Project Management, by the Pragmatic Programmers

See also Joel on Software's recommended books and Coding Horror recommended books.

Regarding estimates: do pad the estimates you get from developers by 20%, 50%, or 100% depending on if the risk/uncertainty level is low, medium, or high, also depending on how clear the requirements are and how thorough the functional design and technical design have been documented. We developers are notoriously optimistic about our estimates ("oh, it'll take 2 days to code that"), and we forget about unit testing, debugging, code reviews, and general bullshit.
posted by matildaben at 12:26 PM on July 10, 2007

Hi dame, welcome to the world of advertising. I've never managed developers, but as a copy supervisor at an interactive agency (previous position), I worked closely with them. Best thing I can tell you is, make the developers part of the team. Get them in on the kick-off meeting for the big projects, let them get to know the copywriters and ADs, ask them for their thoughts, and learn whatever you can from them.

At my last job, I had to step on some PM toes to get access to the developers, which was totally crazy. The PM wanted everything routed through her, which bogged the process down and introduced transcription errors. Let the developers and the other creative staff (yea devs, I just called you creative!) construe and solve things together. You'll want to know about it all, but you don't have to dictate it all.

You don't seem like the dictator type, but maybe the more important part of this is making sure the devs know they can and should talk to the writers and ADs/designers.

Also, monitor their workload carefully. That's where deadlines get blown, is when a PM comes running in, head on fire, yelling "Drop everything and do this right now!" Eventually something has to give, you know? So prioritize that stuff; if it can wait til morning, let it. People will not like to see you if everything is always an emergency. And if account reps are driving you nuts, smack 'em around a little; they're all sissies mostly.

And of course, the more you know about what your people can do, and what they are doing, and how they do it, the better.
posted by Mister_A at 1:48 PM on July 10, 2007

I'm amazed it took so long for somebody to mention Joel Spolsky. Read Joel on Software, especially the older stuff. He used to be a PM at Microsoft on Excel, but he is far from an M$ fan boy.
http://www.joelonsoftware.com/
Really good stuff.
posted by bystander at 7:44 PM on July 10, 2007

I for one believe that a PM should have been a software developer atleast for some time earlier.
posted by chrisranjana.com at 9:52 PM on July 10, 2007

Here's the most important sentence you'll need: "I'll get back to you with an answer when I've spoken to the developers."
posted by malevolent at 12:32 AM on July 11, 2007 [2 favorites]

I would also add three things to the mass of very good advice above.

Firstly, you must be absolutely clear about what the expectations are of your developers and what their priorities must be. I have had a couple of experiences where I have not been as clear as I should have been, and the client's #1 priority != the developer's #1 priority. That made for a few uncomfortable discussions...

Secondly, When you ask for an estimate from your developer make sure they understand what you need (detail sizing / rough guess etc), when you need it by, and that their estimate comes with what degree of confidence. I find it enormously helpful if a developer says to me a piece of work is very complex (as opposed to complex, okay, simple or trivial) and that their estimate is realistic / pessimistic / optimistic. From the combined complexity / confidence information, I can take a pretty good guess as to what amount of contingency time to add, as well as setting the client's expectations that they may need to expect some problems to be uncovered once we get into the 'meat' of the task.

Lastly, don't forget that if you ask a developer to do task A, that means they cannot do tasks B, C, D etc. Therefore, always ask for an indication of the impacts on their other work. It shows you are aware of their workload and don't want to overload them.
posted by mooders at 12:57 AM on July 11, 2007

As someone who's been both a programmer, and a project manager/account services person, let me just offer one piece of advice on top of all this (and, honestly, I'm not being cynical)--in a professional services environment like yours, your job is to keep the programmers employed, by making sure they operate within the bounds of fiscal reality.

Revenue comes in the door to an agency--and jobs _stay_ at an agency--because you are able to offer a combination of quality and cost that your clients find appealing, and that your business finds profitable.

Every point made here by programmers is totally valid, but look at some of the implications. "Make an estimate, and then double it?" You're going to be offering prices in a competitive market--the fundamental question to you and your team, every day, is going to be "Would we rather have work that we had to estimate aggressively, or no work at all?"

Left to their own devices, many programmers would quickly price themselves out of a job. And I say that with a lot of respect and affection, because it's for all the right reasons, as _programmers_. As the "reality interface", though, you just have to be prepared to run interference for a bunch of talented, passionate people whose natural and professional instincts aren't always in their own long-term self-interest. (And probably not get much thanks for it.)

So take all the advice here--it's really good--but understand that if you do your job well, you're going to need to frustrate these same folks as much as you're going to fulfill them.

All that being said, it's a fun, exciting role to be in, if you're in the right kind of place, and working with the right kind of people. Good luck.
posted by LairBob at 4:09 AM on July 11, 2007 [1 favorite]