<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Process on guy@secdev.uk</title>
    <link>https://www.secdev.uk/blog/tags/process/</link>
    <description>Recent content in Process on guy@secdev.uk</description>
    <generator>Hugo</generator>
    <language>en-gb</language>
    <copyright>Guy Dixon | guy@secdev.uk</copyright>
    <lastBuildDate>Mon, 01 Dec 2025 00:00:00 +0000</lastBuildDate>
    <atom:link href="https://www.secdev.uk/blog/tags/process/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Designing Good Process (Without Becoming a Bureaucracy)</title>
      <link>https://www.secdev.uk/blog/leadership/3.6-designing-good-process/</link>
      <pubDate>Mon, 01 Dec 2025 00:00:00 +0000</pubDate>
      <guid>https://www.secdev.uk/blog/leadership/3.6-designing-good-process/</guid>
      <description>&lt;p&gt;Engineers hate process. Or rather, engineers hate &lt;em&gt;bad&lt;/em&gt; process, and most process they encounter is bad. It&amp;rsquo;s imposed from above without understanding the problem it&amp;rsquo;s meant to solve. It adds overhead without adding value. It treats every situation the same regardless of risk or complexity. No wonder the word &amp;ldquo;process&amp;rdquo; makes people flinch.&lt;/p&gt;&#xA;&lt;p&gt;But the absence of process isn&amp;rsquo;t freedom, it&amp;rsquo;s chaos. Having worked in both process-light start-ups and process-heavy corporates, I&amp;rsquo;ve seen both failure modes up close. The start-up where nobody knew how deployments worked because there was no documented process. The corporate where deploying a one-line change required three approvals and a change advisory board meeting. Neither extreme serves the team.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
