# ============================================================================= # Published - Growing Engineering from Startup to Series B (verbatim) # ============================================================================= # An article authored by Cedric Ancellin, first published on this site. # Text is preserved as written (including original wording and any typos). # Governed by ../LAWS. Verbatim files are exempt from the em-dash rule. # # Added on 2026-10-21. # ============================================================================= title: "Growing Engineering from Startup to Series B" author: "Cedric Ancellin" published: "2026-10-25" platform: "zc8.com" linkedin_url: "" # set once cross-posted to LinkedIn cover_image: "/assets/articles/growing_engineering_from_startup_to_series_b.jpg" topics: ["engineering organization", "Series A", "Series B", "CTO", "head of product", "Conway's law", "team specialization", "SOC 2", "software capitalization", "knowledge base", "AI coding agents", "zero trust"] summary: > Series A is not the finish line. It is the year that decides whether you reach Series B with a team that scales, or with dozens of people tripping over each other. Cedric has prepared that jump more than once since the late 90s. He starts with the mistake he still regrets, and ends with the one hire that decides everything. body: | In the beginning, it is you and a handful of full stack engineers. You work side by side and you build together. There is little legacy data to worry about, the business is focused on the one thing you sell, and product decisions happen in the same conversation as the code. Everyone is using AI, which makes your small team feel like a much bigger one, and you deliver ahead of schedule. Customers are happy, the business grows, and one day you close your Series A. That is when the real work begins. Series A is not the finish line. It is the money you use to build the foundation for Series B. I have [done this more than once](https://zc8.com/view/resume), from the late 90s and the internet bubble to the present day. I made mistakes, I learned from them, and this is the advice I wish someone had given me during the last three decades. Let me start with the mistake. More than once in my career, a feature went from the business straight to engineering and into production, sometimes with my knowledge, because I did not have the time to review it properly and I folded under business pressure. Legacy data was entered, customer usage took hold, and corrupted data and a corrupted architecture were live. Five years later, the refactoring had still not been done, because it would have taken too many resources away from the roadmap. Instead we built patches, or more precisely cheats, to compensate, which made the fix look less urgent while entire roadmap features quietly became impossible to build. It is like building an annex without the proper plumbing. You got away with it for one bathroom, but now you cannot expand the annex or add a second one without ripping out the foundation. [Francois Granade](https://www.linkedin.com/in/francoisgranade), a peer of mine, calls this an Ugly Duckling: rogue code that reaches production and becomes very hard to reverse, because legacy data and real usage now depend on it. Except this one never turns into a swan. Ugly Ducklings are born in the gap between the business and engineering, and that gap opens the day the funding lands. You are no longer a single goal product. There is now a roadmap focused on revenue and growth. As a startup, the business was used to walking over to engineering, and you were there with your team to make sure everything was built to the agreed specs. Now your engineering team has grown, and if the business goes directly to your staff, it will be a disaster. Engineers usually stay out of company politics and do what they are told. Their profiles vary. Some do exactly what is asked, without question. Others want to prove themselves by doing more than the ask. Both are problems, but not the same problem. I once wrote a spec asking for a button that said Next or Continue, and I received a button that literally read "Next or Continue." That one is on me: the developer followed the spec, and the spec was ambiguous. On another occasion, a developer who thought he knew better labeled the button Save, without telling anyone he had deviated from the blueprint. That one is on him, and it is far more dangerous. The lesson is that you need both: unambiguous tickets, and a culture where deviation is surfaced, never silent. On an interface, that is a minor annoyance. At the database level, the same kind of deviation is how an Ugly Duckling gets hatched. And the same AI leverage that made your five engineers look like twenty at seed stage now lets a single developer and their agents produce one at scale. That is the problem your first year after Series A has to solve. Start by mapping what your engineering organization needs to look like at Series B, when you will have several dozen people under you, and in some sectors a hundred. Then work backward. Before you hire aggressively, there are three things you need to put in place, and one thing about yourself you need to change. The first is to specialize. No more full stack. Build separate teams for infrastructure, for the database, for the engine, and for the frontend. Once the architecture for a new feature is done, the data team builds the schema and the database, the engine team builds the endpoints that return the data, and the frontend team builds the interface. No one crosses teams. Depending on your business, you may need more: an integrations team, or a frontend split between the public side and the private side behind a login and session. I know this runs against the current fashion of cross functional teams, and yes, the handoffs make each feature slower, sometimes much slower. That is the point. At this stage your goal is not velocity, it is control, and what the handoffs buy you is that no single person can ship a feature end to end anymore. A rogue developer can no longer deliver an Ugly Duckling alone, because each team owns its layer and nothing reaches production without the others. Conway's law is usually quoted as a warning: your architecture will end up mirroring your org chart whether you like it or not. I treat it as a tool. If I want a system with hard boundaries between the database, the engine and the interface, I build an organization with those exact boundaries, and the architecture follows. And the segregation is not only for developers. Their agents inherit the scope of the team that runs them: a database team's agents never touch the frontend, and an engine team's agents never write a schema. Put your developers and their agents in a zero trust environment with clear boundaries they cannot escape, as I described in my article [Zero Trust Is Being Rewritten](https://zc8.com/published/zero_trust_is_being_rewritten). The second is a head of product, the bridge between the business side of the company and your developers. Have them report to the CEO rather than to you, so neither side can claim the bridge has been captured. It is the hire you must drive, even though they will not report to you, and the one most responsible for whether you are ready for Series B. Your head of product installs a ticketing system, and no development starts without a ticket. Business talks to product. Product talks to engineering. Engineering talks to product. You have built a firewall between the business and engineering, and product is the bridge. Be clear about what the firewall means. Engineers still talk to each other, to you, and to the rest of the company freely. But every conversation between business and engineering happens with product in it, request or not, because a product team that misses the conversations misses the context, and direct collaboration between business and engineers without product in the loop is how Ugly Ducklings get commissioned. Work follows the same rule: it comes from product or it does not come at all. This will be very unpopular, and it will be your biggest fight, especially if your management team and investors are not engineers and see development either as AI magic or as a factory where adding workers means getting more done. Roadmap, processes and tickets all run through product, which is why your head of product becomes so crucial. Architecture stays with you. Compliance and security keep their own reporting lines, but their asks reach engineering the same way as everyone else's, through a ticket. You will work more closely with that person than with anyone else in the company. No code is written without a ticket. All development is tracked, categorized, and follows an established SDLC with formal handovers between teams. Any change to the spec during development closes that ticket and opens a new one. Tag your development work for software capitalization as well, so finance can derive opex and capex from the tickets. The principle is clear: new feature development past the design stage can usually be capitalized, while maintenance and bug fixes are expensed, and your auditors will draw the exact line. The ticket categories become the evidence trail they accept. This is the move that brings your CFO and investors to your side. They are already eyeing Series B, and they will help you impose the process on the business. The same rule applies to you. To be clear, this is not a gag order. You still architect with your teams, review their work, answer their questions and solve their problems directly. What you give up is handing them work: even your own ideas become tickets and go through product, because a roadmap the CTO can bypass is not a roadmap. With the business, your job is to be the bad guy who protects your head of product. With investors, you get to be the good guy: you give them the reporting they need, and your roadmap gets delivered because you reframed it from unrealistic business dreams into reality. The third is process and documentation, with SOC 2 as your guide and your target. Start collecting evidence in year one and aim for Type I first. Type II follows, and it requires months of history that cannot be backfilled when Series B diligence comes asking. Beyond compliance, build an AI friendly knowledge base that captures everything that has been done, everything that is planned, and everything that has been contemplated: the architecture decisions and the reasons behind them, the schemas, the endpoints, the specs, the tickets, and the options you rejected and why. Make it machine readable and plug it into your tooling, so an agent answers from your documented architecture instead of guessing from the code, and a new hire spends the first week learning from it instead of interrupting. Your product team, engineers and their agents will live off that knowledge base, and every answer it gives is a question that never reaches your desk. And finally, you stop coding. You architect, you document, you answer questions, you review, and you solve problems. You restructure, you delegate, and you grow the team in a way that spreads knowledge and reduces dependence on key people, so the roadmap gets delivered and the company is ready for what comes next. These steps sound simple. They are extremely hard to implement. Expect your founding engineers to be the first casualty of the reorganization. The handful of full stack generalists you built everything with will not all fit neatly into one layer. Some will become your team leads and thrive, and those leads are your first management layer, which you will need, because by Series B not everyone can report to you. Others will resent being boxed into the database or the frontend after owning the whole stack, and you will probably lose one or two of them. It hurts, it feels like a betrayal of the people who got you here, but it is still the right move. A company that depends on three people who hold everything in their heads is not a company a Series B investor will fund. The first year is many battles and a lot of perseverance. But by the end of it, your teams are split, your processes are established, and everything is documented. The second year is when you grow, and you add the functions a Series B company needs: - A dedicated compliance team, under operations - A dedicated internal IT team, under operations. Laptops, accounts, access control, onboarding and offboarding: your SOC 2 auditor will ask for all of it, and it settles once and for all that IT and engineering are not the same thing - A dedicated security team, under you - A dedicated data and analytics team, under you. Your database team builds the product's data layer, but someone has to own the business metrics and KPIs your Series B deck will be built from - A dedicated QA team, under product. QA verifies that what shipped matches the ticket, and the ticket belongs to product. An engineering team grading its own homework is not a control your auditor, or your head of product, should accept - The SOC 2 Type II audit and the other certifications your market requires That is the foundation. Series A gives you the money. What you do with the first year decides whether you reach Series B with a team that scales, or with dozens of people tripping over each other's Ugly Ducklings. And if you keep only one piece of advice from this article, make it this one: hire a competent and experienced head of product first. Everything else gets easier with the right one, and nearly impossible without. transcription: "As written by Cedric Ancellin, first published here 2026-10-25."