Monday, February 07, 2005
Offering feedback
Lately I have been working with Allen on a "quick Windows app" that is supposed to be a better, more usable version of the "BackOffice" (not to be confused with anything Microsoft does; this is a credit card agent app) product that we bought from Lighthouse software. The original BackOffice app was a truly awful mess from a usability standpoint, and we didn't use the vast majority of its features, so coming up with some kind of an improved app is pretty much a slam-dunk. I have been working on the "Requirements" tab, the details of which I won't get into.
I figured I was about 90% done with it and ready to move on to another part of the app this morning when I got an email from Allen giving me some feedback on my work. Here is a sample of some of what he said:
I don't mind saying I was a bit ticked off on receipt of this feedback In the first place, I didn't ask for it. In the second place, it deals almost exclusively with these ridiculously small details that the average person could not possibly care about. This is an internal app, for crying out loud! Not only that, but the project is on a highly compressed schedule--the whole darned thing is supposed to be done by the end of this week, and there are huge chunks of functionality yet to be developed. And lastly, it set off my highly sensitive turf-infringement alarm. I believe in ownership. This is my thing, so I should be able to implement it how I want.
Oh yeah, and at the bottom of the email, he said the following:
Now, there are a number of problems with my initial, primal response, but we won't go into that just yet. The main point of this post is thus: shortly after I received the email and commenced stewing about it, Allen came into my office and talked to me about it. Now, he wasn't there to apologize for it or anything. Of course not. Why should he? Instead, he went through and talked to me about each item, explaining why he wants it and what the other possible options may be. After he (finally) left, I realized the following:
(a) You have to have a consistent look and feel across the application. Sure, I might want to "own" a piece, but obviously that doesn't mean I can just make it look any way I like.
(b) If I "own" a piece of a project, but I never ask for feedback on it, then I simply must expect to receive unsolicited feedback. It is unacceptable for a developer to expect to have carte blanche over feature implementation.
(c) Some of the suggestions were better ideas than I had originally thought.
There are still plenty of caveats, here. The whole internal app argument I think is still a pretty good one, and there's lots of time being wasted. But the point is, had Allen just sent off the email and assumed I'd take it with grace and gratitude, I not only wouldn't have done any of it, I would have been exceedingly ticked off and added that incident to the memo I'm preparing internally for when I leave because "I really can't work with these guys." But since he followed up the email with a personal visit, I am considerably less offended by its contents and a lot more open to implementing several of its suggestions.
Feedback in an organization is essential. Four eyes are always better than two, etc. But the delivery of that feedback is absolutely crucial. Delivered wrong, it offends the feedbackee and makes him feel like his ownership has been undermined. Here is how feedback has been handled at my previous companies:
1. At Tenfold, they made a conscious effort to have a very abrasive culture. They get smart people with big egos but who aren't afraid to back down from a fight. The reason why this works is because everybody's smart, and so everybody respects each other. That's understood. The reason why it doesn't work is that it just gets real old getting yelled at. Also, 99% of companies can't bring together the kind of brainpower that TenFold had.
2. At Digital Harbor, things worked okay at a developer-to-developer level within the Utah office. Nice guys. Also, there was a formalized testing team and process where they would log bugs to the database. There were two very big problems though. One was that the local (Utah) guy over developers just wasn't very smart and didn't know beans about the code. Having to take feedback from him was just ludicrous. The other big problem was that the head of development over the whole company was in Virginia, and he was just about the biggest jerk I've ever known in my life. He was smart, but not practical, and he assumed that everyone was dumber than him.
3. At BullySports, I had an ideal situation working with Grant, who was essentially my dev manager. But there were only two of us, and we were friends anyway, so we worked together well. There were never turf battles; each knew that the other owned certain areas of the code, and frankly had no desire to intrude on the other's territory. Mutual respect, in other words. We also had a lot of power within the company (though far from absolute, as I'm sure you'll see in future blogs) and so when feedback came from other, non-technical parties, we were free to ignore it.
I notice that as I write this, I'm blurring the lines between feedback and management in general. Obviously it's hard to draw a line, but in general I'm talking about feedback in situations similar to that described at the top between Allen and me.
So what's the ideal method? Well, first of all, you need to be working within the structure of Bruce's Ideal Software Team, which I will delineate in a future post. But beyond that, you need to be very careful about the way you deliver feedback. Be nice. Humble. Leave the door open for other viewpoints. And choose your battles. And unless you have specific authority in the context of the company, you must achieve by persuasion, not by executive fiat.
I figured I was about 90% done with it and ready to move on to another part of the app this morning when I got an email from Allen giving me some feedback on my work. Here is a sample of some of what he said:
- make the "Add" dialog an always-on-top style form
- make the "Add" dialog resizable
- set anchors on buttons so they will move with the form when the form is resized
- set minimum size for form
- where feasible, make buttons a consistent size (I've been doing 68x21 for a lot of them, many I still need to standardize, for some that size is too small)
- include merchant Internal ID and merchant DBA in titlebar
- standardize size of border around the controls (8 pixels?)
I don't mind saying I was a bit ticked off on receipt of this feedback In the first place, I didn't ask for it. In the second place, it deals almost exclusively with these ridiculously small details that the average person could not possibly care about. This is an internal app, for crying out loud! Not only that, but the project is on a highly compressed schedule--the whole darned thing is supposed to be done by the end of this week, and there are huge chunks of functionality yet to be developed. And lastly, it set off my highly sensitive turf-infringement alarm. I believe in ownership. This is my thing, so I should be able to implement it how I want.
Oh yeah, and at the bottom of the email, he said the following:
Changes that you agree and don't mind doing, just go ahead and change; changes you don't agree about, let's discuss until we have consensus; changes you think would be fine but don't know how to do or don't want to spend time doing, let me know and I can help.This was actually quite a brilliant little addendum on his part, because it was effectively a pre-emptive strike on my favorite method for dealing with such feedback: to ignore them.
Now, there are a number of problems with my initial, primal response, but we won't go into that just yet. The main point of this post is thus: shortly after I received the email and commenced stewing about it, Allen came into my office and talked to me about it. Now, he wasn't there to apologize for it or anything. Of course not. Why should he? Instead, he went through and talked to me about each item, explaining why he wants it and what the other possible options may be. After he (finally) left, I realized the following:
(a) You have to have a consistent look and feel across the application. Sure, I might want to "own" a piece, but obviously that doesn't mean I can just make it look any way I like.
(b) If I "own" a piece of a project, but I never ask for feedback on it, then I simply must expect to receive unsolicited feedback. It is unacceptable for a developer to expect to have carte blanche over feature implementation.
(c) Some of the suggestions were better ideas than I had originally thought.
There are still plenty of caveats, here. The whole internal app argument I think is still a pretty good one, and there's lots of time being wasted. But the point is, had Allen just sent off the email and assumed I'd take it with grace and gratitude, I not only wouldn't have done any of it, I would have been exceedingly ticked off and added that incident to the memo I'm preparing internally for when I leave because "I really can't work with these guys." But since he followed up the email with a personal visit, I am considerably less offended by its contents and a lot more open to implementing several of its suggestions.
Feedback in an organization is essential. Four eyes are always better than two, etc. But the delivery of that feedback is absolutely crucial. Delivered wrong, it offends the feedbackee and makes him feel like his ownership has been undermined. Here is how feedback has been handled at my previous companies:
1. At Tenfold, they made a conscious effort to have a very abrasive culture. They get smart people with big egos but who aren't afraid to back down from a fight. The reason why this works is because everybody's smart, and so everybody respects each other. That's understood. The reason why it doesn't work is that it just gets real old getting yelled at. Also, 99% of companies can't bring together the kind of brainpower that TenFold had.
2. At Digital Harbor, things worked okay at a developer-to-developer level within the Utah office. Nice guys. Also, there was a formalized testing team and process where they would log bugs to the database. There were two very big problems though. One was that the local (Utah) guy over developers just wasn't very smart and didn't know beans about the code. Having to take feedback from him was just ludicrous. The other big problem was that the head of development over the whole company was in Virginia, and he was just about the biggest jerk I've ever known in my life. He was smart, but not practical, and he assumed that everyone was dumber than him.
3. At BullySports, I had an ideal situation working with Grant, who was essentially my dev manager. But there were only two of us, and we were friends anyway, so we worked together well. There were never turf battles; each knew that the other owned certain areas of the code, and frankly had no desire to intrude on the other's territory. Mutual respect, in other words. We also had a lot of power within the company (though far from absolute, as I'm sure you'll see in future blogs) and so when feedback came from other, non-technical parties, we were free to ignore it.
I notice that as I write this, I'm blurring the lines between feedback and management in general. Obviously it's hard to draw a line, but in general I'm talking about feedback in situations similar to that described at the top between Allen and me.
So what's the ideal method? Well, first of all, you need to be working within the structure of Bruce's Ideal Software Team, which I will delineate in a future post. But beyond that, you need to be very careful about the way you deliver feedback. Be nice. Humble. Leave the door open for other viewpoints. And choose your battles. And unless you have specific authority in the context of the company, you must achieve by persuasion, not by executive fiat.
# posted by Bruce Hansen @ 2:55 PM 
