标签：#Leadership

The quiet mistake most new mentors make is assuming the person in front of them wants your life. It is an easy mistake, because your path is the one you understand best. You know where the shortcuts were. You know which turn cost you two years. Of course you want to hand that map over. But it is a map of your terrain, not theirs. I have watched good mentors accidentally push someone toward management because management worked for them, when the person across the table lit up talking about deep technical work and went flat every time the org chart came up. I have also watched the reverse. A mentor who loved staying hands on, telling someone who was clearly born to run a team that leadership is a trap. Both were generous. Both were giving real, hard won advice. Both were answering a question nobody asked. So ask first, and ask properly. Not what do you want to be in five years, which almost nobody can answer honestly. Ask what part of last month did you enjoy most. Ask which meeting you would keep if you could delete all the others. Ask what you would do on a Tuesday with nothing on the calendar. The answers tell you far more than a stated ambition, because ambitions are usually borrowed and preferences rarely are. Then hold your own story loosely. Tell it as one data point, not as the route. I did this and it worked for me, for these specific reasons, and here is why it might not apply to you. That last clause is the whole job. Your value is not that you know where they should go. You almost never do. Your value is that you have seen more of the landscape than they have, so you can describe what is over each hill and let them choose the climb. The measure of good mentoring is not that they end up like you. It is that they end up more like themselves, faster than they would have alone. – Asael Shinder

Part of AI Leadership in the Real World — how leaders turn scattered pilots into governed, adopted, measurable capability. TLDR: A support agent doing 50,000 chats a month needs ~3.5 FTE and $500k+/year just to stay accurate — while a typical 100-seat Copilot rollout sees only 20-30 seats used weekly. For SMBs, build-vs-buy isn't about features. It's about what you can afford to own for 24 months. We thought we were choosing a tool. We were really choosing a future dependency, a support queue, a governance burden, and a second bill that arrives a year later. Every vendor demo promised acceleration, control, and simplicity at once. Every internal proposal promised flexibility, ownership, and leverage. Nobody said both bills arrive late — one in engineering on-call, the other in consumption meters. Good platform decisions feel a little boring at first and very smart a year later. Why AI is special (and why old build-vs-buy math breaks) Traditional software mostly stays still when you leave it alone. AI doesn't: It drifts. Knowledge changes, customer language shifts, users ask harder questions once they trust it. Accuracy quietly drops from 90% to 70% with no error log. It speaks for you — legally. A wrong Confluence page is embarrassing. A wrong chatbot answer is a commitment a tribunal can enforce. It lives on someone else's deprecation clock. OpenAI gives at least 6 months before retiring a GA model. That's a hard deadline, not a backlog item. Prompts, evals, and output parsers all need rework. It multiplies cost per request. One human click = one action. One agent resolution = 6 lookups, drafts, updates, and logs — each potentially metered. It turns connectors into permanent work. Salesforce, SharePoint, Jira, Zendesk all change auth, rate limits, and APIs. Your agent keeps running while its knowledge goes stale. Gartner predicts 40%+ of agentic AI projects will be canceled by end of 2027 on cost, unclear value, and weak risk controls. McKinsey's State of AI 2025 (

Agentic Methods: Coding With AI Agents, Designing For Agents TL;DR "Agentic methods" covers two distinct things colliding right now: AI agents that code alongside the team (read, write, run, verify, in a loop), and agentic architectures we design into our own systems (orchestrating autonomous agents on the product side). In both cases, the same principle applies: an agent is only useful if the contract around it is explicit — scope, errors, permissions, stopping points. The Tech Lead role doesn't disappear, it shifts: fewer lines typed, more specification, review, and governance. The underlying topic isn't tooling, it's clarity — exactly like a well-modelled business workflow. Table of Contents Introduction — one word, two meanings Coding with AI agents: what actually changes From autocomplete to the agentic loop The developer's role shifts toward review Explicit guardrails Designing agentic architectures An agent is a box with a contract Orchestration or autonomy: a choice, not a default Observability: if you can't replay it, you can't debug it Where humans remain irreplaceable A Tech Lead checklist for adopting these methods Conclusion — agents reveal a team's maturity Introduction — one word, two meanings "Agentic" has been everywhere for a few months, but it means two different things depending on who's talking: Coding with AI agents : a tool that reads code, writes diffs, runs commands, launches tests, and iterates until it reaches a correct result — instead of suggesting one line at a time. Designing agentic systems : a software architecture where autonomous agents (often themselves LLM-based) make decisions, call tools, and cooperate to accomplish a business task — a support chatbot that triggers refunds, a document pipeline that routes complex cases to a human on its own. These are two separate topics, but the same underlying principle runs through both: an agent — human, AI, or service — is only reliable when it operates inside an explicit frame. It's the s

In this podcast, Shane Hastie, Lead Editor for Culture & Methods, spoke to Adam Wachtel, CTO at Click Boarding, about hiring for personality and problem-solving over pure skillset, turning around a platform and team in crisis, and how AI is reshaping team size and composition without ending SAAS. By Adam Wachtel

Most engineers who stall at a level have the skill. What they don't have is anyone willing to explain the machine they're inside. The explanation you get from your manager is partial by design. They know their part of the process and not the committee's, so what comes back is "keep doing what you're doing, you're close." Which is true, and useless, and then you're close again next cycle. So here is the machine, reconstructed from what the four big companies publish, what their engineers write up afterward, and what levelling aggregators have pieced together. None of it is your company's internal doc. Check the specifics with your own manager. The ladders don't line up Stage Google Meta Amazon Microsoft Apple Typical YOE Entry L3 E3 L4 (SDE I) 59–60 ICT2 0–2 Mid L4 E4 L5 (SDE II) 61–62 ICT3 2–5 Senior L5 E5 L6 (SDE III) 63–64 ICT4 5–8+ Staff L6 E6 L7 (Principal) 65–66 ICT5 8–12+ Senior staff L7 E7 L8 67 ICT6 12+ Principal / Distinguished L8–L9 E8–E9 L10 68–69 Distinguished rare Google's L5 is a senior engineer. Amazon's L5 is a mid-level SDE II. Recruiters map between them and the map is approximate, so the year ranges are typical rather than required. Two things here matter more than the numbers. The gap between adjacent levels is not constant. Entry to mid is mostly about becoming reliable. Mid to senior is about becoming independent. Then senior to staff, which is where the ladder stops behaving like a ladder: it's a change of job, and the things that earned you the last promotion only partly transfer. And every company has a level it considers a perfectly good place to spend a career. Google's L5, Meta's E5, Amazon's SDE II or III depending on who you ask, Microsoft's 63 or 64. Below that level there is an expectation you keep climbing, and at some companies a clock. Above it, promotion is optional and much harder, and nobody will chase you about it. What actually happens in the room The four processes differ enough that optimizing for the wrong one wastes a year

Most EM interview prep fails the same way. You pick three strong stories, polish them until they're tight, run them past a friend, and walk in confident. Then somebody asks how you'd handle a high performer who's difficult to work with, and none of your three stories touch it. That isn't a depth problem. It's a coverage problem, and it's the thing that makes the EM loop different from every IC loop you've done. An IC loop samples from a narrow surface. Systems, code, a couple of behavioural questions that mostly serve as tiebreakers. You can prepare for it by going deep on a small number of technical narratives. An EM loop samples from a wide one. Nine areas, roughly, and you can be excellent at seven of them and still lose the loop on the two you never thought about. The nine areas Team building and hiring Performance management and difficult conversations Conflict and difficult relationships Delivery, prioritization and ambiguity Cross-functional partnership Growth, coaching and career development Technical judgment and architecture Values, culture and self-awareness Vision and scaling Look at that list and be honest about which two are thin for you. For most people coming from a senior IC role it's 2 and 3, because those are the parts of the job you've watched from the outside rather than done. What the questions are actually checking Underneath the surface wording, almost every behavioural question in an EM loop is checking one of four things. Did you run a real process, or improvise? "I had a conversation with them" is an improvisation. "I named the specific pattern with dates, we agreed a 30-day plan, I checked in weekly" is a process. Can you name a specific tradeoff you made, and why? Not that tradeoffs existed. Which one you picked, what it cost, and what you got. Do you own outcomes without deflecting or over-apologizing? Both failure modes read badly. Blaming the org is worse, but flagellating yourself for four minutes over a bad hire is not much better.

Independent safety officials also have high praise for changes by NASA leadership.

A preview of the September cohorts of the InfoQ Online Certification Programs, and the facilitators leading them: Luca Mezzalira, Michelle Brush, Zichuan Xiong, and Premanand Chandrasekaran. By Artenisa Chatziou

A technology problem rarely stays a technology problem for very long. A platform may need to scale. A product may need to move faster. An organisation may want to introduce AI, modernise an ageing estate, improve customer experience or launch something entirely new. The first instinct is usually to look at the technology itself. Which architecture should change? Which platform should we buy? Which team should build it? Which tools should we introduce? Those questions matter. But they are often not the questions that determine the outcome. At Cralgo, one pattern keeps appearing across technology work: the harder part is frequently the system around the technology. The problem behind the problem Consider a programme that appears to have an execution issue. Delivery is slow. Priorities keep changing. Teams disagree. Decisions are repeatedly reopened. The roadmap keeps moving. It is easy to conclude that the engineering team needs to become faster. But look closer and the constraint may be somewhere else: ownership is unclear; priorities are not genuinely ordered; product and technology are working from different assumptions; architecture decisions are being made without business context; teams are executing tasks without understanding the judgement behind them; governance exists, but only as reporting; critical decisions remain dependent on a small number of people. None of these are purely technical problems. They are questions of judgement, ownership, capability, sequencing and governance. Technology simply makes them visible. Better technology does not automatically create better execution Organisations understandably invest heavily in platforms, cloud, data, automation and AI. But technology increases capability only when the organisation around it can use that capability well. A new platform cannot decide what should be prioritised. A new operating model diagram cannot create ownership. A dashboard cannot replace judgement. AI cannot resolve ambiguity that an orga

Kasia Trapszo discusses how Netflix evolved its commerce platform from a U.S. DVD service into global infrastructure. She explains navigating international payment realities, adapting to strict regulatory mandates, decomposing monolithic architectures along domain boundaries, and re-architecting systems for massive live-event demand - proving great systems survive by continually evolving. By Kasia Trapszo

You have done everything right. You made the economic case for automation and got the investment approved. You distributed quality checks across the SDLC instead of piling them at the end. You replaced pyramid thinking with risk-weighted coverage. You stopped reporting a coverage percentage that was lying to you. Six months later, your engineers have started ignoring test failures. Not because they are careless. Because ignoring test failures became the rational choice. This article is about how that happens, why it happens to teams that know better, and why it is the final form of Test Debt. What is flakiness? A flaky test is a test that fails intermittently without any change to the code it covers. It sometimes passes and sometimes fails, with no consistent pattern. The most common root causes are timing issues in async operations, test-order dependencies, shared mutable state, and coupling to external services. All of these are fixable. The fixable nature of the problem is not what makes it interesting. What makes it interesting is that teams fix very little of it, and teams with strong engineers who care about quality fix very little of it. The reason is not the technical difficulty. The scale The numbers are worth stating clearly, because they establish what is actually at stake here: At Google , approximately 16% of tests show some form of flakiness, and 84% of transitions from passing to failing involve a flaky test rather than a genuine regression. At Microsoft , roughly 25% of test failures in large-scale CI systems are caused by flakiness, not actual code defects. The average time a developer spends per flaky test investigation: 30 minutes, before determining it was not a real failure. Atlassian estimated 150,000 developer hours per year consumed by flaky test investigation before they built automated detection tooling. Slack's mobile test failure rate reached 56.76% before they intervened. More than half of all test failures were noise. These are not team

If someone has ownership, when should you check on their work? Too little involvement can mean discovering problems too late. Too much involvement becomes micromanagement. I think the difference is what the checkpoint is trying to achieve . A useful checkpoint asks: “Are we still solving the right problem, and do you need anything from me?” Micromanagement asks: “Why did you do it this way? Change this. Then do this next.” The first keeps ownership with the person. The second gradually takes it away. A checkpoint can be as simple as: Agree on the approach before starting. Share an early draft. Discuss progress after a meaningful milestone. Review the result before it becomes difficult to change. The important part is that the checkpoint should happen early enough to change the outcome , without requiring the person to get approval for every decision. The amount of checking should also change with the situation. A new engineer working on an unfamiliar problem may need frequent checkpoints. Someone experienced and familiar with the problem may need very little intervention. So the goal isn’t: “Never check.” It’s: “Check enough to reduce risk without taking away ownership.” A checkpoint should help someone succeed without making them dependent on you.

In the professional world—especially in high-stakes tech environments—we are conditioned to believe that career advancement is a direct result of having the right answers. From the moment we step into our first junior role, we feel the pressure to be the "smartest person in the room." We equate confidence with certainty and value with the ability to provide instant solutions. But after years of working with founders, engineering leaders, and product builders, I have discovered a fundamental truth: The most valuable professionals are not the ones with all the answers. They are the ones asking the right questions. The Trap of the "Answer-First" Mindset When you focus solely on providing answers, you inadvertently limit your scope. You become a bottleneck. You are only as capable as your own knowledge base, and you discourage those around you from thinking critically. This "answer-first" culture often leads to: Superficial Solutions: You solve the symptoms, not the root cause, because you didn't take the time to explore the underlying complexity. Stifled Innovation: When leaders provide all the answers, team members stop proposing ideas. They wait for instructions rather than taking ownership. Fragile Trust: People trust those who are curious and transparent about what they don't know far more than those who bluff their way through uncertainty. Shifting to Inquiry-Led Growth Moving from an "answer-first" mindset to an "inquiry-led" mindset is not just a soft skill; it is a tactical advantage. When you shift your focus to understanding the problem, the entire dynamic of your work changes. 1. From Directive to Generative Instead of telling a developer how to implement a feature, ask, "What are the trade-offs of this approach compared to X?" This forces the engineer to think through the architecture, improving their skills while often revealing a better solution you hadn't considered. 2. Building Psychological Safety When you ask, "What am I missing here?" or "What does t

For the past two months or so, I've been working on a variety of AI development projects rather than writing -- writing skills, plugins, workflows, and applications; testing and refining harnesses; and performing diligence or working with clients (hands-on work as well as brains-on work) as they think through where they're going with AI and how they're getting there. I've been down a lot of rabbit holes and talked to a lot of forward-thinking practitioners, and I have explored a lot of what is actually possible now by building things...and I've spent my "think-time" on what that all might actually mean going forward. Here's what I've come up with: 59 predictions in 17 categories around how the world of AI -- and the broader world in light of AI -- are changing. I'll write more deeply about many of these over the weeks ahead. Predictions Here's what's coming, in my not-so-humble opinion, based on what I'm seeing in client projects & diligence, conversations, and research. Each prediction is grouped by category and by time horizon (within 12 months / 1-3 years / 2-4 years / 3-5 years), with a confidence level and a falsification criteria (i.e., what I'd expect to observe if I'm wrong). Confidence isn't a measure of how much I want something to be true; it's a measure of how much variance I think exists in the outcome. I'd love your feedback on what I'm missing or where I'm missing the forest for the trees (or the boat entirely :D)! Any surprises for you? Organizational Structure & Delivery Model #1. Small Cross-Functional Pods Become the Standard for Software Development (2-4 years) The leading-edge/aspirational development team model will have moved from agile teams of 6-8 to AI-powered Pods of 2-3 (often product/development/deployment, sometimes SrDev/JrDev/Product). This prediction underpins many of the other predictions in this entire group -- most of the rest of the Org Structure & Delivery Model cluster assumes it holds. It's plausible for greenfield and startup

Architecture is not a fixed choice made once; fitness is a moving target driven by changing regulations, tech, and markets. Even a sound design can silently stop fitting over time without bad calls. Spanning seven articles on context stores, gateways, and topologies, this collection treats architecture as an evolving sociotechnical craft where teams deliberately shape friction, fitness, and flow. By InfoQ

There is a moment in every high-stakes environment when something goes completely, objectively wrong, and the only viable response is to keep working. In my case, it was a pantry clerk who walked into the dry storage room carrying a stack of boxes, clipped a fire sprinkler head, and discharged what I can only describe as an impressive quantity of initially greasy water across an active commercial kitchen. We were told to continue service. It took four hours for the sprinkler system technicians to arrive and resolve the situation. We dried our shoes afterward. I have thought about that shift many times since leaving commercial kitchens for the technology industry. Not because it was the strangest thing I witnessed. It wasn't. Not by a significant margin. However, because the response to it was so instinctively correct. Nobody called an all-hands. Nobody convened a retrospective on the water. We just kept swimming. It turns out that lesson travels extremely well. A few weeks ago I wrote about how a non-linear career isn't actually non-linear, that the industries change but the underlying questions stay remarkably consistent. I want to make that argument concrete. Here's what commercial kitchens specifically taught me about performing under pressure, and why none of it required translation when I showed up in technology. The Kitchen Never Lies I spent years in commercial kitchens before I spent years in technology. Western Culinary Institute. Private golf clubs. A Lebanese restaurant. Bulk production facilities turning out ten thousand pounds of macaroni and cheese a day, five days a week. Country clubs. A casino. Catering. Culinary competitions. The environments were different. The underlying dynamics were identical. High pressure. Constrained timelines. Mismatched team experience levels. Leadership of wildly variable quality and sobriety. Outcomes that mattered regardless of what had happened behind the scenes to produce them. Customers who neither knew nor cared abo

There is a comedy sketch from Bob & Tom that starts with a hilariously impossible promise: overnight delivery by train, from New York to Los Angeles. At one point, someone asks if they can really get a 2,000-pound package across the country overnight by rail. The answer is delivered with absolute confidence: “Norfolk and Waypal, overnight. Absolutely. Positively.” The name is doing some careful work. It lets you hear the phrase that nobody has actually said out loud. No way, pal. When I end up leading a project with six weeks left and something that feels like four months of work to do, I start the internal kickoff by telling the team to go watch that sketch. No other explanation. Just go watch it, then come back. Then I tell them: “Absolutely, positively, we will get you through it. There's Norfolk and Waypal, we are gonna to do it.” That does not mean we are going to do the thing exactly as it was originally promised. It means we are going to get through it. Absolutely. Positively. There is a difference. Laugh at the impossible first I think newer developers especially need permission to laugh at impossible requirements. An 800-pound gorilla from New York to Los Angeles overnight by train is impossible in a way that is easy to laugh at. A project that needs a full cloud environment, API work, a mobile application in the app stores, production deployment, security approvals, and a dozen other things in six weeks? That can feel less funny when it is sitting in your sprint board. But it may be just as impossible if we take the requirements literally. The first danger on a crunch project is shame. A junior developer can look at an impossible deadline and wonder if they are missing something. Maybe everyone else understands how this gets done. Maybe it is a talent problem. Maybe if they just worked harder, they could turn six weeks into twelve. Nope. Sometimes the work is just Norfolk and Waypal . Humor does not solve the problem. It lowers the temperature enough that

In this podcast, Shane Hastie, Lead Editor for Culture & Methods, spoke to David Gudeman about the unique culture of early-stage startup engineering, how founder personality quirks and premature process impositions can derail teams, and how engineers can build influence and make deliberate career choices without formal power. By David Gudeman

The framing that causes the most damage is treating this as a financing decision. It is not. Taking venture money is choosing a category of business: one that must attempt to become very large very quickly, and produce an exit that returns a fund. Everything else follows from that. What venture capital actually requires A venture fund needs a small number of investments to return the entire fund. That structure means a company growing steadily and profitably at twenty percent a year is a failure in a venture portfolio, even though it is an excellent business by any other measure. Once you take the money, that expectation becomes your operating constraint. Decisions that would be obviously correct for a durable business, such as slowing hiring to protect margin, become hard to defend. Questions that actually decide it Can this business plausibly become very large? Not "could it grow", but could it realistically reach a scale where a meaningful ownership stake is worth a large multiple of the money invested. Most good businesses cannot, and that is not a criticism of them. Does speed determine who wins here? In some markets the first company to reach scale takes most of the value, usually where network effects or heavy switching costs exist. In those markets, refusing capital while a competitor takes it is a decision to lose. In most markets this dynamic does not apply, and speed bought with dilution buys nothing durable. Do you want to run this for a decade and then sell it? Venture capital has an implicit ending. The fund needs liquidity. If you want to own a profitable business indefinitely, you want a fundamentally different structure and should say so before, not after. Is capital genuinely your constraint? Founders often raise to solve problems money does not solve. If you have not found product market fit, capital lets you be wrong more expensively and for longer. If distribution is unproven, funding scales an unproven motion. The honest tradeoff Venture backed

Part of the "AI Leadership in the Real World" series: how leaders turn AI from scattered pilots and executive excitement into governed, adopted, measurable business capability. TLDR: 60 ideas on a board. 4 product teams to build them. $1.2M in annualized run cost for pilots that produced $340K in measurable value. The week we made tradeoffs visible was the week AI stopped being a budget line item and started being a product strategy. My AI backlog looked like a menu with 60 "top priorities" and no kitchen to cook them. Every function had a smart idea. Every idea came with urgency and a sponsor. Customer support wanted a deflection chatbot. Engineering wanted a code review assistant. Sales wanted lead scoring. Operations wanted anomaly detection. HR wanted resume screening. Finance wanted invoice reconciliation. Each one was a good idea. That was the problem. When every idea is good, prioritization becomes political. The loudest pitch keeps winning. People start optimizing for being seen, not for being useful. And the organization quietly trains everyone to be louder. I run a product P&L. I do not have the luxury of treating every good idea as a funded initiative. My job is not to maximize the number of AI pilots. My job is to maximize the return on the engineering capacity, infrastructure budget, and organizational trust I have been entrusted with. Those are finite. Every pilot I approve is a pilot I cannot fund somewhere else. Every dollar of inference cost is a dollar that did not go to a product feature, a reliability improvement, or a person. We were treating AI like a lottery ticket instead of a managed investment. The P&L was telling us that before I was willing to listen. What Changed: The Cost of the First Prototype Collapsed Two years ago, prototyping an AI use case took weeks — data pipeline, model, inference endpoint, UI, deployment path. The cost itself was a prioritization mechanism. Only ideas that survived a viability check got built. That barrier is