Show Cover Slide

"Case Study: Structuring a Development Organization by Domain and Designing Hiring Criteria"

gpt-4-turbo has translated this article into English.

Case Study on Structuring the Development Organization and Designing Recruitment Criteria and Interview Flow for a New Service Launch

This case study describes how we structured the development organization’s domain and designed the recruitment criteria and interview process, not just hiring technicians but completing the process with people who can solve problems.

Problem Recognition

The company wanted to implement an automation strategy, but
there was no dedicated development organization in-house,
and it was unclear what roles were needed.
Hiring without defining job roles was seen as ineffectual for embedding technology within the organization as it expanded.

My Design Philosophy

I view recruitment not as “selecting people” but as
“designing a structure with people who can solve problems”.
More important than technical skills is
the mindset that understands the business context and can solve problems with technology.

Design Direction

• Structuring the organization into four domains
  → Service Platform / Data Platform / Devices / Operations

• Analyzing external examples and job definitions to reconstruct roles suited to our business
  → Redefining JDs not in conventional market terms but aligned with our strategy

• Formalizing the interview structure and evaluation criteria
  → Modularizing repetitive questions and focusing on problem-solving skills rather than technical capabilities

• Designing the post-recruitment flow including onboarding structure
  → Structuring systems to ensure growth aligned with direction after joining

Results

• Positioned multiple talents in suitable domains based on role definitions
• Secured technically skilled talents based on business understanding
• Completed forming a dedicated development organization → Established a foundation for internal technology embedding
• Flexible reassignment possible in future service expansions due to domain-centered organizational structure

In Conclusion

A technology organization is not made up solely of technology.
Proper role definition, context-centered evaluation criteria, and a structured onboarding are necessary for technology to truly integrate within an organization.

Our team was completed over about 6 months and launched its first service to the market in just 4 months after that.

• From service development,
• Contracts with third-party suppliers,
• Designing the operational agency process,
• To managing customer delivery, all were internally concluded.

As a result, about 150 customers were able to directly experience our service.
It wasn’t massive growth, but the entire process of recognizing problems, structuring, and executing within a short time was itself a meaningful achievement.

Through this experience, I gained the confidence that a technology organization can also be designed like a platform.

Going forward, I plan to spend most of my time designing people and structures before adopting technology.