tylers-blogger-blog

Most "data strategies" are built like a museum: collect everything, label it nicely, and hope someone strolls through and discovers insight. The contrarian view is simpler-and more uncomfortable: your data strategy is not a storage strategy, not a dashboard strategy, and definitely not a "we should track more things" strategy. A better data strategy is a set of deliberate constraints: what you will measure, what you won't, which decisions you want to accelerate, and where you'll tolerate ambiguity. That sounds like less data, not more. And that's the point. The mistake: treating data like an asset you should hoard Here's the common pattern: 1) A leader says, "We need to be data-driven." 2) Teams instrument everything "just in case." 3) A warehouse fills up, a BI tool goes live, dashboards multiply. 4) People still argue in meetings-now with screenshots. The quiet reason this fails: hoarding data doesn't create clarity; it crea...

At 9:47 PM, our "AI agents" were not a team. They were five talented interns talking over each other. One agent would draft a plan. Another would "helpfully" rewrite it. A third would start coding before anyone agreed on requirements. Meanwhile, the QA agent nitpicked formatting while the data agent pulled numbers from the wrong date range. Nothing was broken individually-coordination was. That night, we stopped trying to make one super-agent do everything and instead built a small system where each agent had a job, a shared memory, and rules for taking turns. The turning point: roles, boundaries, and a single source of truth The first fix was embarrassingly simple: we wrote role cards like you'd do for humans. Planner plans. Researcher gathers sources. Builder implements. QA tests. Reporter summarizes. Each role had: Inputs it is allowed to read Outputs it is allowed to write A "definition of done" checklist Then we introduced one shared artifact: a ...

We didn't adopt local LLMs because it was trendy. We adopted them because we were tired of the same loop: too many customer questions, too many proposals, too many "small" tasks that quietly ate the day. A year ago, our strategy meetings sounded like this: "We should post more." "We should follow up faster." "We should tighten pricing." And then we'd go right back to being buried in inboxes and admin work. Local LLMs changed that-not by magically doing everything, but by turning our best repeatable work into systems we could actually run. Why we chose local LLMs (and what 'local' really meant for us) A local LLM is a language model that runs on your own hardware (a workstation, mini-PC, or server) instead of sending prompts and data to a cloud provider. For us, "local" meant three practical things: 1) We could use real business data safely : sales notes, customer emails, internal playbooks, and pricing logic-without cons...

We didn't plan for our analytics automation to become the main character. It started as a "nice-to-have" script that pulled numbers together so we could stop copy-pasting CSVs at 8 a.m. Then came the quarterly review-leaders in the room, dashboards on the big screen, and a single question that turned our quiet helper into the star of the show: "Are we sure these numbers are right?" That's the moment automation either earns trust... or gets politely benched. When the spotlight hit: what we changed in one afternoon The dashboard looked great. Too great. Which is exactly why everyone suddenly cared about the plumbing. Our automation was doing three jobs: ingesting events, transforming them into a reporting table, and refreshing charts every hour. But under pressure, we realized we had a few trust gaps: Definitions lived in people's heads. "Active user" meant one thing to product, another to marketing. No obvious freshness cues. Charts updated, b...

Project management doesn't fail because people don't care. It fails because coordination is expensive: status updates, handoffs, "who owns this?", outdated docs, and the slow drift between what we planned and what actually happened. This manifesto is simple: stop using AI as a fancy autocomplete. Start using AI agents as teammates-purpose-built, role-based assistants that move work forward across your tools, with guardrails. 1) What "AI agents" mean in project management (and what they don't) An AI agent isn't "a bot that chats." It's a system that can: Understand a goal (e.g., "keep this sprint on track") Take actions in your workflow tools (create tickets, update fields, draft messages) Watch signals (PR activity, calendar changes, blockers in comments) Report outcomes and ask for approval when stakes are high Think of agents as specialists , not a single all-knowing manager. A practical stack might include: Intake Agent : t...

The 2 a.m. Moment We were minutes from pushing a release when support lit up: "Checkout failures spiking." Logs were noisy, metrics were contradictory, and everyone had a different theory. In the old days, we'd have argued for an hour while grepping files and refreshing random queries. That night, we did something better: we stopped talking and started looking. What Actually Saved Us We pulled up a dashboard that layered error rate, latency, and revenue impact on the same timeline. The story snapped into focus: the spike only hit one region, only after a config rollout, and only for a specific payment provider. A quick heatmap by endpoint pointed to a single route returning 502s. Then a simple filter showed the failures clustered around a new feature flag. Five minutes later, we rolled back the flag and watched the line drop in real time. If you're still choosing your stack, this breakdown of popular visualization tools mirrors the exact tradeoffs we ran into that ni...