<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Team-Composition on guy@secdev.uk</title>
    <link>https://www.secdev.uk/blog/tags/team-composition/</link>
    <description>Recent content in Team-Composition on guy@secdev.uk</description>
    <generator>Hugo</generator>
    <language>en-gb</language>
    <copyright>Guy Dixon | guy@secdev.uk</copyright>
    <lastBuildDate>Mon, 30 Mar 2026 00:00:00 +0000</lastBuildDate>
    <atom:link href="https://www.secdev.uk/blog/tags/team-composition/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>The New Shape of the Engineering Team</title>
      <link>https://www.secdev.uk/blog/leadership/4.3-the-new-shape-of-the-engineering-team/</link>
      <pubDate>Mon, 30 Mar 2026 00:00:00 +0000</pubDate>
      <guid>https://www.secdev.uk/blog/leadership/4.3-the-new-shape-of-the-engineering-team/</guid>
      <description>&lt;p&gt;If AI can handle the boilerplate, the scaffolding, and a growing portion of routine implementation, what does that mean for how we compose engineering teams? It&amp;rsquo;s a question I&amp;rsquo;ve been turning over for a while now, and the answers I keep arriving at are uncomfortable.&lt;/p&gt;&#xA;&lt;p&gt;The optimistic version is that AI frees engineers to focus on higher-value work, system design, problem framing, user understanding, architectural thinking. The pessimistic version is that it eliminates the entry-level work that junior engineers have traditionally used to learn the craft. The realistic version is probably somewhere in between, and navigating it well is one of the most important challenges facing technical leaders right now.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
