Krishna Dey Essay
The engineering manager's second architecture
Software architecture is only half the job. The operating system around planning, ownership, review, and decisions is what determines whether a team can actually use that architecture.
Most engineering teams debate service boundaries more carefully than they design how work actually moves.
That is a mistake.
An engineering manager is responsible for a second architecture: planning cadence, ownership, review layers, decision records, incident follow-through, and how clarity travels through the team. This layer is less visible than code. It has more leverage than another clever abstraction, because it governs whether good engineers can turn intent into delivery.
When this layer is weak, even strong people lose time to uncertainty. Priorities feel random. Reviews drag. Meetings become a substitute for a missing system.
When it is strong, people know where a decision belongs, when to escalate, and what “done” looks like before they start.
I used to think of architecture as services, APIs, queues, and databases. That is still part of the job. It is no longer enough. Architecture also includes how the team operates.
What the second architecture actually includes
The second architecture is the set of defaults that determine throughput:
- who owns a surface, and what “ownership” means in practice
- how specs get written before implementation starts
- which reviews catch architecture risk versus implementation quality
- where decisions live after the meeting ends
- how incidents produce follow-through instead of folklore
- how planning turns into sequenced work instead of a calendar event
None of that replaces technical design. It determines whether technical design survives contact with a real organization.
At SpotDraft I lead engineering across Integrations and Platform, with work that also touches developer experience, reliability, and AI-assisted development. Those domains produce the same pattern: the product problem is rarely only a product problem. It is also a coordination and operating-design problem.
If multiple teams keep solving the same pain, there is often a missing platform. If the same people keep heroically unblocking delivery, there is often a missing operating system.
Legal Intake made the operating system visible
Legal Intake started as a 2024 hackathon idea and became a shipped product. The lesson I keep from that work is not only the product surface. It is that execution can be engineered.
I introduced spec-first planning, phased milestones, explicit ownership, Jira-based execution, QA ownership, visible risk tracking, and reusable planning templates. Those mechanisms sound managerial. They were architectural. They changed what the team could hold in its head at once.
Without that layer, a high-context product effort collapses into status meetings and heroic memory. With it, people can disagree about a milestone because the milestone exists as an object, not as a vibe.
That is the second architecture in practice: make the work inspectable, then staff it.
Reverse Sync needed both architectures
Salesforce reverse sync could have been framed as a one-off integration. Ship the Salesforce version. Hardcode the mappings. Celebrate the customer.
We treated it as a reusable automation model — triggers, conditions, object mappings — because the second customer would otherwise pay for the first customer’s shortcuts.
That is software architecture.
The operating architecture around it was equally important: who owned the primitive, how we talked about it as a product surface rather than an engineering chore, and how later native integrations (HubSpot, Coupa, Slack, and others) could inherit a way of thinking rather than a pile of special cases.
If you only design the object model and leave ownership implicit, the reusable design decays into tribal knowledge. If you only design the process and leave the technical model customer-specific, you get a well-run one-off.
You need both.
Reliability is an operating system, not a sequence of incidents
I have spent a lot of energy trying to turn operational pain into something measurable: dashboards, observability, ownership, incident follow-through, on-call, platform improvements.
The important shift is not “we had fewer incidents this quarter,” which may or may not be true and is easy to game. The shift is treating reliability as an engineering operating system.
Incidents will happen. The second architecture asks: is there a default path from detection to ownership to follow-through, or does every event require a senior person to reconstruct the story?
Heroics are sometimes necessary. They should not become the model. If a problem keeps requiring exceptional individual effort, the missing piece is usually a system.
Review load is architecture too
As teams grow, managers become accidental review bottlenecks. Everything interesting waits for one person’s comments.
I have been trying to split that load on purpose. Implementation quality can move through peer and technical-lead review. I want more of my review time on architecture, contracts, risks, edge cases, and high-context decisions.
That is not stepping away from engineering. It is choosing the layer where a manager’s attention actually multiplies.
The same idea applies as AI enters the loop. If coding agents draft more of the implementation, the scarce resource becomes specification quality, evaluation gates, and review judgment. Managers who only know how to “stay in the code” will sit in the wrong layer. Managers who only know how to run process will not be able to evaluate the new tools.
The second architecture has to absorb AI the same way it absorbed CI, on-call, and planning: as a designed system, not as a pile of individual habits.
How to start if the operating system is implicit
You do not need a grand reorg. You need a few inspectable defaults:
- Write the decision before the implementation, even if the first spec is short.
- Name an owner for every recurring surface, including the unglamorous ones.
- Separate architecture review from implementation review so both can actually happen.
- Put risks where people can see them, not only in someone’s 1:1 notes.
- After an incident or a painful delivery, ask what system was missing — not who failed.
I still stay technically close to the systems I lead. I increasingly measure impact by what continues to work when I am not directly involved.
That is the second architecture: the one that keeps the first architecture alive.