What’s all this then?

This is my version of a “manager README.” The point of this README is to introduce myself and give you an idea of how I think, how I work and answer some questions you might have about me. This is a living document so it may will change over time as necessary. Keeping this in the open is intentional.

What is this not?

  1. This is not going to lay out my expectations of you
  2. This is not going to say how I think any particular project should be run.
  3. This is not going to tell you how to do your job.

Important note

This is unofficial in regards to any standard HR practices. Nothing in this document supersedes or replaces any standard performance-management tools or processes.

Also, everything here makes no distinction between temporary and permanent employees, on-site or remote. Regardless of type of employment type my goal is to treat everyone the same way (and you’d be doing me a huge favour by letting me know when it feels like I’m not).

Who am I?

I live in Barrie, Ontario with my wife (Shannie). I was born and grew up in the Edmonton area but since the early 2000s I’ve lived in the USA, the Netherlands, Sweden, Germany, and now back to Canada. I’m a sports fan, comic book geek, video game player, electronics tinkerer, hobbyist athlete and also drink more craft beer than may be necessary.

In my younger days I was highly extroverted but as I’ve gotten older I’ve found myself becoming more of an introvert.

My technical background is primarily in front end development in the advertising agency industry. I’ve been in web dev since 2001 or so and though I started as a designer I learned two things early on: I was terrible at design and I loved coding. Over the last decade I’ve transitioned from pure development IC roles into hybrid developer/manager roles and now exist almost entirely in the “management” sphere (though I do what I can to make sure my coding skills don’t completely atrophy).

In the sense of being a Paint-drip person I have broad (but shallower) experience in backend development, CI tools, 2 & 3D animation, video production, project management, and a bunch of other various and sundry technologies.

There is plenty for me to learn from you and I will bring plenty for you to learn from. It’s going to be great!

Whew. More than enough about me. Let’s talk about us.

What do I care about?

  1. People
  2. Products
  3. Process

…in that order.

Sounds great but what does that actually mean?

  1. People
    • I’m deeply invested in the “Human” side of “Human Resources.” Every person in our organization is a living, breathing, complex individual with their own brand of personality and lifestyle. This also means I have zero tolerance for any kind of harassment on grounds of sex, race, orientation, religion, gender identity, etc. Zero.
  2. Products
    • We need to be obsessive about the quality of the products we’re responsible for. Working in digital is exciting because we have the power to completely shape the way that our company and products are viewed all around the world.
  3. Process
    • It can still be way too easy to get bogged down in the minutiae of how we get things done. Part of why you’re here is because you’re an expert in your own field – speaking up about ways you see to make our work better is not only encouraged… it’s pretty much mandatory.

What do I do in regards to you?

I do a lot of things around this place and wear a lot of different hats from day to day. When it comes to you and your work here I see my role as having two key elements to it:

  1. Attract, hire, and retain the best people possible. That’s you, that’s why you’re reading this.
  2. Provide context for the work you’re doing.

“Wait… provide context? What does that even mean?”

At any given moment you should be able to look at a task you’re doing and know how it fits into the larger overall organizational OKRs, goals, and priorities. This means that if what you’re doing feels like pointless busywork or a waste of time then I haven’t done my job correctly in either making sure you understand that context and/or ensuring that you’re actually working on something important. If you ever find yourself in this situation you’d be doing me a huge favour by letting me know.

What else do I do here?

Outside of being your manager I’m sure I’ll do a bunch of other things around the office so this section could fall out of date way too quickly – if you ever want to know what I’m currently spending my time on please feel free to ask!


I bias heavily towards transparency and candor. You can ask me anything you want and I will answer to the best of my ability. Sometimes I won’t be able to speak about something due to confidentiality or other similar concerns but otherwise you will get my honest opinion about whatever you ask. I will never lie to or mislead you. In my career I have never been asked to lie to one of my employees and if ever asked to do so I would not comply.

My own internal ranking for importance/usefulness of communication methods is roughly: in person, Slack, SMS/WhatsApp, [giant gap] email [grand-canyon-sized gap], Any Other Comms Platform. Note that I didn’t list phone calls here: my phone rings so rarely that my immediate assumption when it does is that something is an emergency. I am almost always available on Slack during business hours and I try to respond quickly whenever possible.

One clear way to not get a hold of me is to tag me in an issue ticket (Jira, etc.). I can receive several hundred ticket update notifications most days, relying solely on a tag in an issue to make me aware of something is not going to be a shortcut to awesome. If a ticket or PR or something needs my attention or you want me to be aware of an issue drop me a link to the ticket on Slack.

There are very few things that I will do here that are more important than talking with you if you need to talk to me. Slack me, email me, drop by my desk, grab time in my calendar. If you don’t find time in my calendar, message me and I’ll make time.

Sometimes I like to get some work done on evenings and weekends. Assuming it’s not marked as urgent if I message you outside core business hours I don’t expect you to respond. Typically I’ll try to contain any non-urgent communication to the workday but occasionally something may slip through. I don’t expect you to work outside of core business hours unless something has been planned ahead of time (i.e. a scheduled feature release on a Saturday). I want you to enjoy your life outside of the office so that you’re happy, healthy and focused when you are at work. The exception to this is if I actually phone you outside of office hours. A phone call means something urgently requires immediate attention.


The importance of feedback to me cannot be overstated. I need feedback. You need feedback. We need to make sure that we are regularly communicating feedback candidly because we can’t make good choices if we don’t understand the actual context of the choice.

My primary goal as your manager is for you to be happy, fulfilled and doing good work. You should never be afraid to provide feedback to me or come to me with any concerns. Your success is my success and it’s in both our best interests to tackle any problems that might be happening for you so that you can move forward.

One-on-ones (1-1s)

I’m a big believer in the importance of 1-1s. I will always make time for these meetings no matter how crazy my schedule might look (vacation/travel/sick leave times being an obvious exception).

These are your meetings. This is time for you to talk about whatever you want with me and have my undivided attention. That means these meetings will be more productive if you bring topics, concerns or just thoughts. These don’t need to be project status updates unless you want to talk about project status updates.

Feel free to send me topics you want to discuss in our 1-1 ahead of time via Slack DM if you think a bit of context or forethought on my behalf will be helpful.

All of that said, if there is something that is urgent that we need to talk about, don’t wait for the next 1-1. Let me know ASAP.

Performance Management

Unofficially I operate under a 🚦 Green-Yellow-Red framework for keeping track of how you’re doing. In short:

  • Green: 🦎 you’re doing a great job and I’m happy with your level of performance in our team. I’d be thrilled to have you work here like this forever.
  • Yellow: 🐝 while you’re still an effective member of our team there’s something about the way you’re doing things that is - in the long run - unsustainable. We’ll work together to identify what this is and how we can correct it.
  • Red: 🦀 a more serious, critical aspect of your workflow has been identified and an immediate correction is going to be required for you to remain a part of the team. We’ll work together to identify, plot a course correction, and a timebox for resolving this (commonly referred to as a “PIP”).

Important: a change of colour will never be a surprise to you. If you aren’t sure where you stand here, if I’ve not explicitly communicated anything to you in writing you can safely assume Green. Always feel free to ask me if you’re still unsure, I’m committed to never misleading you on this.

Also Important: going either Yellow or Red are both absolutely recoverable situations and that will be my goal as a part of the correction process. We’re human beings, we have ebbs and flows in our lives.

Repeated disclaimer: This is unofficial in regards to standard HR practices.

What (I think) I do well

  1. Context, not control. I will rarely – if ever – outright tell you what to do. I’m not interested in giving you orders, I’m much more interested in making sure you have ownership. Take ten minutes to watch this video for a better idea of what I mean.
  2. Understand our customers’ needs and pivot quickly to adapt our strategies when they’re not aligned.
  3. Avoid micromanagement.

What (I think) I don’t do well

  1. I have been known to take “context, not control” to an extreme and not stepped in to provide more direction when it’s been needed.
  2. Write code. This may sound strange coming from someone in technical leadership but I moved out of full-time development almost a decade ago and though I dabble with some hobby projects and try to keep up with current practices chances are you know infinitely more about writing good applications than I do.
  3. Say “no” to requests. This is something I’ve worked hard to correct but is still a trap I fall into. I’ve gotten better at delegating and such but is still an ongoing growth process.