Gitlab hero border pattern left svg Gitlab hero border pattern right svg

Director of Dev Backend

On this page


This page acts as a readme for the current Director of Dev Backend, AKA me. Feel free to make suggestions if you think I should cover something here that I haven't, and let me know if you believe anything here isn't accurate. Topics are more or less arranged in order of importance.

My Availability

DiSC Profile

I don’t typically put a lot of stock in behavioral/personality profiles, but I have found that they can be very useful starting points in building out personal relationships. You can find a full report of my DiSC profile here. The very abridged version of my results is that I am a high DC, where:

I have done a lot of work to become self-aware about the strengths and weaknesses that come with these behaviors but I am nowhere near perfect. It is absolutely fine and correct for you to call me out, individually or in a group, if I jump in and interrupt you or otherwise let these tendencies get the best of me inappropriately.

Oh, and by the way, if you read that full DiSC report, it tells you that I am extremely unlike to ever be sarcastic. So, it's not perfect. Sorry.



This is my first time working at a meaningfully international/multicultural company. I am certain that is going to be a significant learning experience for me. Please be patient with me :)

I grew up in a culture that was not careful about bias in conversation and that has led me to adopt some habits that are hard to break, even though I am aware of them. Particularly things like referring to a mixed-gender group as “guys.” Please feel free to call me on it but also know that I am working on addressing it.


As I've started working at GitLab, transparency has probably been the most difficult value for me to embody - not because I disagree with it, but because it's so foreign to how companies I've worked at in the past have operated. I'm trying to experiment and push my boundaries, but I'm not always doing it at the right times or in the right ways. Please feel free to let me know if you think there are things I could be doing better or differently to be more effectively transparent - I like to think I welcome all feedback, but this in particular is an area where I want to grow.


My default position is to extend trust to people that I work with. There are few behaviors I find as distasteful as micromanagement, particularly in software development teams, so if anything I err on the side of caution sometimes in making sure I get out of your way. Getting started I will probably have a lot of questions to make sure I understand your team, work, and overall situation - but afterwards my default position is to trust you to let me know what I need to know when I need to know it. This means I am not big on mandatory reporting or status updates unless it serves some other function in the company. That said, I would prefer having more information than I need over having too little information, so I welcome whatever you’d like to share with me on whatever basis and via whatever medium you prefer.


I have sometimes been told that I don’t give enough feedback. My natural position for feedback is to provide it when your behavior is outside my expectations - either because you exceeded them or because you failed to meet them. Providing feedback when you meet my expectations feels like giving feedback for the sake of feedback, so I don’t naturally do it. For some people this works fine, but for others it can make them feel like they don’t understand their performance. This is something I am continually working on, but please don’t hesitate to let me know if you don’t feel like you’re receiving sufficient feedback from me.

If you ever even think just a little bit that you might want to give me some feedback, I would encourage you very strongly to do so. I need all the help that I can get. If you do and I am in any way less than grateful, give me feedback on that, too. I know better.


I like to test ideas by negation; that is to say my mental process kicks pretty immediately to “what could be wrong with this idea” and stays there until it’s satisfied. I also like to ask “stupid questions” to clarify my understanding, encourage lateral thinking, and occasionally to make sure we’re trying to implement the smallest viable solution. This can sometimes make me seem overly critical but it’s just a side-effect of the way I process ideas. I usually reserve feedback until I’ve fully processed something, but if you feel like I’m being negative, just ask.

It's also important to know that because of the above, asking a question like "why don't we just rewrite this from scratch" doesn't mean I actually want you to do that. I'm likely just talking things through.


I subscribe to the school of thought that the best way to coach someone is to ask questions rather than provide answers. If I am ever helping you work through a problem, I will probably do my best to stay in “question-only” mode. This can seem overly Socratic at times, especially if I don’t do it well, and that can drive people crazy. If you feel at any point like that’s happening to you, let me know and I will adjust.

For coaching on broader career development, I am personally biased towards using books to facilitate teaching and discussion. I know that’s a personal bias and am happy to do whatever will work best for you, but left to my own devices I’ll probably just be recommending books every time.

Conversational Trivia

Not important information, but in the spirit of letting people get to know me a bit better:

Before GitLab

My first job was as a Java Web Developer at a company that did warehousing logistics and ecommerce for power transmission equipment suppliers. It was as fun as it sounds.

After that, I spent a few years doing custom software development with an all-remote team in the US and Canada. I got to work on projects for companies like Coca-Cola and Brother, helped create an educational game simulating non-violent resistance, and did a lot of other fun stuff.

Between that gig and GitLab, I ran the Engineering team at Treehouse, also working from home. All in all I've been working remotely for 10+ years now.