{"slug": "3-things-top-1-teams-do-differently", "title": "3 things top 1% teams do differently", "summary": "Andrew Churchill, CTO of Weave, says top 1% engineering teams focus on constantly improving their hiring process, learning effective parallelization, and adapting code review flow. Churchill notes that hiring is the single most important task, with work trials offered to top candidates but offers made to only 60% of them, and that engineers should experiment with parallel tasks to find their optimal number between 1 and 10.", "body_md": "*I've been talking with Andrew for the past year and learned a lot from those conversations, so I asked him to go deeper on a few of them here. *[Weave](https://weaveos.com/?utm_source=manager-dot-dev&utm_campaign=top-1-percent-teams&utm_term=top)* is a long-time partner and sponsor of **manager.dev**, and we also use it at my full-time EM job. *\n\nFor the last 20 years, it was clear what ‘good software engineering’ looked like: you are obviously using git, you’re doing small PRs, fast reviews, CI, CD with at least daily deployments.\n\nToday, that playbook is not enough. Even if you are an AI-skeptic, you can’t ignore that software engineering is changing. There are lots of takes on LinkedIn and X on what the best new practices look like, but nobody actually knows (and will probably not know for at least a few years).\n\nThe most effective way I found to learn for myself is to dive deeper into what works for other engineering teams, beyond the surface level hype.\n\nToday’s article is a guest post with [Andrew Churchill](https://www.linkedin.com/in/andrew-d-churchill/), CTO of [Weave](https://weaveos.com/?utm_source=manager-dot-dev&utm_campaign=top-1-percent-teams&utm_term=top). Their goal is to help engineering teams optimize their SDLC.\n\nWe are going to cover **the 3 things he believes every engineering team must focus on today: **\n\nA constantly-improving hiring process\n\nLearning how to do parallelization effectively\n\nAdapting your code review flow\n\nThose are based both on his own experience and on observing the most productive teams using Weave.\n\nMic to Andrew! 🎤\n\n### Constantly improving your hiring process\n\nFor me, as a CTO, hiring is the single most important thing. When you hire the right engineers, in addition to the huge benefit to the company, there is also much less management work.\n\nIn most companies, the hiring process and interview questions are **updated at most every couple of years**, which means you ignore many important signals that happen during every interview.\n\nHere’s how we try to solve it:\n\nFor every ‘failure’, we try to think about how we could have caught this at an earlier stage. The earlier you catch somebody who’s going to fail, the more efficient your system is. For example, we learned that we have to understand why the candidate wants to work at an early stage startup as early as possible, and make sure they are fully aware of the tradeoffs. There are a lot of things that are worse about working at a startup than working at a cushy big company.\n\nAnother takeaway was that we need to get a better understanding of what people can practically accomplish, not just how they can do on ‘simulated’ context or in a conversation, so we started doing work trials (3-5 days, fully paid, including flights and hotels).\n\nWhen we offer a work trial, we are very very sure about that candidate. It means they passed every bar that a typical hiring process has. Still, we made an offer only to 60% of them. Every time we don’t make an offer, we try to understand what we could have done better in earlier stages.\n\n### Learning how to do parallelization effectively\n\nWith coding agents, switching your attention between 4-5 different sessions is actually a very viable workflow (and a very different one from how we used to work).\n\nEvery one of our early engineers is typically working on one main thread, where they put most of the focus, and 3-4 ‘sub-threads’, which are smaller improvements requiring less attention. For new engineers that join, their **biggest unlock is figuring out how to adopt a parallelization strategy that works for them. **\n\nWhat I suggest they do:\n\nPush it to the extreme and then figure out what does and doesn't work and then find the equilibrium. For example, see what happens when you work on 10 tasks at once. It's probably going to be crazy, and it's going to be really hard to maintain the context. But somewhere between 1 and 10 parallel tasks, there's a place that does work for you, where you can still focus on your main task while other things are going on in the background.\n\nWhen engineers say 1 (or even 2) sessions are their limit, it’s usually either:\n\nEach session requires your attention very frequently, causing too many switches\n\nOr the coding agent goes in wrong directions, requiring a lot of effort and babysitting to steer it\n\nIn both cases, it’s about the context. **Most ineffective AI usage is just ineffective context management. **\n\nImagine you have a very smart intern join your team today. How would you onboard them so they could start working effectively immediately? You need to somehow distill everything they need to know:\n\nThe company direction\n\nThe product perspective\n\nCoding standard and style\n\nThe things to avoid\n\nThe things to follow and why they are important\n\nMost companies choose one of the extremes:\n\nbarely any info, letting them figure things out by doing. They give you a messy PR, you comment, and they slowly learn.\n\nA 4-week onboarding, with recorded sessions, onboarding tasks, and so on.\n\nNow imagine every new LLM session is a fresh intern. In the first scenario, you’ll of course get shitty results. But in the second scenario too, you’ll also feed it lots of useless information that will hurt the results. So when the LLM provides bad results, the highest ROI thing you can do is to stop and improve the guardrails and guidance it received, so that it won’t happen again in the future.\n\nWe are very lucky in that regard, as one of the main points of our product is to help engineers figure that out - so everyone has the mandate to spend the time reviewing their own [AI usage metrics](https://weaveos.com/product-pages/ai-insights?utm_source=manager-dot-dev&utm_campaign=top-1-percent-teams&utm_term=mid), and check where things are working well, and where they can improve. The next level we are working toward is a system that does it more effectively, self-correcting itself over time. It’s a tough challenge!\n\nGoing back to parallelization - now is the time to start figuring that out. It’s difficult, but if you have at least solid context infrastructure, it’s totally possible.\n\n### Adapting your code reviews flow\n\nThe biggest mistake I see remains requiring human review on every single PR.\n\nThe 2022 Andrew would tell you “of course you have to review every single PR, it’s insane to suggest otherwise”. But the 2026 Andrew has realized that as long as you have the right guardrails in place, not reviewing every PR will unlock a whole new level of speed that's just impossible otherwise.\n\nHear me out.\n\nThere are 3 main benefits to a code review:\n\n**Coding standards**. Is this how we write code in our team?** Validation**. Is this doing what it's supposed to do? Are there any bugs here?** Direction.**This is the biggest value by far: whether the solution is even on the right path, or could be done completely differently.\n\n#1 and #2 are completely solved by AI code reviewers. We use three different ones: [Cursor Bugbot](https://cursor.com/bugbot), [Cubic](https://www.cubic.dev/) and [Greptile](https://www.greptile.com/). Each of them catches some stuff that the other ones don't, and as long as that is true, it is worth it to us to have 3 of them. If there is no meaningful comment from any AI bot, we can be pretty confident there are no obvious bugs in it.\n\nNow to the direction part.\n\nIf you think about it, **the best way to review it is not after the code is written - but during the planning phase.** It’s already common practice to have a plan for every feature an LLM implements, now it’s just about shifting the reviewing part to that earlier stage. If the plan is well written and agreed upon, there is a very low risk the implementation will follow a wrong direction. It’s also much easier to review 300 lines of markdown than it is to review 3,000 lines of code.\n\nOf course, even with everything said above - some PRs should still be reviewed by humans. If you are making some change to the server config, infra, or another sensitive part, you want to get a review from somebody who really understands that area.\n\nSo how do we combine it all together:\n\nFirst off, code reviews are optional. It’s the code author’s responsibility to request a review if they think they need it. Around 5% of PRs get reviewed by another engineer.\n\nPlan reviews are ~10x more common\n\nThe rest (around 40%) are not reviewed. They are either done by the person with the most context on them or are simple enough that they don’t require it.\n\nNext, we aim to solve our QA bottleneck. Currently, somebody still needs to test every PR in a non-production environment to see that it actually does what it's supposed to and doesn’t break anything. We hope to automate parts of that too. Reach out if you’re building something in this space!\n\n### How companies will adapt\n\nSo until now I’ve talked purely about my focus as an engineering leader, and the huge change software engineering is going through. Just as important is the change your company and product are going through.\n\nAnton wrote a couple of months ago that [Engineering Managers are going to hate OpenClaw](https://www.manager.dev/newsletter/engineering-managers-are-going-to-hate-openclaw). I see it as an inevitable change, where companies will need to climb the ladder to survive:\n\nUnderstanding\n\nSuggesting\n\nDoing\n\nThink about a product like Cursor. Before Cursor could ever come along, there needed to be an AI model that could understand code. That was LLMs. Then Cursor as a product started out by suggesting tab completions, and their initial smashing growth came just with good tab completions. And then as AI coding continued to evolve, it's gone from suggesting what to do to actually doing the work.\n\nI believe it’s a natural evolution process. You need to understand work first to even have a shot at making a good suggestion. And you have to be really good at making suggestions before you can start doing some of the work.\n\nUntil now, we were focused on understanding how engineering teams work, but we’re slowly climbing that ladder. For example, our [prompt router](https://weaverouter.com/?utm_source=manager-dot-dev&utm_campaign=top-1-percent-teams&utm_term=bottom) is a foray into that territory. We're not just saying, “Hey, we can tell that this model has been the most effective for your work”, we are actually routing work to that model for you automatically.\n\nMost companies will need to do a similar shift - instead of just thinking how to do the best UI so the users will be able to do things for themselves, also thinking about how you can effectively do relevant things for your customers.\n\nThanks Andrew!\n\nI’m currently in the early stages of improving each of those areas:\n\nWe are rethinking our interview process (which was the same for 5+ years)\n\nSome engineers on my team already figured out how to parallelize work effectively. I still haven't, and neither have most of my engineers, but we are getting there.\n\nWe stopped having mandatory code reviews, and I’m never going back to that\n\nIt’s definitely not a boring time to be an EM.\n\n### What I enjoyed reading this week\n\n[Attention credits](http://amitaycohen.substack.com/p/attention-credits). Every person you communicate with (or that visits your landing page) starts the interaction with a limited number of attention credits. A useful framework to think through.[Code Yellow, Code Red](https://theengineeringmanager.substack.com/p/code-yellow-code-red). What to do during engineering crises. Another great article by James Stanier.[What I'd Tell My Team About Competition](https://blog.staysaasy.com/p/what-id-tell-my-team-about-competition). A lot of people simply don’t understand the degree to which competition matters in B2B software, and what competing effectively feels like.", "url": "https://wpnews.pro/news/3-things-top-1-teams-do-differently", "canonical_source": "https://managerdotdev.beehiiv.com/p/3-things-top-1-teams-do-differently", "published_at": "2026-07-28 06:01:00+00:00", "updated_at": "2026-07-28 06:28:53.445536+00:00", "lang": "en", "topics": ["developer-tools"], "entities": ["Andrew Churchill", "Weave"], "alternates": {"html": "https://wpnews.pro/news/3-things-top-1-teams-do-differently", "markdown": "https://wpnews.pro/news/3-things-top-1-teams-do-differently.md", "text": "https://wpnews.pro/news/3-things-top-1-teams-do-differently.txt", "jsonld": "https://wpnews.pro/news/3-things-top-1-teams-do-differently.jsonld"}}