← Back to Blog

Working With Me

This is a living document that I’ll update based on your feedback and our experiences working together. Please feel free to suggest additions or modifications that would make it more helpful for you.

Working with Me Guide

My Role & Background

  • Current Role: Engineering Manager
  • Roles at RV:
    • Senior Backend Engineer (ADT/Pod64 🪦)
    • DevDataOps Engineer (I made this title up, Frontier)
    • Tech Lead Backend/Data (Amex)
    • Engineering Manager (Wells Fargo, Current)
  • Prior Roles:
  • Educational Background:
    • MS in Computer Science (Focus: Big Data & Distributed Systems)
    • MBA from University of Michigan (Focus: Marketing & Finance)
  • Technical Depth: Strong technical background with expertise in:
    • Distributed systems and big data
    • Infrastructure as Code
    • Data pipeline architecture and optimization
    • DevDataOps practices

My Leadership Philosophy

I believe in fostering an environment where engineers can grow and thrive while delivering high-quality technical solutions. My approach centers on:

  • Technical Excellence: Leveraging deep technical expertise to guide and mentor while empowering ownership
  • Operational Efficiency: Continuously seeking ways to simplify systems and reduce complexity
  • Full-Stack Awareness: Encouraging engineers to develop broad technical capabilities across the stack
  • Innovation with Purpose: Driving meaningful technical changes that improve team efficiency and system reliability
  • Team Growth: Actively looking for opportunities to challenge and develop team members through strategic project assignment
  • Experimental Mindset: Creating systems and processes that make it easy and safe to try new approaches

Success in these areas comes through a deep commitment to ownership at all levels and a culture that embraces thoughtful experimentation. I believe in building teams where every member feels empowered to innovate and responsible for our collective success.

Ownership

I believe deeply in ownership as a foundational principle. This means:

  • No “That’s Not My Job”: This phrase is antithetical to our success. We succeed and fail as a team.
  • Domain Expertise IS Your Job: You have the right (and responsibility) to become an expert in your domains.
  • Cross-Functional Understanding: While specialization is valuable, understanding how your work impacts others is crucial.
  • Problem-Solving Without Borders: If you see a problem, you’re empowered to solve it, regardless of “whose area” it’s in.
  • Team Success Over Role Definitions: Job descriptions are starting points, not boundaries.

This philosophy manifests in how I:

  • Encourage engineers to develop “full-stack awareness”
  • Support cross-training and skill development
  • Recognize and reward initiative beyond role boundaries
  • Structure projects to build broad expertise
  • Evaluate and reward team members

What This Means For You

  • You’ll be encouraged to expand your expertise beyond your current comfort zone
  • I’ll support your growth into new areas that interest you
  • You’ll be recognized for taking initiative and solving problems holistically
  • I expect you to think about system-wide impacts, not just your immediate task
  • When you see something that could be better, you own making it better

Communication Style & Preferences

  • I am known for being direct, concise, and efficient in my communication
  • My Slack messages are often brief and to the point
  • While this brevity comes from a place of efficiency, I acknowledge it can sometimes be perceived as abrupt or harsh
    • I’m actively working on this, please give me feedback
  • I deeply respect everyone I work with, regardless of their role or experience level
  • I welcome direct feedback

How Best to Work with Me

Communication

  • Don’t hesitate to ask for clarification if my responses seem too brief
  • I appreciate direct, straightforward communication
  • Feel free to schedule time with me for longer discussions
  • I prefer Slack to e-mail. I try to conduct work conversations in public channels. If you have a question, want to have a discussion on a task, or have something for the team I’ll encourage you to start a thread in one of our channels. My DMs are always open as well, and personal conversations can (and will!) be had there.

Feedback

  • I actively seek and welcome feedback on all aspects of my work and leadership
  • No feedback is too small - I want to hear it all
  • I prefer receiving feedback either via 15five, or through Slack
  • I promise to receive all feedback with openness and appreciation

Decision Making

  • I value data-driven decisions and technical rigor
  • I encourage healthy debate and discussion
    • I have a tendancy to bikeshed. I honestly love this stuff. You’re an owner; if you think a technical discussion is veering off the rails you have the power to get it back on track

1:1s and Meetings

  • [YOUR 1:1 STRUCTURE AND PREFERENCES]
  • [YOUR MEETING STYLE AND EXPECTATIONS]
  • [BEST WAYS TO PREPARE FOR MEETINGS WITH YOU]

What You Can Expect from Me

  • Technical mentorship and guidance when needed
  • Support for your career growth and development
  • Clear and honest feedback
  • Respect for your time and contributions

My Areas of Development

I believe in transparency about areas where I’m actively working to improve:

Planning and Organization

  • Working to improve project documentation and status tracking
  • Developing better systems for stakeholder visibility into ongoing work
  • Focusing on more structured planning and milestone tracking
  • Improving use of tools like Jira and Confluence for project management

Communication

  • Making my communication style more approachable while maintaining efficiency
  • Adding more context when introducing technical changes
  • Improving cross-functional communication
  • Being more mindful of how my technical expertise might influence discussions

Implementation Practices

  • Balancing speed of innovation with team readiness and support
  • Being more thoughtful about the timing and frequency of introducing new tools
  • Finding the right balance between “Infrastructure as Code” and accessibility

I appreciate patience and feedback as I work on these areas

Quick Facts

Working Hours & Availability

  • 0830 - 1730
  • Eastern Time (Maine 🦞)
  • I am bad about setting my Slack status to away until it’s too late

Influential References & Principles

Technical Philosophy

  • “Parse, Don’t Validate” (Alexis King): Shapes my approach to system design and data handling. I believe in designing systems that make invalid states unrepresentable and handling data transformations explicitly at boundaries. This influences how I review code and architect solutions.

Work & Time Management

  • “Maker’s Schedule, Manager’s Schedule” (Paul Graham): I try to balance maker and manager time, both for myself and the team. I protect large blocks of focused time for deep technical work and try to cluster meetings to preserve flow states. Please be mindful that context switching has a high cost, especially during technical deep-dives.

Software Development

  • [OTHER KEY REFERENCES]
  • [FAVORITE TECHNICAL BLOGS/AUTHORS]
  • [RECOMMENDED READING FOR TEAM]

Management & Leadership

  • [KEY MANAGEMENT PHILOSOPHIES]
  • [INFLUENTIAL BOOKS/ARTICLES]
  • [RECOMMENDED READING FOR GROWTH]

I frequently reference these works in discussions and they inform my decision-making. I’m always interested in exploring new perspectives and welcome recommendations for additional reading.

Last Updated: 2025-02-18