<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:dc="http://purl.org/dc/elements/1.1/">
  <channel>
    <title>DEV Community: Kevin M. Coles</title>
    <description>The latest articles on DEV Community by Kevin M. Coles (@kevinmcoles).</description>
    <link>https://dev.to/kevinmcoles</link>
    <image>
      <url>https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F4219746%2Fd4d64e85-005b-47d4-9cdf-fbc4bbd878c5.png</url>
      <title>DEV Community: Kevin M. Coles</title>
      <link>https://dev.to/kevinmcoles</link>
    </image>
    <atom:link rel="self" type="application/rss+xml" href="https://dev.to/feed/kevinmcoles"/>
    <language>en</language>
    <item>
      <title>An AI Policy Is Not AI Governance</title>
      <dc:creator>Kevin M. Coles</dc:creator>
      <pubDate>Sat, 31 Oct 2026 23:07:10 +0000</pubDate>
      <link>https://dev.to/kevinmcoles/an-ai-policy-is-not-ai-governance-co4</link>
      <guid>https://dev.to/kevinmcoles/an-ai-policy-is-not-ai-governance-co4</guid>
      <description>&lt;p&gt;Every company I talk to right now has, or is writing, an AI policy. Most of them think that is the finish line. It is the starting line, and a lot of businesses are about to find that out the hard way.&lt;/p&gt;

&lt;p&gt;A policy is a document. It says what is allowed and what is not. It tells an employee not to paste client data into a public chatbot, and that is worth having. But a policy does not tell you who approved the AI tool now quietly running inside your customer service workflow. It does not tell you what happens when that tool makes a decision that affects a real customer and nobody can explain why. It does not tell you who is accountable when the business unit that adopted it never asked anyone.&lt;/p&gt;

&lt;p&gt;That is the gap. Business units are adopting AI faster than most technology leaders can track, because the tools are free, fast, and do not require anyone's permission to try. By the time a CIO or an IT lead hears about a given use case, it has often already touched real data and made real decisions. The policy sitting in a shared drive did nothing to prevent that, because a policy is not a control. It is a statement of intent.&lt;/p&gt;

&lt;p&gt;Governance is the part that actually works: a living inventory of where AI is being used, clear ownership for who approved each use case, a real review of risk before adoption instead of after a problem, and a way to shut something off quickly when it turns out to be wrong. None of that fits on the single page most AI policies occupy.&lt;/p&gt;

&lt;p&gt;I expect a lot of executives to be surprised in the next year, not because they did nothing, but because they mistook the document for the discipline. Writing the rule was the easy part. Owning what actually happens inside the business is the part nobody delegated, and it is the part that was always going to matter.&lt;/p&gt;




&lt;p&gt;&lt;em&gt;Kevin M. Coles is a fractional CIO and the founder of Coles Technical Group, where he helps leadership teams build governance, not just policy, around the technology decisions they cannot easily undo. More on the distinction: &lt;a href="https://colestechnicalgroup.com/blog/ai-policy-vs-ai-governance/" rel="noopener noreferrer"&gt;Your AI Policy Is Not an AI Governance Program&lt;/a&gt;&lt;/em&gt;&lt;/p&gt;

</description>
      <category>ai</category>
      <category>governance</category>
      <category>leadership</category>
      <category>technology</category>
    </item>
    <item>
      <title>The CIO Title Nobody Needs, and the Function Everyone Does</title>
      <dc:creator>Kevin M. Coles</dc:creator>
      <pubDate>Sat, 31 Oct 2026 23:06:08 +0000</pubDate>
      <link>https://dev.to/kevinmcoles/the-cio-title-nobody-needs-and-the-function-everyone-does-5gen</link>
      <guid>https://dev.to/kevinmcoles/the-cio-title-nobody-needs-and-the-function-everyone-does-5gen</guid>
      <description>&lt;p&gt;Nobody has ever called me and asked for a CIO. They call because something is not working, or because something keeps almost not working, and they are tired of finding out about it after the fact. The title is the last thing on their mind. The function is the only thing they actually need.&lt;/p&gt;

&lt;p&gt;I think the title confuses more business owners than it helps. CIO sounds like a corporate seat reserved for companies with a thousand employees and a budget to match. So small and mid-sized businesses skip the conversation entirely and default to whichever role is already in the building: an IT director who was promoted because they were good at fixing things, an MSP whose contract was never meant to include judgment, or nobody, because the business has grown used to making technology decisions the same way it always has, one urgent problem at a time.&lt;/p&gt;

&lt;p&gt;Here is the distinction that actually matters, and it has nothing to do with titles. Someone keeps the lights on. Someone else decides what the lights should be pointed at. Those are different jobs, they require different instincts, and almost every business I have evaluated has the first one covered and the second one empty.&lt;/p&gt;

&lt;p&gt;An IT director or an MSP is built to respond. They are good at it. That is the job. But direction is not a response, it is a decision made before the fire starts, about what the business is actually trying to become and what technology has to do to get it there. When that decision has no owner, it gets made by accident, by whichever vendor called last or whichever system broke most recently.&lt;/p&gt;

&lt;p&gt;I do not care what you call the person who owns that decision. I care that someone does, and that it is not the same person who is also responsible for the help desk ticket queue, because those two jobs will always lose to each other, and the ticket queue always wins the argument in the short term.&lt;/p&gt;




&lt;p&gt;&lt;em&gt;Kevin M. Coles is a fractional CIO and the founder of Coles Technical Group. He wrote a longer breakdown of where this distinction actually lives: &lt;a href="https://colestechnicalgroup.com/blog/cio-cto-it-director-msp/" rel="noopener noreferrer"&gt;Do We Need a CIO, CTO, IT Director, MSP, or Something Else?&lt;/a&gt;&lt;/em&gt;&lt;/p&gt;

</description>
      <category>leadership</category>
      <category>cio</category>
      <category>technology</category>
      <category>management</category>
    </item>
    <item>
      <title>Your Vendor Is Not Your Strategy</title>
      <dc:creator>Kevin M. Coles</dc:creator>
      <pubDate>Sat, 31 Oct 2026 23:02:03 +0000</pubDate>
      <link>https://dev.to/kevinmcoles/your-vendor-is-not-your-strategy-48ca</link>
      <guid>https://dev.to/kevinmcoles/your-vendor-is-not-your-strategy-48ca</guid>
      <description>&lt;p&gt;Every business I have ever walked into already has a technology strategy. Nobody wrote it down. Nobody approved it. It got built one vendor recommendation at a time, by people who were never asked to think about the business, only to sell what they sell.&lt;/p&gt;

&lt;p&gt;That is not a criticism of vendors. A security vendor is supposed to recommend security tools. A cloud provider is supposed to recommend more cloud. An MSP is supposed to recommend whatever keeps the ticket queue calm. Every one of them is doing their job correctly. The problem is that nobody above them is doing a different job: deciding which of those recommendations the business actually needs, in what order, and why.&lt;/p&gt;

&lt;p&gt;I have sat in rooms where a six-figure platform decision got made because a vendor's slide deck was good. Not because anyone compared it to what the business already owned. Not because anyone asked what it would cost to walk away from in three years. The deck was convincing, the timeline was tight, and nobody in the room had the job of saying "wait."&lt;/p&gt;

&lt;p&gt;Here is the test I use with clients. Pull up your last five significant technology purchases. For each one, write down who proposed it. If the answer is a vendor more often than it is someone inside the business who owns outcomes, you do not have a technology strategy. You have a technology history, assembled by the people with the most reason to sell you something.&lt;/p&gt;

&lt;p&gt;This is not an argument for distrusting vendors or slowing everything down with committees. It is an argument for a specific kind of ownership: someone whose job is to sit between the business and every vendor in the room, who has no commission riding on the answer, and whose only accountability is whether the decision was right for the business two years later. Most small and mid-sized companies do not have that person. They have a founder who is too busy, an IT lead who is too close to the tools, or nobody at all. The vendor relationship fills the vacuum because vacuums get filled.&lt;/p&gt;

&lt;p&gt;The fix is not more process. It is a different seat at the table, one that outlasts any single vendor relationship and answers to the business, not to a quota.&lt;/p&gt;

&lt;p&gt;&lt;em&gt;Kevin M. Coles is a fractional CIO and the founder of Coles Technical Group, where he owns technology direction for companies that would rather have a strategy than a vendor history. More on how vendor-driven decisions quietly become the default: &lt;a href="https://colestechnicalgroup.com/blog/vendors-technology-strategy/" rel="noopener noreferrer"&gt;Should Vendors Define Your Technology Strategy?&lt;/a&gt;&lt;/em&gt;&lt;/p&gt;

</description>
      <category>leadership</category>
      <category>technology</category>
      <category>cio</category>
      <category>management</category>
    </item>
  </channel>
</rss>
