I'm Shian Izumida, a software engineer and engineering manager. RAKSUL has scaled about 500 employees across multi regional offices, and only the printing industry unit - the biggest business in RAKSUL group - has more than 50 software engineers on staff in Japan and Vietnam. In this post, I will share the organization management methods that we have introduced since this year to address quality growth in the scaling organization.
Background
Until now, the talent management of RAKSUL’s software engineers has consisted of competence based Grade Standard, performance based OKR, and 360 degree feedback. And some of them were working on multiple projects managed by different managers. However, along with the company’s scaling, while some of them could work well with high autonomy, others faced some challenges by multiple report line managers such as working prioritization by different management's ownership. Therefore, to address this and strengthen the management structure, we introduced the reporting structure and job description for all positions.
Report line structure
Concept of Engineering organization structure:
We clarified the relationship between the evaluator and the evaluatee on the simple report line. We don’t normally allow multiple hat. Then, this structure makes segregation of duties clear, and be able to focus on our work with clear priorities without worrying about the multiple areas of responsibility required by several managers.
Job Description
For certain senior or higher grade members, the managers define the job descriptions of their direct reports. These job descriptions are public with their OKR/MBO in the company and it can guarantee the transparency for the range of impact their work.
OKR / MBO
We apply OKR as a goal of our team such as delivery schedule of epics, product quality KPI, business KPI and so on. The draft of each project is typically written by TechLead and finalized by engineering managers.
Here is a sample Job Description of a TechLead:
Summary
Having used the job description and report line structure for about six months, here are some GOOD and MORE from me.
Good
- Can leverage job description for recruitment and evaluation of our staff in relation to the general job market
- This helps me explain to my direct reports about how high-level expectation could be associated with their direct reports’ missions
- Published job descriptions are great value when I consider missions for anyone
More
- Quality of job description depends on the managers.
- Strict “police” who remind all managers to submit the job description need until the operation is penetrated
- Simpler competency-based personal development is still good enough for junior to intermidiate software engineers without job description
Of course, not all can follow the above rule perfectly for the moment. But this strongly supports organizational alignment, and encourages everybody to arrange the way toward our same goal. We will continue to optimize our product development performance with better management!
