# Stay in the weeds As a new manager, it's difficult to determine exactly how much hands on coding you should be doing. There are hybrid Team Lead or Tech Lead roles where the requirement is stated but flexible in how much hands-on coding you should be doing, there's a newer monicker of Technical Engineering Manager which implies some amount of hands on coding is expected, and then there's roles where managers are out right told never to touch the code. It can be difficult to navigate, but my mentality around it is a principle I fall back on time and time again: be explicit in expectations. Or ask your manager to be explicit in their expectations. Without explicitly setting expectations it's difficult to evaluate success in the metric of hands on coding. My personal thinking aligns well with that of James Stanier's, *"all managers should be in the code, but not all managers should be writing code"*. This mentality is shaped through lessons learned, practices observed, and advice received through my time as a manager. It boils down to two reasons to me: 1. You need to be able to validate and challenge solutions your team proposes 2. You need to be able to communicate, to a reasonable level of detail, the inner workings of your team's solutions to stakeholders At the end of the day, you are accountable for what your team does and does not deliver. If you cannot validate and challenge their solutions then you will likely find yourself in a place one day where you're asked why your team went ahead with a solution that was not properly scoped, investigated, or executed and all you'll be able to do is shrug your shoulder and say *"LGTM"*. Amazon has the guiding principle, *Dive Deep*: *"Leaders operate at all levels, stay connected to the details, audit frequently, and are skeptical when metrics and anecdote differ. No task is beneath them."* One of the ways I see this enacted as a manager is an example where a direct report departs in the middle of the project. Abiding by this principle, I expect a manager to be able to dive in and continue to move the project along through hands on code, albeit at a slower pace. If they don't understand the solutions being implemented to a sufficient degree, how can they execute effectively. # Read widely, learn constantly Another principle that I live by is continuous learning. Very early in my career I recognized that I was able to level up quickly just through reading books on software development. I churned through books like Code Complete, Clean Code, The Imposter's Handbook, The Pragmatic Programmer, and many more. These books taught me a lot about how to be a better developer, but only through seeing things in practice and discussing approaches with more senior individuals did I learn when it was important to deviate from some of the ideas presented in these books. A principal engineer I work with has a saying *"DRY is something you tell junior developers because they don't know any better. As you gain more experience, you begin to realize that DRY is just a tool in your toolbox and you learn to use it when it makes sense"*. Learning these best practices is vital to a young engineer, but challenging them can only be done through lived experience and wise mentorship. I still read and learn constantly, but my approach is different now. I read to learn various opinions and then discuss with other engineers to get as wide of input as I can. I read to learn new skills that are important to the business, but I accumulate questions as I read and take them to subject matter experts. There are no required continuing education credits that I must accumulate every year, I learn because I recognize the importance of constant up-skilling. I also recognize the importance of challenging what I learn. # Manage your manager As a high-performing individual the most regular feedback I would get from, regardless of whether my managers over the years was, *"You're doing great, just keep doing what you're doing"*. This was frustrating to me, I wanted to learn and grow but I was labelled as *"easy to manage"*, so my managers would spend their time with individuals who needed more support. Through reading about being a manager though, I learned about a system called **Managing Your Manager**. ## 30-60-90 plan Managing your manager stems from the idea that your manager's time is finite and if you want to best maximize your time spent with them you need to come to them with points of discussion and expected outcomes for every one-on-one. An example of this is something I established with manager in my first week on the job, I asked to set up a 30-60-90 plan. Abiding by my principle of clear expectations, I didn't want to be left at the end of my first three months unsure if I was meeting the expectations set out by my manager. By establishing a 30-60-90 plan, we created measurable results with specific check points. It was clear what my goals were and if I was unsure how to go about achieving them I could discuss that with my manager. Too often I see one-on-ones where the person doesn't come with anything discuss and the meeting ends ending early. It's okay if you have nothing to discuss every once and a while and let your manager know you want to cancel the one-on-one. But regularly showing up without discussion points and meandering your way through a meeting that ends early is not the best use of either one of your times. ## Constant goal setting I like to take the idea of the 30-60-90 plan further and do constant goal setting exercises with manager. We talk about micro and macro project goals, goals for my direct reports, goals for myself in the next 6 months, and goals for the organization for the year and how I can contribute. I do this through telling my manager about the goals I have for myself and asking about the objectives for various projects on the go. The only caveat I will mention is that it's important to have only a couple goals at any given time, too many goals all at once will leave you drowning in them and many of them will likely not be met. Goal setting is another tool at your disposal, use it wisely and precisely. ## Seek feedback A method for seeking feedback with my manager that I like to use and that I recommend to my direct reports is to seek targeted feedback. It's really easy to ask, *"how am I doing?"*, or *"how do you think I did on that last project?"*, but those are vague questions that lead to broad and vague answers. I have found when I asked questions like this in the past I leave the meeting unsatisfied and feeling like I don't have a clear picture on my manager's perspective of my performance. This improved when I learned how to start seeking targeted feedback. When you ask something like *"how did I do on this project?"*, it's a difficult question for your manager to answer and requires them to think quickly through everything you did and boil their answer down to something that the two of you can then talk about. Instead, I learned to ask something like "there was a lot of new for me on this last project, one of which was writing RFCs for proposing my architecture designs. While I think these RFCs were good at relaying my thoughts, I don't think I effectively sought feedback from the broader organization on them. How do you recommend I go about that next time?". All of a sudden this is a really precise question to answer and you and your manager can have a productive discussion around this topic. If you come to every one-one-one with one of these questions I promise you will see a notable improvement in the quality of your one-on-ones with your manager. # Learn how to hire people - Sit in on the process - Ask how other team members approach interviewing - Consider improvements to the system - Recognize your own biases - Take chances on people in the interview process If you've never been on the other side of the hiring process it can be a bit of an eye opening experience. You learn # Learn how to fire people - Seek advice/guidance - Therapist - It's not about you - Tell the story about Victor # Learn how to give feedback - Radical candor - Don't be afraid to give feedback up and down the chain - You're doing people a disservice by not giving people necessary feedback # Network in and out of the business - [Build a network of peers]([https://lethain.com/network-of-peers/](https://lethain.com/network-of-peers/ "https://lethain.com/network-of-peers/")) - Be visible in the company - Quality over quantity in the network - The output of a manager is the output of their team, plus the output of the neighbouring teams under their influence # Embrace the product trio - Continuous Discovery Habits, Teresa Torres - [Ask the EM: How Can I work Better with My Product Manager, as an Engineering Lead?]([https://blog.pragmaticengineer.com/how-engineering-can-work-better-with-product-managers/](https://blog.pragmaticengineer.com/how-engineering-can-work-better-with-product-managers/ "https://blog.pragmaticengineer.com/how-engineering-can-work-better-with-product-managers/")) - [Trifectas all the way up]([https://theengineeringmanager.substack.com/p/trifectas-go-all-the-way-up](https://theengineeringmanager.substack.com/p/trifectas-go-all-the-way-up "https://theengineeringmanager.substack.com/p/trifectas-go-all-the-way-up")) # Links - [https://theengineeringmanager.substack.com/p/should-managers-still-code](https://theengineeringmanager.substack.com/p/should-managers-still-code "https://theengineeringmanager.substack.com/p/should-managers-still-code") - [https://www.theengineeringmanager.com/managing-managers/being-in-the-details/](https://www.theengineeringmanager.com/managing-managers/being-in-the-details/ "https://www.theengineeringmanager.com/managing-managers/being-in-the-details/") - [https://www.amazon.jobs/content/en/our-workplace/leadership-principles](https://www.amazon.jobs/content/en/our-workplace/leadership-principles "https://www.amazon.jobs/content/en/our-workplace/leadership-principles")