At some point or another, most software developers find themselves at a career crossroads.

In one direction is comfort, ease, and predictability. In the other? Challenge, intention, and responsibility. (And, yes, higher salaries to go along with them.) That second route is what happens when developers start to think more deeply about the systems behind their work, but some people struggle when it comes to knowing whether they’re ready to take that leap.

Remember in The Matrix when Neo starts to see the simulation as cascading lines of green code? Only when he can envision the underlying form of the program does he truly understand the Matrix, and gains the ability to control it. When we stop thinking about APIs and start thinking about the systems they’re part of, we gain similar power.

At our 2025 Platform Summit, Burns and McDonnell’s Bonnie Why joined us to talk about what she calls “architectural instincts” and how they can lead to significant changes in an individual contributor’s growth and responsibility. Thinking more like an architect isn’t (just) about scoring a promotion or title change, but is the beginning of a transition of how you view APIs.

In this piece, we’ll cover some of Why’s architectural instincts, as well as actionable tips for nurturing and responding to them, and how shifting focus from individual features to designing broader system architecture and API strategies can improve consistency and scalability.

What Is an Individual Architect Anyway?

At first glance, the distinctions between terms such as “individual contributor” and “individual architect” might seem like semantics. In fact, they’re a reflection of two very different mindsets.

An individual contributor (IC) contributes to an organization through a specialized skillset. This could be a data engineer, front end developer, or an API developer for the purposes of this blog post. ICs typically don’t have the responsibility of managing other employees, with their focus instead on executing tasks within their area of expertise to the best of their ability.

The individual architect role, on the other hand, marries “individual contributor” and “systems architect.” It’s less an official title and more a way of thinking beyond individual tasks, with the aim of developing an understanding of how everything fits together. An individual architect needs to be able to see both the forest and the trees.

Where an individual contributor would look at a piece of code or documentation and think “I understand how this works, so that’s good enough for me,” an individual architect asks:

• Will others understand this?
• What happens if this stops working?
• How does this decision affect existing integrations?

“At first it feels like a burden,” Why observes. “Like you’re the only one who cares; the only one who sees it. But it teaches you how to illuminate the system.” Change is often born out of frustration, and systems architecture is (unfortunately) no exception to that rule.

But Why suggests an upside to feeling this way: “Every architect I admire didn’t start with confidence. They started with confusion and learned how to make something useful out of it.”

5 Architectural Instincts Worth Listening To

So, how does one transition into having a more architectural perspective at an individual level? Let’s look at some of the architectural instincts that Why highlights in her talk:

1. Pattern Recognition

“Great architects don’t just solve problems, they show other people where they are.”

The more you work on an API, or set of APIs, the more likely you are to identify signs of drift. Where, in other words, things are moving in the wrong direction, and certain user pain points keep occurring. You can measure drift through common errors, support tickets, and so on.

It’s easy to ignore these patterns, especially if you’re not directly responsible for them.

But Why describes how, when looking at a system, she’ll “try to understand something that’s missing, something that I have to explain all the time.” With a proactive approach, you can actively turn those missing pieces into artifacts — documentation, lint rules, and so on.

2. Trade-Off Thinking

“Great architects don’t just handle ambiguity, they give people a way through it.”

“Every decision is a compromise,” Why states. She provides the example of rushing to meet an upcoming deadline: “Do we spend a bit more time now and make things right, pushing back deadlines so that we can actually meet them? Or do we make an entire castle out of duct tape and hope we have time to fix it before it creates a ton of problems in production?”

While an individual contributor might feel a trade-off (and its consequences), an architect will make it visible. “My favorite way to practice this,” Why says, “is writing architectural decision records (ADRs).” An ADR is a record of what went into the decision, she adds, so that other people can understand where you were coming from.

A simple ADR might include:

• Title
• Status
• Context
• Decision (including other options not chosen)
• Consequences

Try writing an ADR for one decision you make every week, even if it’s only a small one, making sure to document an alternative that you didn’t choose and explain why you didn’t choose it. They can be particularly valuable for highlighting how a choice will make future decisions easier (or more difficult) in the future, and what precedent it sets.

3. Systems Thinking

“Great architects focus on how parts fit together, not just how one thing works in isolation.”

When you’re locked into working on individual features or components in isolation, achieving that sort of big picture thinking can be tricky. Why suggests that “code is not [always] the cleanest, clearest way to explain things to people, even to developers.” One solution to that problem is to use something like the C4 model to help you zoom out.

“Diagrams are a great way to express the topology and ecosystem of your project,” Why says, describing the C4 model as “four diagrams broken up by common layers of abstraction: the system, container, component, and code.” She describes the model as follows:

• System context: Describes a system that delivers value to its user.
• Container: Something that needs to be running for the overall system to work.
• Component: Group of related functionality encapsulated behind an interface.
• Code: Individual code elements constructed with classes, interfaces, functions, and so on.

Maintaining a living system diagram helps you understand the machine you’re building cogs for and breaks down the abstract idea of “the system.” The latter of which will only become important as the agentic orchestration of APIs, MCP, Arazzo, and the like gather steam.

4. Failure Awareness

“Great architects change and lead without being asked.”

Keeping a close eye on potential failure points might sound pessimistic, but it has a lot of value: “If you understand what will break first, then you’re going to be able to get to it quicker — check for what’s missing, what’s fragile, where dependency issues lie, and other points of failure.”

To improve awareness of failure points, Why recommends fitness functions. Unlike unit tests — “which validate code, not systems” — and observability — “answers questions about what’s happening when the system runs” — fitness functions are “continuous automated checks that ensure a system is abiding by the characteristics you care about.” They protect architecture.

Fitness functions (which can be automated) ensure that architectural efforts lead to meaningful outcomes, avoid drift, and limit technical debt. As a natural extension of continuous integration, their aim is to reduce the overall number of failure points in play as you identify them. Examples might include latency of core endpoints, error rate thresholds, and schema validation.

5. Communication Shift

“Great architects create clarity and structure for themselves and others.”

A word of warning: there’s a degree of risk involved when trying to combat the issue of siloization. If you don’t tread carefully, it might feel like you’re overstepping boundaries or trying to make people feel like they have to explain themselves.

That’s not the aim here. Rather, the goal is to foster a collaborative environment in which everyone feels comfortable sharing what they’re working on, highlighting any issues they’re having, and explaining the logic behind any major decisions they’re making.

A weekly stand-up or daily scrum might be enough to achieve that, but Why suggests that group code reviews across the organization (including non-technical audiences where appropriate), pair programming, actual PR reviews, and presentations can all be helpful tools as well.

Beyond the Individual Architect

To recap the architectural instincts and suggested action points above:

• Create diagrams for your current system(s)
• Start writing ADRs to explain your decision-making
• Ask one system-level question per task
• Implement fitness functions and identify points of failure
• Explain your work to people outside your team

We can see that most of them boil down to the following: taking a more holistic approach to development than focusing on a single feature or release, along with a conscious effort to take things from “good enough” to “as good as they can possibly be.”

The world of video games offers a helpful analogy here. Where a AAA game might have a team of sound designers, programmers, concept artists, and level designers — individual contributors — working in sync, a solo developer (solo dev) manages all of those elements themselves.

Since its release, the solo dev creator of Stardew Valley (Eric Barone) has brought in a small team to assist with updates and ports. By embracing the tenets of being an individual architect — careful iteration and refinement, making difficult decisions that he feels comfortable standing behind, and so on — Barone has successfully transitioned from solo dev to game manager.

That’s not to say, however, that management is or needs to be the final goal of every individual architect. Best practices associated with system architecture inevitably improve the execution of development projects, make implementation more straightforward, and reduce technical debt if or when a project needs to be handed over or expanded beyond one person’s capabilities.

As Why notes, developing this awareness can also open new opportunities. She details her own forays into ambiguous areas and taking ownership of unclear problems, as well as improving your knowledge and gaining additional experience in the field. This can be valuable from a career growth perspective too: it demonstrates a deeper level of engagement with your work.

The shift to individual architect doesn’t come from a promotion, but comes when you start considering the whole system, even when you’re working as part of a team. Listen to those architectural instincts, and you’ll be seeing the world as cascading green code in no time.