Categories
Archives
- September 2008
- August 2008
- July 2008
- June 2008
- May 2008
- April 2008
- March 2008
- February 2008
- January 2008
- December 2007
- November 2007
- October 2007
- September 2007
- August 2007
- July 2007
- June 2007
- April 2007
- March 2007
- February 2007
- January 2007
- November 2006
- October 2006
- September 2006
- August 2006
- July 2006
- June 2006
- May 2006
Is Touching Better? | Home | New York's Own ColdFusion User Group
Filed under Thoughts on January 10, 2008 by Tim MeaneyDear Developer
Dear Developer:
I'm writing you today to express a frustration, perhaps you can help. You likely know me by one of a number of titles: Business Lead, Project Manager, Product Manager, Project Owner. In a well-functioning software company, I have an important role, some might argue the most important of roles. When a project kicks-off, I interact with the 'business', whether that be the market, a client or internal business team. It's my responsibility to articulate the need, the driver for the software endeavor (have you ever attempted to build something not well defined? Good luck.) During this phase of a project, I'm wholly engaged in the effort - organizing people, designing, creating requirements, spec and tickets. You, developer, and I, spend a bunch of time together at this phase and collectively define the effort - the design, interactions, error handing, the software architecture, XML schema, resources, database definitions and others. This effort belongs to the both of us. The whiteboard is full of our sketches, flurries of tickets are created, and a plan is put in place. We commit to dates, shake hands, and then....
...I go back to my office and wait. You have to understand, I was once a developer too, but I hung it up when I realized I would add more value as a definer, communicator and facilitator. But I love software too, I'm as passionate about it as you are. I understand nearly everything that you do, albeit at a more superficial level. My frustration - I can't stay late, open Eclipse and start implementing, but trust me, I wish I could. Just for a moment, put yourself in my shoes. Imagine the feeling I have sitting there waiting for you to build our software. Now of course, I have levers to push, I might be your boss, I might be responsible for rewarding you. But those are nearly irrelevant, building good software isn't effected by that. However, I certainly have the say as to whether your effort is successful or not, in fact, I define that success for you. I can motivate you, recognize your efforts, shine the light on your many successes. Think about it, who has been a more powerful advocate of your work? Why do you think that is? This is why you should even bother being concerned about my opinion on this matter - I'm not just a project manager, I'm your customer - I define your success.
So back to the subject at hand. I sit in my office waiting for tickets to move to QA. I try to hold back from harassing you, I've learned from experience that you're at your best when I stand down. But sometimes I see you leave at a reasonable hour and can't fathom it! If I could, I'd sleep here tonight to bang this out! Everything is teed-up, there's clarity of definition, all that needs to happen is to author those lines of code!
I guess I'm like the football coach. I used to be a great player; nobody cares more about the game than I do. I've spent the week crafting the perfect game-plan for this team, we can't lose. I'm better prepared than the other coach. All you, quarterback, need to do is go out and execute on it and we'll win. So now it's kick-off, and while I can call time-out, yell at you, give a kick-ass half-time speech, pull you out of the game, call a deep pass or a sweep right -- in a sense I'm powerless. I would never have thrown into double coverage, but you did. If I could throw the pads on like I used to, I'd show you how to really play this game...
So what's all this about? What do I want from you? Mostly, I'd like a little empathy next time I ask you a question about how you're implementing something. Not only do I need to understand this stuff in order to champion it, to articulate it and to test it, I'm simply just curious about it.. Remember, it's our software you're building. Pull me into your world, talk me through your decisions, do a code walk-through with me - you'll be surprised how much I understand. I sometimes even have killer implementation ideas, as I bring a different perspective from yours. Overly communicate with me, we're all better off when I completely understand where you stand. Just as your job is made much easier when I fully and clearly define the business need and project goals, mine is made easier when I fully understand where we are in an effort at all times. If you want to know why that's the case - two reasons are: I'm responsible for communicating this to the client or internal business owners (and trust me, there's nothing worse than being caught ignorant on this front) and I'm also responsible for resourcing across many efforts, so I need to know where we stand to make informed calls about who should focus on what. Pay attention to the priority that I set, just as you know the best implementation approach, I have my ear to ground and understand when something apparently small is crucially important, or when something you think is crucial is not. Trust my judgment here by respecting my calls, as I do yours.
Finally, understand my frustrations, they run as deep or deeper than yours.
Trackback Pings (TrackBack URL for this entry)
http://www.arc90.com/cgi-bin/mt4/mt-tb.cgi/96.
Comments
My Dad was my sports coach on countless occasions throughout my childhood. He didn't really encourage or support easy communication to the leader. I'm a software developer now and find that I have a really hard time communicating effectively up the ladder. Go figure. Deep frustrations indeed...thanks for listening.
Posted on January 10, 2008 2:51 PM by Patrick
Dear Business Lead, Project Manager, Product Manager or Project Owner,
i agree with you on most things you wrote. Good communication helps a lot bringing a project forward and is one of the many keys to success.
However, this left me with a very sour taste in my mouth, especially when you say you once were one of us:
"But sometimes I see you leave at a reasonable hour and can't fathom it! If I could, I'd sleep here tonight to bang this out! Everything is teed-up, there's clarity of definition, all that needs to happen is to author those lines of code!"
See, software developers are a very creative bunch. Yes, i said creative. I often compare software development to creative writing. You rarely ask a writer to finish that particular chapter today and please not leave until it's finished even when the plot is well defined. If you do, you are likely to get crap writing, or at least not something you were hoping for. Creative output is not something you can fit into an eight hour day. Creativity comes and goes. Maybe the writer even went home because she worked through the previous night already, trying to satisfy the (often ridiculous) deadlines of her editor?
Posted on January 10, 2008 7:21 PM by Claus Wahlers
Claus: You picked up on an important point - I was writing this to express the feeling "we" have, not attempting to say that we're right. I fully appreciate the creative process that writing good software demands. At Arc90, we're so bought into this concept that we don't have core hours. Developers give so much more of themselves to their work when it's on their terms, I've seen it played out time and time again for years.
However, that doesn't change the feeling we have - which is sometimes one of frustration at your methods. I wrote this with some hyperbole in order to put forth a point. Don't take me all too seriously - I know exactly why you're leaving at a reasonable hour - because you worked hard all day.
Cheers!
Posted on January 11, 2008 12:05 AM by Tim
Interesting article. Good to know that people are opening up to newer ideas.
Posted on January 18, 2008 7:47 PM by T1 Mike
Goes back to the same old saying, "Communication is key."
Posted on June 3, 2008 12:23 AM by qwick cover
* Tim Meaney is a colleague at Arc90.
This is a very expressive post in which you've high-lighted your personal experience of "transitioning" from developer to product manager, yet you're still a developer at heart. Your skillset is a rarity and a huge benefit to your team.
I've worked with a lot of developers on different s/w projects in my career and always had to establish my expectations in a collaborative effort from the onset. I always remind them that s/w is an experience to the user's benefit, not a checklist of things to throw over the wall. We're all working hard together. Moreover, the initial specs that you define as a product manager may not be exactly what the market really wants at the end, so you always have the probability of changing direction. Therefore, product managers walk the precarious tricky tightrope act of listening to the client / market needs while making sure engineering is developing the product. The definition of execution and getting things done is elusive. For example, sometimes wait and see is the wisest approach (which hard to control when you have a million deadlines to manage), because the engineers don't want to change direction at every new possibility. Also, I observed that engineers are most productive in spurts, so it's hard to grind the productivity 24 x 7. Deadlines must be followed, yet a talented engineer will deliver their code in a reasonable amount of time.
This presents 2 extreme cases: Being too flexible with your specs will impede development, whereas Being too rigid with your requirements may not please your customer base. After all, what good is s/w if it doesn't suffice the needs of the end-user? The thing about internet s/w these days is that there are so many options, and switching costs are minimal.
As for the internal culture between developers and product managers, this depends on every organization's culture. Every organization has to define their own equilibrium and measure their productivity and qualitative metrics. The goal is to create a culture of transparency and empathy. Engineering needs to understand that their livelihood is contingent on satisfied "paying" customers; product managers need to understand that engineers work best when they have clear, detailed specs that don't change every day and to limit distractions. For instance, this is what google as they established their culture in the 2001-2003 timeframe by not having any phones for engineers (I don't if is still the case today) for less disruption.
IMHO, I assert that product managers and technical leads are ultimately responsible to keep developers on track and in the loop. Otherwise, it's far too easy to calcify departments into a Us vs. Them culture, which plagues many technology firms all over the world. Another qualitative issue is motivation. Product Managers often are not only coaches but cheerleaders. We must keep the morale high and praise team members when they contribute to the project, even when it's an unpopular viewpoint. Teams of people are capable of producing awesome, cutting edge products with great communication and a optimistic attitude.
Posted on September 19, 2008 1:28 PM by Pete Park
Is Touching Better? | Main | New York's Own ColdFusion User Group

Yes, sir!
Great post!
Posted on January 10, 2008 10:21 AM by Avi Flax