Skip to content

My Manager README. For more information, see https://managerreadme.com.

Notifications You must be signed in to change notification settings

bdrelling/manager_readme

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

1 Commit
 
 

Repository files navigation

Brian Drelling's Manager README

Hello! I'm Brian Drelling, and this is my Manager README. In it, you'll find a lot of extremely transparent information about who I am, how I prefer to work, and what's important to me.

You may treat this document as a reference and promise on how I will conduct myself as a manager, as well as what I will expect from you.

Please hold me accountable to my promises and feel free to call out anything that might be missing or inaccurate within this document.

Table of Contents

My Role

Throughout my time at the company, there are three things that I will always consider myself responsible for, no matter how my role may change.

tl;dr: I’m here to provide technical feedback and guidance, to encourage and assist with your professional development, to advocate for your needs and the needs of the team, and to champion our successes.

Technical Advocacy and Leadership

Software development is not only my career, but also still one of my biggest hobbies. If I'm not programming enough during the day, I tend to dive into random side projects at night. I love writing Swift for Apple platforms, command-line applications, and server-side development, but my career has spanned across frontend, backend, full-stack, video game, and mobile development, and I've picked up way too many languages along the way.

It is my hope that I can leverage any and all technical experience I have to help our product, our platform, and our careers.

I do not enjoy working in a silo; if I am able to gather feedback prior to making any significant technical decision, I always will. I will work hard to ensure our technical debt is considered and maintained, that architectural decisions are made by committee, and that the team has as much of a say in how our technical stack evolves over time as I do.

As time permits, I would love to encourage more open source software as well as an engineering blog, and will do my best to find time for these sorts of efforts for anyone else on my team that has an interest.

Career Development

Your career is yours. You alone know best how you'd like to grow and in what areas.

Together, we'll work as partners to articulate your career goals and discover opportunities at the company that will help you learn and grow. I can provide feedback and offer an outside perspective as much as you would like.

There is a world of experience and perspective that I simply don't have, but in the event I'm unable to provide you with actionable next steps in your career journey, I will help you find someone who can.

My biggest value to you is to be a strong vocal advocate for your success. I'll get you the resources you need to be successful, empower you to make an impact without friction, remove any blockers I am able to, and lead and foster collaboration amongst the team.

Psychological Safety

In a psychologically safe team, all team members should feel accepted and respected. I believe this is the top-most priority on any team, and will do what I can to ensure that any and all norms and standards we've established as a team continue to be respected.

I hope you will feel comfortable sharing any thoughts and concerns with me related to your morale, happiness, and overall job fulfillment so that I can work hard to address them.

My Core Values

Assume Good Faith

My entire world changed when I discovered this value on Wikipedia ages ago, and I think about the phrase at least once daily.

As someone with an anxiety disorder, it can be an upsetting spiral when you aren't sure about the tone and feeling behind what someone is saying. This is doubly true for text communications.

Instead of assuming the worst, I will always try to assume positive intent unless I have reason to honestly and truly believe otherwise. I hope that you will provide me with the same benefit.

Communicate Early and Often

So many problems in our industry could be avoided with more frequent and transparent communication. I will probably (read: definitely) post a lot of "FYI" and "Heads Up" comments in Slack that you may not care about. I will probably also @ you more often than you're used to.

If it ever honestly gets to be too much, let me know. Communication is good, but noise is bad, so let's work together to find the right balance.

Have Fun While Being the Best

I first heard this when working for Best Buy. I maybe wouldn't say I had the most fun working there, but the value resonated with me and still sticks with me years later.

We spend ~40 hours a week at work, which in our case can involve a good deal of isolation while we bury our heads in code. This can be doubly true when working remotely. Sometimes, the challenge alone can be fun and rewarding, but it isn't always enough.

I believe that if we aren't having fun while we're working, then we most likely aren't delivering our best work.

My Expectations

Availability

I am available during my working hours, which are indicated when planning a meeting with me.

If my availability changes for a significant length of time or I am unable to attend a previously accepted meeting, I will communicate in our primary team channel as soon as I am able, if at all possible. I expect the same from all members of the team as courtesy to the rest of us.

I will also do my best to communicate any OOO, as well as any PTO prior to my time off.

I suffer from chronic insomnia, which leaves me with an inconsistent schedule and some late nights. Rarely, this may impact my attendance to an early-morning meeting, which is also why I'll always push to have meetings a bit later than typical. I may not be able to appropriately communicate my availability in some cases (as I'm dead asleep), but will do my best to impact the team as little as possible. I appreciate your patience and understanding in advance.

Accountability

On a product development team, no one person is responsible for a missed deadline or a bug in production. I have taken down and impacted enough production services to understand that the best reaction to any mistake that any member of the team makes is to accept that it happened, appreciate any learning that came from the mistake being made, and move forward with a plan to correct and/or prevent it.

Please let the team know as early as possible if you feel you may miss a deadline. The earlier the team knows about it, the sooner we can make a plan to course-correct and adjust other priorities as necessary.

Providing and Receiving Feedback

Feedback is the only way we learn and grow. It can be hard to hear, but it's usually better to have heard it.

I prefer to receive feedback as close to the moment that inspired it as possible. I'd prefer it privately, such as via Slack, Email, or a 1:1 conversation, but this isn't always possible if the feedback is urgent, so you're welcome to (respectfully) provide feedback in a meeting if necessary. I'd also ask that you be open to follow-up questions in a non-defensive manner so that I may better understand your feedback.

While I will always try to assume good faith, it also helps if you do your best to ensure the feedback comes across as helpful and constructive however you're communicating it, but especially when communicating via text. Emojis always help! This isn't just a request, but helpful advice anytime you're providing feedback.

I will ask you how you prefer to receive feedback in our first 1:1, and will do my best to follow your preferences.

Contacting You

I will reach out to you via Slack during your set working hours. If there is an extremely, extremely urgent issue, such as an unsolvable product fire or other on-call event, I may reach out to you via Slack, then text or call the phone number that you have provided to the company.

Occasionally, because of timezone overlap, I may mess up and send you a message before my work day ends, but after your work day is over. If this happens, you shouldn't feel the need to respond before the next day. If anything is urgent enough to warrant a same-day reply, I will always clearly state the urgency and/or deadline of the request.

Contacting Me

I can be reached via Slack and email during the day, and will be constantly checking each. I am typically like a hawk with notifications, so you should have no problem reaching me this way.

Typically, I prefer Slack for conversations and email for action items, but it really doesn't matter how you send me a message.

After hours, feel free to Slack me if you don't need a response until the following day. If you need a response more immediately for any reason, feel free to send me a text. It doesn't bother me at all, and if I'm busy I will respond when I'm able to.

Scheduling Meetings with You

I will try my best to schedule only necessary meetings. With that said, meetings may frequently be necessary. If you don't feel they are providing value, please let me know. With that said, sometimes the value is for others and not for us, so please come to any meeting with an open mind.

I encourage you to set your preferred working hours on your Google Calendar. Additionally, if you prefer to take lunch at the same time every day, please block that time off.

These aren't requirements—they are for your benefit to ensure that I (and others at the company) schedule meetings only when you are available, so that our work does not impact your life.

Scheduling Meetings with Me

I prefer quick virtual meetings to potentially long Slack conversations.

As long as I have free time with respect to my working hours, which are visible while planning a meeting, you are always welcome to book time on my calendar.

1:1s

Who leads our 1:1?

1:1s are for you, so I'd encourage you to lead the discussion if/when you feel comfortable doing so.

Alternatively, if you prefer some guidance or structure or are never totally sure what to discuss, I will always have topics we can dive into.

How often will we have our 1:1?

When first joining a new company or onboarding a new hire, I will likely set a weekly, 30-minute cadence for our 1:1s.

The cadence and length of our 1:1s is always up for discussion. We can meet as often or as little as you feel provides value, within reason.

Our 1:1 meeting will be independent from any "quarterly reviews" or "performance reviews".

What topics belong in our 1:1?

Again, these meetings are for your benefit, so I encourage you to raise any and every topic, concern, or thought that you want to discuss. These meetings are your opportunities to let me know how you're doing, what you need, what you wish could be different, how you feel about our team and your teammates, where your career goals are, etc.

On my end, I will make a commitment to ensuring that we remember to touch base on both Career Development and Psychological Safety (eg. morale, happiness, fulfillment) very regularly.

1:1s shouldn't be about work updates (unless you really want to talk about work). I'll typically leave these sorts of topics for a Slack discussion, or schedule a follow-up meeting if needed.

Urgent matters shouldn't wait for a 1:1! I can always find time on my calendar if you need to talk.

What is safe to share in our 1:1?

Anything shared in our 1:1 should stay between you and I, full stop. I believe that the best working relationships are built on a foundation of candor and trust, and that can't be achieved if we don't have a safe place to share thoughts, feelings, concerns, and feedback with one another.

If there is ever an extenuating circumstance (eg. intended bodily harm to others, etc.) where I feel that I am obligated to share the information you have provided with me with another party, I promise to always transparently inform you what information I am sharing and with whom.

Our 1:1 setting should be a safe place; if you don't feel this is the case, please provide feedback to my boss so that I may understand and improve.

Credit

The idea and initial format for this document comes from Oren Ellenbogen of SoftwareLeadWeekly and his work on Manager Readme.

About

My Manager README. For more information, see https://managerreadme.com.

Topics

Resources

Stars

Watchers

Forks