DEV Community

Matt Hogg
Matt Hogg

Posted on • Originally published at matthogg.fyi on

My Manager README

This README is an attempt to succinctly explain who I am, how I work, and my personality quirks. For the reader I hope it helps expedite any potential interaction between us. I also hope it helps me triangulate and refine how I present myself in work settings.

In The Beginning...

I've been working in web development since 1999. I was a "full-stack developer" before it was even a phrase—writing "spaghetti code" in ColdFusion or PHP to connect to databases in Microsoft Access while creating gaudy UIs in Flash. We were called "webmasters" back then.

My original passion is frontend development. CSS is my all-time favorite programming language (yes, it's a programming language). My expertise and curiosity is primarily client-side—HTML, accessibility, CSS, responsive design, making delightful UIs and clicky things, etc.

Over my career I've earned responsibility and authority by giving a damn. This means asking questions, showing an interest in a particular problem space, understanding the value or impact of the work, thinking about process for myself or my teammates, and communicating well. I firmly believe exceeding expectations in this way is what's made me a great developer.

This Is Me Now

It's this feedback loop—exceed expectations, gain more responsibility, exceed new expectations, and repeat—that's put me in leadership and management roles since 2015.

I use my own development background as a force multiplier to support, grow, protect, and defend my reports. Because I've been there myself I'm uniquely qualified to coach developers or guide them through any challenge. By combining my experience with the philosophy of servant leadership I firmly believe investing in the individual is what's best for the organization, too.

What I Do For You

As a leader there are numerous things you can expect me to do for you without hesitation. I feel it's important to list them because people can often talk themselves out of asking for help when they shouldn't. I can...

  • Provide context and perspective about the company at large.
  • Advise on your individual or team priorities.
  • Gather and relay feedback on your performance.
  • Identify and coach for career growth opportunities.
  • Offer technical guidance by way of pair programming.
  • Help with rubber duck debugging.
  • Participate in code reviews.
  • Find peer support from other developers, teams, and departments.
  • Communicate with stakeholders or adjacent parties.
  • Rally on production issues.
  • Hire your teammates.
  • Organize regular, recurring 1-on-1 conversations.
  • Celebrate your accomplishments in public settings.
  • Listen to your complaints or rants.
  • Offer my opinions on anything from coding to process.

My Values And Principles

These are the values and principles that I've accumulated through my career and inform my daily interactions.

I work for you. If you think I'm a good leader then you should see the people I work for—my reports! Any success I might enjoy as a leader is a direct reflection of my reports, the feedback loops I maintain with each of them, and their capacity to execute. I am here to help.

Proactive communication. I speak candidly, but factually, and I try to anticipate what people want before they want it. I'm liberal with my status updates and "FYI" messages. When I take an action item I'll tell you when I expect to finish. When you ask me a question I'll provide any supporting links, documents, or other material that I have. When I think my response is likely to generate a follow-up question then I'll answer it before you even have to ask.

We're doing hard things. I'll be asking you to do novel or difficult work. If our problems were simple then they'd already be solved and we'd be bored or unemployed. So, let's embrace it.

I love helping developers grow. This means I'll challenge you to do more than just write code (or code that you're used to). If I ask something of you that you've never done before remember that it's because I have every reason to believe you can do it. Patrick McKenzie said it best:

Every great developer you know got there by solving problems they were unqualified to solve until they actually did it.

Perfection is unlikely. I aim for steady improvement, iteration, and evolution towards an ideal. Progress might be slow or modest—if we're trending ever upward then I'm happy. If we're not but we know what to do about it, I'm also happy. Andy Hunt said this about software, but I think it can easily apply more generally:

No one in the brief history of computing has ever written a piece of perfect software. It's unlikely that you'll be the first.

Zen detachment. I regularly locate myself within the circles of concern, influence, and control. Living in the circle of concern is certainly uncomfortable but it's far better than mistakenly thinking I'm in the circle of control! I jokingly refer to the former as achieving "zen detachment"—knowing what I don't directly control can actually reduce my stress. The latter is just borrowing trouble.

Let's do it. I'm often inclined to "just do it." I'm typically in favor of launching semi-aggressive MVPs, rolling forward, or tolerating short term frustration and growing pains if it means we're on a path to iterate and improve. I don't like to move fast and break things but I'm certainly more pragmatic and less risk-averse than most people. I rely on my coworkers to push back if I'm being reckless.

Work/life balance. As hard as we might work, we're not performing heart transplants or rescuing people from burning buildings. The firmer the boundaries between work and life the better I can focus on both. I care very little about when you clock in/out, flex time, appointments, or time off as long as your work gets done and your team knows where you are.

Make 'em laugh. A sense of humor is actually helpful for getting work done. It's not just about cracking jokes—although I absolutely will do so at the slightest provocation—but also the ability to stop, take a breath, and loosen up a tiny bit. I like how @daisyowl sums up the absurdity of being self-serious all the time:

if you ever code something that "feels like a hack but it works," just remember that a CPU is literally a rock that we tricked into thinking

Empathy and humility are assets. These aren't just personality traits but "skills" that make me better at my job. Ego will always get in the way of solving problems. Empathy and humility are the basis of any interaction I start with someone. Likewise, I assume positive intent from others. If somebody fails to meet that standard I see no reason to lower myself to that level or fight ego with ego. Empathy is not an infinite resource for me but when I'm tapped that's only discussed behind closed doors.

Strong opinions, weakly held. Paul Saffo's mantra is useful for starting with uncertainty and arriving at a conclusion. No opinion is so absolute that it can't be amended in light of new information or fresh perspective. I actively seek out such information to prove my "strong opinions" wrong or see where they start to bend.

Speak up! If I don't say something then I shouldn't be surprised when nothing improves. I make observations, offer suggestions, or ask questions when I have them. They might be dumb. Sometimes I'm genuinely being an idiot, but otherwise it's a tactic. I'm using Socratic questioning to explore solutions and ideas that otherwise could be missed.

Technical hiring is buggy. I have an unorthodox interviewing philosophy based on my experiences when hiring people. It's served me well but it's certainly not the industry standard nor to everyone's liking.

My Communication Style

Communication is a core skill and therefore my communication style merits particular emphasis here.

Inbox Zero. I'm at "Inbox Zero" all day every (business) day. You'll typically get an acknowledgment or response from me within 30-60 minutes. Yes, really. A non-zero unread message count stresses me out more than any lack of focus. I don't recommend this for others, but years ago I made the trade-off to prioritize unblocking my reports even if that means a lot of context switching for me.

Transparency and clarity. I tell you what I know when I know it. I'm candid about what I don't know and what's uncertain or subject to change. I distinguish objective facts from my own personal speculation or interpretation. If I need something from you I state it clearly or otherwise indicate it's "FYI" only.

Asynchronous messaging over meetings over email. I prefer asynchronous messaging (e.g., Slack) 95% of the time because I can get you a response faster than any other method. When that won't work, meetings or ad hoc calls are more effective (i.e., larger groups or Slack threads that approach 99 replies). I do not like emails.

Loud and clear. I overcommunicate by default. This means repeating the same thing across multiple venues (e.g., Jira, Confluence, email, Slack channels, pull requests). My messaging will be as public as possible for maximum visibility. I'm also vocal with my compliments and gratitude. So far nobody has told me to shut up!

Meetings. I appreciate properly organized meetings and decline invites when I can't determine their value. I may have written an essay on this topic because I'm a big nerd.

Personality Quirks

I'm not a corporate robot, so you should probably be aware of certain personality traits or behaviors.

I'm an introvert. I can talk a good game but my social battery drains quickly. I tend to be more forthcoming with people I know well over time. It's also why asynchronous and written communication comes more naturally to me.

If there's a joke to be made I'll probably do it. It's very hard for me to resist making a joke once it pops into my brain. Puns and dad jokes are the lowest hanging fruit but that doesn't stop me. I'm also playful, sarcastic, and self-deprecating in most meetings. Chat sidebars in video calls were a godsend for me because I can wisecrack without derailing the meeting.

I use a lot of GIFs and emoji. Like, a lot. A picture is worth 1,000 words, after all. Also, it's GIF with a hard "G" and I won't be taking questions at this time.

Spelling and grammar matters. One wrong character can alter the entire meaning of sentence. But it's more than that—I'm the guy who edits his Slack messages after the fact because the innocuous typo is staring me in the face and I can't focus until it's corrected.

Watch my language. I use a lot of idioms, analogies, and metaphors in conversation. They are great shorthand for complex concepts but I do tend to mix them or take them too far. Worse than that, using them presumes a cultural or linguistic background you might not have. If my meaning is ever unclear you'd be correct to stop me and ask that I explain it again.

I think out loud. Writing allows me to collect and prepare my thoughts. When I'm speaking I'm often thinking out loud and on the fly. When I do this I'm aware I have a tendency to look around the room and often past you while my brain is working (this is more obvious in person and less so on video calls). I often search on the spot for just the right word which can be disruptive mid-sentence.

I love completing tasks. There are few sensations better than the dopamine hit when I complete a task and cross it off my to-do list. Like, literally the act of crossing it off my list makes me giddy. By extension, I can get pretty enthusiastic about other people's tasks, too.

Some Exceptions May Apply

I do my best with all of the above but I'm only human. I will make mistakes or present the occasional contradiction. I appreciate when people tell me where I'm falling short or being inconsistent.

If we're undergoing an emergency or existential threat that affects our company, teams, or product then the laws of nature may no longer apply. I will swiftly—and temporarily—put aside any of the above during such times. Ideals are nice but they're useless if I don't have a job or a website to work on.

The End...?

This is a living document that undergoes regular revisions as I myself change over time. If you ever find a discrepancy between this README and my actual behavior, I invite you to please reach out and help me improve it. Thank you!

Top comments (0)