enginner ladder 관점에서 지난 3년 반 주니어 생활을 회고한다.
http://www.engineeringladders.com/
This framework allows software engineering managers to have meaningful conversations with their direct reports around the expectations of each position and how to plan for the next level in their career ladder.
진유림님의 '주니어 개발자를 위한 시니어 레벨업 가이드에 소개된 적 있다.
구성 요소
Technology: knowledge of the tech stack and tools
System: level of ownership of the system(s)
People: relationship with the team(s)
Process: level of engagement with the development process
Influence: scope of influence of the position
크게 기술, 시스템, 사람, 프로세스, 영향력이 있는 것 같다.
각각을 더 구체적으로 살펴본다.
테크
Technology
1. Adopts: actively learns and adopts the technology and tools defined by the team
적극적으로 배우는 단계로 이해했다.
2. Specializes: is the go-to person for one or more technologies and takes initiative to learn new ones
go-to person: 어떤 기술의 전문가. 사람들이 궁금할 때 찾아가는 사람.
3. Evangelizes: researches, creates proofs of concept and introduces new technologies to the team
proofs of concept: 신기술이 실현 가능한지 확인하는 과정인 것 같다.
4. Masters: has very deep knowledge about the whole technology stack of the system
5. Creates: designs and creates new technologies that are widely used either by internal or external teams
시스템
System
1. Enhances: successfully pushes new features and bug fixes to improve and extend the system
Designs: designs and implements medium to large size features while reducing the system’s tech debt
2. Owns: owns the production operation and monitoring of the system and is aware of its SLAs
3. Evolves: evolves the architecture to support future requirements and defines its SLAs
4. Leads: leads the technical excellence of the system and creates plans to mitigate outages
사람
People
1. Learns: quickly learns from others and consistently steps up when it is required
2. Supports: proactively supports other team members and helps them to be successful
3. Mentors: mentors others to accelerate their career-growth and encourages them to participate
4. Coordinates: coordinates team members providing effective feedback and moderating discussions
5. Manages: manages the team members’ career, expectations, performance and level of happiness
프로세스
Process
1. Follows: follows the team processes, delivering a consistent flow of features to production
2. Enforces: enforces the team processes, making sure everybody understands the benefits and tradeoffs
3. Challenges: challenges the team processes, looking for ways to improve them
4. Adjusts: adjusts the team processes, listening to feedback and guiding the team through the changes
5. Defines: defines the right processes for the team’s maturity level, balancing agility and discipline
영향력
Influence
1. Subsystem: makes an impact on one or more subsystems
2. Team: makes an impact on the whole team, not just on specific parts of it
3. Multiple Teams: makes an impact not only his/her team but also on other teams
이 부분은 회사에 따라 다를 것 같다. 실 내에 기술 교류가 많으면 Multiple Teams에 영향력을 행사할 수 있지만, 그렇지 않다면 여러 팀에 영향력을 행사하는 것은 힘들 수 있을 것 같다.
4. Company: makes an impact on the whole tech organization
5. Community: makes an impact on the tech community
현재 상태
지금 내 상태를 다이어그램으로 그렸다.(개발 경력 3년 반)
Tech
Specializes에 못 미치는 상태다.
Specializes는 어떤 기술에 대해서 사람들이 떠오르게 되는 사람이다.(java에 대해서는 ooo님에게 찾아가야겠다~라고 떠오를 수 있는 수준)
왜 아직 specializes에 못 미쳤다고 느끼고 있을까?
팀에서 사용하는 기술은 spring, java, elasticsearch, mysql, tomcat, netty, aws 등이다.
개발 2년차에 elasticsearch에 대해 전문가가 되기 위해 노력했다. 하지만 당시 sql과 비교되는 nosql의 필요성을 모른 채로 공부했다. 기초 개념을 모른 채 세부사항에 대해 공부하는 건 한계가 있었던 것 같다.
System
Owns에 못 미치는 상태다.
위 ladder 사이트에서 글을 읽으며, 내가 팀 시스템의 SLA를 모르고 있다는 것을 알게 되었다.
Owns의 요건은 팀 시스템 SLA에 대해 알고 있는 것이다.
Process
Enforces에 못 미치는 상태다.
Enforces를 못한다는 건 요즘 들어 많이 느끼는 문제다. 스스로 팀 룰을 잘 지키고 있다고 생각했지만, 막상 동료가 팀의 전통과(컨벤션) 다른 방식으로 작업할 때 반대하지 못했다.
신규 입사자에게 이렇게 설명했다. 예로 들어 배포 방식도,
"보통 저희는 워커/배치를 배포한 후 API를 배포해요. API를 먼저 배포한 기억은 없어요."
컨벤션이라는(규칙) 것을 강조하기보다, 평소에 많이 해왔던 방식임을 강조했다.
팀의 컨벤션이나 규칙에 대해 이해하고, 이유를 얘기하며 팀원에게enforce(강제)할 수 있어야 할 것 같다. 강제라는 어감이 별로니, 적극적인 설득이라고 하자.
People
Mentors 단계에 이르지 못했다.
다른 개발자에게 커리어 패쓰를 조언할 수 있을지 모르겠다.
Supports 단계에는 이른 것 같다.
다른 팀원들의 작업에 관심을 가진 적 있으며, 적극적으로 간섭하여 응원했던 기억도 있다.
Influence
팀 전체적으로 영향력을 준 적은 있는 것 같다.
자동 배포 구조를 만들 때나, 리뷰 브랜치 삭제 구조를 만들 때 팀원들의 동의를 얻어서 팀 전체에 적용한 적 있다.
다만 전사 활동이나 커뮤니티 활동을 한 적은 많지 않다.
앞으로도 크게 할 생각이 없다.
되고 싶은 목표
Tech
Masters를 할 수 있으면 좋겠다.
특정 기술의 세부 사항을 아는 것은 한계가 있다고 느낀다.
데이터베이스의 전반적 지식, 네트워크의 전반적 지식, 분산시스템에 대한 지식이 필요한 것 같다.
그 지식들을 기반으로 세부 기술들을 더 잘 이해할 수 있을 것이다.
System
Evolves를 할 수 있으면 좋겠다.
팀 SLA를 정의할 수 있어야 한다.
현재 SLA에 대해서 인지하고 있어야 하고, 미래에 나아가야 하는 SLA가 무엇인지 고민할 수 있어야 한다.
Process
Adjusts를 하는 것이 목표다.
때때로 설득력 있게 enforce할 수 있다.
문제제기도 근거를 기반으로 할 수 있다.
다른 사람의 문제제기를 기반으로 process를 수정할 수 있다.
People
Mentors를 할 수 있는 수준이 되면 좋겠다.
Mentors 단계에서 다른 사람의 커리어에 대해 조언을 할 수 있다.
~일을 해보니까 개발에 많이 도움이 됐어요, ~일을 하니까 성장에 많이 도움 되더라구요. 등의 말을 할 수 있는 단계일 것 같다.
나는 어떤 경험에서 많이 성장했을까?
Influence
영향력은 Tech나 System에서 일정 수준 이상의 성취를 하면 자연스럽게 따라온다고 생각한다.
커뮤니티 활동, 회사 전체적으로 영향을 끼치고 싶다는 필요성은 느끼지 못한다.
Team을 목표로 했다.
Action Item
[-] 기술 습득에 필요한 기초 CS 지식 익히기
[-] 두 개 기술에 대한 강의자료 만들기
[-] 나에게 필요한 기술 커리어가 무엇인지 적기.
----[-] 가고 싶은 직군에 면접 보기
[-] 내가 하고 싶은 기술이 무엇인지 적기.
