Career 2026-05-13 ⏱ 6 min read

My Career Vision as of May 2026

Articulating my career vision as of May 2026 — aspiring to be an architect who improves the long-term value of organizations and software.

Read in: ja
My Career Vision as of May 2026

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:

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.

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

What I Want to Work On

Technical Contributions

  1. 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
  2. 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

  1. 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
  2. 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
  3. 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

  1. 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)
  2. 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

  1. 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.

Tags: Architect Leadership Thinking Methods
Share: 𝕏 Post Facebook Hatena
✏️ View source / Discuss on GitHub
☕ Support

If you enjoy this blog, consider supporting it. Every bit helps keep it running!


Related Articles