Hi, This is meant to be a README file that is aimed at introducing you to my management style & philosophy. This document is meant to help you understand me better and hopefully enables us to work better together, but is definitely not meant as a replacement to actually getting to know each other.
- Your wellbeing in the company is my most important KPI. If you want to talk to me, you should interrupt whatever I'm doing and we can talk. We don't need to wait for our next 1:1.
- However, the same rule does not apply for technical questions. If you interrupt me, I expect you to have tried to solve the problem on your own (or google it) first.
- I truly care about you and each and every member of my team. I hope you'll have a successful career and that you enjoy your time working with me.
- Retain & grow our talent - I want to keep discussing your own personal goals and how I can help
- Project Management (Including agreeing with you that the assigned ticket is specified to your liking & Ready For Development)
- Hire new talent (because hiring never stops)
- Technical discussions - always available to discuss efficient ways of solving a problem
- Bridging the gap between QA & Engineering
- Briding the gap between Product & Engineering - This facet of the role has been taking more of my time and attention lately. I have seen promising companies squander great talent. Marty Cagan sums this up perfectly: "It does not matter how good your team is if they are not given something worthwhile to build".
If I find myself with free time in-between those three points, I switch back to Developer mode; usually in collaboration with other developers in-between tasks.
- You will let me know if you're unable to do your job
- You feel safe debating with me
- You know what you're doing better than I do
- You know the codebase you're working on better than me; However if you tell me that a problem can't be solved a certain way, I will keep probing you until you convince me. It's only at this point that we can begin debating an alternate solution
Your work. This is what I usually track:
- Your communication with Product/Design as you work through your epic
- Overcoming a problem - either by splitting a task into subtasks, finding a new library online, asking a teammate for help etc.
- Driving your work to production - Because you understand that merging to master does not mean that the job is done
- Ownership of your stories - How you deal with QA and bugs that may arise from tickets that you have worked on
Our conversations are always private, unless you do require me to involve someone else in the discussion. Sometimes the company can require me to keep something secret, but they will never ask me to lie to you.
- Make good use of our 1:1s; Give me feedback about:
- my managerial style - Tell me when I screw up
- The team
- The problems that you're solving
- The company vision
- Yourself
- Do great work
- Be reflective & share them with me
- Are you happy doing the same kind of work you're doing? Do you see yourself doing it for the next year?
- What do you want to learn?
- What are your ambitions? - For yourself, for the company, for a problem etc.
- Tell me when I screw up
- I can sometimes make impulsive decisions based on gut feeling, if you feel like the decision is too hasty you should call me out on it.
- I enjoy optimising a solution. Even if I can save just 5 milliseconds in a http request, I get a kick out of it. If you have a solution, I want to hear it. If I take it too far, you should call me out on it.
- I want to learn from you, and I want you to teach me. I am probably mediocre at best at what you're currently working on.
This is a living, breathing document. If my expectations are unfair or if I fail to live up to my responsibilities that I have listed in this document, you should call me out on it.