How to make your team read your mind

The article argues that the worst thing a manager can do is leave expectations unspoken. To make work easier, the author wrote a “Manager’s ReadMe” and discussed it with the team so everyone could see what he expects, what he measures himself on, and how he wants the team to work.

He uses that document to state priorities around 1:1s, office presence, working hours, alerts, Slack, ticket estimation, sprint delivery, feature ownership, design leadership, and feedback. The text closes by saying the document is a tool for thinking through expectations and discussing them with the team, not something to display without discussion.

Reading notes

#

• Unspoken expectations make team work much harder than it needs to be.
• The author wrote a “Manager’s ReadMe” to make his expectations explicit to his team.
• He wanted the team to know what he expects, what he measures himself on, and what he wants to discuss with them.
• A main goal of his role is to help the team work well without depending on him.
• He measures himself by helping people improve and by delivering work on time and in high quality.
• He uses 1:1s to catch up personally and align on the person’s path forward.
• He wants team members to steer him through their topics, feedback, and requests.
• He prefers the team to be in the office for the daily, and he sets 10 AM in-office as a firm rule for planning day.
• He trusts people to manage their own schedule, but asks them to mark long breaks or focus time on the calendar.
• He wants alerts checked at the start of the day, with each alert investigated and addressed.
• He says people are not responsible for fixing every issue, but they are responsible for making sure it gets handled.
• He expects Slack availability during working hours and no expectation to answer after hours or on weekends.
• He asks that odd-hour messages be scheduled for the next morning.
• He uses WhatsApp only for rare cases that need help outside working hours.
• He wants tickets read in full, missing information raised, and estimates treated as bets that should improve planning.
• He expects people to do their best to finish sprint commitments, while also recognizing that sprints are only a method.
• On the last day of a sprint, he wants the team to think about what went wrong and suggest practical fixes.
• He wants every feature to have an internal leader.
• He expects feature leaders to do design work, ask questions, break work into tasks, divide it well, and take ownership of follow-up after release.
• He wants people to gather feedback and open tickets when something bothers them.
• He says the document is meant to clarify expectations and start discussion, not to be posted on a wall.