# Jasond_s's Manager Readme

**Head of Engineering at Crezco**

# Motivation for this document 👨‍💻

I have written this document to help people understand a bit of my  **personal and professional philosophy**. Sometimes it's hard to know how to interact with someone, my hope is reading this will  **encourage people** to know how to ** reach out to me**.

I don't really like writing about my personal self, but I am really happy to talk about it. I appreciate people getting to know me as a full person and I like getting to know my colleagues beyond their job role, so let's chat.

# My role

I care most about helping my team to grow, improve, create, and of course, how much money we are spending and making.

I have a passion for  **data and business modelling**  and love to lead those sorts of sessions, if you need a  **domain modelled**  or  **architecture ** advice,  **get in touch**.

I generally will make myself accountable to a few  **key **** metrics**:

1. **Our operations scale linearly or better against product usage 📈** - Does the money and time we spend on making the system work go up quicker or slower than the usage of the system. Hopefully, slower.
2. **The 4 Golden Signals 🥇- ** This is the absolute baseline for customer experience of software and a good way to put them at the heart of even the most technical of problems, and to ensure we are thinking about experience at a systems level.
3. **The Accelerate Metrics 👟** - Getting new ideas that solve hard problems into the hands of customers as quickly and accurately as possible, the devops loop.
4. **Happiness 😄** - Are people motivated and enjoying the problems they are being asked to solve. Is there a thing we could do that would make everyone happier and motivated which might increase all the other metrics! Are other teams happy to work with engineering, do they come away smarter or baffled?

These are not the only things that matter. Everyone has a role to play in ensuring that our customer is at the heart of business decisions, engineering has a huge part to play in making sure a customer has what they need as fast and as accurately as possible. I like OKRs alongside things like this.

# What do I value most?

The things I value the most are  **honesty and a collaborative attitude. **

I have 2 important mantras:

**"An idea or an error shared is a challenge for the team, a great idea forgotten or a problem hidden, is a failure."**

**"Complexity is not the problem, ambiguity is, simplicity is not the solution, clarity is"**

I will always encourage you to take ownership, support your team mates, and **hold each other (including me) to account**. Teams work the best when they  **share vulnerabilities and weaknesses** , and seek to  **support and **** improve each other**. There should be no sense of loyalty to any personal agenda, only to outcomes, own things, but don't let the code or process get personal.

My weakness is;  **I am interrupt driven**. This means  **I might have forgotten**  to do that thing you asked me to do politely, _if I haven't written it down or given you a date,  **make me** _. 

I will never say no to an Engineer that wants my opinion, support, or celebration, so don't ever wonder if I am too busy with _important things _to hear you out.  **I will make the time**.

# My expectations

Book some time into my diary and  **add an agenda** , I will come prepared if I know what to prepare for. 

Having no agenda for a meeting is inefficient, we all reserve the right to not show up for a meeting if there is no agenda (unless the agenda is _create an agenda_)_._ Amazon's document meetings are a good idea_._

**If you think you have done something wrong**  or made a mistake, ** remain calm and get in touch**. I will expect humility, and honesty, and not much more. I'm sure it's something we can fix. Emotion and passion are always fine, but blame and anger is generally not fine. I have carried out 100s of post mortems and never once encountered malice.

I expect frequent and clear communication about what, when, and how. I will of course be making my own observations but a truely trusting and autonomous environment requires good communication up and down. I will try my hardest to challenge yourself to do better, **I will set ambitious targets**. Challenging is fine, but it can cross a line and become **a struggle** and that **is never my expectation**.

My natural bias towards supporting autonomy leads me to drift into _ **ruinous empathy ** _sometimes. It can help me a look if you ask for feedback or critique directly.

# Training, Coaching, Mentoring and Sponsorship

We will have a 1:1 if you are a direct report of mine at least once every week. This is timetabled for you, I ask some questions about what you are enjoying and what you are dreading, it's a time for you to share with me anything that you need to. 

I have a  **skip meeting**  with at least one engineer who doesn't report to me each week that follows the same agenda as my 1:1s.  
  
I like to spend some time in these sessions talking about your near, medium, and long term goals.   
  
I often ask, "_W__hat do you want to be when you grow up?_" Together, we can tailor your work to getting you there, and along the way your motivation for these goals will provide our customers with amazing value.

I don't get the time to do dedicated training. If you have a specific goal and it's something I can coach you with I will, but that goal setting I will expect to come from you. I sit better in the mentoring and sponsoring brackets, my influence and reach usually allows this to be very effective.

# Personality quirks

I take my job seriously but myself, not at all. I am light-hearted and self deprecating. I accept radical candor and will be honest with you too.

I find cynicism and office politics toxic and unacceptable. Cynicism isn't the same as doubt and questioning, which is fine, cynicism is closer to defeatism or bigotry and I don't think that is ever very helpful.

I really like Eurovision🦄 and Black Metal🤘. I write science fiction stories and have been known to play DnD.

# How to spend your first 90 days working with me

I am a big fan of  **deliberate practice**. If you want to improve your skills, focus on applying them to a task, and then spend time reflecting on your performance. 

I think software engineers complain about code being readable more often than they  **spend time practicing reading code**. Take some time to do some  **deliberate practice of reading code**. In the first 90 days, this is time well spent.

**Remember all the things that were better in your last job, and make noise about it.**  New colleagues can often see the trees when everyone else only sees the forest and this insight can be unparalleled in helping to improve culture and process. Use your fresh eyes to uncover inefficiencies!

**Write at least one page of documentation.**  Getting into the spirit of communicating technical ideas early is good. You should also encourage members of the team who rely on tribal knowledge to think about writing things down rather than merely relying on verbal communication, where things can get lost.

If you don't know team topologies, C4 and UML, learn about them, I use these tools a lot.

# P.S.

I often us  **bold** as a way **to redact** a lot of **text** , if you **speed read** the  **bold ** it should tell you **all you need to know** , but nuance can be important. Use it to **find relevant sections** and then **drill into the detail**.