Introduction
I felt the need to articulate the direction of my career once again, so I'm putting down my career vision as of May 2026.
Thoughts naturally evolve over time, but writing them down at milestones lets me look back later and trace what I valued at the time.
Summary
I aspire to be an architect who improves the long-term value of organizations and software. Organizational and software structures inherently synchronize through Conway's Law, and I believe people who can intentionally design both axes are rare.
To this end, I place "what others can achieve through the systems I build" — rather than the code I write myself — at the center of my values. I anchor my work in architectural design and decision-making while stepping into hands-on leadership or organizational work as needed to deliver results. I always explain technical decisions in connection with business and user value. Ultimately, I aim to leave value at the DNA level of the organization.
This vision builds on past experience (freelance web development → startup → in-house infrastructure design at a business company) and current strengths (structured thinking, hands-on experience in cross-cutting domains, team lead experience), and stems from a desire to deliver greater impact to the organization.
Purpose
To improve the long-term value of organizations and software, and contribute to the business, as an architect.
Not just to show technical skills, but to produce greater outcomes through teams.
Core Values
What is the Value of an Organization?
A state where outcomes are continuously produced through systems and culture rather than individuals, adapted to change, and propagated across the entire organization.
I break the components down as follows:
- Reproducibility: Anyone can produce a baseline level of outcomes (no over-reliance on individuals)
- Learning ability: The ability to learn and self-update from environmental change and failure
- Propagation: A mechanism by which improvements and successes spread to other teams and the wider organization
- Sustainability: The ability to execute short-term outcomes and long-term investments (paying down tech debt, growing people, etc.) in parallel
What is the Value of Software?
Total value that starts from the direct value delivered to users and business, and extends to the ability to maintain and evolve that value over the long term.
The weight of these dimensions shifts depending on time horizon.
| Time Horizon | Nature of Value | Key Indicators |
|---|---|---|
| Short-term | Delivering user / business value | Functionality, experience, contribution to business KPIs |
| Mid-term | Changeability, evolvability | Lead time, change failure rate, extension cost |
| Long-term | Reliability, operability, knowledge inheritance | Availability, MTTR, onboarding cost |
The longer the horizon, the more dominant "design quality" becomes. I see the architect as someone who decides how to weight value across time horizons.
Synchronizing Organization × Software
Organizational and software structures inherently align (Conway's Law). The state in which both can be intentionally synchronized and controlled is the source of long-term value.
- Idealizing only the architecture without changing the organization causes design and reality to diverge until things get pulled back to the original shape
- Even good design becomes obsolete if the operating organization can't sustain it
- Even a good organization will redo the same work across teams if shared foundations don't scale
- People who can design both axes simultaneously are rare, and that is the essential value of the architect role
The Value of Technology that Scales Through Teams
Technology that lifts others' productivity through systems, foundations, and standards — accumulated as organizational assets — without depending on individual capability.
I value what others can achieve through the systems I build more than the code I write myself.
I think of value progression as: individual skill → team standard → organizational asset → organizational DNA.
It's more impactful to build a system through which 10 people can produce 80% of their potential than for one person to produce 100%. Hands-on output scales linearly, but systems, foundations, and standards compound their value over time.
Motivations: Why Aim to Be an Architect
1. I've Felt the Value of Technology that Scales Through Teams
I believe technology scales through teams more than through individuals.
From my past experience as a lead engineer driving development, I felt that lifting the technical capability of an entire team has a much greater impact than improving individual capability alone. I value the outcomes and growth that emerge through collaboration, and I want to contribute to building systems that let teams produce sustained outcomes.
2. I Want to Use My Structured Thinking and Abstraction Skills
I'm interested in surveying system components and designing for reusability, scalability, and consistency. I believe I'm good at structurally organizing complex problems and seeing through to the essence via abstraction, and I want to apply that to structural challenges in organizations and systems.
3. I've Internalized the Value of Cross-Cutting Foundations
I've designed and built foundational areas — authentication, notifications, permission management — that affect many teams and products. From that, I've experienced how a single foundational system can affect the development efficiency and quality of an entire organization, and I've internalized that cross-cutting technical foundations underpin long-term organizational value.
4. I Want to Design Both the Organizational and Software Axes
As Conway's Law shows, organizational and software structures influence each other. Optimizing only one collapses. The role that can see both axes simultaneously and drive their evolution in sync is rare, and I see it as a place where I can bring my structured thinking, foundational experience, and team lead experience together.
5. I Want to Produce Bigger Outcomes
I want to take part in high-impact decisions and support, in a position that shapes the direction of the business and product as an architect.
Stance
- Balance hard skills and soft skills
- Beyond technology, I value coordination, communication, and the ability to bring people along — grounded in the context of the team and organization — to actually deliver outcomes
- Have interest in and understanding of the business
- Aim for a state where I can explain why a design contributes to the business, not just optimize technology in isolation
- Be conscious of organizational propagation
- Favor horizontal spread over local optimization. Design the flow: improvement in one team → systematization → rollout to other teams
What I Want to Work On
Technical Contributions
-
Designing technical foundations that span the organization
- Design foundations that integrate concerns shared across many products and teams (authentication, notifications, permission management, etc.) to lift development efficiency and quality
- Aim for reproducible, accountable architecture grounded in standard specifications and design principles
-
Removing business growth bottlenecks through technology
- Design non-functional requirements (scalability, availability, performance) systematically at a level appropriate to the business phase
- Make technical decisions where short-term business demands and long-term maintainability coexist
Organizational Contributions
-
Formulating and executing mid- to long-term technical strategy
- Articulate the desired state and priority issues based on the direction of the business and technical constraints
- Decide how to handle technical debt in a way that balances short-term development speed with long-term maintainability
-
Systematizing decision-making and knowledge inheritance
- Make clear who decides what and when, and document design decisions in a form that successors can inherit
- Design processes that standardize individual successes and propagate them across the organization
-
Building a sustainable engineering organization
- Through cultivating technical culture and improving development efficiency, create a state where the organization continues to deliver outcomes
- Through hiring, growing people, and producing the next generation of leaders, build an organization that doesn't depend on specific individuals
Business Contributions
-
Connect technical decisions to business value
- Explain the effect of technical initiatives — and the "cost of not doing them" — in business indicators and cost terms, so management can discuss them as decisions
- Choose the right architecture for the business phase (with the premise that "always-correct design" doesn't exist)
-
Expand business options from a technical starting point
- Proactively propose new features and business models that become possible because of technology, positioning technology as a force that drives the business
User Contributions
- Foundation decisions starting from user value
- Surface user experience degradation as a technical issue and reflect it in the prioritization of foundation investments
- Always keep user value as the axis of judgment, so foundation investments don't become engineers' self-gratification
Closing
The vision I've laid out here reflects my current thinking. I expect both the wording and the granularity to change as I gain more experience.
Even so, the axis "to improve the long-term value of organizations and software as an architect" likely won't change for the time being, so I want to keep accumulating daily decisions and learning along that direction.