There are 3 big problem areas for us to collectively solve as we develop best practices for building software with AI.

1. Supply sufficient context

In modern software development we have moved to faster and smaller iterations, less waterfall and more agile development. Which is great for a ton of reasons but a side effect of these improvements is that we have also moved away from clearly articulating the requirements and business objectives of each discrete, functional piece of code. It is quicker for humans to verbally sync and align on these things and then codify them through the process of writing the code. Humans, over time, carry more and more tribal and organizational knowledge and we can apply this context automatically. Which means we only need to clarify how new functionality fits into the broader context.

However an agent does not naturally hold onto this information. We define a new piece of functionality and without additional context the agent may develop a piece of software that is functionally fine or even great, but off-center from the alignment the humans in the room will automatically have.

This applies to code review as well. A great code review agent can absolutely detect bugs, inconsistencies in logic, and test issues, but it will not be able to have the appropriate judgement for if this architecture maps to the broader architecture or even the directional future architecture the team is moving towards.

So how do we fix it? Well we have to give the agent the context. There are a bunch of different strategies to help set this context. We can add AGENT.md files, more context in README.md, and we have the prompt itself. We also can iterate on a plan.md file with the agent, so that we can start with a relatively high-level prompt and iterate until the plan for implementation accurately reflects the constraints and business goals of the work.

This plan.md file, is starting to look a lot like a traditional spec file. The higher the detail in the plan, the more likely the agent can implement the code correctly. With the help of the agent, even a semi-technical Product Manager can develop a plan that will at least give the software engineer a great starting point for execution and reduce the number of iteration loops that we have learned to love in our hyper-agile world.

2. Training junior engineers

This is a tough problem in the age of agentic coding. Our Senior+ engineers have all succeeded in the industry without the help of AI. But to those new to the profession it has never been easier and harder to succeed. For someone growing in the discipline of software engineer it’s not enough to produce executable code at a high velocity. You also need to thoroughly understand the code that you are producing and signing your name.

As managers, we could possibly go a long while thinking our junior engineers are progressing just fine. After all, they are producing code at a fine rate, they are responding to feedback in code review, and they are getting things shipped. At some point though, the complexity of work could outpace their own understanding until they find themselves drowning in code they don’t understand and using AI more and more as a crutch for knowledge and experience. Suddenly, we have a performance issue that seemed to appear out of nowhere.

So how do we ensure that our junior engineers are developing and understanding the code that they write?

I propose another return to form with synchronous code reviews. The problem with pushing all communication through github is that it is still to easy to hide behind AI-powered explanations for how and why your code works the way that it does. With some form of synchronous code review, dissertation-style, a junior engineer will have to learn how to explain and defend their code and respond to critical feedback. Really this is something that perhaps all engineers should do on occasion. A good engineering manager will be able to help moderate the conversation and pick up on specific cues that may help with coaching the engineer in the future.

3. Validating that it’s working

This is perhaps the most controversial but with more and more of the software development lifecycle becoming automated, how do we know that something is working?

Maybe more prevalent for front-end development but if we have agents writing the specs and the code, reviewing the code, and testing the code. When do the humans make sure that software meant for human consumption is usable by, you know, actual humans?

The answer here is probably many things. You can argue that this is even more reason to “test in prod” and increase our production observability. We launch code into production so fast that we essentially let our users test the code and we rely on extremely fast fixes for regressions. This can work, but I think we are already seeing the early signs of regression fatigue from users. Just watch how the Claude team is constantly, quickly fixing issues. There is still an invisible quality bar that paying users have, and once you cross it, wait for the lagging churn indicators a year or two from now.

Another old-school practice could help us alleviate the problem. Yes, that’s right, maybe its time to bring back manual Quality Assurance testers. First of all, remember your expensive Product Managers and Engineers are now writing down better plans and specs than we ever have before. How easy would it be for an agent to go ahead and notate a testing checklist and maybe even a risk assessment score? Then its a simple math equation, how many regressions can a small, human QA team catch that all the agents and automation will miss? And how many regressions before your churn starts to be affected?

AI is revolutionizing and disrupting everything that we know. Things are changing so quickly that maybe, if we can stop and take a breath, we will realize that they haven’t changed at all.

Most agent systems can produce code, summarize files, and follow steps with reasonable consistency. Review is different. A good review has to understand intent, reconstruct context, notice second-order effects, and call out risks that are easy to miss precisely because the code looks plausible on first pass. The agent has to separate “works” from “is wise”, and that gap is where most of the real engineering taste lives.

This gets even harder when the codebase has history. The best review is rarely about syntax or style alone. It is about whether a change fits the architecture, preserves the product behavior, avoids hidden regressions, and matches the team’s standards for maintainability. In other words, review is where local correctness meets system-level judgment.

Below are a few agentic skills that can help make code review more structured, more repeatable, and more useful.

Skill Snippets

---
description: Code review behavior and priorities
alwaysApply: true
---

# Code Review Expectations

When asked to review changes, prioritize inline suggestions and label issues as **Blocker** or **Nitpick**.
You are a principal software engineer and focus on overall architecture, ensuring new code adheres to the existing structure and design patterns.
You do not skip over files and you consider the changes holistically in context of the surrounding code. If you find something that could be a
controversial decision, you raise it as a question on the pull request.

## Review focus (always)
- Correctness, edge cases, and regressions
- Security and data safety
- Performance and scalability
- Style/consistency with existing code
- Tests and coverage gaps
- Documentation clarity

## Process
- Start with blockers, then nitpicks.
- Provide actionable, concise fixes.
- Call out unverified assumptions explicitly.
- When possible, add GitHub review comments on specific line items.
- Always add inline GitHub review comments for findings when reviewing a PR.
- Always run related tests as part of code review and report results.
- Check for duplicate or redundant tests when reviewing test changes.
- Perform a deep review on every PR: read docs/README changes, API/design notes, architecture concerns, naming consistency, i18n usage, and code duplication risks. Do not skip these areas.
- Scan for duplication across packages and shared utilities; flag DRY violations.
- Scan reducers for unused actions or dead state transitions.
- Consider and incorporate design feedback in the review summary.
- Use the `vercel-react-best-practices` skill when reviewing React changes.
- Do not publish verifier summaries to GitHub; keep them in the review summary only.
- Always use `gh` CLI to publish the review and PR comments.

## Review guardrails (avoid misses)
- Do a doc accuracy pass for new/changed README/MIGRATION files and code examples.
- Check API parity vs existing behavior (feature gaps, migration concerns).
- Scan for cross-package duplication (parsing, helpers, services) and note DRY risks.
- Evaluate bundling/instance boundaries for shared-state utilities.
- Verify i18n guidance for user-facing strings in types/docs.
- Review package metadata impacts (e.g., `sideEffects`, exports).
- Consider dynamic config changes (initial state vs runtime updates).
- Review this code for potential edge cases, race conditions, or error handling issues

## Sub-agent verification
- If a verifier sub-agent exists (e.g., `code-verifier` or `verifier`), run it during your review and incorporate its findings.

## React reviews
- When reviewing React files (e.g., `*.jsx`, `*.tsx`), employ the `vercel-react-best-practices` skill.

This Code Verifier sub-agent will give the agent and yourself context for if the code actually works and is tested. It will be run as part of the code review skill.

# Code Verifier

You are a verification sub-agent. Your job is to validate completed work and report what is verified vs incomplete.

## What to check

1. **Correctness**
   - Validate behavior changes against intended requirements.
   - Look for regressions, edge cases, or missed updates in related files.
   - Ensure types, contracts, and public APIs remain consistent.

2. **Tests**
   - Identify relevant tests to run based on touched areas.
   - Prefer repo conventions: Jest for unit tests and Playwright for end-to-end tests.
   - If you cannot run tests, state which tests should run and why.

3. **Build and lint**
   - Identify linting or type-checking risks in changed files.
   - If errors are likely, call them out with file paths and reasoning.
   - Check for proper i18n usage when user-visible strings are added.
   - Ensure accessibility considerations when UI changes occur.

## Reporting format

Return a short report with:
- **Verified**: What you confirmed and how (tests run, files reviewed)
- **Risks**: Possible issues or unverified assumptions
- **Recommended tests**: Specific test commands or suites to run

## Constraints

- Be explicit about what you did not verify.
- Do not claim tests passed unless you ran them.

Clear communication starts from clear thinking. Clear communication is memorable and self-explanatory. It creates focus on the most critical topics and leaves room for interpretation on topics with ambiguity.

The best leaders of any discipline are noticed by their clear communication and decisions, which means two things: That they have developed a system to think clearly That the deliverables of thought are typically decisions and/or communication

So what does it mean to think clearly?

Thinking clearly means that you have a system for processing the available information in order to arrive at the best, or at least a good, outcome, consistently. A good outcome doesn’t mean that you always succeed, but rather that you have also prepared for failure. In failure you know how to course correct (and if it is still worth doing) and in success you have not just achieved a goal but solved the problem.

How do you think clearly?

Everyone’s process will be different and situational. But of course, I will operate from the perspective of a business that develops software for this example.

1. Establish the fundamental truths of your environment

You can’t have one hundred of these, they must be memorable and easy to gut-check against, probably 3-5 is right.

A business that develops software must:

• Produce value for its users that is commensurate but ideally much higher, to its cost
• Treat its software as a living organism.
• Software that is not fed and maintained, dies.
• Software that does not grow and adapt to its changing environment, dies.
• Software that does not plan for industry seasonality, dies.
• Plan for unknowns.
• Software is research and development. It carries both quantifiable and unquantifiable risk.
• Software is experimentation, it is not always steady and incremental progress. It is often failure after failure after failure, and eventually exponential success.

2. Establish what you know

You will never have enough information on any decision, in fact clear thinking is needed the most when you have the least amount of information. But here are a few questions that you can consider:

• What is the impact and scope of this?
• What are the risks of getting it wrong?
• What is the historical or entrenched context to consider?
• Who cares about this?
• Why is this coming up now?
• What happens in failure? Is this easily reversed?

3. Establish what you DON’T know

The most important thing about this list is deciding if you can find answers to things you don’t know and then, is it worth pursuing the effort of obtaining those answers.

• Do I need to better understand user behavior?
• Do I have telemetry/metrics on this topic?
• Do we need to better clarify options through discussion?

4. Read the room

This step may be considered optional but I think this is often the “secret sauce” for people with reputations for decision-making competency.

• When you talk about this topic with people are they excited, anxious or frustrated?
• Is the hard part of this problem Product, Design, Technical or Political?
• Is someone not voicing their opinion because it is too controversial?
• Is there urgency here and is it real or fabricated?

5. Decide Clearly

By this point you are probably leaning towards a certain direction and if you have done all of the previous steps then you are well on your way to a well thought out deliverable. Here’s a few questions to ask yourself:

• Does this make sense within the boundaries of your fundamental truths?
• Have you teased out all the spoken and unspoken implications?
• If this fails do you know what you would do next?
• Do you have a good sense of how people will react to your next steps?

If you have good answers by this point in time, congratulations you are about as confident as anyone can be in this situation! Also, sometimes the answer is: we don’t know enough to act on this or it’s too risky. We need to test alternatives or wait for new information.

6. Communicate Clearly

Now it’s time to synthesize all of this information. How much this needs to be communicated and to whom will vary widely. You might just need to write one sentence in Slack, you may need to prepare a presentation to your entire department or company. You may need to tailor your communication to engineers or executives.

In every case remember, communication must be simple, it must be memorable, and it must give focus to the important thing.

7. Listen to feedback

You have now communicated a clearly thought out plan or decision. Now it’s time to look for reactions, new information, things that could impact a previous step in your thought process. Did someone react strangely to your communication? Maybe they know something that you missed. It’s time to follow up and adapt, you will likely be iterating steps 2, 3, and 4 for sufficiently complex problems.

But look at that, people are starting to ask you to help them think clearly.

There’s a lot of advice out there on the internet for the entry-level positions in software engineering. Do you want to know how to be a good Senior Engineer? Solve lots of problems, ideally with a growing sense of technical, product, social and corporate complexity.

If you want to learn how to make the leap from Senior Engineering Manager to Director, the answer is similar but with less tangible output and outcomes to latch on to. All I can do is speak from my own experience but here is how I think about the broad categories of leadership on the manage-y side of the career ladder.

For managers and senior managers:

You deal with the day-to-day execution and performance of your team. You unblock the team, clarify goals, set expectations and communicate to the broader ecosystem what you are doing.

For directors and senior directors:

You are still, primarily focused on execution but the great ones are frequently learning and applying themselves to the grand endeavor of contributing to “strategy”. Not only are you responsible for doing things but you are also responsible that those things are the right things and that they generally align to the vision, mission and strategy of your company and area.

For vice presidents (and up, let’s not separate out the C-suite today):

Congratulations, you are in charge of the soul-crushing, anxiety-inducing responsibility of setting the direction and strategy. Yes, you will help with execution and you will frequently have to jump in to the messiest situations to support your directors and managers. But your primary job is to look at the vastness of time and space, the wavering and unending distance of the Sahara desert, the dense and inscrutible markings of the slightest path through the Amazon and point your finger and say, “That way”.

The Director Function

Today however, we step back from the abyss and we look at what it is that you will do (or perhaps currently attempt) as a Director of Engineering. In my own history, I have spent years in the nebulous “Head of Engineering” role at a few small startups and I have also spent time in a specific “Director of Engineering” role. While I have been in board rooms, “senior leadership” offsites, and managed everything from a team of four to the entire engineering vision, the Director position is the one that I have inhabited the most thoroughly.

So let’s break the Director role down into categories of work. Depending on the company, team size, culture, and a hundred other variables, each Director position is going to be somewhat unique and the time and effort in each of these categories will swing wildly between roles and even as circumstances change in the same role. People, Product, Process, Public and Tech, these are the five categories of work that you will see on your docket each and every day when you are trying to sort through all of your todo lists.

People

As a Director of Engineering, your bread and butter is still managing people. You are coaching and training managers underneath you on how, in turn, to coach and train their teams. You are challenging people directly when you foresee a performance problem or you are giving that extra support to a manager who needs to have a difficult conversation.

One of the biggest differences for people management now, in comparison to a Senior Manager, is that you will need to be able to clearly articulate how you think about managing people. When do you promote, when do you fire, how do you exert the appropriate amount of pressure into the system and when do you give someone or a team some space to sort things out on their own. You can do this sort of work by instinct as a Senior Manager, and if you are a manager with relatively high emotional intelligence, there is a good chance that this sort of work comes natural to you. It may even be difficult to explain your actions to someone new to management because you just do what is instinctually correct.

In an effort to hone these instincts into a proactive management philosophy here are some things that you can try:

• Expand your sphere of influence for people management and be seen as a leader in this space for the company.
  • Present to your team your approach for career development
  • Mentor a more junior manager with a difficult team member
• Participate in any HR-related management committees
  • This could be, helping to write or update the company’s career ladder documentation
• Plan a book club for your team on a career-related book
  • I recommend starting with “Staff Engineer: Leadership beyond the management track” by Will Larson.
• Get your own leadership coach
  • Everyone needs help and if you are struggling with making time for some of this work then find someone who can keep you on track.

Product

The greatest Directors have an uncanny sense of what is right for their product. Not only in the same broad, strategic sense that a VP would have, but in the day-to-day minutiae of building software. Product Managers work best with a strong Engineering counterpart that can help make tough trade-offs between the effort involved and the ultimate impact to the customer.

I don’t believe that “some people just have it” when it comes to product-sense but rather our gut feel and intuition is built on top of a strong and constant exposure to the problem and surrounding market conditions. You have to be right most of the time when influencing Product direction and you have to be confident. The toughest and most critical decisions also tend to attract the largest peanut gallery of people, all of whom are willing to poke holes in your plan but very few are willing to propose their own. To be great at this you have to be confident and resolved, while simultaneously listening to your team, peers and leaders to adjust and flex as needed.

If you don’t feel like you could swap into the PM role for a period of time then here are some things to try:

• First and most obviously, use your own product
  • Build something real with it, try and use it like a customer truly would
• Do your own competitive analysis
  • Hone your product sensibilities in relation to your company’s business model
  • The best way to know you are right and have confidence is to spend time doing competitive analysis
• Talk to Product leaders in other parts of the organization
• Make your own proposals for specific features and show them to your PM team
  • Ask for critiques, often PMs will be happy to see an engineering leader willing to put skin in the PM game
• Join customer calls every so often, especially ones that are escalated

Process

Everyone hates process. Good process is good because you won’t be able to tell that any process has happened at all. Also, it is your job to grow and scale processes so that your teams can grow and scale in turn. If you are a Senior Manager then you likely have established a few processes that work well for your team, now it’s time to apply these processes more broadly. This is a good way to learn how to influence outside of the culture of your own team. Maybe your processes don’t work well for other teams, is there a way to adapt the process to be more inclusive of other perspectives? How flexible can you make the process without losing the core value it provides?

Pick a few places to expand on what processes work well for your team and find ways to apply them more broadly:

• Create/own SLOs for bugs, flaky tests, tech debt
• Run a department-wide team meeting
• Improve common processes for collaborating with the Support team
• Investigate pain points in existing department-wide process
• Take on a leadership task that goes beyond your own scope
  • Perhaps this is improving documentation
  • Clean up the backlog
  • Document “unwritten” policies

Public

How much you participate as a public leader in the broader industry is completely up to you but it is a way to grow leadership presence. One of my own weaknesses and a common one for many, is practicing presentation skills. Speaking in front of your own team is one thing, but presenting to hundreds or thousands of people requires effort, timing, charisma and planning.

There are plenty of leaders with rough edges in this space but a great way to distinguish yourself is finding your own voice and style for broad communication. I sometimes joke that being a leader is at least 20% having an “entertainment factor”, if you can make an hour long status update (is this a meeting that should be an email?) fun and exciting, or at least interesting, your team will love you for it.

Here are some easy places to start:

• Contribute to or write a blog post either on your own blog or ideally for your company
• Present at a local meetup group
• Take a current meeting and spice it up…
  • Add some memes, tell a story don’t just rattle off things from a list

Tech

Finally, unironically last on the list, you should feel comfortable contributing to technical decisions. This is an important aspect of the job but also the area where you have the least expertise, there are plenty of people on the team who can own technical contributions. Your primary job here is to ask questions and watch for over-engineered solutions. Remember, the technical solution must match the customer impact in effort.

You should have an ROI (return on investment) calculator in your head and if an engineer starts describing a multi-week/month solution to a low impact problem it is your responsibility to pull the team away from sunken-cost fallacy and find another way or shut it down. This can be a gut-wrenching, painful experience at times. Once you give an engineer a problem and they become invested it is so hard to turn it back off. You have to show the team that it is not worth solving with the current constraints. Ultimately, you should have some strong Tech lead partners in this category but you are still responsible for poor technical decisions.

If you feel like you have lost your coding mojo:

• Gain expertise in the codebase by writing a test, fixing a bug, or writing documentation
• Understand the infrastructure model for your major services
  • What technologies do they use, how are they setup from an infra/devops perspective
  • What are the potential scaling and performance challenges
• Learn about the system your team uses for tracking performance and health in your services, become an expert on this data and what we can learn from it

Just do all the things…

That’s it, surely you can tackle all five of these categories all the time, everyday on top of the regular fires, mayhem and chaos that you get to deal with. Unsarcastically, this is a lot to keep in your brain. Don’t feel pressure to be hitting it out of the park on every topic, every leader will naturally gravitate to a subset of skills within these major areas. That’s what makes you, you.

One solution that my team has discovered is video games, and in this case specifically, Overcooked 2 on the Nintendo Switch. For deeper thoughts on how to socialize from home, see my companion article, this article will focus on the nuts and bolts of getting your computer setup.

What you will need:

1. Nintendo Switch (Not the Switch Lite)
2. Nintendo Dock (I prefer this after-market one)
3. Mirabox HDMI Capture Card
4. OBS Studio
5. Zoom

Setup Capture Card

The Mirabox Capture Card is a bit of an investment at $99.99 but it is still on the low-end for these devices and roughly half the cost of the more premium Elgato Capture Cards. I’m not looking to be a professional Twitch streamer so the Mirabox suits my needs just fine.

The hardware setup is pretty straightforward. Your Nintendo Dock HDMI plugs directly into the Mirabox, which then plugs into your computer via USB 3.0. I would also recommend using the HDMI loopout to forward the signal to a spare computer monitor. Trying to play directly from the Zoom stream will prove to be too laggy to be useful.

Just a note, I had difficulty getting the Mirabox to register properly when attaching it through a USB dock so I ended up connecting it directly to my Macbook.

Setup OBS Studio

So after you download and install OBS Studio, you should be able to open it and add your Mirabox as input.

Once you have OBS open, click the “+” sign under “Sources” and select “Video Capture Device”.

Next, give the device a name and then select “Mirabox Video Capture” from the dropdown menu.

Now you should see a stream from your Nintendo inside of OBS.

You can repeat this same process for audio by adding an “Audio Input Capture” device as well to bring in sound from the Nintendo. I found this process to be a bit finicky so I did have to do some googling and adjust some Mac settings the first time.

Ok, the last thing we need to do is view a Window preview of the screen so that we can screenshare just the Nintendo viz Zoom and not all of the OBS options and chrome.

Right-click on the preview and select “Windowed Projector (Source)”.

This will give us a new window with just the video capture screen.

Setup Zoom

Now that we have done all the tricky bits, setting up the Zoom call should be pretty familiar.

First, start a meeting.

In my case I like to run the meeting from my work laptop and add my personal laptop to run the game screen share.

Now, share your screen in Zoom and select the Windows Project screen to share and make sure to hit the check mark to “Share computer sound”.

Now you should be looking at a stream of your Nintendo Switch!

That’s it! From my experience sharing the screen is useful as we usually have a few people playing and a few more spectating and rotating out taking turns. Plus, for Overcooked specifically, half the fun is yelling instructions at team members through the chaos as everyone learns how to work together. Now if that isn’t team building, I don’t know what is.

When you work for a remote, fully distributed company, this becomes something to actively solve. One way to partially solve this problem is to do what many distributed companies do. Invest heavily in one or two big events a year where everyone travels to the same city, alternates between drinking caffeine and booze and spends every waking hour together for a week. I’m not knocking this by the way, this is great, it’s fun and everyone holds on to those crazy fun moments for six months or a year until the next one.

But now what do we do? Covid-19 has pushed everyone to be a remote company and, simultaneously, prevented everyone from this one proven solution to connect with each other.

Even without travel disappearing overnight, teams function better when us humans know and care about each other personally (spoken from a true introvert). The answer is to treat these social events as part of work.

In a co-located company you do these things because it’s almost impossible not to. You go to get a drink, there’s a person, you have to eat lunch, so does everyone, you need to decompress a bit, there’s a bar with a great happy hour a block away. In this environment, it’s easy to view these things as almost, in the way of the actual work, and they can be if that is all you do.

In a distributed company everything veers sharply the other direction. You can code, or write emails or documents, plan things in spreadsheets and an entire day goes by the next time you come up for air. It’s absolutely wonderful for doing individual work (once you teach yourself how to be disciplined in your home).

But, in this environment, the system can also be less than the sum of its parts. If everyone is moving in their own individual direction, you lose that extra magic that is capable of moving mountains. Instead, everyone is just running around pushing their own mole hills and ignoring the bigger picture.

Now, you can invent processes and meetings and check-ins. You can do scrum and hire black-belt project managers who know how to burndown chart and write JIRA tickets and email. This would work in an emotionless void and the trains would run on time.

Or, you can play video games.

The real solution here is a vast array of tiny things. You can do random Slack coffee chats (for extroverts), morning team coffee, afternoon team tea (for the Brits), the trick is to do two things. One, do things that expose people to others outside of their immediate area. Two, do things as a team, with the people you work with every day.

The second one is where video games come in. If you are already meeting as a team once a week or every other week set aside half an hour as a social call. This is a step in the right direction. If you find it hard to force a social chat on the team, playing a game is a great way to get things moving.

In my case, the entire team shares video games as a hobby but there are also games with a very low barrier to entry.

Here are some ideas.

1. Drawful 2

Right now Drawful 2 is free on most platforms to help keep people sane while we shelter-in-place. It also only requires one person to have the game and everyone else can join via a phone or tablet. I recommend getting it on Steam, it should run on a standard Macbook, that will make it easy to stream the game over Zoom while everyone follows along on their phone.

2. Jackbox Party Pack

Jackbox makes a ton of low barrier-to-entry games like trivia games and other party games that can all be played with a phone.

3. Overcooked 2

This is veering heavier into gaming territory but Overcooked is just a great experience trying to work together as a team. If you have a Nintendo Switch and want to give this a try, check out my article on how to get setup to stream on Zoom. The downside here is the game maxes out at 4 players, but there is still opportunity to yell at your teammates from the peanut gallery for any spectators.

4. Mario Kart

Since you’ve got your Switch setup to stream, Mario Kart is a great game to try a company or team tournament. Remember those dart or ping pong table tournaments you would have in the office? This is the remote version of that. This can get expensive, as every participant has to purchase a copy of the game. For the non-gamers something like a tournament is still an opportunity to tune into something social and cheer on your teammates.

There are a ton of other games that would work in this way, many on your phone with low overhead. We have just started scratching the surface of how to embed this into work. Right now, as a team, for whomever wants to participate, we try and set aside an hour once or twice a month to play a new game and catch up with each other.

Now that we’ve been doing it for a few months, I’ve noticed that everyone genuinely looks forward to these times together and hopefully we are all learning a little bit more about the humans that we work with everyday.

Hiring Senior Engineers

The first time I was tasked with expanding a team I spent a lot of time interviewing senior-level candidates and I learned a few things:

1. The really excellent Senior Engineers rarely fall into your lap, you have to work at it, have a network, and be willing to circle back with people sometimes for years until the timing can work out.
2. Attitude is everything. A Senior Engineer who already knows everything and is considering blessing you with his/her employment is probably not actually a Senior Engineer. The great ones have a growth mindset and are always looking for a new challenge.
3. Do you actually have a challenging problem to solve? Sometimes the work is a grind and a grind is more suited to junior/mid-level engineers who can cut their teeth on something and still get some personal growth out of it.

So hire based on the problems you expect to solve over the next 6-12 months. Justify your hiring plan against the expected work, at least quarterly. This will help optimize the work for potentially more junior and mid-level hires. Turns out, after attempting to only hire Senior Engineers I realized that there just aren’t that many Senior Engineers out there in this hyper-competitive landscape that also match my own team and culture expectations.

The biggest thing I’ve learned and incorporated as part of my “secret-sauce” to hiring is to structure interviews around hiring for growth trajectory. Finding the right Junior or Mid-level Engineer with aspirations, work ethic and ambition has consistently blown me away. It is our job after all, to not only hire people that can help us but to take a chance on those early in their career who just need someone to give them a shot. Especially when considering diversity and inclusive goals, there are many more opportunities with people at a slightly earlier stage in their career that are willing to put in the work.

Hiring Junior/Mid-level Engineers

Finding the right person is still very hard, attempting to measure someone with a high growth trajectory in a short interview means that you will get it wrong a few times. Also, expect 10x the resumes to sift through.

A few things to look for:

1. I like to find people who maybe had a different, previous career, maybe they ran their own business or had a startup briefly. While these people may be junior in skill level, they bring a mature perspective to the job and know what it takes to get something done.
2. In general, people who have had to push through some hard extenuating circumstance are on high growth trajectories, maybe they worked their way through college or contribute to open source in some fashion.
3. People who have a real appreciation for the opportunity and bring some humility to the table are diamonds in the rough because they know how ultimately spoiled we are in tech and know what it’s like to work outside of our industry.

My hope, as a manager, is that people remember me as a supportive foothold as they climb on to bigger and better things. I still wake up feeling grateful for those that took a chance on me all those years ago when I took a pay cut to go from Retail Management to Entry-level Software Developer. The best job in the world is to send the ladder back on down and then help equip and coach others to achieve their goals. Chances are, if I’m doing a great job at this, then the people working together on the team just might make a dent in the universe.

As it turns out, I’m hiring at Elastic. If you see a role that’s interesting and want to chat about it hit me up on twitter or send me an email.

1. Communicate Simply Based on your Audience

You will need to spend most of your time interacting with other cross-functional leaders, practice describing engineering problems as simply as possible with the direct business effects baked into the conversation. “We need to move our data queue over to AWS because it is currently super expensive and insecure.”

2. Say No

Saying no doesn’t feel great but it’s what everyone expects from you, at least in my experience Engineering tends to be the first leader to think through every critical detail of a project and explain what’s hard or things we shouldn’t do. Say no to your boss, your peers, your team, to projects and distractions, to suggested promotions and firings, say no. Say yes to whatever is best for the business.

3. Repeat Important Things

In every Engineering meeting you run, remind yourself that your team is only going to take away one sentence from everything you say. Make sure it’s the right sentence. Repeat everything that’s important constantly. Learning how to ensure the correct take away is hard and requires iteration. Ask people in 1x1s what they took away from an important meeting, it will surprise you.

4. Your Job is More Product than You Think

Engineers and Product can sometimes have a hard time getting along, it’s built in to the incentivization structure. Product will want to ship and everything would be better if it was done yesterday. Maybe it’s unfair to pin this on product, think about how much better the business would be if everything was magically done yesterday. It’s your job to help them understand the trade-offs. People will be upset if you miss a deadline, they will be more upset if you release something shitty.

Treat Product Managers like members of your engineering team and sometimes that means sitting them down to have a hard discussion. Always let your Product counterpart (Director of Product) know you did this, but don’t wait for that person to do it for you. Your miles may vary on this one, the right way to approach it depends on your relationship with your peer but at the end of the day, don’t let a situation fester because you are waiting for someone else to deal with it. One Product person can destroy a whole team of engineers.

5. You are the Boss

Everything you say will be scrutinized for secret meaning so try not to make glib or overly dire remarks. You are also the man, the face of leadership and unpopular decisions. You will be frustrated with your peers or boss or decisions but your team can’t see this. Treating your direct reports like peers or friends that you can bitch to is the quickest way to dysfunction. You have to be honest without undermining your boss or company. This is hard.

6. Don’t Protect People

Or, strategically don’t protect people on your team who are ready to handle it. Your most senior engineers and managers should be able to sub in at the leadership table for you. There are others on the team who can’t affect things and will just have anxiety if they know everything you do about something, they don’t need to know. You job is not to be a shit umbrella but rather to prepare people to handle shit.

7. Code is Low Impact

You don’t have time to code on mission critical things anymore, it’s tough to let go. If you have 2 hours and you think you want to code, first make sure your todo list is done and that you have tracked down any gut feelings about things that you feel may be headed off track. These will keep your team way more effective than a bug fix you hack together. Yes, figure out ways to stay sharp and technical as much as possible, but congratulations you are in management, coding skills will atrophy.

8. Be Honest

As long as you keep being honest with your team they will be surprisingly resilient to everything that you throw at them. This means, be vulnerable when you are anxious or don’t understand, be candid and tough with someone who needs it, be caring and kind with someone who needs it, and be yourself, nobody else will lead exactly how you do.

When do you use it?

An important distinction to make right off the bat is that different situations require us to use different mental models, in fact I would argue that we value the wisdom obtained from experience not because it gives us the answers, but because it gives us new frameworks or modalities to use when solving problems.

Outcome-oriented thinking is best used when we are trying to achieve something experimental by design, something that will require flexibility and failure along the way.

Examples include: inventing the light bulb, finding product/market fit, teaching/learning a new subject, etc…

When do you NOT use it?

In contrast, a common mental model that serves as an antithesis to outcome-oriented thinking is process-oriented thinking. Process-oriented thinking is the ability to focus on discipline and incremental progress instead of the outcome. This is a good way to think when attempting an outcome that has a well-understood path to success.

Examples include: training for a marathon, losing weight, saving money, etc…

</figure>

Because we work on teams, with other humans, it’s not as simple as setting a goal and saying “Go!”

First let’s start with a different example.

</figure>

In 1943 Abraham Maslow released his initial work describing humanity’s hierarchy of needs.

</figure>

The idea is that humans have different, cumulative levels of needs in order to achieve happiness based on their current position in life. Once we have acquired a certain level of happiness we immediately focus on the next one until we achieve “self-actualization” or our full potential in life.

It would be difficult to focus on our psychological needs while lacking some basic needs like food, water and shelter. It would also be difficult to focus on our full potential while lacking a sense of belonging, personal relationships and feelings of accomplishment.

If the outcome we aim for is happiness, as described by achieving our full potential, we first have to establish the lower levels in the hierarchy of needs.

Similarly, if we are attempting to achieve an outcome, as a team, with the full flexibility, failure and trust of outcome-oriented thinking, then we first have to establish a hierarchy of trust and accountability.

Outcomes as Teams

</figure>

How do we do it?

Transparency

</figure>

The base of our pyramid is transparency. Transparency means that we are communicating our failures and roadblocks. Everyone understands that the outcome may require fits and starts of experimentation, there is a healthy, blameless dialogue of what is going well and what isn’t. The team is learning together and has trust that everyone is making intelligent decisions in an attempt to reach the outcome. We are asking ourselves, “how can we deliver value along the way?”

Output

</figure>

Output is the middle layer of the pyramid. Output is the work that we are producing on a daily basis. We are working hard, with a sense of urgency, but we also know our own limits and when we need a step-function increase in results we stop and think about how we can work smarter instead of even harder. Heroics, while sometimes necessary, are a negative influence to a sustainable, repeatable process. Most importantly, output without learning and without achieving the outcome means nothing.

Table-stakes

Transparency and Output are both table-stakes to outcome-oriented thinking as a team. They have to be there but they are not the level to optimize against for accountability. In order to produce outcomes as a team we need trust and accountability, because transparency and output are table-stakes we default to trust that our team is being transparent and producing output and we leverage accountability at the outcome level.

Outcomes

</figure>

Because we are holding ourselves accountable to producing the outcome, we ask ourselves every day, “Does this matter?” instead of wasting time completing work that is no longer valuable.

We break down the final outcome into milestones that we communicate and deliver, which shortens the time between each hypothesis and expected value, instead of leaving stakeholders anxiously awaiting a binary result from months of work.

We push ourselves as a team to ruthlessly prioritize what’s important and to accept failure along the way, instead of politicizing and pointing fingers at the first sign of trouble.

We debate each other to arrive at the best solution, instead of becoming attached to our favorite ideas.

We succeed together, so we help each other, instead of focusing on showing off our own individual effort.

We succeed together.

The benefits to having a remote-friendly environment are many and worthy of their own article, but the primary ones include:

• Talent is not limited by geography, opportunity historically has been
  • Or rather, access to hiring the best and brightest means looking beyond your home city
• The data on Employee satisfaction and work/life integration is available and positive
• If you have one remote employee, congrats, you have a remote company
  • Otherwise you have a second-class citizen employee who likely won’t last long
• Need to run 24/7 support or on-call shifts? Turns out timezones can help with this
• Productivity increases!

Ok, so how?

If you are a brand new company, it will be much easier for you to start with a remote-friendly culture, but for the rest of us, completely changing the office dynamics is a bumpy road. At Cratejoy, we decided to switch to a remote-friendly environment about 3 months ago, so we are still relatively new to it but here is what we have learned.

First, “remote-friendly” needs to be defined. We already generally had people working from home if they needed to occasionally. A trip to the doctor, an electrician, or car repair would be enough to sign in from home for the day with little issue. However, this doesn’t create real “remote” issues. Previously, we would move meetings, catch people up later, skip meetings, and generally make important decisions whenever said person was back in the office. You can’t do these things if people only come to the office twice a year.

So, when we said “remote-friendly” we meant some version of: on any given day we don’t care where you are physically, we should be able to accomplish all of the same things (if not more) than we would in the office.

Advice.

As the volunteer leader to make this happen, one of the first things I did was find as many people to talk to that had made a similar transition. The number of companies embracing remote work is only increasing and I found quite a few companies that were 6 to 12 months ahead of us in the process.

The best advice I heard over and over again was:

“It has to be the whole company, including the leadership team.”

and

“You don’t have to go full remote all at once.”

It has to be the whole company, including the leadership team because ambitious and smart people at the company will emulate what they see successful leaders doing. So if you want to drive real adoption, you have to do it too. But more importantly, everyone has to feel the pain. When we started, our conference rooms didn’t have real video conference equipment, so we dragged laptops in and set them on the table. We thought we were fine because we would ask remote people, can you hear us? Sure, they’d say because they don’t want to be a bother. When you are that remote person you realize that you are only going to hear about 60% of the conversation and your ability to contribute drops to basically zero.

You don’t have to go full remote all at once because, well, you have an office space probably and like every other change, this one is going to require some adjustments. It’s a good insurance plan to still have some time where you can clear up communication issues, reset expectations and check in in real life.

Step One.

Ok, so you have your advice, your reasons to do it, and your grit all ready to go. What’s first? The other important advice I got was to be ready to upset some people. This surprised me a bit because I thought I was about to announce a huge perk for everyone, and while that was true for a majority of people, there were people who liked the office and seeing people and other generally extroverted things.

Do an experiment.

Pick a small amount of time and announce that you are going to do an experiment for said amount of time where people can choose to work remotely or from the office. Then, empower your teams to come up with a few things:

1. We need a clear way for how we are going to track progress and communicate about our goals.
   1. You probably were doing this to some degree already but now you need to communicate, online, asynchronously and pay attention more closely to not just goals but productivity as well (measure output as well as outcomes, this is a post for a different day)
2. Schedules, in our case we decided Mondays would be a full-company onsite day and teams could choose to be onsite additional days if they wanted to.
3. What does success look like? How do we know if we should keep doing this or not?
4. Don’t start the experiment too soon after announcing to the team, they will need time to adjust: talk to their families, figure out their home office, etc.

My Mistakes.

At least the above is what I would have done for my first experiment. I ran an experiment before getting advice and here is how I messed it up.

1. I started with just the Engineering department, that is my department why not start with it?
   1. Every other department immediately reacted, as they should, wondering why and how they could be involved.
2. I announced it on Monday, we started it on Thursday.
   1. This was not enough time for people to acclimate.
3. I forced everyone to stay away from the office, I leaned too hard into “feeling the pain” and didn’t think about the people who may have a tiny downtown 1-bedroom apartment and hate it.

Despite these mistakes, it was a resounding success. At the beginning, our primary concern was if working remotely could actually be as productive as being in the office. How do you know what people are doing? What keeps them from goofing off the whole time?

One of the tools I use to measure Engineering velocity is GitPrime, I highly recommend it as an Engineering leader as a quick gut check for how things are going. Here is the velocity chart I showed the rest of leadership after this experiment.

We had a hackathon the week before the experiment so that primed the productivity of the team as well.

Step Two.

Do another experiment.

After a few weeks back in the office, we did another experiment and this time I got it right. The whole company went remote, but we all showed up to the office on Mondays and people could choose where they work otherwise. This second experiment was scheduled to run a month but after a month, it was the new normal and so we extended it through the end of the year for now.

During this time, I ran weekly company health surveys to ask for feedback. Were there communication issues? Are you happy? Do you feel like you know what’s going on? I also worked with the rest of the leadership team to release a company-wide report on productivity of each department and if we are achieving our goals. This helps everyone feel like they know what their virtual neighbors are up to and that everyone is still working hard to make the company successful.

Some Cool Things.

As part of the survey I also asked if anyone had an opportunity to do something new or fun because of working remote and a few patterns started to emerge.

• People eat better and exercise more.
• They fit appointments and errands into their day to minimize time away.
• They go on lunch dates with their spouse (kid-free).
• They feel more rested in the evening, so they go out and be social during the week.
• They stop yelling at traffic every day.
• Some of them have a hard time turning off work, it’s too easy to work constantly.
• They are more satisfied and in control of their day.

Like I said, we are new at this and there are going to be new classes of problems to solve as we get further into it. But so far, there’s a lot to be gained by working more flexibly.