Running Diary: The online community article, Part 2
This is Part 2 of a trio of posts on my experience writing an article on HP.com's architecture for the Java online community The Server Side. Part 1 covers the genesis of the article, the restrictions I had to adhere to, and how I got over writer's block. Here in Part 2, I discuss getting defensive over what turned out to be very good feedback, losing touch with details as you move up the corporate ladder, and I summarize this very interesting experience. Part 3 goes into the things that happened after the article went live.
The HP Review cycle
Before I could submit the article to editors at TSS, I needed some feedback from some folks inside HP. Not only was this for technical correctness, but to make sure I was protecting proprietary strategy as well. Among the hardest things for me to do is to accept feedback and I don't think I'm alone there. Even when that feedback ends up being correct, I can't help but initially feel defensive about it. I'd like to think that's a natural reaction, but maybe there's something wrong with me.
The most constructive piece of feedback I got fell into this pattern as well. I spent several hours putting together this diagram that attempts to show the different kinds of sites there are, which are most complex, and what kinds of reusable services are available:
The Development Manager of the Portal Platform told me that, while he could see where I was going with the idea, it was clunky to look at. After I got over feeling like I wasted time putting the graphic together, I followed his suggestion to have some of our people with graphic arts backgrounds look at it. The concept they came up with, that I then modified slightly was much, much better:
The next time I feel defensive about feedback I've received, I need to remember this experience. That's not to say that you have to follow every piece of advice you receive. You don't. But, be open to the suggestions you get and you'll end up with a better product. With the HP feedback complete, it was time to submit my paper to the TSS staff.
The TSS Review Cycle
After the productive defensiveness of the internal review process, the suggestions from the TSS folks was pretty painless. The hard part wasn't fielding their feedback for more details in certain areas of what I had already written. It was delegating the necessary response.
The part of my job I'm most uncomfortable with is that I no longer know the same level of detail on the 30+ projects that I'm involved with at a very high level as I did when I was intimately familiar with the 2-3 I was directly writing code for. That's a curse for any job. As you begin to accumulate responsibility you lose direct control over the details as you delegate various aspects of the project to others.
That was the problem I had here. I didn't know the exact details the TSS staff was asking for, but I knew who did. Of course, then I ran into the next problem: the most knowledgeable person was on vacation. So was his backup and the backup's backup too. This paralyzing realization swept over me that I was at the mercy of others for something I could have had the answer for had I had the time, but instead had to wait out several other people's summer plans.
Not that everyone isn't entitled to their vacation, they certainly are and it's not beneficial to the group longer term if you don't go recharge yourself every once in awhile. The timing was just unfortunate. It happens.
Publication and what I learned
Eventually, I got the details the TSS staff asked for and they approved my changes. My article got put in their publication queue and a few weeks later, when it was my turn, it went live. In hindsight, I obviously learned a lot from the experience:
Before I could submit the article to editors at TSS, I needed some feedback from some folks inside HP. Not only was this for technical correctness, but to make sure I was protecting proprietary strategy as well. Among the hardest things for me to do is to accept feedback and I don't think I'm alone there. Even when that feedback ends up being correct, I can't help but initially feel defensive about it. I'd like to think that's a natural reaction, but maybe there's something wrong with me.
The most constructive piece of feedback I got fell into this pattern as well. I spent several hours putting together this diagram that attempts to show the different kinds of sites there are, which are most complex, and what kinds of reusable services are available:
The Development Manager of the Portal Platform told me that, while he could see where I was going with the idea, it was clunky to look at. After I got over feeling like I wasted time putting the graphic together, I followed his suggestion to have some of our people with graphic arts backgrounds look at it. The concept they came up with, that I then modified slightly was much, much better:
The next time I feel defensive about feedback I've received, I need to remember this experience. That's not to say that you have to follow every piece of advice you receive. You don't. But, be open to the suggestions you get and you'll end up with a better product. With the HP feedback complete, it was time to submit my paper to the TSS staff.
The TSS Review Cycle
After the productive defensiveness of the internal review process, the suggestions from the TSS folks was pretty painless. The hard part wasn't fielding their feedback for more details in certain areas of what I had already written. It was delegating the necessary response.
The part of my job I'm most uncomfortable with is that I no longer know the same level of detail on the 30+ projects that I'm involved with at a very high level as I did when I was intimately familiar with the 2-3 I was directly writing code for. That's a curse for any job. As you begin to accumulate responsibility you lose direct control over the details as you delegate various aspects of the project to others.
That was the problem I had here. I didn't know the exact details the TSS staff was asking for, but I knew who did. Of course, then I ran into the next problem: the most knowledgeable person was on vacation. So was his backup and the backup's backup too. This paralyzing realization swept over me that I was at the mercy of others for something I could have had the answer for had I had the time, but instead had to wait out several other people's summer plans.
Not that everyone isn't entitled to their vacation, they certainly are and it's not beneficial to the group longer term if you don't go recharge yourself every once in awhile. The timing was just unfortunate. It happens.
Publication and what I learned
Eventually, I got the details the TSS staff asked for and they approved my changes. My article got put in their publication queue and a few weeks later, when it was my turn, it went live. In hindsight, I obviously learned a lot from the experience:
- Networking and how you present yourself online matters, a lot. I wouldn't have had the opportunity had I not used my job title openly in a blog comment.
- There's an art to showing technical competence without revealing proprietary information. I haven't exactly mastered that, but got some good experience with it.
- Don't get defensive about feedback. Nobody thinks that my original drawing is better than the one it evolved to. Ask for feedback and then be serious about improving the end product without taking it personal.
Labels: Running Diary
0 Comments:
Post a Comment
<< Home