An open API service indexing awesome lists of open source software.

https://github.com/bkamapantula/managers-alphabet

Good practices as a manager
https://github.com/bkamapantula/managers-alphabet

engineering-management management software-engineering

Last synced: 3 months ago
JSON representation

Good practices as a manager

Awesome Lists containing this project

README

        

# Managers Alphabet
This is a curation of good practices as an engineering manager. Generally, these apply to managers who aren't engineers too.

*Note: my experience is in software industry, academic research. Bulk of the advice is geared towards working with knowledge workers in the IT services sector. Your mileage may vary. Adopt accordingly.*

You may want to know my [background](#background) to appreciate the content better.

Clearbit's [Manager's Handbook](https://blog.clearbit.com/managers-handbook-tldr/) was a trigger to curate best practices. I realized Clearbit's version of handbook can be more explicit for easier understanding and adoption.

A not too different version of the document was adopted at [Gramener](https://gramener.com/). Links to contexts internal to Gramener (calendars, learning material) have been removed due to authentication restrictions.

- Table of Contents
- Appraisal Discussions
- Breaks
- Communication
- Deep work
- Dos and Don’ts
- Empathy
- Feedback
- Firefighting
- Growth
- Handling Exits
- Improvement
- Leadership
- Learning
- Limitations
- Meetings
- Note taking
- One-on-ones
- People
- Planning
- Questions
- Resource
- Reviews
- Smart Goals
- Training
- Unchain
- Work-life balance

## Appraisal Discussions

Appraisal discussions are the hardest meetings.

**Preparation**

Prepare to communicate feedback from HRMS questions. Typically 3-5 weeks notice is given by the People Team to managers to complete the feedback. If planned well one can complete the assessment within time and arrange for a one-on-one discussion with the reportee.

- Assess based on their current role.
- Talk to all managers with whom they have worked in the past one year.
- Leverage project reviews and feedback from that.

Accumulate everything and prepare the discussion points.

**Communication**

- Give evidence backed feedback.
- Assess the person in the past year. Monthly one-on-ones help iteratively aggregate feedback.

Productive Appraisal discussions can be achieved within 30 mins. Multiple discussions may be required depending on the feedback.

**Using SMART Goals**

SMART Goals are a way to measure incremental progress at internals of three months (that is, a quarter). Read [its section](#smart-goals) to know more.

## Breaks

Work can get hectic from time to time. Personally, take regular breaks. If you’re unable to take leaves find a buddy who can hold you to take breaks regularly.

Next, enable your team to take regular breaks.

- Identify over-worked people (Timesheet report can help). However, people can over-work and still not fill Timesheet. Track using other means (code activity, project activity, emails, personal assessment etc.).
- Between phases of a project, give people a break for few days to recuperate.
- After a long-term project completes consider rotating the key people (if they're inclined) who worked a lot.
- Often, people follow the behaviour of their managers, role models, mentors. Take breaks, personally.

## Communication

Good communication is a foundation skill of a manager.

**Asynchronous over Synchronous**

`Hangouts` and `WhatsApp` are comfortable for messaging but are a medium for urgent communication. There’s a constant urge to reply to messages.

However, tasks are better managed over emails. People can get to emails whenever they’ve time (as they are occupied with work tasks) as they don’t need our immediate attention like chat services do. This mode is asynchronous.

Read [Basecamp’s handbook](https://github.com/basecamp/handbook/blob/master/how-we-work.md#asynchronously) for the benefits of asynchronous communication.

**Conflict management**

In a dynamic working environment conflicts can arise in different scenarios: during allocation, project meetings, discussions, appraisals etc.

Work to resolve them calmly.

Also see [Firefighting](#firefighting) below.

## Deep work

Encourage deep work within your team and practice it yourself.

*Talk video: Know about* [*the benefits*](https://www.youtube.com/watch?v=0UmUgaJwEr0) *of long periods of uninterrupted time.*

Designers and developers need long hours of dedicated work to be productive. Identify blockers for them (talk to them) and help them focus.

Identify what’s hindering the work you want to do.

It could be ad-hoc calls. Block your calendar for 3 hr stretches where you cannot be disturbed. Refer people to check your calendar. Configure auto-SMS messages.

*Scenario* - Someone needs your time to validate a project plan?

*Approach* - Ask them to email, share your comments or updated project plan. Refuse meeting if the document isn’t shared few hours/days earlier (define as per your convenience).

*Scenario* - Someone needs your input to send an email?

*Approach* - Ask them to share the draft over an email or chat. Share your comments. If it’s urgent share the comments over a quick call.

It could be meetings. The tasks that need meetings often can be sorted over an email. The tasks that need emails can often be sorted over a call. The tasks that need a call can often be sorted over a text message (Slack or Hangouts).

*Scenario* - Someone needs 30 mins of your time for a *quick chat*

*Approach* - Ask them to share an agenda. If sensitive (time or people-related) act immediately.

Judge wisely.

## Dos and Don’ts

**Do**

- Give freedom.
- Give periodic, specific feedback.
- Apologize when you're in the wrong (ex: late for meeting or on a promised incomplete task).
- Care about health of those in your team. Ask them to take leaves regularly.

**Don’t**

- Ever publicly shame.
- Micro-manage. Not sure if you're doing it or not? [Read to know](https://hbr.org/2014/11/signs-that-youre-a-micromanager).
- Give generic feedback.

## Empathy

Be empathetic.

## Feedback

**Evidence-based**

Feedback should be backed by evidence.

Bad - “You are always late to meetings” is vague.

Better - “I noticed the last two times you weren’t on time. Is anything bothering you?” is backed by evidence and shows concern to know about their problem.

**Be specific**

Bad - “Your code is not good” is vague.

Better - “This code is a starting point. If you can work upon lines `x1` to `x2`, `y1` to `y2` with `XX` and `YY` abstractions application will be more performant” is specific.

Productive Feedback sessions can be achieved in 30 mins.

## Firefighting

A manager’s role doesn’t exist in isolation. They will be part of projects that need to be executed against deadlines. These projects will involve cross-functional teams. People can behave unexpectedly when under pressure (due to delayed timelines from internal or client-side etc.) and tempers could flare up. Prepare for it and work with individuals to get the focus back to project.

If you are unable to manage it loop in respective people managers and work through them. Loop in People Team if things escalate. If such instances occur repeatedly inform respective practice heads. Typically, frequent communication can help resolve such incidents.

## Growth

Personal growth is critical to manage your teams (client-facing projects or reportees).

Use SMART goals to set your goals.

## Handling Exits

People leave organisations all the time. Be prepared to handle it.

Refer to your organization's policy on separation and termination.

**Be cordial**

Yes, you're under tremendous pressure to deliver the project and the exiting person is skilled at what they do. Be cordial in communication.

People only leave their current role and in several instances, are happy to return at a later point. People maybe inclined to gain experience elsewhere for industry exposure. Welcome that and work with them for a smooth transition.

**Transitioning**

Ensure projects transition well.

Ask yourself and your team these questions:

1. What are the pieces of information only she/he knows?
1. Document them in project repositories or internal Wiki.
2. What are the pieces of information she/he knows along with others?
1. Document them, train others to pick up on those aspects.
3. Is she/he your team's client SPOC?
1. Prepare a checklist of touch-points with client.
2. Arrange for another person (or two if the exiting person is experienced) to shadow for 3-4 weeks.

**Clean up**

- Notify the IT team. Know the process in your organization.
- Ensure client data is handled appropriately.
- Transfer ownership. Does the person own directories in Google drive or Seafile? Transfer the ownership to someone else.
- Are their private keys on the server(s)? Remove them.

## Improvement

At times, one would end up working with a colleague who might not reach the expectations. Before deciding to move the person out of the team ensure you have followed the right approach.

**Expectations**

Scenario - Were overall expectations clear from day 1?

Approach - If not, set the expectations. Explicitly. Write them down. Share with the colleague.

Scenario - The output (design artefact or code or quality check or documentation) was not as you expected consistently?

Approach - Prepare a list of quality checks.

**Opportunities**

Scenario - Was the person given enough chances to prove their skill?

Approach - If not, rethink and provide more opportunities.

Scenario - How many number of opportunities is the cut-off?

Approach - Three opportunities (different or similar tasks across projects based on the person’s preference) is reasonable.

Refer to your organization's performance appraisal procedure.

## Leadership

There are plenty of opportunities for growth. Be on the look out for emails:

- on talks or workshops in organizations or universities
- meetup events

Extend these invites to others and help them grow.

Know your leadership style. Engage with different teams and use the opportunities to fine-tune the processes, learnings.

Best of the leadership styles enable teams to excel without constant interference.

## Limitations

You may have been promoted as part of managerial track or hired as a manager. The people you manage may have better skills than you. That is alright.

A manager’s role is to facilitate business and help people grow. Know your limitations. If you are allocated a task or picked up a task that you, realize later, are not equipped to handle well identify the right people within or outside (raise a hire request) Gramener.

You may chose to work on that specific task if it interests you for work (make it a goal) or as a hobby (find a buddy and review periodically).

## Meetings

You can’t always avoid them. Aim to reduce them for your team. Less distracted people focus more.

Always cut the group calls in half until you can’t. Cut a `1 hr` meeting to `30 mins`, cut a `30 mins` discussion to `15 mins`, cut a `10 mins` discussion to a quick call.

Context switching (across several tasks) has a [cost](https://www.youtube.com/watch?v=T7MCplY_yPc) and is real.

**Agenda**
Set the agenda if you’re creating the meeting, check if only those are present whose inputs are required.

Ask everyone to share their thoughts over the calendar invite or on a shared document. Writing down your ideas will clear your head and streamline thoughts further.

Ask for an explicit meeting agenda if you’re attending one. Skip it if you don't have it upfront.

## Note taking

Sharing updates after meetings is critical for businesses to function. Note taking helps this immensely in different contexts: internal/external stakeholder meetings, one-on-one meetings, appraisal discussions, ad-hoc meetings, sports, cultural events, social settings etc.

1. Note taking is a necessary skill for a manager.
2. Offer to take notes whenever possible.
3. Share the notes once a meeting is complete.
4. Mentor others to pick up this skill by gently nudging them to take notes on specific topics then complete conversation. Review their progress frequently.

Note taking need not be item-based. Refer to Rasagy’s [sketch note](https://twitter.com/rasagy/status/1102763157162881025/photo/1) taking approach. It’s important to capture the essence as well minute details (in certain contexts).

## One-on-ones

One-on-one meetings are critical to get timely feedback from people.

1. These meetings are for the reportee.
2. Set them frequently. Twice a month is good. Once a week is great.

Productive one-on-one meetings can be achieved in 30 mins.

## People

As a people manager you are responsible for the overall well-being of the reportee including health, career path, mentoring, performance.

Occasionally, reportees might reach out for help in personal lives. Support them.

## Planning

Everything at work boils down to planning. Be it projects or tasks or goals or meetings. Deliberately practice planning via tools (calendar, emails etc.) and templates (project plan, WSR etc.).

Revisit the planning frequently and adapt.

## Questions

Ask lots of them, upstream. It’ll help clarify short-term and long-term goals.

Request lots of them, downstream. It’ll help clarify your thought process.

## Resource

What is a resource? Laptop, USB, WiFi hotspot.

What is not? Person.

Be sensitive while allocating people to projects and communicating via emails and conversations. Language permeates through different contexts, unknowingly at times. [Non-violent communication](https://www.clearerthinking.org/single-post/2019/03/06/Want-to-improve-your-relationships-Try-Nonviolent-Communication-1) is handy.

## Reviews

**People**

People reporting to you might be working in projects that you aren’t part of. This may not be uncommon at your organization.

Establish a mechanism to track such instances. A periodic review call with reportee, concerned consultant or project manager is a good mechanism.

**Projects**

Establish periodic (monthly) reviews of projects and pass on timely feedback. Refer to an internal `Project Evaluation Template` for a reference. Create one (after consulting the relevant stakeholders) if it doesn't exist.

## Smart Goals

SMART Goals are an accepted form of setting targets... where SMART is an acronym:

- S - Specific
- M - Measurable
- A - Attainable
- R - Relevant
- T - Time-bound

1. First, ensure your goals are set. Discuss with your manager about it.
2. Set every goal specifically that be measured within reasonable timeframe.

**What can go wrong**

If a manager isn't proactive and vigilant with setting up goals for his/her team this mechanism wouldn't work.

## Training

**Yourself**

Identify the areas for improvement, chalk out a plan. For every area of improvement identify a mentor or a buddy who will hold you accountable for your plan. Setup periodic calls to review progress.

**Your team**

Discuss with each of your reportees and identify their interests and problem areas (by asking them). Chalk out a plan for the most important one (individual and organization alignment).

## Unchain

Meetings have real cost. To quote the book [It doesn't have to be crazy at work](https://www.goodreads.com/book/show/38900866-it-doesn-t-have-to-be-crazy-at-work) -- "a 1 hour meeting with 4 people isn't 1 hr, it's worth 4 hrs".

Unchain your time from different meetings, initiatives when necessary. Contribute where you're *absolutely* needed (where the initiative or the meeting will fail without you). Others will understand.

## Work-life balance

All of us aim to balance our interests at work and life outside of work. Planning extensively before a project is executed in different phases (design, development, QA) can help immensely to bring the best out of all teams.

There are moments of intense and lull work periods. Keep a tab on your team members and importantly, yourself.

Background
----------

I've been at [Gramener](https://gramener.com) for over three years and 19 months of those as an engineering manager. Prior to that I spent about 8 years in academic research with different mentors. Real-time experience in projects and dealing with people simultaneously helped me understand different situations.

My frequent interactions involve developers, business analysts, designers, quality analysts, SBU and practice heads.

My thoughts are shaped by leaders of the industry: [S Anand](https://twitter.com/sanand0/), [Charity](https://twitter.com/mipsytipsy/), [Jessie Frazelle](https://twitter.com/jessfraz), [Feross](https://twitter.com/feross/), [Camille Fournier](https://twitter.com/skamille/) and many others.

References
-----------
1. Clearbit's [Manager's Handbook](https://blog.clearbit.com/managers-handbook-tldr/).
2. [Engineering management](https://charity.wtf/2019/01/04/engineering-management-the-pendulum-or-the-ladder/) by Charity.
3. Your leadership weakness is being “too controlling”. What to do? [Signal v. Noise blog](https://m.signalvnoise.com/your-leadership-weakness-is-being-too-controlling-what-to-do/).
4. [Asynchronous communication](https://doist.com/blog/asynchronous-communication/), Doist.
5. It doesn’t have to be crazy at work, book. [Introduction](https://m.signalvnoise.com/our-new-book-it-doesnt-have-to-be-crazy-at-work-is-out/). [Amazon](https://www.amazon.in/Doesnt-Have-Be-Crazy-Work/dp/0008323445/).
6. Excellent curated [list of books](https://github.com/jesselpalmer/the-engineering-managers-booklist) for managers.
7. [The engineer-manager pendulum](https://charity.wtf/2017/05/11/the-engineer-manager-pendulum/) by Charity.