After almost four years at GitHub, I've seen a consistent way of working + values here that transcends teams, products, and leaders. It's hard to describe, but you know it when you see it. I've heard it called being "GitHubby."

I created this doc to capture (my own fork of) the durable cultural characteristics that make GitHub special. These aren't temporary trends or flavor-of-the-month processes. They're the patterns I've seen persist across nearly four years at GitHub.

Inspired by The Zen of GitHub + other insights from @benbalter, and Lessons from GitHub by @swannysec.

The pillars of GitHubby-ness

• 📚 We are all smart
• ❤️ Nerd with heart -> technical depth + empathy
• 🌎 Async-first humanity + respecting slow
• 🔗 Url-able truth -> transparency as infrastructure
• 👥 Open by default -> community as a core identity
• 🚢 Ship to learn -> Iteration over perfection
• ⚙️ Change is an opportunity to grow and re-focus
• 🔍 Focused curiosity

📚 We are all smart

There is a scene in Zero Dark Thirty where a character calls someone smart, and the response is immediate: “We are all smart, Jeremy.”

This sentiment captures the baseline experience of working at GitHub. You are surrounded by people who are not just intelligent, many are experts in their area of responsibility (AOR). By default we assume + expect our peers to be experts within their AORs.

Operating this way changes how we work:

• Trust the expert: Believe in your peers' ability to own their AORs.
• Strong opinions, loosely held: We bring our expertise to the table, but we balance it with the knowledge that others are experts, too. We challenge ideas, and we (attempt to) welcome having our own thinking challenged.
• Directness and good intentions: We appreciate direct conversations because they respect our time and intelligence. We strive to assume good intentions, but that has been an area for improvement in our culture.

The anti-pattern to this is that non-experts/performers within GitHub are often worked around instead of worked with.

❤️ Nerd with heart -> technical depth + empathy

You don't have to choose between being technically precise and deeply empathetic at GitHub. You're expected to be both. Technical depth is only half the equation; it must be paired with heart.

This looks like:

• Precision matters: Whether you're crafting a product spec, analyzing user feedback, debugging a race condition, or writing documentation, the details count. A thoughtful word choice can matter as much as a good piece of code.
• Listen before you build: Read the thread, search across repos, ask questions to relevant people. You're solving problems for real people, and their opinions have value.
• Say what you mean: Skip the buzzwords. "We should sync up to ideate" becomes "Let's talk about this sync because I don't understand why we are even doing this work."
• Credit costs nothing: When someone helps, say thanks. When you ship their idea, name them. It takes five seconds and matters more than you think.

🌎 Async-first humanity + respecting flow

Your best work happens when you have uninterrupted time to focus. GitHubby means respecting that deep work requires blocks of time where you can get into flow state, and that your teammates exist across time zones with their own schedules.

Synchronous communication is an escalation path, not a default. A two-hour block of focus time isn't the same as four 30-minute blocks scattered throughout your day. Protect your flow.

But async doesn't mean cold. GitHubby is :sparkles: emoji, GIFs, and human warmth encoded in text. It's professional without being formal, precise without being robotic.

🔗 URL-able truth -> transparency as infrastructure

"If it doesn't have a URL, it didn't happen."

GitHubby things have URLs not just for convenience, but as a philosophical commitment that every idea, decision, and artifact deserves a durable address in the universe.

This reflects a deeper belief: knowledge shared openly is valuable/impactful, while knowledge hoarded diminishes value/impact. When you work GitHubby, you can point to decisions, subscribe to updates, fork ideas, and build on what others have created.

Here's the most GitHubby thing of all: this culture itself has a URL, accepts pull requests, and encourages you to fork your own interpretation.

This is an aspirational belief we often fall short of, yet has remained a core belief.

👥 Open by default -> community as core identity

Your first instinct should be to work in the open, overcommunicate, and make work visible. This is rooted in the founding idea of open source + working in public. Open collaboration and work is the foundation of GitHub.

🚢 Ship to learn -> iteration over perfection

"Demos, not memos." Show what you built, get it in front of users, and learn from what happens next.

GitHubby isn't about shipping perfect things. It's about shipping things that teach you what perfect looks like. Most decisions are reversible. Most features can be improved. Most "final" designs get redesigned. So why wait?

You'll be wrong. A lot. The question is whether you find out in six months of planning or six days of usage. When you discover you're wrong, pivot fast. This faster cycle of learning from actual use (rather than theoretical guesses while planning) often results in better outcomes + impact. It validates your work through reality, not guesswork.

Here's the tension: this isn't permission to ship garbage. "Practicality beats purity" doesn't mean "ship shit." It means ship something that works but isn't polished, then make it excellent through iteration, as you see through practice what is working (and what isn't). Each release should be better than the last. Done and improving beats perfect and theoretical.

⚙️ Change is an opportunity to grow and re-focus

Change is constant at GitHub. Like many fast-moving tech companies, we are always adapting to ensure our focus matches our top priorities. Priorities evolve, teams shift, leaders change, and structures adapt. At GitHub it happens often enough that we have an internal "When was the last reorg?" repository—a tongue-in-cheek tracker that illustrates how common this is.

While frequent change can feel daunting, long-term Hubbers re-frame it through a different lens: resilience. Instead of framing a reorganization as a disruption, many of us see it as a signal. It’s a mechanism for the organization to correct its course, and for you to do the same.

It means valuing being given the ability to:

• Re-align with impact: Use moments of transition to ensure your work maps directly to the company's most critical investments.
• Focus on what matters: Shift your energy away from legacy projects and toward high-value initiatives that accelerate your career growth + compensation.

All that said, over the years GitHub has become (a bit) better at bringing work to existing teams, compared to reorging to achieve the same result.

🔍 Focused curiosity

Hubbers are curious. Many contribute to open source, run side projects, or dive deep into whatever fascinates them. That curiosity shows up at work. People want to understand how things work and aren't afraid to dig in.

But, with hundreds of millions of repositories and over 100 million developers on the platform -> you could spend forever being curious about everything. The most senior Hubbers I know are some of the most passionate and curious people I've ever met, yet they've mastered something crucial: knowing when to turn curiosity off.

Their curiosity is laser-focused on a combination of impact and passion. They go deep on what matters to their work and what energizes them personally. For everything else, they trust their peers to be the experts while staying focused on their own impact/passions.

Putting GitHubby to action

Some GitHubby litmus tests

Wondering if something you're doing is GitHubby? Ask yourself these questions:

1. The URL Test: Can someone who wasn't involved understand the context, decision, and rationale from a single link? Does this have a durable, searchable, discoverable home?
2. The Time Zone Test: Could someone in a completely different time zone participate meaningfully without synchronous communication? Have you made it easy for others to opt-in to context?
3. The Fork Test: Could someone take this and build on it, learn from it, or improve it? Can they submit a pull request?
4. The Feedback Test: Was input sought before the decision was made, allowing genuine collaboration? Did you consult and then decide, rather than decide and announce?
5. The Human Test: Would a peer/developer reading this feel respected, informed, and empowered rather than marketed to or talked down to? Is it conversational and authentic?
6. The Zen Test: Does it favor focus over features? Does it encourage flow? Is it logically awesome? Is anything possible?
7. The Visibility Test: Is the work visible? Can others discover it, subscribe to it, and understand its status and ownership?
8. The DRI Test: Is there a directly responsible individual who owns the outcome? Are responsibilities clear?

Examples of GitHubby in the wild

Sometimes the best way to understand the culture is to see it in action. Here are a few moments that capture the spirit perfectly.

The Copilot-Powered Furby

At GitHub Universe, Martin Woodward didn't just give a talk—he hooked a vintage Furby up to GitHub Copilot. Why? Because he could. It was technically impressive, slightly ridiculous, and completely joyful. It perfectly embodied Nerd with Heart—taking serious technology and using it to make people smile.

Open Sourcing How We Talk

Most companies keep their internal communication guidelines locked in a Google Doc. GitHub open sourced ours. By publishing "How GitHub Engineering Communicates" publicly, we turned our internal culture into a URL-able resource that others could fork, learn from, and improve. Thanks to @benbalter and @amatlack.

Hackable Conference Badges

For GitHub Universe, we don't just hand out plastic name tags. We give attendees badges like Badger 2040s, fully hackable, e-ink badges powered by Raspberry Pi.

The Octolamp

Martin Woodward designed and open-sourced the Octolamp. It's a 3D-printable, WiFi-enabled smart light compatible with Home Assistant, it includes full instructions for anyone to build their own.

What GitHubby is not

• Not secretive: Hoarding information or having "you had to be there" moments
• Not (long-term) hero-driven: Success depending on one person rather than sustainable systems, any 'heros' should be temporary
• Not synchronous-first: Defaulting to meetings when async would work, or forcing synchronous interactions
• Not corporate-speak: Buzzwords over plain language, being inauthentic or formal
• Not pure without practicality: Dogmatic adherence to principles without pragmatism, practicality beats purity
• Not formal: Stiff, distant, or impersonal communication. We're professional, not formal
• Not shipping to finish: Shipping without iterating and improving, or shipping slow things
• Not email-based: Using ineffective collaboration mediums that don't capture and expose process
• Not committee-driven: "DRIs, not committees" for clear ownership and accountability
• Not invisible: Work happening without URLs + without ways for others to discover and participate
• Not blame-focused: Seeking to blame instead of a system to fix. Focus on learning, not punishment
• Not blocking: Creating hurdles that stop others from making progress. Non-blocking is better than blocking

Key phrases that signal GitHubby thinking

If you hear these phrases, you're in GitHubby territory:

Further reading

• The Zen of GitHub: Ben Balter''s original articulation of GitHub's taste
• Why Everything Should Have a URL: On the value of giving concepts URLs
• Why Async: Benefits of asynchronous communication + why we are async
• Leaders Show Their Work: On working in the open
• Meetings Are a Point of Escalation: When and why to meet synchronously
• How GitHub Engineering Communicates: Complete communication guide for Engineering
• Lessons from GitHub: Professional principles from 9+ years at GitHub Security written by @swannysec

Originally published on Matt Nigh's Blog

Working with AI coding assistants is fundamentally changing how we write code. Here are some early observations:

The Good

• Rapid prototyping: Especially when combinations of tools are leveraged. I've had a lot of success using Lovable for design, and the GitHub Copilot Agent functionality for the actual functionality.
• Instant documentation lookup: I've been using it like having a partner smarter than me explain documentation to me.
• Pattern recognition across large codebases: My most common personal use case so far here has been reuse of styling and functionality between different apps or contexts.

The Challenges

• Over-reliance on suggestions: While I feel like I am still learning rapidly, I find when I am tired I will overrely on suggestions. Instead of seeking to understand what it did, I will accept and then immediately test what it did. I am not sure that is an actual problem, but it is something to consider.
• Need for careful verification: There have been plenty of suggestions that either didn't work, they introduced new problems, or similar. My lesson here so far is working to better judge what things need careful verification, and what doesn't.
• Context understanding limitations: With the recent limitions on number of files removed from Copilot, I might take this off the list. It used to be something low, like less than 15 files. At the moment I right this the only limitation seems to be around maxing API/AI limits. If this functionality is kept I will likely remove this from the list.

Originally published on Matt Nigh's Blog

What I am currently working on/with at home:

• https://openwebui.com/
• LM Studio
• Web Search with SearXNG
• Whisper
• Assist - Home Assistant

Originally published on Matt Nigh's Blog

GitHub Copilot isn’t just for completing code—if you feed it the right prompts, it can scan your pull requests, issues, and more to generate discussion ideas, outlines, and even full drafts of blogs. In other words, it can help you better showcase your work via discussions, writeups, etc.

Below, you’ll find a series of prompts designed to help you from brainstorming new topics to honing your final paragraphs. Note depending on the context/area in which you run this prompt, you might need to specify the repo or repos you want Copilot to analyze.

Prompts to get ideas for a Discussion/Blog

• Brainstorm Blog Angles from Recent PRs:

  I’ve worked on three major PRs (#21, #27, and #44) in the last month. Could you suggest five potential blog topics that highlight the unique challenges or solutions from each PR?
  

• Combine Issues and Code Changes:

  We improved backend performance in PR #16 and addressed user feedback in Issues #10 and #12. What interesting blog ideas can you propose that tie these updates together for a developer audience?
  

• Major Version Upgrade Inspiration:

  We released a major version upgrade in PR #99 for our library. Could you suggest three blog angles that highlight the major changes, the lessons we learned, and how the community can benefit from it?
  

• Feature-Focused Topic Generation:

  We’ve been working on a new AI-driven feature in PR #120. Please propose some blog post titles and short descriptions that will catch developers’ attention while explaining how this feature fits into our product roadmap.
  

• Implementation Deep Dive:

  I just finished implementing a complex authentication flow in PR #30. Could you outline a blog post explaining the challenges we faced, the approach we took to solve them, and a brief code example highlighting key sections?
  

• Lessons Learned & Best Practices:

  Please suggest a blog post structure that covers the top five lessons learned from our recent microservices refactor in PR #78. Include any best practices for error handling, testing, and deployment.
  

• Architecture & Design Decisions:

  Generate a blog outline that discusses our shift to a more modular architecture in PR #55. I want to explain why we made the switch, how it impacts scalability, and any trade-offs we faced along the way.
  

• Code Example Showcase:

  Propose a developer-focused blog post centered on the new caching mechanism we built in PR #64. Highlight the major code snippets, performance improvements, and any pitfalls or debugging tips for others who want to implement similar functionality.
  

Prompts to draft a Discussion/Blog

• Prompt for an Outline Based on PRs and Issues:

  Check out PR #42 and PR #53 in our repo. Could you propose an outline for a blog post that introduces the new features from those PRs, mentions any user-facing improvements, and wrap up with next steps?
  

• Prompt for a Full Draft with Specific Focus:

  Please write a short blog post describing how we integrated a new logging module from PR #22, fixed major bugs in Issues #15 and #16, and introduced a better error-handling feature. Make sure to include the main benefits to the community.
  

• Prompt to Summarize Commit History:

  I want a blog section that summarizes the last five commits, highlighting any major changes or exciting features. Could you draft a paragraph focusing on what changed and why it matters?
  

• Prompt for a Highlight of Collaborators:

  Generate a brief ‘shout-out’ paragraph that highlights the contributors who submitted PRs #33 and #37, explaining their impact and thanking them for their work.
  

• Prompt for Creating a Feature-Focused Section:

  Create a blog subsection that introduces our brand-new feature (from PR #41) in plain language for non-technical readers. Mention how it solves a pain point and include a quick code snippet if helpful.
  

• Prompt to Refine Tone & Style:

  Please rewrite the conclusion in a more informal, conversational style. The original conclusion was: ‘Our team successfully launched a groundbreaking update.’ Make it feel more personal and celebratory.
  

• Prompt for Next Steps & Roadmap:

  Draft a final section on upcoming milestones and open issues labeled ‘enhancement.’ Show how these tie into our long-term roadmap and why readers should stay tuned.
  

Originally published on Matt Nigh's Blog

Writing a brag post is a great way to highlight your team’s achievements and share insights that can help others. Here’s a simple approach to crafting one that resonates.

• Keep It Short and Focused: Aim for a post that’s 1-2 pages. The goal is to capture attention quickly and convey the key points without overwhelming your readers.
• Highlight the People Behind the Success: Make sure to recognize the contributions of individuals and teams throughout your post. Giving credit where it’s due helps build morale and encourages future collaboration.
• Promote It After Posting: Once you’ve written and posted your brag, don’t let it sit unnoticed. Share it on platforms like Slack, tag relevant people, and ask for feedback. This not only increases visibility but also helps you improve future posts.

Include Key Elements

• Share Replicable Success: Explain what worked and how others can apply the same strategies.
• Demonstrate Impact: Show how your team’s work has made a difference to users, colleagues, or stakeholders.
• What’s Next? Let readers know what’s coming or if your team needs support for the next phase.
• By keeping your brag post clear, concise, and action-oriented, you can effectively showcase your team’s success while providing value to others.

Team Brag Post Template 👇

Immediately say hello,

Now get to the point of your post -> state what happened succinctly and clearly. Give one to two more lines about that point of this post. Three max.

Maybe put a gif here if it fits your post.

🎯 Tl;dr

Provide a short tl;dr here. This should be able to be read at a glance. If your post is longer, your tl;dr should take the form of easy to consume bullet points. If your post is short, have this be 2 - 4 sentences (what you did / why it matters / the impact)

• Use bullets if 2+ pages: And formatting can be helpful to consumption as well. The easiest it is to read the more readers.
• Use bullets if 2+ pages: And formatting can be helpful to consumption as well. The easiest it is to read the more readers.
• Use bullets if 2+ pages: And formatting can be helpful to consumption as well. The easiest it is to read the more readers.
• Why do you have more than 3 bullets? You better have a good reason 👀

🚀 What We Did and Our Impact

Now write a real open here with some context and detail. This area should provide context and explicitly summarize both (1) what you did and (2) the impact of the work. Are you using bold to express big points? This should probably be around 4 - 12 sentences and call out contributors throughout.

Try to put a graphic or video here. Ideally presenting relevant data, a demo, or something similar. A table or other visual representation of data would also be appropriate. If not, bulleted lists are always a good last resort to improve readability. This should probably be around a paragraph in ‘size’, two if necessary.

Here (if needed) break down the information even more. But are people going to care about this level of detail? If yes, keep writing! If not, start moving to the close. Nothing is wrong with summarizing your work, impact, contributors, and moving on! You can always write a follow-up post if needed.

If you want to get into more detail, think about the main areas, steps, themes, or whatever you want to cover. Instead of just rambling in detail, try to group your writing in ways that an outsider would find helpful.

(If your post is long enough to have multiple themes/areas/etc consider the below structure)

Summarize ‘theme1’ in just 1-2 sentences. Now explicitly callout and summarize impact. Then go into calling out the teams and people who contributed. Now if helpful add in just a bit more detail. In total this should be ideally one paragraph, especially if you have 3+ themes.

Repeat above for ‘theme2’, ‘theme3’, and etc.

⚙️ Next Steps

This can also be Takeaways, Closings, Request for Feedback, Lessons, etc.

Now start closing out your writing. Call out any remaining contributors, including partners. Summarize maybe a takeaway, or lessons learned, or next steps.

Reemphasize points if you think you should -> using formatting to your advantage.

Feel free to be reflective here for a few lines. Look at you learning from your work and documenting it! Also, consider maybe another gif if you are feeling funny.

And close.

Originally published on Matt Nigh's Blog

Reorganizations (reorgs) are necessary pivots in how an organization invests its people and resources. Reorgs are a necessary evil in the world of engineering. They're tough, messy, and bound to piss people off.

If done right, reorgs keep company priorities and investments aligned. If done wrong, you can end up in a worse state than when you began.

According to a McKinsey survey in Harvard Business Review, over 80% of reorganizations don’t deliver the expected value on time, and 10% cause more harm than good.

I've been through my fair share of reorgs, and I'm here to share what works, what doesn’t, and how to come out the other side without losing your mind.

What happens in a standard reorganization? At a high level it means 👇

• Problems are identified that a reorg might fix.
• You justify the reorg by demonstrating how it should fix said problems.
• You plan, communicate, and execute the reorg.
• You land the reorg over time and learn from it.

Making organizational changes shouldn’t be done lightly. They can dramatically impact peoples’ careers, happiness, and work productivity. Executive teams can prevent unnecessary reorgs by asking:

• How do we know this reorg will solve, or assist with the issue at hand? Make sure you have a damn good reason before you reorg. And if you don’t have clear, justifiable reasons for a reorg, don’t even think about it. The disruption you’ll cause isn’t worth it unless there’s a real payoff.
• Are we using this reorg to hide people and/or leadership problems? If your leaders or managers suck, rearranging the org chart won’t magically turn them into rock stars. My advice is to deal with it. If there is a skill, attitude, and/or relationship issue, it should be worked through.
• What is our ability to land this reorg well, and what major risks are there? Reorgs are heavily scrutinized, and are often going to have a negative impact on your people for a time. While some of this friction is inevitable, it at least should be discussed and planned for.
• What happens if we wait? Maybe a reorg does need to happen. But what is the impact of doing it now versus later? Are there any benefits to waiting, like lessening fatigue? Would waiting potentially change our perspective? Could or should this be rolled out with other changes?

Prior to Planning your Reorg

A reorg is like using a sledgehammer to solve a problem. It might be the right tool, but it’s costly if you get it wrong. To mitigate that issue, here’s what you should do before you agree on a reorg.

📌 Identify the problems this reorg should address

Reorganizations aren’t just about shuffling people around. They’re about addressing big issues and realigning your team with strategic goals. That said, here are reasons a reorg can be necessary:

• Aligning investments to company priorities/needs: As company priorities change, so should how your people are spending their time. Does how your people are allocated across work reflect company priorities appropriately? Maybe your organization recently refreshed its company-wide priorities. Or a market change means you need to reorg to capture potential value.
• Addressing structural issues: Maybe there are issues with how you distribute scope across your organization, and people don’t have enough high-scope/impact opportunities. Or you’re having ongoing issues with staffing on call or incident response.
• Layoffs/Downsizing: It is ugly but it happens plenty. Sometimes you need to reorg to redistribute people and responsibilities after a layoff.
• Correcting seniority/grade distribution issues: Over time, your seniority distribution can become off. One team might have almost all Senior+ talent, while other teams need that guidance.

🎯 Justify your Reorg

To avoid unnecessary reorgs, create a process that requires leaders to justify their reorgs. The might involve documenting:

• The problems and how you expect the reorg to address them.
• A high-level proposed new structure that demonstrably aligns with the goals of the reorg.
• What success would look like with this new structure and why that is desirable.
• The major risks of the reorg + new structure, and how you’ll mitigate those risks.

Take that draft and gather feedback from those in the loop, and adapt as needed. Allow for meaningful debate + pivots, especially with the problems to address and the proposed new structure.

​​🙋 Common reorganization challenges

Before you begin planning your reorg, keep in mind common pitfalls:

• Communication that should have been more thorough/clear, coordinated, and/or thoughtful.
• Access issues, automated email mistakes, or other notification issues.
• Friction from people joining new teams, with new expectations, processes/habits, etc.
• Poor people placement and/or fit that could have been mitigated/prevented.

Planning a Reorganization

Once a decision is made to proceed with the reorg, there are a number of steps to take.

👥 Planning + Documenting Your Future State

• Draft a new organizational structure or guidance that supports your goals, including:
  • A list of all the new M1 teams, and their major areas of responsibilities/functions.
  • Each team should have a documented purpose, goal, or something similar.
  • The proposed headcount by team, and why that specific headcount.
  • The proposed manager of each team.
  • Any critical unique (compared to the broader org) skills that team/area needs.
• Draft a before and after organizational chart.
• Identify if any job descriptions need creating/updating.
• Have a list (via excel, google sheets, etc) of all impacted employees, including manager and title changes. You will need this for drafting reorg comms, as well as (likely) working with HR/IT.

👥 Decide how you will move people

There are several ways to move people, often involving a mix of these methods:

• Directed Moves: Top-down decisions. Quick and dirty. This is when leadership points at someone and says “you are moving here.” This might be because a specific person is needed in an area, or because someone had to be picked and they got the “lucky straw.”
• Team Matching and/or Yellow Sticky exercises: Team members participate in a matching exercise to document + consider preferences. Leaders still direct the moves, but (most) decisions are driven by preferences.
• Stays: Identify the untouchables who stay put due to specific experience or critical needs.

Maximize Yellow Sticky exercises where possible. Empowering people and giving them choices leads to better outcomes. When directed moves or stays are necessary, consider the impact on individuals. Someone might be perceived as critical, but what if that choice pushes them to leave?

When moving people, it is critical to partner well with other departments. This is to make sure a smooth administrative process happens behind the scenes. Usually this looks like working with HR (or People Systems) and your IT department.

What can happen if you don’t work well with those departments?

• Pay and/or compensation issues that can be difficult to unwind.
• Automated notifications can be sent out at the wrong time (and that can mean early).
• It can take a few days for access issues to be resolved, frustrating employees during an already vulnerable time.
• Lots of small embarrassing issues that can make you look unorganized and uncaring.

I’ve generally solved this by making sure one overall person is responsible for coordinating with HR/IT during the reorg, and they farm out work as needed.

🎙️ Create your Communications Plan

Communication is your lifeline in a reorg. Nail it, and you keep the ship steady. Screw it up, and you’re drowning in pissed off people. Here’s how to get it right.

Decide on your communications plan, for example how will you:

• Explain the why: Lay it out. Why are we doing this? Your team needs to know the real reasons behind the reorg. No fluff, just facts. Clear, straightforward, and honest​ while compassionate.
• Land reorg messaging + get feedback: Don’t just talk, listen. Schedule events where employees can ask questions and provide feedback through AMAs, manager/leader round tables, town halls, and surveys.
• Handle sensitive changes compassionately: Big role changes can suck, so handle them with care. Inevitably someone gets a manager, team, AOR, or something they don’t want. Consider how you will handle those, and how to be compassionate while still making the hard/right choices.
• Communicate mistakes + lessons learned: Putting on paper what went right, what went wrong, and how you will learn will help keep an environment of trust with your team. While part of the lessons learned might need to stay confidential, my own experience is that maximizing what you can be transparent with is received well by people.

Consider if + how you should:

• Centralize your communications coordination: Identify the different groups who will need communication and the different messages/information they will need. Make sure people have time to review and refine any drafted comms.
• Update executive leadership post-reorg: What information is leadership expected post-reorg? What is your plan for collecting and getting them that information?
• Notify outside departments/areas: Is there a separate way you need to communicate to outside departments (or external partners/people) about the reorg?

✅ After your reorganization

Pulling off a reorg is one thing. Sticking the landing is another. Here’s how to make sure the changes actually work:

• Refine your success criteria: After the reorg, you're going to need to re-tune your success metrics based on real-world feedback and on-the-ground learnings. Set realistic expectations that these will change/evolve, and be ready to adjust your plans as you go.
• Lessons learned: Reflect on what went right and what went sideways. Host a post-mortem to capture insights and make sure you don’t repeat the same mistakes next time. Be brutally honest and create practices to document this feedback.
• Determine training needs and resources: Post-reorg, some folks might need new skills or resources. Identify these needs quickly and make sure everyone gets the support they need. This might look like investing in introducing them to their new code base, significant amounts of pair programming initially, etc.
• Invest in team building: When teams shuffle, productivity can take a hit. Even in the best of cases. Help new team members integrate by investing in team-building activities. Plan events, offsites, or even casual get-togethers to help everyone click.
• Seek out opportunities to mediate and/or resolve disputes: Be the glue that holds it all together. Address minor disputes and foster a collaborative atmosphere. It's about creating a cohesive, productive team in the new structure.
• Identify where white glove communications/service would be impactful: With the impacted individuals consider where additional conversations, skip 1:1s, meetups/lunches, or other types of “white glove communications/service” would be helped.

Originally published on Matt Nigh's Blog

My flavor of autism comes with the ability to hyperfixate and get into a state of flow for long stretches at a time. Let's dive into how you can tap into this state yourself and how managers can facilitate it for their teams.

What We'll Cover:

• How to consistently get yourself into a flow state.
• How managers can help their teams achieve flow states.

Nicole Forsgren nails it in The Space for Developer Productivity:

Developers often speak of "getting into the flow" or "being in the zone." Such statements colloquially describe the concept of flow state, a mental state in which a person performing an activity is fully immersed in a feeling of energized focus, full involvement, and enjoyment.

Simply put, it's fun and immensely productive. So, how can you consistently get into flow?

Getting Yourself into a Flow State

🕥 Schedule Dedicated Time Blocks

First things first, block out 2-3 hours on your calendar. Flow doesn’t just happen by accident; it takes time to get there, and it’s only valuable if you can maintain it for at least 1.5 hours.

🚀 Set Specific Goals

Have a clear, achievable goal for your time block. Whether it’s drafting a PR, knocking out code reviews, or writing a spec, know what you’re aiming to accomplish.

🎯 Remove Distractions

• Physical Environment: Identify what distracts you in your workspace and eliminate it. I work in a dark office, wear noise-canceling headphones, and keep my door shut to minimize interruptions.
• Virtual Environment: Turn off Slack notifications, emails, and other digital distractions. I usually put a “heads down” message on my chat and check it only once every 15-60 minutes.
• Physical Comfort: Wear comfortable clothing. My go-to flow attire is sweatpants, a hoodie, and thick socks.

💪 Get Energized

• Take a Break: Start with a 10-15 minute break. Let your mind wander away from work. Go for a walk, play with your pets, or stretch. Do something that relaxes and clears your mind.
• Do something that makes you relaxes and happy: Light a candle, grab a snack, or pour some coffee/tea. Do something you enjoy that lifts your spirits. For me, it’s lighting candles and sipping on cold brew or tea.
• Do something that motivates you: Watch a motivating video or listen to some music while you review what you need to accomplish.

🔎 Become Immersed

Once you’re in the zone, staying there can be tricky. Here are some tips:

• Noise-Canceling Headphones: Listen to music that energizes but doesn’t distract you.
• Fidgeting/Stimming: Many neurodiverse people focus better when they fidget or stim. Try a fidget toy if you’re new to this.
• Pairing and Body Doubling: Many developers are familiar with pairing. If you’re a hermit like me, YouTube has pre-recorded “study with me” or “work with me” videos.
• Establish Habits and Routines: Consistent work schedules and rituals can help maintain flow. Start your day with a code review, for instance.

How Managers Can Enable Their Teams

Managers, here’s how you can help your team get into flow states:

• Leverage Async Communication: Use asynchronous communication as much as possible.
• Encourage Focused Time Blocks: Promote your team scheduling large blocks of uninterrupted time.
• No Meeting Days: Schedule team days with no meetings to allow for deep work.
• Limit Tasks: Give your team 1-3 tasks at a time. It’s hard to get into flow with a to-do list a mile long.
• Foster a Culture of Deep Work: Celebrate achievements that come from focused efforts and share tips and tricks for achieving deep work.

Originally published on Matt Nigh's Blog

Engineering Management Reading List

A curated collection of books and articles that have shaped my approach to engineering management.

Essential Books

1. The Manager's Path by Camille Fournier

   • Comprehensive guide for technical leadership
   • Practical advice for each level of management

2. High Output Management by Andy Grove

   • Fundamental principles of management
   • Process-oriented approach to leadership

3. Team Topologies by Matthew Skelton & Manuel Pais

   • Organizational design for software delivery
   • Team interaction patterns

Online Resources

• LeadDev - Conference talks and articles
• Staff Engineering Path - Stories and guidance
• Engineering Ladders - Career progression frameworks

Key Articles

1. "What Distinguished Great Software Engineers" - Exceptional vs average engineers
2. "Managing Technical Debt" - Balancing speed and sustainability
3. "Building Inclusive Teams" - Creating diverse, high-performing teams

Originally published on Matt Nigh's Blog

We went over the project budget by $50k. Our PM didn’t even mention it.

As soon as we found out, the partners pulled the PMO director and me into a room. One of our partners was frustrated as hell and said, “How hard is it to teach people to just look at their budgets? This is not a process problem. It is a people and coaching problem.”

Success is neither magical nor mysterious. Success is the natural consequence of consistently applying the basic fundamentals. — Jim Rohn

I was six months into my first leadership role. I had no idea what to do.

Back then, I was the Manager of DevOps. I obsessed for days about the problem. I talked to my dad and asked him for advice. I got back a chuckle and heard a lecture about focusing on people and fundamentals.

You can practice shooting eight hours a day, but if your technique is wrong, then all you become is very good at shooting the wrong way. Get the fundamentals down and the level of everything you do will rise. — Michael Jordan

Over the next few years, I focused on two things:

1. Simplifying how we manage budgets
2. Improving our understanding of what our clients want

That work wasn’t fun or exciting. Smart people want to work on interesting things, and I wasn’t offering any. I spent years dealing with doubt from others who didn’t understand or agree with that philosophy.

To this day, I still think about questions I was peppered with:

• “When are we moving towards automated testing?”
• “Why aren’t we using a build server yet?”
• “We plan to eventually start working on continuous deployments, right?”

These were seen as exciting projects that our team would get to leverage. Instead, over the next three years, I focused our team on the fundamentals. That focus doubled our profit, improved the work-life balance of the team, and led to having a happier team than ever.

I learned two valuable lessons:

• Focus on what builds your business, not what is fun to work on
• The best teams focus on fundamental skills

Everyone wants to feel smart, especially when they can impress others.

Great leaders don’t focus on providing the ideas and value directly. They focus on getting their team to provide the majority of company value.

Good management consists in showing average people how to do the work of superior people. — John D. Rockefeller

To be a successful leader, you have to be a great coach.

The value of a leader is your ability to coach people, grow business, and see what is up ahead. A football coach doesn’t try to out throw the quarterback. Coaches focus on teaching, planning, recruiting the right people, managing talent, developing culture, and creating a clear vision to win.

Being the “dumbest” person in the room

It means asking questions that might be seen as embarrassing to ask.

1. “Remind me, why are we here?”
2. “Help me understand how that relates to our goals.”
3. “Why do you feel like that is important?”
4. “What do you think is most important here?”

“Dumb” questions help your team focus on what you really care about.

Leaders often focus on giving their teams the answers instead of helping clarify the problem and how to go about solving it.

Ask yourself what drives your revenue, growth, and team happiness.

Other ways to focus on the fundamentals

• Listen more than you speak: Stop trying to provide your own opinion in every situation. Ask a lot of questions. Provide guidance where necessary, but step back and let people grow.
• If the business relies on you for success, change it: Build and grow a leadership team around you. Treat time spent growing them as an investment in your future.
• Give the guidance you wish you had: Most of us complain about not having training or that we wish we were managed differently. Are you doing the same to your own people?
• Coaching vs. management: You cannot be a good leader without both skill sets.
• It doesn’t have to be your idea: Are you are the loudest in the room? You shouldn’t be. Encourage and develop ideas that others have without feeling the need to add your own brand.

Stop trying to be the smartest person in the room. You probably aren’t.

Originally published on Matt Nigh's Blog

Eight years ago my wife, then my fiance, and I adopted a Mastiff who became the center of our lives. We raised her from a six-week-old adorable yet demonic puppy. We were shocked at how much we had to learn.

Over the next few years, Tinkerbell taught us many valuable lessons.

Many of these lessons apply at work.

Below are some of the lessons Tinkerbell taught me over the past eight years.

Lesson 1: Run into the danger

When I worked at Franklin American Mortgage Company, my manager used to say “Run into the danger.”

Over the past five years I have been lucky to advance my own career, from Project Coordinator to VP. Taking measured risks is the key to how I have accelerated my own career.

The first female CEO of a TV network, Kay Koplovitz, discussed risks in her own career:

“You really have to put one foot in front of the other and start on your journey. You have to be comfortable that you don’t know exactly how you are going to get to the results that you want to see. There is going to be experimentation along the way. And you have to be comfortable that you can think your way through and actually execute your way through to the desired outcome. I expected to be successful. I wanted to be successful.”

One of the biggest risks I took in my career was accepting a promotion to Manager of DevOps. I didn’t have a background in DevOps; all I had was passion.

It was the most challenging job I ever had, and I wasn’t ready for it. I spent two years studying every free minute I had while seeking any and all mentoring I could get.

Because I took that risk, I was promoted to Director, and eventually VP.

Smart risks advance your career and increase your experience level.

Lesson 2: Don’t take yourself too seriously

One of the biggest culture killers is ego.

A bad habit of many leaders is adding their two cents to every discussion. Being a leader is about growing others — not showing off how smart you are.

Marshall Goldsmith, author of What Got You Here Won’t Get You There, said:

"Imagine an energetic, enthusiastic employee comes into your office with an idea. She excitedly shares the idea with you. You think it’s a great idea. Instead of saying, “Great idea,” you say, “That’s a nice idea. Why don’t you add this to it?” What does this do? It deflates her enthusiasm; it dampers her commitment. While the quality of the idea may go up 5 percent, her commitment to execute it may go down 50 percent. That’s because it’s no longer her idea, it’s now your idea."

One of my first failures was implementing a mentor program at my first job out of college. The intent was to increase employee retention and improve training.

I thought my idea was brilliant, but it was a complete failure.

I asked around for advice on how to fix it. One person gave me a great piece of feedback and said, “This feels like you created it in a hole. Why should I care about it or put my time in it? Even if it is a good idea.”

I spent the next few weeks meeting with every Lead or Manager and had each help me redesign the program.

Almost nothing changed on paper. What did change was people’s enthusiasm about the program. The Leads and Managers now felt like this was their creation as well and embraced it.

What started as a failure turned into a success, all because I took my ego out of the equation.

Lesson 3: Reward performance and behavior

Ian Hutchinson, CEO of an employee engagement company, said:

“Your number one customers are your people. Look after your employees first and then customers.”

Every leader understands the importance of taking care of clients. Not every leader believes in taking care of employees.

The problem with that is your employees are the ones serving your clients.

How many times have you called a customer service line to hear a listless voice on the other end? Too many.

Studies have shown that rewarding positive behavior motivates employees more than punishments.

Customers want to buy from companies that take care of their employees.

Lesson 4: Training is vital

Imagine a football coach who holds practices only once a month. Or a silent coach on the sidelines.

You can’t grow people without coaching and feedback.

Invest a significant amount of time coaching your employees.

More than 70 percent of high-retention-risk employees say they’ll have to leave their organization to advance their career.

Leaders must develop a coaching culture and become excellent coaches themselves.

Do you believe your employees require constant micromanagement? If so, that is a reflection your coaching and leading ability.

In 13 Ways Leaders Can Build a Coaching Culture at Work, a member of the Forbes coaching council states:

A coaching culture encourages employees to learn from their experience by exploring the right questions rather than telling them what to do and how to do it. Next time an employee has a challenge ask them open-ended questions that begin with “how” or “what.” For instance, “What would you have done differently? and “How can I support you?” This way you empower employees to come up with meaningful solutions.

Lesson 5: Rest is essential

I traveled 40% of my time during my first two years as a manager.

I obsessed about doing a good job. My first year of travel, I would leave from Nashville at 5:00 a.m. I would often arrive in Memphis before most of my people arrived at the office — and with a three-hour drive.

Did it show my dedication? Sure. But I was barely functioning outside of work hours.

During that time I made more mistakes, had less patience, and didn’t manage my team as well as I should have.

Multitudes of studies show the impact that sleep deprivation has on performance.

You can’t take care of your team without taking care of yourself.

Lesson 6: Engage your team

Engaged employees are the holy grail for managers.

Having engaged employees lowers turnover, increases work quality, and increases customer happiness.

Yet, businesses are terrible at engaging employees.

Only 33% of employees in the US are considered engaged at work. In the world’s best organizations, 70% of employees are considered engaged.

One of my favorite examples comes from Jack Welch’s book, Winning. He describes a time a factory worker spoke up at a town hall meeting. The employee felt that managers didn’t care to hear ideas from their team.

“For twenty-five years, you paid for my hands when you could have had my brain as well — for nothing.”

Four steps to improving employee engagement:

• Measure current engagement — An engagement tool can assist and automate engagement measurement. I would personally recommend Insight or CultureAmp. These tools are simple to use and good for medium to large companies.
• Leaders set the tone — Align performance expectations with engagement. Empower managers to make a difference in their environment and teams.
• Managers need to care — The key decider for engaged employees is their direct manager. Managers must take a direct role in ensuring employee engagement.
• Communicate what engagement is — Abstract definitions of “engaged employees” create confusion with expectations. Define and discuss engagement with your team. Use simple and realistic examples from their day-to-day work. Create a common understanding of what engagement means.

Lesson 7: Be radically transparent

Zenefits defines radical transparency as “…the belief that all corporate entities should be honest, open, and straightforward.”

Radical transparency can be a powerful tool. It can cut through poor communication, empower employees, and help create a meritocracy.

Ray Dalio is the founder of the biggest hedge fund in the world and manages over $160 billion. He is a key thought leader of radical transparency. One of his favorite stories is an email he received from an employee after a meeting.

“Ray — you deserve a “D-” for your performance today in the meeting … you did not prepare at all because there is no way you could have and been that disorganized. In the future, I/we would ask you to take some time and prepare and maybe even I should come up and start talking to you to get you warmed up or something but we can’t let this happen again. If you in any way think my view is wrong, please ask the others or we can talk about it.”

Radical candor helps authenticity and increases employee engagement.

Even if your company doesn’t embrace radical transparency, it can help you as a manager.

Lesson 8: Help your team enjoy work

Your team cannot be engaged without enjoying what they do.

In The Happiness Dividend, Shawn Achor says,

"A decade of research proves that happiness raises nearly every business and educational outcome: raising sales by 37%, productivity by 31%, and accuracy on tasks by 19%, as well as a myriad of health and quality of life improvements."

The Corporate Leadership Council conducted an employee engagement study. The CLC surveyed over 50,000 employees across 59 companies. In the study, they found:

Those employees who are most committed perform 20% better and are 87% less likely to leave the organization — indicating the significance of engagement to organizational performance.

Want to build a great company? Then you want happy employees.

Lesson 9: Embrace the pack

Team members often focus on the individual team they are a part of instead of the larger company.

Investopedia defines silos as:

“An attitude that is found in some organizations; it occurs when several departments or groups within an organization do not want to share information or knowledge with other individuals in the same organization.”

Company size has little to do with silos. They exist everywhere, even in small teams. Beneficial silos are rare. The job of a leader is to find and help remove unnecessary silos.

Eash Sundaram, CIO of JetBlue, discussed silos in an interview. He stated:

“The most important thing we are doing here is collapsing the silos. When we think about a program, we don’t think about IT and finance and commercial operations. We think about how the program improves our customer or employee experience.”

A lack of trust, accountability, and poor leadership create silos.

Patrick Lencioni, author of Silos, Politics, and Turf Wars, suggests:

"The key to eliminating silos is simply to provide a compelling context for colleagues to understand that they should be rowing in the same direction. While leaders have been focusing on punishing negative behaviors that lead to internal conflict, they have often failed to give people a clear understanding of what they have in common, and why serving the common good is better for them than looking out for number one."

Lesson 10: Encourage positive conflict

Positive conflict can increase organizational health.

It acts as a check on ideas, decisions, hires, and everything in between. Conflict grows teams through feedback, challenges, and defending ideas.

Fear of conflict is a challenge in almost every organization.

Help your employees understand what positive conflict looks like and what behavior is unacceptable.

Encourage and reward positive conflict. When employees speak up and say difficult things, thank them and encourage others. Discuss it in reviews and in one on ones.

Originally published on Matt Nigh's Blog