Manager Readme

As the new year approached, I wanted to write a Team Leader manifesto or a document to catch how it feels to be a team leader after one year. To summarize what I learned or to help new team leaders with what to expect.

I found this Manager Readme format and wanted to try it out.

You can find the primary doc here at managerreadme.com.

Motivation for this document

Why did I take the time to write this document?

This document is my team lead manifesto as of 2022. I write it in the first person as a team lead, and I write it to You as if you’d join my team soon. It’s like a discussion, which is how I’d tell you if we met.

I heard about this format in a Hungarian podcast called ‘Anonim Vezetők Klubja’ ep s01e07. It seemed interesting enough to try it out.

What was I aiming to get from others reading it?

I wanted you to understand how I “work” and what working with me can feel like.

Also, I wanted to remind myself of all my bad and good quirks that I should mention to avoid surprises.

My role

Besides my software development roles, my role as a team lead includes these areas:

• Administration: Manage newcomers, leavers, changes, timesheets, accesses
• Knowledge Management: What you should know, what should I know
• Resource Management: What projects will you work on
• Performance Management: Provide feedback
• Career planning/Development plan: Discuss options and goals
• Recruitment: Choose the new candidates for my team

What are the team’s KPIs? How are you being measured?

We mainly work in consulting, so the clients pay for our time. Basically, the sooner you finish the tasks, the better you are based on this metric.

In this sense, it makes you more valuable if you can estimate how much time it’d take you to finish a task. It’s even better if you could estimate something that you haven’t done before, of course I know it’s a dream.

In a broader sense we have detailed carreer plan document that we go through regularly to be on the same page of what’s expected on certain levels.

How will I help my teammates get better at their jobs?

I’ll be there for technical problem debugging and can refer to tutorials or pieces of training.

I’m up to jumping in calls for challenging technical problems to debug them together. You can join me on my development tasks to work them through together to get a glimpse of how I work.

What do I value most?

I value attention to detail. So it’ll make me happy if you mention that you also thought about edge cases.

I believe that we are humans, and sometimes we make mistakes, I value when people come forward with their mistakes before its undeniable.

I value proactivity. I don’t want to nudge you to tell me how you’re doing. If we’re working on time-sensitive tasks, keep me posted.

I value humility for the tasks and projects, and when people can argue on a technical level and does not take it personally when their ideas are not the ones that the team chooses to implement.

I value ideas that make things better.

What does helping me look like?

You can help me by asking the right questions and coming up with new ideas we can implement together.

I can help you by managing conflicts, giving you technical help via screen sharing, and mentoring you on software engineering topics I know more about.

What is my process for handling conflicts? (and how you can do it yourself)

Write me on Slack, and we’ll figure it out.

I’ll most likely ask these questions:

• Does the other party know about this issue?
• Did you listen to their point of view?
• How did you try to resolve it?

What weaknesses of mine should the team know about, and how can they help me improve?

I studied Computer Science at the university, I worked professionally in a developer role for seven years before I got a managing position.

I’m still learning communication and management. So please be patient with me. I’m still learning.

My Expectations

How should people set time with me?

• If you want me in a meeting, please tell me in advance at least 2 hours ahead. The best way is on Slack.
• I want to avoid meeting during my lunch break or after work hours.
• For ad-hoc help, ping me on Slack, and I’ll tell you when I’m available.
• My calendar is up to date with personal slots booked as well. You can book a time there with confidence.
• Please only book between 2 time slots that have at least 30 mins between them, or let me know in advance.
• If you send me a calendar invitation, please give me the context in a few sentences or make a descriptive title that I can remember if we discussed it earlier
• Please don’t set up a meeting where you tell 5+ people what we need to figure out on the spot. Let us prepare for larger discussions.

When it comes to mistakes, what’s the best way for employees to come forward?

Tell me on Slack about the problem and describe it in a short sentence. (So I won’t get a heart attack until the explanation). After that, we can jump on a call to figure out how to solve the issue.

How do I define “Done”?

• The happy path works flawlessly.
• The error paths let the user know what’s wrong.
• You demonstrate that you thought about edge cases even if they’re not implemented yet.
• It’s “demoable” to the user without shame.
• There’s some documentation or way to demonstrate it with example input to use.

When should people be available and how?

For cooperation, it’s best to be available during regular work hours in Europe. If you need to leave for at least 2 hours, please let me know so that I know that you’re away. I expect to communicate in a heavily async way so it does not matter when you answer. Suppose there’s something complex/urgent problem, then we jump on a call. On the other hand, I prefer detailed text messages.

I will only bother you via telephone if there’s a special on-call agreement, it’s your shift, and something related is going on.

Email chains are the worst way to communicate with me.

1:1s

What are 1:1s?

One-on-ones are a scheduled, formal way to have a friendly discussion.

It would be best if you didn’t wait for them to tell me anything. Ping me on Slack, and we can have a discussion whenever.

When do I usually have 1:1s with my team?

I like to have 1:1 sessions in the morning before starting development. If it’s up to me, I’ll schedule at most 3 of them in a row, close to each other, with 15-minute breaks.

I like 1:1 sessions to last for at least 30 minutes, and I prefer to hold them once in 2 weeks.

We can postpone the original schedule but don’t cancel it (unless there’s an extended vacation or similar).

Who should lead the 1:1?

As you prefer, I’ll prepare for our meetings with a simple agenda if there’s anything that we ought to talk about.

Otherwise, how much you’d like to share is up to you.

This meeting is about confidential talking and bonding.

If there’s anything I’d like to share with others I’ll ask it explicitly.

What to expect on a 1:1?

I’ll ask you how you feel and what you would like to talk about. Also, if there’s anything you’re proud of that you’d like to share, what is blocking you, and how can I support you.

Also, I usually prepare some topics beforehand as an agenda if it’s applicable.

• feedback from others
• company-related or work-related things to discuss
• project-related things to discuss
• personal growth

I like to take notes to expand my memory and mark down the action items we discuss. Taking notes makes me feel safer that I can come back with answers to you at most the next time.

What should be the primary focus during that time?

You.

I don’t want to take a lead and bore you with my stories. I’m interested in how you feel, what you struggle with, and how I can help.

Personality quirks

What are the individual quirks that anyone working with me should know about?

• I’m not too fond of cold starts. #TeamNoHello.
• If you believe in personality tests, I got blue and green in the DISC model. What it means for me is that I prefer to talk about technical stuff, and I want to support you.
• I don’t like to repeat myself. So if I ask you something to do, I’ll expect you to write it down to remember it. I’ll occasionally remind you of it in a friendly tone, but it’ll make our work together more seamless if you remember it, and you’ll grow in my eye.
• I’ll make sure that there are no elephants in the room. If we discuss something only half of the team does not know about, I’ll give them context in a few sentences. I’ll expect the same in return. Please keep me in the loop while I’m on vacation. Write me anything. It’ll make my catchup easier when I get back from it. I won’t read it while I’m away.
• I don’t like the firefighting mentality. I’ll try to be one step ahead of the team, and I prefer dealing with issues earlier than they become a burning issue
• I wouldn’t say I like micromanagement. I believe you’ll ask questions if you get stuck for at least an hour.
• I’m incredibly polite, so it might not be evident when I’m pissed off. If I raise my voice, you’ll know that I’m super mad.

Where to focus on your first 90 days?

What does effective onboarding look like on my team?

We have a few-week-long onboarding program that dives you deep into our workdays into real projects. You can work with a single colleague for an extended period to bond and see what working on the projects together feels like.

It’s considered effective if you better understand who we are, what we do, and how we like to do it.

How can you tell if you’re doing a good job in your first 30 days?

You ask many questions. You fit with the team personally, and you feel with most of them that you can work together effectively.

Disclaimer

This document is reflects my personal experience, these thoughts and ideas are my own.

This document captures how I feel currently. I aim to update it regularly when my team changes. I can remind myself of my values and reevaluate how I work.

Being a leader is a journey for me. I don’t know what the future holds.

Self-reflection is key. If you’re also a leader, I can recommend you to collect your thoughts on finding your answers to these topics.

If you have anything to add or discuss hit me up on Linkedin or via Email.

Happy leading!

Cover Photo by Miguel Á. Padriñán from Pexels