My README.md

Photo by rawpixel.com on Unsplash

Having been inspired by various posts on the importance of transparency, communication and openness from the leadership side of engineering, I’ve decided to kick things off here with my own edition of a Manager’s README.

First off, welcome! If you’re reading this, you’ve either come across it by searching or you’ve been linked to it from an on-boarding document. However you got here, I think this will be a valuable first step in us working well together.

This README is an earnest, incomplete (we never stop growing) and concise guide. It sets both my expectations for you and a base-line for your expectations of me. If you like the general thinking behind this document, please create one for yourself. It can go well beyond just the working relationship with your manager and peers and provide a good jumping off point for conversations around self-awareness.


Communication

  • I’m fairly open about everything, from which kid won the most “floor is lava” matches on the weekend (pro-tip: it’s always me) to whatever Netflix shows let me down this month. I don’t expect everyone to be as open, but I do expect that when problems arise you talk to me as soon as you can. I need that level of immediacy and transparency on issues in order to help move us all forward.
  • I often use humour as a means to help others feel comfortable and relaxed in group situations, while also making myself a bit more approachable on an individual basis. I expect that if you have issues with this approach you will let me know and I will curb it for our interactions. Although to be fair, I’ve yet to meet anyone who doesn’t like to laugh.
  • I actively work on creating a rapport with all members of an organization, both in engineering and outside of it. It’s not easy when you’re an introvert but it’s critical for success. I encourage you to do the same as much as possible. Building strong relationships can often be more critical to getting things done than building a widget.
  • I expect you to effectively communicate ideas, problems and solutions. I value that more than I do technical proficiency. I’ll say this again because it may sound backwards when it comes to software development: I value the ability to effectively communicate higher than technical proficiency. I’ve seen far too many #fails because either communication from the top-down was incomplete or lacked clarity, or an engineer was unable to provide accurate and timely information to their leaders. Do this well and you’ll go a long way in building a solid foundation of trust in our relationship.
  • Tying into the above. I will likely want to understand the thought process behind your decisions, gain deeper insight into an estimate or have a technical briefing on the various moving parts. So be prepared to provide it in a clear and thoughtful way. I will make decisions and move communication up and across the chains based on information you are providing. In the same vein, you should expect me to understand technical deep dives and, in situations where I do not, to ask questions. If I am suggesting solutions for a problem, you should hold me to the same standards. At the end of the day, I need to understand why you have made the decisions you have, and then mirror that against the attached business objective to ensure we aren’t in the midst of a #fail.
  • When it comes to providing the information discussed above, I also expect different people to have different speeds of communication. I can respect both the ability to respond immediately and the need to thoughtfully reflect and get back to me. I am the latter, so expect that from me.
  • I never want ideas, questions or solutions to become something anyone is afraid to engage in. I think passionate debates that allow everyone to contribute, be heard and feel respected (even when they “lose”) are highly useful. I expect those types of discussions will develop amongst your peers as a first step to solving an executional problem. I will only step in if a solution cannot be found, or if my help is requested or an impasse has been reached. I do not, and hopefully will never, aspire to micro-manage at the execution levels.
  • I prefer in-person chats about anything you need to discuss, but I also realize this is not ideal for everyone when locations are remote or availability is limited. Here’s how I rank communication methods in terms of urgency via medium: In-person (right now) -> Call -> Text -> Slack -> Email (later is fine). If you have an alternate ranking method it is up to you to let me know, otherwise I will apply my ranking to interactions with you and thus expect that when I come to you in-person or via a call, you will understand there is an urgency attached to it.

Feedback Loops

  • I will always endeavour to give you direct feedback as quickly as possible. If there are actionable items in the feedback I will always try to provide at least one suggestion for a corrective track forward, but I expect that you will determine the ideal way in which you can act on those items and then report progress back efficiently.
  • If you have feedback for me I will expect this feedback to also be as immediate as possible. I am here to help you succeed but I can’t do that if I’m not aware of areas I’m failing you in. You should hold me to the same expectations I hold you with respect to uncovering actionable items and reporting back on them.
  • The best way to move forward on personal and organizational goals is to be aligned and heading in the same direction. If you are unsure at any time how a feature you are working on, a solution you are designing, a team you are leading or a bug you are fixing, contributes to a larger business goal, LET ME KNOW! It’s my job to avoid time and resource sinks. Once you ask the question, you should expect me to do my best to provide the answers quickly and with clarity.
  • I am always open to critical feedback from managers, peers and directs, provided it is framed in a way where I have the potential to create something actionable if nothing exists inherently. I can’t promise I will always improve or act on every piece of feedback I receive, but I CAN promise I will actively listen and respond. In the same vein, as mentioned in the first point, I will expect you to be open to critical feedback that is framed in a similar way.

1:1's

  • These meetings are for you. I want you to drive the agenda around what’s on your mind, what you feel is succeeding, what you are challenged by and above all, how I can help. I’ll ask questions to help discover more.
  • These meetings can and often do devolve into project status updates. Expect me to try my best to avoid that while I expect the same of you. That doesn’t mean we can’t talk about larger engineering concerns or ideas, but the more we can focus on what you need to overcome challenges and roadblocks, the better the outcomes eventually become.
  • I will track all that we discuss as much as I can and share it with you. It will become the basis for a historical look at our conversations and how we have progressed over time. The tool we use is not important, the content is.
  • At the end of the day, 1:1’s are about building relationships on a level beyond simply “what’s going on with project a today”. I’m here to support you and your growth, it’s up to you to let me know how best I can do that.

The Actual Work

  • This is where the meat and bones of your job is done. If you’re an individual contributor it’s The Code. If you’re a people leader it’s The Team. Whatever your role within the organization the work encompasses the things you do that help us all succeed. I have a fair amount of expectations around this that frame themselves around the various levels you are at but those are more specific and usually handled in our initial 1:1's. However there are a couple of constants:
  • Apple calls it DRI (Directly Responsible Individual) and I expect it from every person on the team. You. Own. Your. Work. At first you will start small and own a feature or a bug fix or even just a small part of a larger feature, or you will be responsible for driving you team towards quarterly completion goals. Whatever it is, from the moment you are assigned the task, through pull requests, sprint plannings, mentoring, delivery, QA approvals and all the way back to a reopen if it fails you are the DRI. As you level up you will own larger things like workflow, infrastructure, architecture, teams or strategy but the key takeaway is always the same, I expect you to take the reins of ownership, and all that entails, in everything you drive, such that when you succeed you will own that as well.
  • I know what you’re thinking, what if I fail? I most definitely have the expectation of both failure (on occasion) AND ownership of the follow-up. In turn you should expect me to have your back 100% of the time. I never throw anyone under the bus and expect the same from you. We will all win together just as we will all lose together.
  • Tying back into the notion of DRI. I expect you to show up. Literally. If you have a meeting scheduled for 9am then I absolutely have the expectation that you will be in attendance or will join remotely. Showing up is a critical visual tool that earns the respect of your peers, keeps us all informed of status and helps others who may have blocking questions requiring your response.
  • I expect that some senior level engineers will inevitably be better coders than me. I not only expect it, I encourage it. I never want to be the best coder, developer, shiny object junky in the room. If I was, then my hiring framework would be flawed or my ego underfed. In short, when it comes to the work, I expect you to eventually or already be better than me. I’m ok with that and you should be too.

Professional Development

  • I expect that in the early days of your career you are never entirely sure what it is you want to do. Some gravitate to people management, others to software architecture. You should expect me to be available to answer questions and provide guidance to help you figure out some of the answers. I will expect you to drive the conversation by refining your goals over time and being transparent with me about them.
  • Circling back to the concept of a DRI. Your career is likely the biggest thing you will be a DRI for. I expect that if you need training you will ask for it. You should never shy away from levelling up your skills, whether it’s taking management classes or deep diving into a part of the application you have previously struggled with. I will find time to ensure you can attack the opportunities, but you need to find the opportunities.
  • Always push yourself. Look for places that make it easiest to try new techniques, solutions, patterns and ideas. I never stop looking for ways to improve as an engineering leader, I expect you should never stop finding ways to improve your skills as well.

TLDR;

  • communicate effectively and frequently
  • be prepared to provide insight and clarity to decisions you make
  • don’t be a tech-bully
  • f2f -> call -> text -> slack , my order of urgency with respect to communication
  • direct feedback as quick as possible, both to and from you
  • be open to critical feedback
  • if you don’t understand something, or how it fits into the larger picture, ask!
  • you own the 1:1’s, they are for you, I’ll keep track of them
  • OWN YOUR WORK!
  • be on time for meetings
  • be a better developer than me, if you aren’t already
  • own your career path
  • push yourself to try new things and continue to engage in learning