<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Team Culture on Kianoosh's Blog</title><link>https://kianoosh.dev/tags/team-culture/</link><description>Recent content in Team Culture on Kianoosh's Blog</description><generator>Hugo -- gohugo.io</generator><language>en-us</language><lastBuildDate>Sat, 03 Jan 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://kianoosh.dev/tags/team-culture/index.xml" rel="self" type="application/rss+xml"/><item><title>The Death of the Data Monolith: An Introduction to Data Mesh</title><link>https://kianoosh.dev/posts/2026-01-03-the-death-of-the-data-monolith-an-introduction-to-data-mesh/</link><pubDate>Sat, 03 Jan 2026 00:00:00 +0000</pubDate><guid>https://kianoosh.dev/posts/2026-01-03-the-death-of-the-data-monolith-an-introduction-to-data-mesh/</guid><description>&lt;h2 id="the-people-problem-of-data-platforms">The People Problem of Data Platforms&lt;/h2>
&lt;p>In my previous &lt;a href="https://kianoosh.dev/posts/2026-01-01-the-architecture-of-evolution-why-the-lakehouse-is-inevitable">post&lt;/a>, I discussed how the Lakehouse architecture addresses the technical gaps between Data Lakes and Warehouses. But even with state-of-the-art components, will we automatically have a successful data platform? &lt;strong>OF COURSE NOT!&lt;/strong>&lt;/p>
&lt;p>Engineering is easy compared to people. Who is responsible for which part? How does the organization scale as the business scales? These are critical questions an architect must answer before the wrong structure defines the architecture for them (the Conway&amp;rsquo;s Law reverse maneuver).&lt;/p></description></item><item><title>The Human System: Applying Engineering to Leadership</title><link>https://kianoosh.dev/posts/2025-12-26-the-human-system-applying-engineering-to-leadership/</link><pubDate>Fri, 26 Dec 2025 00:00:00 +0000</pubDate><guid>https://kianoosh.dev/posts/2025-12-26-the-human-system-applying-engineering-to-leadership/</guid><description>&lt;h2 id="the-transfer-of-fundamentals">The Transfer of Fundamentals&lt;/h2>
&lt;p>In a recent article, Mallika Rao (Engineering Manager at Netflix) revisits a familiar friction point in our industry: the transition from maker to manager. She argues that when engineers move into leadership roles, they often stop applying the systems thinking they developed through years of hands-on engineering.&lt;/p>
&lt;p>This is a massive missed opportunity.&lt;/p>
&lt;p>We spend years learning how to optimize throughput, manage load, and debug complex interactions. Yet, when we step into management, we often treat the team as something entirely different, governed by vague intuition rather than structural logic. Rao suggests that systems thinking isn&amp;rsquo;t just for code—it is an essential toolkit for leadership.&lt;/p></description></item><item><title>Discipline Under Pressure: Shipping Without Messing Up</title><link>https://kianoosh.dev/posts/2025-08-20-discipline-under-pressure-shipping-without-messing-up/</link><pubDate>Wed, 20 Aug 2025 00:00:00 +0000</pubDate><guid>https://kianoosh.dev/posts/2025-08-20-discipline-under-pressure-shipping-without-messing-up/</guid><description>&lt;p>&lt;img src="https://kianoosh.dev/images/squid-game-umbrella-cookie-1536x913.jpg" alt="squid game umbrella cookie">&lt;/p>
&lt;h2 id="the-reality-of-urgency-in-startups">The Reality of Urgency in Startups&lt;/h2>
&lt;p>It’s crucial for every senior software engineer, technical leader, or anyone accountable for delivering technical solutions to know how to handle urgent tasks wisely. Let’s call this person a &lt;em>leader&lt;/em> — and today, that’s you.&lt;/p>
&lt;p>In some industries, or at certain stages of a company’s lifecycle, urgent requirements hit technical teams constantly. I currently work as a technical lead at a startup (&lt;a href="https://www.linkedin.com/company/donetech/">Done&lt;/a>), where the rules of the game seem to change every other week.&lt;/p></description></item></channel></rss>