A Technology Architect’s Guide to Humans: Make Feedback a Batch Process

How do technology architects know that we are doing a good job? We are often working as the only architect on the team, making decisions which others may not agree with, making sense of complex and ambiguous topics, and trying to set a direction which others can follow. How can we tell that this all adds up to something useful?

One way to find out is to ask for feedback. We do better when people tell us freely why they disagree with us, whether we are successful in making ourselves understood, and whether the paths we lay out lead to the right place.

Unfortunately, humans are rarely good at asking for feedback, and are often even worse at giving feedback. Fortunately, we can improve both by grasping grasp two apparently paradoxical ideas.

You can get better at giving feedback by not giving feedback when you are asked to give feedback.

You can get better feedback by not expecting feedback when you ask for feedback.

How can these two statements be true? I’ll try to explain by sharing some learning experience from my past.

I used to be terrible at giving feedback. This wasn’t because I didn’t want to give feedback: I wanted to, and tried to, but I didn’t know how. As a result, in my earliest management roles, my one to one meetings with team members might end something like this:

TEAM MEMBER (five minutes before the meeting is due to end): . . . one more thing, can you give me some feedback?

ME: Feedback?

TEAM MEMBER: Yes, I’d like to know what you think of how I’m doing.

ME (thinking frantically): Erm . . .

TEAM MEMBER: Perhaps at our next meeting?

ME: No, no, it’s fine. Well, I guess everything’s going well. You did a good job on <the first thing that comes to mind>.

TEAM MEMBER: Great. Anything I should work on?

ME (mind blank): Nothing that I can think of right now.

TEAM MEMBER (standing up and leaving): Thanks very much.

ME: Thanks, see you later.

TEAM MEMBER (thinks): That went well.

ME (thinks): That was terrible.

Of course, this is a caricature from many years ago, but I am sure that I had conversations nearly as awkward and futile, and I suspect that you have had them as well.

My problem was that I thought I was doing the right thing: feedback is good; my team member has asked me for feedback; it is my duty to provide it now.

I got better over time, but did not really understand how to make feedback more effective until I attended a great leadership course (which we now offer through the HSBC Technology Academy under the name Fusion, delivered by our partners IDG).

This course taught me, first, that feedback is the breakfast of champions, (a phrase I repeatedly quote whenever I or my team receive feedback which is difficult to hear) and, second, to adopt a very simple technique to prepare and deliver feedback.

This technique is so simple that I expect that you have already encountered or used some version of it: it is to structure your advice to the recipient under three headings: things that they should continue doing; things that they should stop doing, and things that they should start doing.

This approach has many virtues: it forces you to be balanced (everybody has things that they should continue doing as well as things that they should stop and start); by starting with thing the recipient should continue it opens with the positives; and it focuses on behaviour rather than personality traits (it is much easier to stop doing something than to stop being something).

But I think that the most important feature of this technique (or any other technique which has a similar structure) is that it forces you to think about your feedback and write it down. It forces you to stop and reflect, rather than to blurt out the first thing that you think of: it treats feedback as a batch process (scheduled; may take a long time to complete; user expects to wait for the output) rather than a real time process (on demand; synchronous; user may set a very short timeout).

Today, I find that the most useful feedback is the feedback which I have put most effort into: that I have taken time to think through. While I still have a lot to learn, it means that the dialogue from before tends to go a bit more like this:

TEAM MEMBER (five minutes before the end of the meeting): . . . one more thing, can you give me some feedback?

ME: Of course . . .

TEAM MEMBER (settling back and reaching for notebook)

ME: . . . but not today.

TEAM MEMBER: ?

ME: I’d like to take some time to think and write some feedback which is most useful to you. After all, you don’t want me to just tell you that everything’s fine, do you?

TEAM MEMBER: No, no, of course not.

ME: So let’s use our next one to one meeting for some proper structured feedback.

I have also learnt more about how to ask for feedback. If you spring the request on somebody in the middle of a meeting, you are likely to get a bland response based on the first experience that comes to mind. If you make it clear when you ask that you are scheduling a batch job, and that you don’t expect an immediate response, then you are providing time to reflect.

Batch jobs also run to a rhythm. As you get comfortable with how to give and ask for feedback, you can make it a regular part of your batch schedule, rather than something you do when you are coming up for an appraisal. For technology architects, this is a particularly important habit to acquire: creating regular opportunities for your stakeholders to provide considered, structured feedback will help you keep improving.

I hope that makes these two apparently paradoxical statements clearer:

You can get better at giving feedback by not giving feedback when you are asked to give feedback.

You can get better feedback by not expecting feedback when you ask for feedback.

Just like the difference between a batch job and a real time process, it is a matter of timing and expectations.

(This is one of an occasional series of lessons learnt about how technology architects can deal with their fellow humans. Previous articles cover the need to remember that humans are human, the need to understand the other person's point of view when communicating, maintaining integrity in difficult meetings, empathy for other people's jobs, persistence in conveying your message, and the architect's role as a connector. I’ve now started publishing these and other articles as a LinkedIn newsletter: let’s find out if that is helpful.)