Feedback: Giving, Seeking, and Receiving

Giving feedback is difficult. Receiving feedback can be tough at times (especially when it's negative feedback).

In my world, feedback is very useful critical. After years of practice, I still feel that I'm not good at giving feedback. So, I'm writing down some notes that I found helpful in giving (seeking and receiving) feedback.

Note #1: Give Feedback As Soon As Possible

Don’t store it up. Give feedback as soon as possible (within hours, or days, of a specific event or instance if you can).

Note #2: Choose An Appropriate Time And Place

Allow enough time so that you are not rushed. Never give "negative" feedback in public.

I also time-box the session to not exceed 60 minutes. I find that about 30 minutes is good enough. If the conversation begins to drag, get emotional or you/they need time to "digest" what is being said, take time out—arrange a break and reschedule the meeting for a later time.

Note #3: Be Specific

There's nothing more frustrating than feedback that is not specific. How would you react to the following?

• You're doing ok, I’m happy.
• You need to do/manage this better.
• I'm disappointed with you.
• Your code was terrible.

Seriously! How would you react to the above?

So, how can I be more specific? Here, I found that using the STAR and SBI models help me think about ways I can be more specific.

Here's an example, and further breakdown (in table form).

I felt you really supported me when the team missed some stories in the recently concluded sprint. I had expected you to be frustrated by that because we had committed to it, but you understood and told the team that it wasn't my fault. So I’d like to say thanks, I feel much better about things.

Situation	I felt you really supported me when the team missed some stories in the recently concluded sprint. I had expected you to be frustrated by that because we had committed to it…
Behavior	…but you understood and told the team that it wasn't my fault.
Impact	So I’d like to say thanks, I feel much better about things.

Here's another example, and further breakdown (in table form).

I've noticed that you have been coming to work at 10:30am this past week. The team's daily stand-up was agreed to be at 10am. It's in our team policy that we are all on time in the morning. Because you came into work after the stand-up, the team didn't hear about your status updates and blockers. Being 'one person down' put a lot of pressure on the rest of the team. The others in the team even took tasks that you've probably started.

Situation	I've noticed that you have been coming to work at 10:30am this past week.
Task	The team's daily stand-up was agreed to be at 10am. It's in our team policy that we are all on time in the morning.
Action	Because you came into work after the stand-up, the team didn't hear about your status updates and blockers.
Result (or impact)	Being 'one person down' put a lot of pressure on the rest of the team. The others in the team even took tasks that you've probably started.

At this point (after providing the facts/specifics, and sometimes the impact), I would usually pause, and ask for the person's feelings. Like, what happened?, what do you think happened here?, how do you feel about that?, and listen. Yep, pause and listen. Sometimes, pausing is enough. The person I'm giving feedback to, would explain his/her side. So, I pause and just listen.

Note #4: End with an Agreement

End the feedback session with an agreement. This is important. So, don't forget about ending with an agreement.

Usually, when giving negative feedback, an agreement should be reached. This agreement involves preventing the undesired behavior from occurring again, and providing consequences if it does occur again. Decide together what action(s) you both will take after the meeting.

A Suggested Sequence

While researching further on giving/getting feedback, I chanced upon a PDF from ACTPS Performance Framework. It suggests the following sequence:

1. When you… (situation and behavior)
2. I am concerned because… (impact)
3. Pause for discussion.
4. I would like…
   Because…
5. What do you think?

When you…	A statement that describes the behaviour without judgment, exaggeration, labelling or motives. Just state the facts as specifically as possible (You could use the STAR model outlined above).
I am concerned because…	Say who or what it impacts and what the impact is.
Pause for discussion.	Let the other person respond.
I would like… Because…	Describe the change to the other person to consider and why you think the change will address the issue/concern.
What do you think?	Listen to the other person's responses. Be prepared to discuss options.

And, don't forget to end with an agreement.

Good News For Those Who Seek Feedback

A research paper, "Tell Me What I did Wrong: Experts Seek and Respond to Negative Feedback," in The Journal of Consumer Research, says that when people are experts on a subject, or consider themselves experts, they’re more eager to hear negative feedback, while those novices are more likely to seek positive responses.

So... if you're eager to hear negative feedback, congratulations! You're on your way to becoming experts.

Further Reading

Just a few days ago, I saw this book by Douglas Stone and Sheila Heen at Fully Booked (across DLSU Taft).

I don't have a copy. But I watched some talks (on YouTube) given by the book's authors. So far, it's good to know that receiving feedback is a skill that can be learned.

Delegation versus Abdication

I've had several instances where I was being asked about management work at an IT software/services company. They were interesting conversations, and I thought I'd write about it here. Some of the senior developers and project managers I've worked with indicated they wanted to either stay away from management (and remain with coding), or get out of management (and get back to coding).

These discussions usually boiled down to the difference between management by delegation and management by abdication. I've read about this before in E-Myth Revisited and here too.

The dictionary defines delegating as "entrusting (a task or responsibility) to another person, typically one who is less senior than oneself". And defines abdicating as "to renounce or relinquish a throne, right, power, claim, responsibility, or the like, especially in a formal manner".

I'd usually get a chuckle and a reaction that indicates that they're not abdicating, since they are obviously still occupying the position of power. But I believe they are missing the point.

Delegation requires a manager to understand what needs to be done, and then assigns someone to perform or be responsible for that task. A delegating manager designs what they are managing, and then delegates the responsibilities of that management to the people underneath him.

Abdication, on the other hand, involves assigning tasks to others, while not having any understanding of what they are doing.

Are you delegating? Or are you abdicating?

Real-world Example: IT Manager

Abdicator

Hires a team of software developers, analysts, and testers, for a project. Never gives them clear roles and responsibilities, but instead just says "do your job". While the team is busy with the project, the abdicator doesn't monitor and check if the project is progressing the way he wants it to progress (as s/he does not understand how it needs to be done).

When a project team member would ask the manager for suggestions, the abdicating manager would simply say something like "I surround myself with people smarter than me. That's why I hired you. So, what do you think would be best? ... Then go with it." (Sound familiar?)

Then, when something goes wrong with the project (e.g. missed deadlines, etc.), the abdicator gets mad and fires the team because they weren't doing their job.

And worse, this repeats again with another project team, since the abdicator still hasn't learned his/her lesson. S/he still has not designed a way (strategies/tactics/processes) for the team to manage the project, and failed to ensure that the team is following it.

Delegator

Hires a team of software developers, analysts, and testers, for a project. Understands that the following processes need to happen for a successful project: contract, schedule, backlog, sprints, iterations, version control, coding, testing, deployment, etc. Delegates the: backlog to the product owner, user stories to an analyst, design and coding to the programmers, testing to the testers, etc. Understands that each of these tasks happens continuously and then tracks the progress of these. S/he knows before something goes wrong in the project, and understands how to remedy them.

S/he continues to refine the design with structure and forethought. This frees the manager from the crushing load of day-to-day issues, and allows him/her to expand and scale out.

Micro-manage?

Remember our dictionary definition of "delegate" is to entrust someone else a task? Regardless of who has the responsibility for a task or function, the delegating manager is ultimately accountable for the outcome.

If it's such a big risk to delegate (and ensure things are done correctly), then should we micro-manage? Please don't!

Delegate, Do Not Abdicate

There are ways to help ensure that delegated tasks are done correctly (without micro-managing). That's why most IT managers define processes and checklists to help ensure that things are done well (e.g. require a signed contract before starting a project, ensure that work effort is charged to the correct project account, how are margins affected when team members are promoted, consider effects of long-term engagements over short-term, etc), and if things go wrong, managers can readily see it and take action.

In the E-Myth Blog post, it provides some guidelines for effective delegation. These include:

• Document the correct way to perform this task, step by step, including the quality control standards for each step.
• Clearly specify the expected results of the delegated task. Give information on what, why, when, who, where and how.
• When the new system document is ready, provide it to the employee responsible for that task, train them on how to successfully run this "system" and insert a copy of this process document into your company's Operations Manual.

In an organization that provides IT software/development services, these step by step guides to performing (delegated) tasks may mean: using TDD or ATDD, setting up a version-controlled repository for team members, using user stories and story points, having a daily 15-minute stand-up, proper on/off-boarding for new team members, etc.

Note that the processes need to be continuously refined. Or, if the process was defined by someone who does not have a good understanding of the business of software development, then perhaps the process itself is flawed.

If you're joining a company to become part of management (or whatever role), this is effectively being delegated the task of managing (or whatever the role entails). It would be good to determine if the company (and its leaders or managers) is good with delegation, and check if they have processes to bring you up to speed with how to do things correctly. Ask how you'll be evaluated to see if you're doing a good job or not. Otherwise, it might be a sign that the company doesn't really know what it's doing (and is just abdicating to hired people and telling them to "do your job").