<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Team-Building on guy@secdev.uk</title>
    <link>https://www.secdev.uk/blog/tags/team-building/</link>
    <description>Recent content in Team-Building on guy@secdev.uk</description>
    <generator>Hugo</generator>
    <language>en-gb</language>
    <copyright>Guy Dixon | guy@secdev.uk</copyright>
    <lastBuildDate>Mon, 12 Jan 2026 00:00:00 +0000</lastBuildDate>
    <atom:link href="https://www.secdev.uk/blog/tags/team-building/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Scaling Your Team Without Breaking What Works</title>
      <link>https://www.secdev.uk/blog/leadership/3.8-scaling-your-team-without-breaking-what-works/</link>
      <pubDate>Mon, 12 Jan 2026 00:00:00 +0000</pubDate>
      <guid>https://www.secdev.uk/blog/leadership/3.8-scaling-your-team-without-breaking-what-works/</guid>
      <description>&lt;p&gt;I lived through this at a growth start-up where the engineering team tripled in under two years. At fifteen people, we were fast, aligned, and effective. Everyone knew what everyone else was working on. Decisions happened in hallway conversations. The culture was strong because it was small enough to be transmitted through proximity.&lt;/p&gt;&#xA;&lt;p&gt;At forty-five people, almost none of that was true. Communication had broken down. New hires didn&amp;rsquo;t understand the culture because nobody had time to transmit it. Decisions that used to take minutes now took weeks because the number of stakeholders had multiplied. We were bigger, but we weren&amp;rsquo;t better, and for a painful period, we were actively worse.&lt;/p&gt;</description>
    </item>
    <item>
      <title>The Case for Team Stability</title>
      <link>https://www.secdev.uk/blog/leadership/3.4-the-case-for-team-stability/</link>
      <pubDate>Mon, 20 Oct 2025 00:00:00 +0000</pubDate>
      <guid>https://www.secdev.uk/blog/leadership/3.4-the-case-for-team-stability/</guid>
      <description>&lt;p&gt;There&amp;rsquo;s a persistent belief in engineering organisations that moving people between teams is healthy, it spreads knowledge, prevents silos, and keeps things fresh. I understand the appeal. I&amp;rsquo;ve also watched it destroy team effectiveness more times than I can count.&lt;/p&gt;&#xA;&lt;p&gt;The research is clear, and my experience confirms it: stable teams outperform shuffled ones. Not by a little, by a lot. And the reasons are rooted in how humans actually build trust and develop working relationships, not in how org charts look on a slide.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Onboarding That Goes Beyond Setting Up a Dev Environment</title>
      <link>https://www.secdev.uk/blog/leadership/3.3-onboarding-that-goes-beyond-setting-up-a-dev-environment/</link>
      <pubDate>Mon, 29 Sep 2025 00:00:00 +0000</pubDate>
      <guid>https://www.secdev.uk/blog/leadership/3.3-onboarding-that-goes-beyond-setting-up-a-dev-environment/</guid>
      <description>&lt;p&gt;At one company I joined, my onboarding consisted of a laptop, a Confluence page titled &amp;ldquo;Getting Started,&amp;rdquo; and a Slack message saying &amp;ldquo;let us know if you need anything.&amp;rdquo; At another, I had a structured first week with an assigned buddy, a schedule of introductions, and a 30/60/90-day plan. The difference in how quickly I became effective was enormous, and it had almost nothing to do with the technical setup.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
