[{"content":"I\u0026rsquo;m the VP of Technology for a mail-order pharmacy. If you run a technical org, you already know the person I\u0026rsquo;m about to describe: the one who shows up with an idea. There are two kinds: the ones who know it involves my team, and the ones who haven\u0026rsquo;t realized it yet. Both end up on my desk.\nThe short version of how I deal with this:\nGet involved early, because the work rolls downhill to IT no matter what. Make them prove demand and the unit economics before anyone builds. Kill big-bang launches. Validate with a fake door instead. Protect the backlog you already committed to by saying no. The rest of this is how I actually do that.\nThe refrigerator that needed a sysadmin Our operations team was sourcing a limited-distribution drug. The manufacturer said sure, you can carry it, but it has to live in this specific refrigerator. Fine. The refrigerator shows up, the drug goes in.\nThen: \u0026ldquo;Oh, by the way, open port 22 so we can SSH into the fridge, and 443 for the web server we monitor it with.\u0026rdquo;\nSo now the refrigerator requires IT to run. You can\u0026rsquo;t just plug it into the wall like a toaster. Give it a week and the toaster needs a ticket too.\nThat\u0026rsquo;s the part nobody warns you about. The work finds you whether you invited it or not. It rolls downhill, and fighting it is fighting gravity. Miss the early conversation and it lands on your team fully formed, with nobody having asked whether it should exist.\nTwo reasons to say no There are always a million reasons to do something. Expand into a new market. Bolt a feature onto the portal. They all sound great in the room.\nThere are usually only two reasons not to, and it\u0026rsquo;s the same two every time:\nNobody wants it. The math doesn\u0026rsquo;t work. Your customer acquisition cost is $150 and your lifetime value isn\u0026rsquo;t, so you lose money on every signup and the whole thing is underwater. So when an idea shows up, turn it around: how are you validating this? I lean on Y Combinator\u0026rsquo;s Startup School for the framing. Startups optimize every decision around who does what and when, because there\u0026rsquo;s nobody spare to do the work. That discipline is exactly what evaporates once a company has enough money to absorb bad bets. Push the burden of proof back to the front, before any of it touches engineering.\nBig-bang launches almost always miss Some cultures love the big-bang launch: one giant reveal, everything at once. I\u0026rsquo;ve never been part of one at a healthcare company where anyone actually used the thing the next day. There\u0026rsquo;s far more logistics in how something gets built and adopted here than people expect. Unless you\u0026rsquo;re direct-to-consumer, you\u0026rsquo;re not getting a hundred thousand users on day one. You\u0026rsquo;d be lucky to get two.\nA big-bang launch is software deployed one year at a time. You skip the iterating, the market research, the validation, and ship the whole year in one shot. Who needs sprints? Who needs continuous delivery? Just send it and pray.\nMarketing decides whether any of it works When leadership comes to you with \u0026ldquo;we want to do this, we want to do that,\u0026rdquo; one question cuts through it: how much does it cost to acquire each customer? If they don\u0026rsquo;t know, it isn\u0026rsquo;t worth doing yet.\nEvery product lives and dies by marketing, and everyone has an ad-spend ceiling. Google has tuned its algorithm to know the exact price a click is worth, and it\u0026rsquo;ll make its money whether or not you make yours. Bet against that without knowing your numbers and you go broke while Google doesn\u0026rsquo;t.\nA sentence from them, a decade from you The other thing about idea people is the asymmetry. Someone says \u0026ldquo;I want a rocket that lands and is reusable after launch.\u0026rdquo; Three seconds to say. A decade to build.\nEvery day the top of the company generates a few sentences. \u0026ldquo;Wouldn\u0026rsquo;t it be cool if we had X.\u0026rdquo; \u0026ldquo;We should have Y.\u0026rdquo; Each one can be two or three years of engineering. And it\u0026rsquo;s not always the leadership team. It\u0026rsquo;s the board, the parent company, some external factor, whoever. The source doesn\u0026rsquo;t matter. The asymmetry does: a steady stream of cheap sentences will happily trample a finite amount of expensive capacity.\nPut the work back on them The only way to fight that asymmetry is to hand the work back. You have an idea? Great. Here\u0026rsquo;s the process.\nIt starts with about three months of them writing a business plan and sizing the market. Then you shift the goalposts for the tech team all the way to the left. No build. A landing page. A fake-door site with no functionality and a waiting list. Email a few thousand patients: here\u0026rsquo;s an idea, here\u0026rsquo;s the signup link, here\u0026rsquo;s $10 off your first order.\nIf ten free dollars won\u0026rsquo;t get someone through the door, you\u0026rsquo;re in deep trouble. You\u0026rsquo;re about to spend real money advertising a product you can\u0026rsquo;t even give away.\nSomebody has to say no Here\u0026rsquo;s why all of this matters. A big company has a money cushion, so a bad bet doesn\u0026rsquo;t kill you the moment you make it. What it doesn\u0026rsquo;t have is unlimited time. My team\u0026rsquo;s capacity is already booked through next year. If we stopped all new work today, the backlog is still a year deep. That\u0026rsquo;s not a figure of speech.\nSo somebody has to say no, because the work already in the queue is almost certainly worth more than whatever idea is rolling toward us this week. Saying no to the new thing is how you protect the time you already promised to the things that matter.\nMost people don\u0026rsquo;t realize how much of this is already solved. I won\u0026rsquo;t pretend YC is perfect, but it beats burning a quarter and a budget to relearn the same lesson. When I can\u0026rsquo;t win the argument myself, I just send the link. It\u0026rsquo;s a twenty-minute crash course on validating an idea, and it holds up fine for a large, established company. Steal it: Y Combinator Startup School.\n","permalink":"https://barajas.blog/posts/dealing-with-idea-people/","summary":"Somebody always has an idea that turns into your team\u0026rsquo;s problem. Here\u0026rsquo;s how I make them prove it\u0026rsquo;s worth doing before a single line gets written.","title":"Everything Rolls Downhill to IT"},{"content":"Welcome to the blog. This is where I\u0026rsquo;ll write about software, systems, and whatever I happen to be building.\nWhy a blog Writing forces clarity. If I can\u0026rsquo;t explain a thing simply, I probably don\u0026rsquo;t understand it well enough yet. So: notes in public.\nCode renders nicely Here\u0026rsquo;s a quick Go snippet to confirm syntax highlighting and the copy button work:\npackage main import \u0026#34;fmt\u0026#34; func main() { for i := 0; i \u0026lt; 3; i++ { fmt.Printf(\u0026#34;post %d incoming\\n\u0026#34;, i) } } And a shell one-liner:\nhugo server -D More soon.\n","permalink":"https://barajas.blog/posts/hello-world/","summary":"First post — what this blog is and a quick taste of code rendering.","title":"Hello, World"},{"content":"I\u0026rsquo;m Michael Barajas. I build software and write about it here.\nEmail: michael@aioperable.com Code: GitHub This site is built with Hugo and the PaperMod theme, hosted on Cloudflare.\n","permalink":"https://barajas.blog/about/","summary":"About Michael Barajas","title":"About"}]