This is a document about my management style. There are many like it, but this one is mine. It is a living document, and I’ll revise it periodically with notes from the journey.

Published 2023, revised 2x in 2023, revised 2x in 2024.

About You

  • I consider you valued, competent, and well-intentioned. I will make decisions based on those assumptions.
  • Your personal well-being is more important to me than whatever $COMPANY has going on.
  • You and your teammates have various nationalities, ethnicities, religions, genders, orientations, neurotypes, disabilities, disorders, and so on.
    • It should go without saying, but it is unacceptable for you to be discriminated against or treated poorly for these.

About Me

  • I ask questions, especially dumb ones, and encourage you to do the same. Looking cool or smart is not a long-term winner.
  • When making decisions and commitments, I consider both the needs of the business and the needs of the employee, and bias towards the latter.
  • Whenever possible, I am transparent. I am happy to answer questions or give you information at any time.
    • In rare cases where I will not or cannot be transparent about something (i.e. due to comfort, or due to $COMPANY, etc.), I will explain why instead of avoiding the topic or lying. For example: if you asked me “how much does $TEAMMATE make,” I would say that I will not unilaterally disclose this information as some people consider it private, and encourage you to ask $TEAMMATE directly (or if multiple teammates volunteer, start a voluntary spreadsheet).

Your Job

You are given space to solve big problems with little oversight. I trust you, so I will not micromanage you - that would slow both of us down. I will try to make sure you have the resources you need, and then I will get out of your way. If I didn’t make the mark or an issue has cropped up, you can always ask me for help, resources, context, escalations, etc. and we’ll work together to make sure you get everything you need.

You should be engaged, but not busy. Being “busy” is not a desirable condition. You should not run at 100% capacity during the normal course of business. Excessive busy-ness is a symptom of a problem that needs to be addressed, and we’ll work together to address it. There is a known failure mode here: If you don’t tell me you’re overloaded, I assume you have bandwidth, and will keep giving you more shit to do. Easy solution: tell me you’re at max, and I will correct that. I will try to mitigate this by asking you how you’re doing during our 1:1s.

You should have clear priorities. You are encouraged and empowered to decline or postpone requests for additional work that are lower priority than your current task list. If your “no” doesn’t take, escalate to me and I will handle this for you. If you don’t have the information to prioritize, I have done something wrong. Talk to me so I can correct this.

You are empowered to maintain harmony between work your work and home life. I don’t care where or when you work. Find what works best for you in harmony with your home life, hobbies, family, and friends. If I can reach you within a business day, you attend meetings you’ve accepted, and you are generally making an effort to be available: we’re probably good. $COMPANY or $CONTRACT may have requirements, and if they do we’ll be sure you can meet those requirements with as little impact to your work-life balance as possible.

My Job

I will prioritize you and your teammates over stakeholders. You are a greater priority than our customers, my peers, and my management.

I will ensure you have context about the work you are doing. I will ensure you understand the reason of, purpose of, and value of the work you are asked to do. This is to inform your priorities and ensure you have appropriate context to complete tasks correctly. In some way, big or small, I hope this also motivates you - I enjoy learning new things and solving tough problems, while this isn’t a requirement for the job (it is a job after all) I hope you do too.

I will make sure you can do your job with minimal hassle. Where possible, I will remove administrative overhead, unnecessary pages, and other miscellaneous bullshit from your task list so you can focus on solving problems. I would rather that nobody’s time is wasted - but if I have to choose between someone wasting my time and my team’s time, I will ensure they waste my time first and foremost.

I will provide you with performance feedback and growth opportunities. Performance and growth opportunities are year-round, not just when we do performance reviews. On an ongoing basis, you should know how well you’re doing in your current role, what it takes to move to your next level or job family, and have ideas or tasks (ideally - but not always - tasks) that will help you achieve your career goals. You should never be surprised by performance reviews - if that happens, I have done something wrong. If you are unsure of how you’re doing, we can review anytime in 1:1s.

I am always available for my team for any reason. To be clear: you are not expected to mirror this level of availability - you would be expected to have this availability while oncall, but not when offcall. Another way of saying what makes my role different would be: “as a manager, I am always oncall for my team.” If you need access to me, you can reach me by any means available to you, but note that I will not always be checking. Sorted by most to least likely to catch my attention: pager, call, text, Slack, email. My profile with $COMPANY has all of these listed, and I trust you to be responsible with this.


1:1 Meetings

I schedule a weekly 1:1 (30 minutes) with every team member. This is your meeting - you can reschedule if needed, and I will prioritize our scheduled time over other meetings. Except in rare cases (‘true’ emergencies), I will only reschedule with your permission.

At the start of our 1:1 time I will ask for a brief status update, focused on how you are doing. You have mechanism to share status with me and the team (ex. weekly standup), but that is generally focused on what you are doing. This can take as much or as little time as you want.

The remainder of the meeting is entirely your time. You can talk with me about whatever you like - problems, ideas, career things, what you had for lunch, anything at all. Some weeks we don’t have anything to talk about and don’t get into a groove. This is not a problem, and we can take the time back. The point is, it’s your time to do whatever you want with.

Ad-Hoc Meetings, Good News, Bad News

When I have something to discuss with you, I will either ping you on Slack (for quick chats), or set up dedicated time for us to meet (for extended conversations). This could be good news, bad news, performance reviews, dumb questions I have, etc.

I will try to notify you about the contents of the meeting ahead of time - both so you can prepare and to eliminate any anxiety about what the meeting is - but may not be able to due to time constraints or competing tasks. If you are anxious about ad-hoc meetings with me, “no news is good news” is a good rule of thumb. Please tell me if that isn’t working for you, I will do better to give you a one-liner about the topic, so you are assured it’s not bad news/performance related.

Generally, I follow the philosophy of “news first, details second.” As an example in performance reviews: we will not conduct an entire performance review before telling you how you’ve done overall at the end. This is suspenseful for no reason and limits your ability to focus during our conversation. I will give you your status immediately when the performance review data is unsealed, and then we will discuss the contents of the review.

Oversight & Escalations

As mentioned, I will help you get the resources you need, and then I will get out of your way. It’s normal for us to talk the most in our 1:1s, with ‘hallway conversations’ outside of that in Slack or other meetings. This means a lot of your time will be spent working on problems individually or with your team members. This creates another known failure mode: if you find that you are stuck, struggling, without context, getting paged, etc. I will not immediately notice this.

You are encouraged to bring me into an issue (or project, meeting, etc.) whenever you want; but only if you want. If you’re getting a handle on what you’re working on or are clearing the blockers fine on your own, keep at it. If not, or if it’d be easier with help, notify me.

In particular, this can be useful for dealing with organizational issues, for example if another manager is not responding appropriately to a “no,” or if you need me to escalate an issue. It can also be useful if you’re confused about a particular project/meeting/etc. as I may have broader context and can refer you to an SME or team that handles this.

Oncall & Paging

Our team does have oncall rotations, emergecies can happen, and when those emergencies happen the oncall will be paged. The oncall will need to have a communication device with them, should have reliable access to their corporate device (ideally within 5-10m, at most within 1h), and a reliable enough internet connection to receive pages and respond to events.

Emergencies should be rare, and we should assess and downgrade anything that doesn’t meet the criteria for an emergency, then handle these through our normal processes. For legitimate emergencies, we will address these first, then do a retrospective on what could’ve been done to avoid the emergency or reduce the time we needed to address it.

Generally, the opinion I have is this: if someone gets woken up in the middle of the night for [some reason], we may have (or can obtain) the knowledge we need to ensure the same never happens again, and can build that into our software/processes/etc. If we can, even if we need to adjust the timeline for lower-priority deliverables, we should do that immediately. First and foremost we need to sustain our operations, and reducing operational load by fixing the root cause of an unnecessary page or outage helps us scale even in the short-term.

Finally, if the page comes in off-hours or requires off-hours effort, keep track of the time you’re working outside your usual schedule. This is your time. I’m serious about this - inform me when you’ll be taking that time back (ideally: within days or weeks), then disappear to go rest and recuperate.

PTO should be sacred time. There’s no qualifier for this, either. 1 day? 2 weeks? Going on vacation? Playing video games? Building a shed? Getting married? Marathoning three seasons of The Bachelor? If you’re on PTO, you’re not available, and we should have the capacity to soak even a major emergency without sending you so much as a single notification.

When you’re going on PTO:

  • Wrap up or reassign your day-to-day work,
  • Trade oncall shifts,
  • Remove yourself from consultation queues & ticket rotations,
  • Leave good documentation (this is high priority! deprioritize other work!),
  • Put an out-of-office block on your calendar (invite your teammates, myself, and optionally any key stakeholders),
  • Set a clear status (“🌴 PTO until $DATE. For escalations, contact $NAME”),
  • And disconnect.

If I see you online - outside of posting cool pictures of whatever you’re doing - I will remind you to log off and enjoy your PTO. In the unlikely event someone pages you directly (as they would be skipping or ignoring oncall), escalate to me immediately and I’ll handle it. Better yet, silence/disable your pager while on PTO.

If you feel like you can’t take PTO or can’t “disconnect” during PTO, this is a sign that our processes and operations are not healthy - talk to me and I will fix this.

“All-Hands” Emergency Availability

Of course we will try to have as few emergencies as possible, but working in the security space: shit can happen. To be clear, the vast majority of events should be resolvable by only the oncall, and the oncall will only infrequently need to escalate to a manager (either myself or my manager). Emergencies that require off-call staff to be paged should be extremely rare, on the order of less than one per year.

When this happens, I will try to structure emergency response by preferred working hours (ex. night owls might take night shifts, early birds might take day shifts).

Our plan for contingencies is pretty simple: 50% of the team should be available within a “few hours’ notice.” If you’re off on PTO, great! If everyone is off on PTO (ex. for a holiday), I’ll ask for volunteers to help make sure the 50% bar is met so any well-timed incident can be handled - and the rest of the year we’ll be mitigating the risk of such an incident.

Opinionated Glossary


Very few things qualify as emergencies. Security issues and software outages, sure! But digest it carefully if another team insists you should bump your priorities to switch to an emergency. There is necessary conflict here:

  • We do want to be scrappy, agile, and helpful when there are problems we can solve,
  • But we can’t solve every problem simultaneously. Context switching and working off-hours are both expensive short-term.

I will try to help you strike a balance of agility with focused time. You may succeed with different levels of randomization than your peers, and this is OK. If you need help prioritizing (especially when new tasks come in), or need me to rebalance the tasks you’re getting, please ping me.


Everybody makes mistakes. I make mistakes, and I expect you to make mistakes too.

We make mistakes as a team, take responsibility as a team, and mitigate mistakes as a team. I will not blame or bemoan the you when you make a mistake, and won’t tolerate anyone else blaming or bemoaning you for making a mistake, whether they’re on our team or not. After making a mistake, we will review what the root cause of this mistake was, opportunities to improve our operations, and take steps to ensure that the same mistake cannot happen again.

The only time that a mistake will reflect on you individually is if that mistake was caused through negligence or malice. The bar I apply is: “would a reasonable engineer have made this mistake, given the circumstances.” Very few mistakes would ever fail this test, even very expensive or embarrassing ones.


We should be frugal by default - the simplest metric for ‘real’ success in securing a business is “are we resolving more risk than our team, tools, etc. cost. on a yearly basis?”

To the naive, that might sound like “if you cut costs, you increase your margin” - but this isn’t true. Our most expensive asset is our team’s time, and to get the best ROI our team’s time needs to be used as effectively as possible, as only the productive time on the team will reduce risk. This means that you should not be spending your workday fighting with an uncooperative craptop, debugging program crashes because you’ve selected the smallest possible instance to run applications, maintaining server fleets to save a buck on serverless, and so on.

This of course doesn’t mean “spend wildly” - spending money just to push the envelope or fill out a budget is never something we will do - but that frugal choices should take the value of your time (and the opportunity cost of wasting your time) into account.


This was inspired by - and some portions needed no modification from - tkrpata’s REAMDE. To date, it is the best introduction to a new job I’ve ever had.

Many thanks to the influential engineers, team leads, and managers I’ve worked with across my career - too many to list, but special thanks to Griffin, Bonny, Tyler, Katie, Susan, Becca, and Bill. Nanos gigantum humeris insidentes.


If you read all this and aren’t yet part of the team, but are now potentially interested in joining us, please follow me on LinkedIn. I will post job specs that would allow you to work with me, my team, or teams we directly work with - these are typically Security Engineer and Software Engineer roles (plus related roles: Support, PM, etc.). Come shoot your shot like I once did!