Coaching: practical guidelines

As a senior you will always have high-value priorities competing for your time. Coaching should be one of those priorities for these nine reasons. 

Continuous feedback

Give feedback continuously. Two points every four weeks is better than 12 points in one single meeting every six months, because:

1. You and coachee won’t forget the feedback you intend to put forward.
2. The coachee will digest feedback bit by bit. Avoid information overload.
3. The coachee can act sooner and add more value sooner.
4. Conducting the six month appraisals on time becomes easy.

Set aside time for coaching on a frequently recurring basis.

Process: TBD, preliminary and AD docs

Use three separate Google docs for each of your coachees:

1. “Name FB – TBD”. To Be Discussed. This is not shared with anyone. Note down ideas often.
2. “Name FB – Prel”. Place preliminary feedback that you’ve discussed with the coachee only very briefly. Give the coachee time to verify the feedback and comment on it, before you move it over to the widely shared AD doc.
3. “Name FB – AD”. Already Discussed. This is shared widely: with the coachee, relevant seniors and preferably coachee’s juniors as well. Move the feedback here after the above due process.

Bookmark these documents in a folder named “Coach”. Should be easy for you to add ideas to TBDs at any time.

Why a preliminary doc? It saves time because the feedback presentation can be extremely brief. You avoid notifying others of inaccurate feedback, as the coachee has time to revisit the matter. It ensures that you are both in sync.

As several seniors will add to the AD doc, suffix the heading of your input with your name. Here’s an extract: “Name FB – AD”. The most recent feedback is added to the top of each section.

Providing continuous feedback is easy once you’ve formed the habit. We all notice juniors’ improvement opportunities on a daily basis.

Selectively note down your ideas immediately once you notice something valuable. Add the idea to the TBD doc.

Place the URL and a brief text if needed into the TBD doc. Example. The URL could be: Gmail URL, screenshot URL, Basecamp URL.

Use an automated screenshot to clipboard URL feature such as send-screenshot-to-dropbox feature or SnagIt to Google Drive to make it super easy to get screenshot URLs.

Set a reminder to discuss TBD points once per month or so, during a block of time that you dedicate to coaching. Points that are already explained via email, require little time and effort to perfect.

After discussion copy over a “firm version” from TBD to preliminary or AD.

Benefits:

1. Preparing for an appraisal becomes easy. The preparation consists of formatting and improving feedback including the latest relevant sections from the LBPs. If you haven’t noted down feedback ideas continuously it becomes very difficult to find good examples retrospectively.
2. Jotting down TBD feedback takes little time. Allows us to focus better, and carefully select the most relevant and most high-impact feedback once we set aside time for coaching.
3. You improve the clarity of the feedback at a later stage when you have a better overview. You can remove irrelevant or low-value feedback at this time.

Standard feedback structure

Structure your feedback the following way, and like in this example:

1. The problem story.
2. Acknowledgement (optional).
3. What you should have done differently.
4. Generalization; make it relevant to a broad audience (optional).
5. Principles reference (optional).

The uniform, concise and clear structure makes it easier to grasp. Example:

Clearly named heading

Aim to assign a clear heading such as “Principle->specific scenario”. E.g. “16 Jun 2020 – Sell / careful interpretation: lead Grace and permanent staff – David”

For project-related feedbacks, you should include project abbreviation in the title for added clarity. For eg. “14 May 2020 – Assume & Suggest: Fix for ads renewing in ByT – Ajith”

It should not be so long that it breaks into two lines though. It will make it very easy for all stakeholders to remember what the feedback was about.

The date on the feedback heading should be the date of formalizing the feedback, ie: the date on which the feedback was discussed and shared/published.

In some cases, the feedback and required corrective measures may have been discussed in detail much earlier. In that case, the date in the feedback heading can be the date of discussion.

The main aim here is to bring clarity about when the feedback was discussed. This allows us to better understand the amount of time the coachee had to act on that particular feedback.

Feedback formatting styles

The feedback should be styled as follows:

Get in sync

For feedback to be accurate and motivating, you and your coachee must get in sync. You must encourage your coachee to be transparent when they have concerns about feedback.

Disagreements must surface and be dealt with, not swept under the rug.

Giving the coachee time to go through the preliminary feedback document helps. If the coachee disagrees or puts across new information, you can add acknowledgements or even scrap the planned feedback altogether.

Read more in service quality guidelines: get in sync.

Notify and share

Notify staff after adding feedback by emailing into a thread named “YEAR: Feedback – Name” (for eg. 2023: Feedback – John Doe). Use this exact thread name making it easy to search and find the thread. Benefits:

1. All seniors will be on the same page and colleagues will learn from similar feedback.
2. Our feedback becomes uniform. All staff is treated the same way.
3. We can learn from each other and settle on best practices.

Transparency

When sending the feedback notification, CC relevant staff. We are fair and transparent so don’t hesitate to loop staff in.

Radical transparency has many advantages. Colleagues are given the best possible chance to grab valuable tasks. They can avoid repeating others’ mistakes. They will better understand the company’s background and challenges.

When you are open about the feedback given to yourself, it’s more likely that your colleagues will embrace feedback given to themselves too.

As you know, getting used to transparent feedback can be psychologically overwhelming for new staff especially.

Discuss first, then formalize

Discuss the feedback with the recipient before sharing it into the Preliminary or AD doc:

• To allow the recipient to respond and thereby avoid that incorrect feedback is being shared.
• To avoid that discussions occur after sharing feedback.
• To give the feedback a milder and more positive touch; to avoid that the recipient responds negatively.

Hint via email

You can hint at feedback via email if you have a strong coaching relationship and the matter is not sensitive. The feedback-to-be might have a lower level of criticism in the email than the final AD version.

Add Gmail URL to TBD so you won’t forget to perfect it later. This is an example of setting clear expectations on vacation days research.

Acknowledge efforts, build strong relationships, educate, aim for brutal directness

A coaching relationship can be brittle if the coachee is: a new employee, someone who might respond emotionally, someone who doesn’t yet understand the coaching concept fully, someone you don’t work much with, someone at similar or higher seniority level who feels “criticized by their junior”.

Aim to build a strong coaching relationship by making sure that your colleague understands the principles and the coaching concept.

Educate and explain why coaching is win-win, and why the coachee should never get emotional about feedback.

Acknowledge your coachee’s hard work and the difficulties that they have faced. The more brittle your relationship, the more important this is.

An acknowledgement will reduce your colleagues need to explain themselves and make your colleague interpret it correctly.

This being said, the aim is for feedback to be brutally honest and direct. Don’t go overboard with acknowledgements; there should be no need for sugar-coating once you’ve formed a strong relationship with your coachee.

In a strong relationship, the coachee understands that even brutally direct feedback is for their own good.

High impact

Bring up the highest impact examples that you can think of; feedback that have the most effect on value-creation.

Simple feedback that can be applied to many frequently recurring situations can also have a high impact through its cumulative potential but group these together to avoid lengthy AD docs.

Only through high-quality examples can we expect high-quality results.

Anonymize

Ideally, we should be able to distribute feedback very widely. The gold standard would be to be able to publish it publicly like PD’s.

Abbreviate client and project names. Closely involved parties will still understand what projects are being referred to, and distanced parties won’t need to know exactly what project is referred to. Example problem description:

“You requested feedback from client rep W for project A on 18 July 2018. The questions asked were ‘closed’, triggering yes/no responses which won’t be informative.”

Cut out screenshots in a way that names in greetings and signatures are not included. If it’s not possible to cut away all names while retaining clarity on the case, then blur out (redact) sensitive information.

You need not anonymize LiteBreeze employee names in order to save time, unless its a sensitive feedback.

Be proactive, if you write an email that you know will be part of feedback, refer to “the client rep” instead of “name” for example.

You can blur areas using SnagIt. Take a screenshot of a part of your screen using Ctrl-C to load the screenshot in SnagIt.

Once you’ve blurred the regions, either send to Dropbox/Google Drive from within SnagIt, or simply take a screenshot that is automatically sent to Dropbox using Cmd-Ctrl-Shift-4.

The screenshot link is now in your clipboard and you can simply add it to the feedback document.

Avoid using external links like Basecamp, bitbucket etc. and always use anonymized public screenshots using Gdrive/Dropbox. This will make it easier to share the feedback with a broader audience.

If you anonymize an AD doc to send to a client, you can move very old or very sensitive feedback to a separate document.

Delegate formalization of feedback

Combat systemic under delegation by identifying problems but delegate the formalization of the problem as feedback.

Hint via email or even flesh out a 90% ready-to-copy feedback example. Then ask your junior colleague to formalize the feedback into the coachee’s AD document. Example 1, example 2.

Clarity, specificity, screenshots

Write a concise introduction to each feedback point (example). Anyone should be able to quickly grasp it at a later stage, including clients and new staff.

Evaluate accurately, not for the sake of being kind. In the end, a tough but accurate evaluation is the kindest thing to pass along.

Screenshots help us grasp situations faster. But ideally, your feedback should be graspable even without looking at the screenshot. If we don’t need to open up external screenshots, that saves time.

I suggest using external screenshots instead of internal screenshots to keep feedback documents neat. The obvious benefit of inline screenshots is that it’s easier to grasp without having to waste time opening separate links.

You can use inline screenshots during the appraisal for this reason if you wish. But converting them into external screenshots within 10 days after the appraisal.

Converting internal screenshots to external is super-simple using the send-to-Dropbox feature.

Avoid large inline screenshots when possible; take a screenshot of the relevant part of the screen.

If emailing feedback: If you need to paste a big screenshot, use the “best fit” image option in Gmail to avoid the email thread widening resulting in that rows of text don’t break properly.

In addition to screenshots, include links such as a Basecamp link to a specific comment, in case anyone wants to dig deeper.

Bring up specific project situations and make it really simple to understand them for anyone at any time: a concise summary of the case, screenshots, relevant chat transcript snippet or whatever may help to grasp the scenario quickly.

Include references to principles

Sections from our principles that are related to your feedback can be pasted into the feedback doc. Paste without formatting, then use italics, hyperlink the heading, place it below the feedback.

I’ve included only the first paragraph to save space and encourage the coachee to visit the LBPs. This can bolster your message.

Benefits:

1. Saves you time explaining why a concept is important. Explains the concept from another angle which complements your own interpretation.
2. The LBPs are continuously being perfected, so if your colleague revisits old feedback the link might contain a newer and clearer version than the one you had copied X months ago.
3. A copied section hints that the feedback ideally could have been avoided, because the concept was already explained in the LBPs.
4. A copied section hints that there might be other important sections in the LBPs that your colleague has missed.
5. Adds authority to your feedback.

There’s a risk that the feedback doc becomes too lengthy. You don’t have to copy the same sections often. Include only if you find an LBP section that matches well.

If there are inconsistencies and you think the LBPs need to be updated, contact me.

Always personalize feedback

“Identifying who made mistakes is essential to learning. It is also a test of whether a person will put improvement ahead of ego and whether he will fit into the Bridgewater culture. A common error is to say, ‘We didn’t handle this well,’ rather than, ‘Harry didn’t handle this well.’

This occurs when people are uncomfortable connecting specific mistakes to specific people because of ego sensitivities. This creates dysfunctional and dishonest organizations.

Since individuals are the most important building blocks of any organization and since individuals are responsible for the ways things are done, the diagnosis must connect the mistake to the specific individual by name.

Someone created the procedure that went wrong, or decided we should act according to that procedure, and ignoring that fact will slow our progress toward successfully dealing with the problem.” – Ray Dalio

Seniors’ feedback is a complement

Your seniors may continue to give feedback to your juniors. This is to give you inspiration and to show you what type of feedback we feel is important.

Ideally, all coaching of your juniors should be handled by yourself though. So feedback from your seniors to your juniors is just complementary to your own feedback; never rely on it!

Appraisal delays

Staff are responsible to prepare their input (appraisal guidelines) on time and sending their appraisal input to their senior when ready.

It’s not a problem if the appraisal meeting is held slightly after the actual effective date of the hike, as long as your colleague is aware that the ball is in their court.

This being said, do not delay your subordinates’ appraisals too much.

Delays can lead to problems:

1. Staff will improve slower as seniors are not given the opportunity to re-stress their feedback.
2. If the payout of salary hikes are delayed, the appraisee might be demotivated. Management can only decide on the hike after the appraisal is conducted and we may need some weeks to benchmark salaries and take a final hike decision.
3. The appraise might feel that you don’t care enough about the appraisee’s training. Yes, the staff is responsible to take the initiative to apply for an appraisal, but at a certain point of time, you need to step in if the appraisee delays too much.
4. If the payout of salary hikes are delayed, then administration and accounting become more complex. Management accounting reports may also become complex.

The effects of delays are more severe for new staff, who need to digest many principles and much feedback, and who might react more negatively to a delayed payout.

Junior’s appraisal input

You should follow the below process when your juniors submit their appraisal inputs:

1. Make sure that all pending TBD points along with QA buglists are formalized before pushing upwards.
2. Keep the PL looped in review conversations.
3. Once reviews & modifications are completed, you should create the PL input and request your PL to review the inputs.
4. Upon receiving confirmation from PL, you can send an appraisal scheduling request to PD.
5. You should include any applicable unavailability times for the next two weeks so that PD can plan accordingly.

Seniors’ appraisal input / PL input

You don’t have to bring up old basic feedback that the employee already has taken action on such as the fact that a new employee didn’t book time properly during his first two weeks of employment here at LB.

Instead, try to contrast early feedback with late feedback; what does your colleague still have to improve – what has s/he not yet taken action on? Read through old feedback before deciding on your input.

You can create a temporary appraisal input document if you wish, as has been practised till date with the PLs input docs in the technical team.

You can also show your input directly from the feedback already discussed (AD) doc. Avoid discussing any pending TBD feedback during the appraisal meeting; the coachee shall have been given the chance to argue against feedback before the meeting.

Remove your temporary PL input doc after you’ve moved it into AD. Keeping all feedback in one place is convenient.

All stakeholders can easily refer back to old feedback at any later point of time. We get an overview, we see how feedback has evolved.

You don’t have to follow the reverse chronological order in PL input as in the feedback doc. The highest impact feedback should be listed first.

You can group the feedback of similar nature. For example, if the developer received multiple feedback on updating work plan, you can put it together. Also, you may move one of those feedback to VM and stress the importance of avoiding repeated feedback.

You can also remove the LBP reference from PL docs.

To allow us to find examples that were brought up during the appraisal, suffix a tag in the AD doc such as #APPRAISAL-SEP-2019# (example). The tag should match the month in which the appraisal took place.

The appraisal meeting

Make sure that the appraisee has prepared input as per the instructions before we have the meeting.

Direct your input to the appraisee. There’s sometimes a tendency to explain feedback to the most senior instead of explaining it to the appraisee.

“YOU did X which caused problem Y. In the future I’d like YOU to do Z.”

is much better than:

“AppraiseeName did X which caused problem Y. AppraiseeName should do Z”.

Like we ask of the appraisee: Keep appraisal meetings brief. All stakeholders will have reviewed your input before the meeting, so give a quick 2-3 sentence recap.

If appraisal meetings take too much time, there’s a risk that people will start dreading them. Aim for the meeting to take max 40 minutes.

After the appraisal, write an appraisal summary to stress the most important takeaways one last time. Include the links to the appraisee’s input document.

Send the summary in a separate email. The summary should not be long, but very concise. Try to make it unique. It’s good if you send it a few days after the meeting.

I will re-stress the summarized points when informing the final salary hike in a face-to-face meeting.

This shows the appraisee how clearly performance is linked to the actual salary hike, and what we expect in the next six months.

I usually wait a week or more, to allow for the appraisal to sink in before stressing everything again.

How to book coaching time

Set up a coaching requirement in each project in the ERP/Portal where you book the time you spend. We can then evaluate if enough coaching time has been spent, how much time is appropriate to spend, and plan for the future.

Routines

Spontaneous feedback is 90% of the feedback that I personally generate. You could set up a routine to go through the following periodically if you can’t find enough feedback:

• The actual deliverables, such as features reported as completed in case of developers
• Emails and chat messages received from your juniors
• Time entries
• Reports
• Time overviews
• Work plans/todo lists
• Previous feedback, is it acted on?

For developers and designers:

• Basecamp messages
• Chat transcripts
• Code
• Bitbucket commits

You obviously won’t have time for everything, but do enough random spot checks to come up with quality feedback.

Guidelines specific to the technical team

The above guidelines are general guidelines applicable for all departments, including HR, recruitment, administration, marketing. Below are the technical guidelines for developers.

Booking coaching time

The rule of thumb is to book coaching time as billed. Coaching will benefit the client and it’s tightly linked to managing the project.

If it’s an extreme situation where the client would balk at the time being billed, or the client disputes this time, we can always rebook some of it as unbilled.

Add a coaching requirement to the work plan to keep it synced with the time sheet overview.

Code reviews

You can delegate code reviews to a colleague who is great at coding but who may not be at your seniority level due to for example inadequate service quality skills.

Just make sure that those reviews are done well, and that quality code examples are brought up in the appraisal meeting.

Technical appraisals – who should lead?

To decide who will preside over an employee’s appraisal meeting, check what projects that the employee has spent most time on and which project leaders are responsible for those projects.

Let the project leader who has managed most of the appraisee’s hours handle that appraisal.

However if that senior already handles many appraisals, you may make an exception and let the less busy project leader take over. Exceptions can also be made for the purpose of training potential new project leaders.

Request brutally honest feedback from clients

Start with sending copies of your feedback to clients as well. Benefits:

• They will appreciate your efforts to help the team and ultimately help them.
• They will appreciate our honesty and transparency, and that we strive to learn from our mistakes.
• It’s a chance for you to build rapport with the client, show that you are involved and that you are ultimately responsible for quality in the project. It will help cement your position as the leader and reduce upward delegation.
• They will understand the effectiveness of constructive feedback, and may even send their own.

Constructive feedback sent to us directly from clients is an information gold mine. If we can act on what the client deems most important, imagine the impact it will have on the client’s satisfaction.

Aim to make feedback as transparent as possible. Ideally, you should just have to share the same feedback with the client, without editing or needing to redact sensitive information.

This saves you time. We’ve got nothing to hide and if there’s something very sensitive, we can always put it across in a separate email to the coachee.

Before sending a request for feedback, show the client what feedback you already have provided. The client’s feedback is complementary to yours. You can attach this article when requesting feedback from clients.

Sending feedback copies to clients would make even more sense if the person responsible for handling most of the communication is not a PL/APL with a team but a single developer.

You may not communicate with these clients frequently, so it would remind them that you have an important and valuable role even if it’s mostly behind the scenes. It builds rapport.

Example in project F: After an incident where the client has criticized us, sending copies of feedback related to the biggest problems can help us regain some of the lost rapport.

This worked very well in project F in November 2016, where the client representative was impressed that we had taken his concerns so seriously.

He was pleased that we had discussed the issues in such detail with each single team member and explained what we will do differently next time.

Before sending these feedback copies, the client representative M thought that the repercussions for developers at LiteBreeze, for making mistakes, were minimal.

That’s why he was happy to see that each developer had received individual and personalized feedback, and to learn that this feedback determines salary hikes and designations.

He liked the fairness and transparency of this system; earlier M had complained that he felt that we try to sweep things under the rug and make excuses.

He trusts our organization more when knowing that we are truly meritocratic. And more importantly, he understands that he can expect better quality from us in the future.