Browsing Tag


Development: Leave Us the $Foo Alone!

Jeff Lash has a good post up about Delegating. There are some interactions you need to have – like regular tradeoff meetings with Development. As a general rule, programmers hate meetings. A lot of that has to do with the fact that prior to you, they had some “Marketing” airbag pull them into blahfests about “sustainable competitive advantages” and how we can get a that feature to “go viral.” Now meetings from Marketing (and by proxy Product Management) are dismissed as a waste of time.

Lead Architects in are alpha dogs. There’s only room for 1-2, otherwise they start to piss on each other’s territory and talk about how so-and-so isn’t pulling their weight or how they had to clean up the other’s code. Design planning and software requirements are viewed as nice-to-have’s, and often as Product Management you’ll find yourself in a situation where you’re bringing requirements to Development only to hear “Oh yeah, I heard you were working on that so I already built it.” Great! It’s done, on to the next feature…uhhhhh, no.

What you’ll find is that you got a half-implementation based on:

  1. What was easy for the developer to do over the weekend
  2. What was interesting for the developer
  3. What is based on the developer’s (incomplete) interpretation of the customer’s problem

When you push back on the implementation you have to do it gently to avoid bruising ego’s. Engineering’s usual M.O. is to say “this is what we’re offering, to do your (complete) implementation will take<$ridiculous_timeframe>.” Besides, who is going to call B.S. on the development estimate – they’re the one’s making it! Fox, meet hen house!

There are two ways around this problem. First you need to have the fortitude to call Engineering’s bluff. If you get a time frame of 6 additional months, say “OK. That’s fine. I’ll need to see a detailed schedule so we can determine what resources we need to hire to help you.” If the full implementation is that important, you should be able to drive a business tradeoff to get the resources to make it happen.

Second, you can avoid the problem in the first place with proper planning. Once you approve a product onto your Release Plan, form a Core Team and pull the lead developer onto it. He/She will grumble about the meeting but stay firm – you need the Core Team to drive tradeoffs and get ahead of the prototype that they’re going to build.

Often, Developers project verbal and non-verbal signals that meetings are inefficient uses of time, that they don’t need to be there, or that they could be doing “more important” work. Basically they are saying: “Leave me the F alone!” I’ve found that they feel that way because they don’t interpret their time as valued by Product Management or Marketing, or they don’t feel like PM has a good handle on the tradeoffs that need to be made. Whenever I get these signals from a Developer, these are my tactics:

  1. Be sure to start the meeting with an explicit statement about why we are here, what the goals are, and the expected output of the meeting
  2. If you start getting verbal or non-verbal signals from a Programmer (disinterested, checking email, sighing, rolling eyes, pacing around the room, etc), stop the meeting immediately and address the issue – “Joe, I keep hearing you sigh and roll your eyes, do you understand why we are here? Do you understand why we need YOU here? Is there something else that you need to be doing at this moment?” I’ve actually been in meetings where the developers had stopped working on a critical hotfix, without telling us that we were holding up their work, and were glaring at PM for running the meeting! Enable people to have a voice, because they might not speak up…
  3. If Joe agrees with the purpose of the meeting and his role there, and is still offering bad non-verbals, actively engage him with open-ended questions, much like you’d do on a customer interview.
  4. After the meeting, follow up one-on-one to talk about the importance of the design and tradeoff process, emphasizing that a good design solves a more complete problem set and reduces wasted work in Development. The only thing Developers hate more than meetings is doing work and having it go to waste or get mothballed.

…because it’s Friday, here’s an Office Space clip that always makes me think of Product Management and grin: