Notes on enginering leadership and software development.

The Natik User Guide

At Airbyte, we've had a set of Notion pages where everyone posted their "instruction manual" on how to best work with them. It's based on a list of questions on how each person consumes information, communicates, makes decisions, provides feedback, wants to receive feedback, etc. It was insanely helpful!

As I'm ramping up at Lambda, I'll post my version of this, but internally and here, so that both folks who are in my organization already, and folks who will interview with us in the future can see what they're getting themselves into. It'll also be fun to see in what ways my work style changes in a year.


Daily Schedule & Work Habits

  • Work hours & time zones: I'm in Pacific timezone, and I'm usually active at work 8am — 6pm. I am not at my computer all that time though. Some days I will go for a run 3 — 4 pm, or sneak out for a dog walk. Most days, I will check-in with work in the night hours after my daughter falls asleep.
  • Focus time: I will block off chunks of my day for focused work. You can book over them, but I appreciate when you ask.
  • Energy patterns: I might be slow 4pm — 6pm. I'm peaking at 10am — 1pm Pacific.
  • You will see me snacking on calls: don’t take this as disrespectful please. You don’t want me hangry. 👹

IRL

  • I live in Bend, Oregon! Before that, I’ve spent 8-ish years in San Francisco, and I’m about to move back there in the next few months.
  • My mornings are usually a breakfast with the family and a dog walk, then dropping off my 5 y/o daughter at school.
  • I love reading — both fiction and non-fiction, and connecting ideas between books in my Obsidian book notes vault.
  • I love contributing to OSS projects. @natikgadzhi is my personal GitHub account. I even did some Swift on Server stuff! (Almost like a real software engineer, huh).
  • I don’t really have a consistent fitness habit, but I like running! Find me on Strava or something. I’m always down for a running-and-coffee-after 1:1 meeting.
  • I'm into music. As in I listen to music maybe one hour a day, but I have some gear, including IEMs, DACs, headphone amps, speaker amps, and a record player that is older than me.
  • Why yes I have four keyboards and they are all unique and for different things, okay? No, it's not too much.

Communication & Collaboration

  • Preferred communication channels:
    • Slack is fine, but please for the love of everything holy, post project-related things in open project channels, not in DMs.
    • I don't like email very much 🙃
    • I do read my GitHub notifications, but I might miss some things.
    • Why yes, you can text me on my phone.
    • I don't like long meetings, but I love meetings.
  • My response time expectations:
    • Slack: up to 2 hours if I am in meetings, but 5-10m for most things.
    • Phone: 1m if I have your number, and never if I don't.
    • Email: Up to 2 days.
    • Calendar invites: I will accept them within a couple hours, similar to Slack. If I show as accepted, I'll be there, even if you did not ping me on Slack about it.
  • What I expect of you re: response times:
    • You are not on-call for Slack. I don’t expect that you will see or respond my public messages, tags, or DMs in a few minutes.
    • But I do expect that you see and respond to DMs, public channel tags and your teams channel messages in a few hours.
    • I expect that you monitor all relevant notification channels, including GitHub mentions, PR review assignments, Google Docs or Notion comments, Figma comments, and such. I expect you’ve setup your notifications the way that allows you to be most productive. If you miss a few and I’m upset about it, I’ll ask you to tune them and won’t hold it against you in the future.
  • Don’t disturb and work boundaries:
    • You’re an adult and you own your don’t disturb settings. I might tag you at 9pm and I expect that you will not see it or respond to it in any way until the next workday, unless you really wanted to.
    • If I tag you in a doc or an issue, it doesn’t mean that I expect you to start working on that issue. In fact, I expect that you stay focused on your current project, and catch up with the issue context or contribute to it, but not drop everything and work on it.
  • Meeting preferences:
    • My calendar is open, and you can edit events if I invited you. If you need my time, go ahead and book anytime you want. If I can't make it, I will cancel the meeting and ping you to reschedule.
    • Please put an ask and an agenda in the event description, or Slack me. I'd love to be prepared.
    • If I am a leader in your org and you need my help, I will always make time for you. Never hesitate to book time and talk to me. I'm here to help.
  • Open vs direct messages:
    • I will push everyone around me to work in an async-first, open mode. Everything project-related should be in open channels AND documents.
    • If you’re ever stuck on anything for more than 20 minutes, please post a question on a Slack channel.
  • Notion vs Google Docs: Honestly, use whichever you like most, just don't mix three different platforms in a single project. I will get grumpy if you do.
  • In-person vs remote: I love meeting people in-person and working together. That said, it's emotionally and physically expensive for most folks in a remote-first company, and I've been working remotely for 15ish years.
  • Pet peeves:
    • If you tell me that someone said something and you don't link to the Slack post or a Notion or Google Doc paragraph or a comment, I'll get slightly mad.
    • If you discuss an important project or tech design trade off with someone in DMs, and then another person in another DM group (say one thread of DMs with security, another with SREs) and then tell me all is great — I will be HELLA MAD. Please don't do this, it's a recipe for disaster.
    • If you give me or others any measurements (analytics) verbally without a link, I'll get mad. If you show a screenshot of a chart with unclear axis legends or legends clipped off, I will absolutely go berserk.

Supporting My Team

  • I'm “hands on”. I have the thing running locally, likely. I strive to have a strong understanding of what my teams, and wider org, are working on, and I'm usually able to make small changes, fix bugs, prototype new features, or spike new approaches.

  • Coaching and 1:1s:

    • If you’re on my team, we should have a growth plan for you, and review it every dev cycle or month. If we don’t have one yet, force the conversation, keep me accountable.
    • I like to spend time in 1:1s on topics that help you navigate the organization, understand larger context, priorities, impact, and grow. Sometimes this means diving in a code pairing session or a design session, but as you get more senior, it’s mostly in communications and “reading the room”.
    • I don’t like spending time in 1:1s on project status updates. It’s easy to save time by posting project status + next steps beforehand. Instead of status updates, we can then dig into risks and trade offs.
    • I will advocate for you to take more responsibility and grow. But, I’ll ask first. If you’re happy with the work you’re doing, and you’re at a terminal senior level and don’t want to stretch, that’s okay too.
    • Never hesitate to ask for more support and more of my time. It's my job to help you learn, grow, and be successful.
  • I will not micromanage you. I expect you to take freedom to make decisions and actions, and responsibility for the outcomes. This means that when your project is at risk, I expect you to raise it. Raising a potential problem is great. Saying things are great and then not shipping on time is not. I will help you see red flags and potential problems and fix them before they blow up.
  • If you're on my team, I will ask you for direct feedback, and whether you even trust me enough to give me direct feedback. I really mean that. I know trust is earned, not given, and I will work hard to build it.
  • You should tell my boss how I can improve. Perhaps what you want me to do more of, and what you want me to stop doing. I get it, there will be things that you won't be able (yet) to tell me — and that's okay! Please tell my boss — you should have skip-level 1:1s at least monthly. Don't wait until the performance review season.
  • PR Reviews: Yes, I'll do those! I try to be intentional and clear about my feedback, but it's always going to be direct. If I have not requested changes explicitly, and someone else approves the PR — please feel free to merge it, even if you have not addressed all my comments and questions. I am mostly reviewing pull requests to learn, and in most of my teams, I will be surrounded with senior engineers who are way more experienced and smarter than me.

Feedback to Me

  • Be direct: I’m from Eastern Europe. Between kindness and politeness, I’ll choose kindness any day. I’m direct. I will adapt to your style, sure, but I love to receive direct feedback to me, too.
  • When you expected me to do something and I didn’t do it, please tell me! “Hey, I thought you’d do XYZ by DATE and you didn’t. What happened? Why didn’t you?” is a really good conversation to have.
  • I would rather have real, difficult, challenging conversation with intent to improve early and often, rather than have one critically difficult termination conversation later. This applies to both feedback to me, and how I approach conversations with everyone at work.
  • If you’re my manager, know that any reasonable format of feedback is good:
    • Worst you can do is a “hey we need to talk, I scheduled for Monday”. Now I’ll be an anxious wreck and it’ll be difficult for me to process whatever yo have in a healthy way. Either just bring it up in a 1:1 next week, or let’s have a quick ad hoc meeting.
    • I will not be upset about your critical feedback, unless I’m completely shocked by it. Assuming we established basic understanding, direction, and trust — I should not be shocked.
    • Written feedback works best when you give me your situation context, expectation, your observation, and how you felt about it. Help me get in your shoes and see the picture.
    • I will ask for clarification and direction if I can't see a better approach myself.

Failure Modes

  • Long (seriously) narratives. I love explaining the key points, and providing wide context that feels very helpful to me. I also like using anecdotes and metaphors to drive a point. Sometimes, this is too much. If I’m rambling, tell me to get to the point, u won’t be offended.
  • Intensity: I’ll get obsessed and become a bit jumpy. This is more noticeable in person. Remotely, you'll see me waving my hand way to energetically, AND DO MORE OF THIS. #wontfix #worksasexpected.
  • I'll get excited about helping on too many things. In theory, helping teams around mine is great, but in practice, this would put more pressure on me that I understoon in the moment, and I'd need to stay late to deliver. If this looks unsustainable, tell me. I need a wake up ping some times.
  • On the surface, I process chaos into clarity. Inside, my first reaction to some utterly surprising shit is sheer panic. If you're in the inner circle and receive a 50 messages rant 8:30pm on a Tuesday, don't try to fix things, firmly and kindly explain to me that I should not invent an underlying story and need to go for a walk, breathe, and think again in the morning.
  • Oversimplifying tech complexity. Alright you're all doing this, BUT I figured out a flag. If you hear me say “Oh it's easy, we can just do %{XYZ}” — stahp me and tell me that I said the forbidden “just” word.

Natikisms

Folks at Airbyte made me a shirt on my last day there. I love and hate how accurate this is 🖤

Who needs a click to zoom behavior if you can squint really hard
Who needs a click to zoom behavior if you can squint really hard

Aaaaaaaaanyway.

⌘ ⌘ ⌘
Originally published on Apr 20th 2025.
Last update on Apr 20th 2024.