How Engineering Teams Structure Project Delivery

Organizing Teams in the Real World Organizing dev teams isn’t just about dividing headcount by the optimal Scrum team size. It’s about creating structures and interactions that minimize inefficiencies and maximize throughput. Imagine you’ve got 40 engineers (front-end, back-end, security, DevOps, BAs, etc.). Some are seasoned; others are less experienced. With limited specialists, equal skill distribution isn’t possible. So how do you balance customer focus, reduce handoffs, and optimize delivery? Approach 1: Functional Teams w/ Centralized Specialists Functional teams are organized by skill. F/E devs in one team. B/E in another. Centralized specialists support everyone. Ex: Five functional teams and a central pool of 3 security engineers and 2 DevOps experts. Pros: Deep expertise within domains. Efficient use of scarce specialists. Cons: Lots of handoffs and delays as features move between teams. Specialists become bottlenecks. Low throughput due to coordination overhead. Result: Prioritizes expertise but sacrifices efficiency and speed. Approach 2: Component Teams w/ Platform Support Component teams own specific architectural layers (e.g., database, APIs), supported by a platform team that builds reusable tools. Ex: Four component teams and a 5-person platform team for shared services. Pros: Clear ownership of systems. Standardized tools reduce redundant work. Cons: Features spanning components require coordination. Platform dependencies can delay delivery. Teams may lose focus on customer outcomes. Result: Improved scalability, but handoffs and misaligned priorities persist. Approach 3: Hybrid Cross-Functional Teams w/ Specialist Support Feature teams are organized around end-to-end business domains, supported by floating specialists or a platform team for niche needs. Ex: Six cross-functional teams, 3 floating specialists, and a 2-person platform team. Pros: Low handoffs. Teams handle most work independently. Customer-centric focus. Efficient specialist use through targeted support. Cons: Demand spikes can stretch specialists. Upskilling generalists requires investment. Result: Balances autonomy, specialization, and throughput. Best Fit: Hybrid The hybrid cross-functional model provides the best balance of autonomy, scalability, and efficiency. This topology reduces handoffs and mitigates skill shortages. Implementing the Hybrid Model 1) Organize teams around business domains (e.g., onboarding, reporting). 2) Use floating experts or a platform team for shared needs (e.g. security, DevOps). 3) Upskill generalists to reduce dependence on specialists for routine tasks. 4) Standardize tools and create reusable solutions to streamline dependencies. Reality Perfectly balanced teams are a rarity. The hybrid model delivers a practical compromise. By minimizing handoffs, focusing on customer outcomes, and optimizing the use of specialists, you can enjoy faster delivery and greater agility despite real-world constraints.

As an advisor to tech scaleups, and a former CTO and SVP of Engineering,  I've often encountered a familiar CEO complaint: "Our engineering team is too slow!" However, focusing solely on increasing individual productivity is rarely the solution. Sometimes the answer is changing the organizational structure. 🔍 The Issue with Flat Structures: Time to market was a major problem in a scale-up I advised, even though they had a flat structure where 40+ engineers reported directly to the VP of engineering and all of them shared equal accountability to the delivery of the software. 🚧 The Consequences: Major overcommitment.  People raised their hands to take on work even if the group was super extended. There was nobody that fully understood the team’s capacity vs the actual workload they took on. This approach led to a lack of predictability, chronic delays, unhappy customers, and ultimately, a tarnished reputation. 🛠️ The Solution: Transitioning to a hierarchical structure with focused teams and accountable experienced leaders was the game-changer. This shift brought in clarity, accountability, and much-needed structure. 📈 The Results: Predictable schedules, improved customer satisfaction, and a thriving engineering culture. ✅ Takeaways for Your Organization: Examine your organization with critical eyes: Is your ownership and accountability structure clear? Are your teams sized and focused appropriately? Do your leaders have the authority to deliver effectively? For more on the case study and about building a sustainable, efficient, and customer-centric engineering team in the blog post. 💭 I'm curious to hear your thoughts: Have you faced similar challenges? How did you address them? Let's share insights and grow together! #EngineeringManagement #Leadership #Productivity  _______________ ➡️ I am Talila Millman, a fractional CTO,  a management advisor, and a leadership coach. I help CEOs and their C-suite grow profit and scale through optimal Product portfolio and an operating system for Product Management and Engineering excellence.  📘 My book The TRIUMPH Framework: 7 Steps to Leading Organizational Transformation will be published in Spring 2024 https://lnkd.in/eVYGkz-e

Let's be honest: extensive cross-team coordination is often a symptom of a larger problem, not an inevitable challenge that needs solving. When teams spend more time in alignment than on building, it's time to reconsider your organizational design. Conway's Law tells us that our systems inevitably mirror our communication structures. When I see teams drowning in coordination overhead, I look at these structural factors: - Team boundaries that cut across frequent workflows: If a single user journey requires six different teams to coordinate, your org structure might be optimized for technical specialization at the expense of delivery flow. - Mismatched team autonomy and system architecture: Microservices architecture with monolithic teams (or vice versa) creates natural friction points that no amount of coordination rituals can fully resolve. - Implicit dependencies that become visible too late: Teams discover they're blocking each other only during integration, indicating boundaries were drawn without understanding the full system dynamics. Rather than adding more coordination mechanisms, consider these structural approaches: - Domain-oriented teams over technology-oriented teams: Align team boundaries with business domains rather than technical layers to reduce cross-team handoffs. - Team topologies that acknowledge different types of teams: Platform teams, enabling teams, stream-aligned teams, and complicated subsystem teams each have different alignment needs. - Deliberate discovery of dependencies: Map the invisible structures in your organization before drawing team boundaries, not after. Dependencies are inevitable and systems are increasingly interconnected, so some cross-team alignment will always be necessary. When structural changes aren't immediately possible, here's what I've learned works to keep things on the right track: 1️⃣ Shared mental models matter more than shared documentation. When teams understand not just what other teams are building, but why and how it fits into the bigger picture, collaboration becomes fluid rather than forced. 2️⃣ Interface-first development creates clear contracts between systems, allowing teams to work autonomously while maintaining confidence in integration. 3️⃣ Regular alignment rituals prevent drift. Monthly tech radar sessions, quarterly architecture reviews, and cross-team demonstrations create the rhythm of alignment. 4️⃣ Technical decisions need business context. When engineers understand user and business outcomes, they make better architectural choices that transcend team boundaries. 5️⃣ Optimize for psychological safety across teams. The ability to raise concerns outside your immediate team hierarchy is what prevents organizational blind spots. The best engineering leaders recognize that excessive coordination is a tax on productivity. You can work to improve coordination, or you can work to reduce the need for coordination in the first place.

Startup CTOs, if you're running engineering for an even slightly complex enterprise B2B product, it's not just Scrum everywhere or Kanban everywhere. You have to configure your teams properly for success, and apply the right process principles to each (or better, guide them to do it). You'll have three different buckets of work: 1. Sales support and onboarding new customers 2. Maintenance and support 3. R&D / innovate Each of these business functions requires a different set of people (or configurations of the same people) with a different approach to getting work done. You can't just smear "agile" on it like peanut butter. The work required for sales engineering is a lot like consulting. It requires careful listening and reflecting back. And onboarding new customers includes dealing with configuration, data imports, integrations, and the like. The process for this team, and its metrics for performance and success, will be unique and different from that of the other two types of work. Projects have a start and finish, and don't align well with either Scrum or Kanban methods. A documented protocol or checklist approach is usually better. Operating an existing customer product tends to involve a steady stream of heterogenous work, arriving randomly, sometimes with urgent response times. Kanban is perfect for this. A "platform team" as described in Team Topologies aligns well here. Teams that are developing new capabilities are the ones we tend to think about the most as "engineering" or "product" teams, as if that's the only thing tech companies do, ignoring the above two to our detriment. These product development or innovation teams can apply principles from Design thinking, Continuous Discovery, and Scrum to enable reliable and predictable delivery of new, valuable capabilities. The value-stream aligned teams concept aligns here. Look, you don't have to break it down exactly as I have said. Use your judgement, and expand your understanding of what is available to you by looking around and learning from other companies and teams. Don't just paint by numbers to build your teams and process. -- If you need help with this sort of thing, I coach CTOs and other technology leaders. I'd love to hear from you. Give me a shout.

Scaling delivery capacity sounds simple on paper, right? Add more people, get more output. But in reality, every new engineer, designer, or manager changes the system. Processes that worked for 30 people may start to break at 60. The way we’ve managed it at FlexMade is by structuring teams around outcomes instead of headcount. Each delivery group owns a complete vertical of work (development, QA, DevOps) and has direct access to the context and decision-makers they need. This setup keeps ownership clear and helps to avoid the handoff trap, where responsibility gets diluted as the team expands. We also invest heavily in internal knowledge continuity. Every new engineer joins a project with a clear understanding of its architecture, business goals, and delivery history. This takes more time in the beginning, but it protects velocity later, when the team grows or changes. So the key for me is to pay attention to two things: how fast information moves through the organization and how clearly accountability is distributed. If either starts slowing down or becoming blurry, we’re outgrowing our current setup. When growth happens gradually, it feels invisible. When it’s rushed, the cracks show fast. And in software delivery, fixing cracks later always costs more than reinforcing the foundation early.

Some teams look fast from the outside. But when you look closely, their real strength is not speed. It is design. Not just system design. Team design. The best engineering teams follow patterns that make both software and people work better together. → 𝐌𝐨𝐝𝐮𝐥𝐚𝐫 𝐀𝐫𝐜𝐡𝐢𝐭𝐞𝐜𝐭𝐮𝐫𝐞 • Break big systems into smaller services • Clear ownership reduces confusion and dependency chaos • Teams move faster when each module has a defined owner → 𝐎𝐛𝐬𝐞𝐫𝐯𝐚𝐛𝐢𝐥𝐢𝐭𝐲 & 𝐌𝐨𝐧𝐢𝐭𝐨𝐫𝐢𝐧𝐠 • Logs, metrics, and tracing create visibility • Teams can detect issues early and respond faster • Better transparency leads to stronger operational control → 𝐒𝐢𝐧𝐠𝐥𝐞 𝐑𝐞𝐬𝐩𝐨𝐧𝐬𝐢𝐛𝐢𝐥𝐢𝐭𝐲 𝐏𝐫𝐢𝐧𝐜𝐢𝐩𝐥𝐞 • Every component should do one job well • Focused ownership improves accountability • It also makes debugging and performance tracking easier → 𝐅𝐞𝐞𝐝𝐛𝐚𝐜𝐤 𝐋𝐨𝐨𝐩𝐬 • Strong teams improve through retrospectives and postmortems • Learning cycles help teams adapt as products evolve • Progress becomes continuous, not accidental → 𝐒𝐜𝐚𝐥𝐚𝐛𝐢𝐥𝐢𝐭𝐲 𝐛𝐲 𝐃𝐞𝐬𝐢𝐠𝐧 • Great systems are built for future growth • Great teams do the same with processes and structure • This prevents bottlenecks before they slow everything down → 𝐃𝐨𝐜𝐮𝐦𝐞𝐧𝐭𝐚𝐭𝐢𝐨𝐧 𝐚𝐬 𝐈𝐧𝐟𝐫𝐚𝐬𝐭𝐫𝐮𝐜𝐭𝐮𝐫𝐞 • Decisions should be written, not just remembered • Shared knowledge improves onboarding and alignment • Good documentation protects momentum as teams grow → 𝐀𝐏𝐈 𝐅𝐢𝐫𝐬𝐭 𝐂𝐨𝐦𝐦𝐮𝐧𝐢𝐜𝐚𝐭𝐢𝐨𝐧 • Clear contracts reduce misunderstanding between services and teams • Structured communication improves collaboration • Everyone works with more clarity and fewer blockers → 𝐂𝐈/𝐂𝐃 & 𝐀𝐮𝐭𝐨𝐦𝐚𝐭𝐢𝐨𝐧 • Automation removes repetitive manual effort • Teams ship faster with more confidence • Reliable delivery creates consistency at scale →  𝐋𝐨𝐨𝐬𝐞 𝐂𝐨𝐮𝐩𝐥𝐢𝐧𝐠 • Independent services enable independent progress • Teams can deliver without waiting on everyone else • This unlocks real parallel development →  𝐑𝐞𝐬𝐢𝐥𝐢𝐞𝐧𝐜𝐞 & 𝐅𝐚𝐮𝐥𝐭 𝐓𝐨𝐥𝐞𝐫𝐚𝐧𝐜𝐞 • Strong systems recover from failure • Strong teams do too through backup ownership and cross skilling • Resilience keeps delivery stable during pressure The hidden truth is this: The way you design your systems eventually shapes the way your teams operate. And the way your teams operate will always show up in the architecture. Follow Umair Ahmad for more insights

Your Project Is Late? It's Not Lazy People. It's Invisible Flow. Most project systems optimize for task tracking. Great. You can count activity. But activity is not flow. The real failure point in complex projects is almost always the same: cross-functional handoffs. Work leaves one team, enters another, and silently stalls in the gap. Traditional plans rarely make that gap obvious in time to fix it. Swimlanes do. A swimlane structure makes one thing brutally clear: who owns what, when accountability shifts, and where execution risk is building right now. That’s operational power. When teams use swimlanes well: ▸Handoffs become explicit commitments, not assumptions. ▸Delays are seen where they start, not where they explode. ▸Meetings shift from “what happened” to “what needs action.” ▸Leaders get clarity without waiting for status translation. ▸Teams align around delivery flow, not just task completion. This is the mindset shift: A project plan should not be a filing cabinet. It should be a live map of coordination. If your team is drowning in detail but still surprised by delays, you may not have a discipline problem. You may have a visualization problem. Deep dive: https://lnkd.in/etqShbbu

What can upper management do to enable a culture of collaboration—even in large projects with multiple teams and managers? Ever wondered how to make large, multi-team projects truly collaborative? In many organizations, a common challenge is ensuring that engineers feel empowered to contribute and learn across different parts of the same project. The good news? Leading companies are actively cultivating cultures that break down silos, fostering a much deeper understanding of the entire system. It’s about enabling engineers to see the bigger picture and contribute wherever their expertise is most valuable. Here are three powerful strategies that are gaining traction: 1. Implementing InnerSource Imagine applying open-source development practices within your company. Engineers are encouraged to contribute code, fix bugs, and propose enhancements to modules owned by other internal teams. This fosters shared ownership, promotes knowledge sharing, and builds a collective understanding of the codebase across the organization. It’s collaboration on a grand scale. 2. Organizing Around Value Streams or Features Instead of structuring teams purely by technical layers (e.g., frontend, configuration backend, observability GUI, observability backend, data plane, service plane), many networking and security companies now organize teams around end-to-end delivery of customer value or features. For example, you might see a dedicated Firewall Team, VPN Team, CASB Team, or DLP Team—each owning their feature across the stack, from UI and APIs to backend and data plane functions. This structure fosters holistic understanding and alignment within teams, ensuring that everyone grasps the full scope of a feature’s delivery. 3. Establishing Guilds or Communities of Practice (CoPs) These are groups of engineers from different teams who share a common interest or specialization (e.g., a “Cloud Security Guild” or a “Performance Optimization CoP”). They meet regularly to share knowledge, discuss best practices, and solve common challenges. CoPs transcend traditional team boundaries, enabling cross-pollination of ideas and continuous learning beyond the formal reporting structure. These approaches directly support the kind of system-wide thinking that’s crucial for effective debugging, resilient design, and growth into impactful architectural roles. They help engineers expand their horizons and take true ownership of the product’s success. #SoftwareEngineering #TeamCollaboration #InnerSource #DevOps #TechCulture #NetworkingSecurity #EngineeringLeadership #CareerGrowth #SystemDesign #Aryaka

People often ask how we manage complex projects as a team of 100 people in 35 countries, and since I'm currently revamping our documentation on this subject, that info is top of mind. Here's 29 pages of content condensed into 1 LI post for a sneak peek into our DO (Doist Objectives) System 👀 It starts with our annual roadmap, which the leadership team builds in Q4 of the prior year. To execute that plan, we organize our work into four areas of priority (Strategic Priorities, aka SPs), each running multiple initiatives simultaneously in quarterly "cycles", and overseen by a Directly Responsible Doister (DRD): • Brand (DRD: CMO): Marketing campaigns, brand evolution, growth initiatives • Product (DRD: Head of Product): New features, user experience improvements, product strategy • Engineering (DRD: CTO): Platform stability, performance optimization, technical infrastructure • Doist (DRD: 🙋🏻♂️): Internal tools, company operations, team effectiveness Planning kicks off four weeks before each quarter when the CXOs provide the DRDs with general guidance and goals. We respond by proposing general plans for DOs (Doist Objectives; projects/initiatives) in line with our annual roadmap. Two weeks before the new quarter begins, the DOs are agreed upon and the team Heads assign team members to cross-functional "Squads" as "Squad Leaders" and "Squad Members". **See photos below to illustrate the squad infrastructure. Each SP typically runs 2-5 major DOs per quarter, meaning we're executing 12-16 significant projects at any time. The quarter begins with a two-week "Foundation Phase", where squads: • Deep dive into the challenges and opportunities their squad faces • Conduct user research • Create comprehensive specs detailing their proposed solutions • Align on execution approach • This phase ensures we have the space to avoid diving too deep into the upcoming cycle while working on the current cycle From there, squads maintain momentum for the following 10 weeks in the "Execution Phase" through established rituals: • Weekly "snippets" in Twist for progress updates and transparency (our version of an async standup meeting) • Bi-weekly recorded demos to showcase work in-depth • Monthly retrospectives on squad health for continuous improvement • Monthly companywide updates on each strategic priority's DOs • Monthly strategic reviews/adjustments by the leadership team • Expectation = each squad should "ship" something weekly Of course, we manage most of this using Twist for communication and Todoist for project management, but more so than the tools, this system works for us because we emphasize clear ownership/autonomy, transparent communication, and just enough processes to stay coordinated without slowing the team down. That was a lot to digest, but I hope it's helpful. Let me know if I can expand on anything or answer any other questions 👇