Developer Incentive Alignment for InnerSource Contribution
TBD
- The organization needs to adopt a more collaborative, open source like workstyle, but its developers are not properly incentivized or extrinsically motivated to participate in the company’s InnerSource processes.
- There is a prevailing attitude in the developer culture that helping or contributing to others' success and learning is a “time sink” or "not my job."
- Credit and kudos are not consistently shared with developers who help or contribute to others' success.
- Prevailing developer culture is such that many believe the way up the organizational ladder - via increases in title or compensation - depends on one’s performance on quantitative metrics such as lines of code output, deadlines met, ownership of product releases or updates, and so forth.
- Developers aren’t moving up the ‘organizational ladder’ because it is perceived as a path toward people management and direct reports, rather than a path of deepened respect or capabilities in engineering.
- There is a need to foster team-centric behaviour and limit instances of ego-driven development or idolizing a 'star developer.'
- There are multiple developers within the organization or business unit with the same or related areas of expertise, such as front-end development, devops, testing, etc.
- Mid-to-top level management either do not have a technical background or their technical backgrounds and experiences are many years out of date; organizational emphasis is therefore on quantitative output of development team.
- The organization wants to create more alignment between work efforts and external motivation without relying directly on financial rewards or quotas.
- The organization is comfortable with a personnel management and/or professional development style that is organic or “bottom-up” as opposed to traditional training or development programs run through HR (even as task management or velocity is managed in a more top-down fashion).
- Existing attitudes and developer culture
- Team-centric behaviour is not evident. Developers of all levels tend to focus mostly on their own contributions. When stories are assigned, work is often done ‘locally’ and not pushed up or checked in until the end of the sprint.
- Asking developers to push code early and often is met with extreme resistance, accusations of micro-management, or claims that such a practice would slow velocity.
- Existing practice commonly leads to duplicated work, missed requirements, or frequent gaps in the software or process.
- Need to retain developer talent
- Managers focus heavily on tasks or velocity for developers rather than providing mentorship. Developers view helping or mentoring others as the job of Management, or something “I don’t get paid to do.” Career progression, or other ‘upward mobility paths’ (to receive a raise, for example) are not clearly identified in the organization.
- Existing job descriptions, promotion tracks or compensation bands are opaque or hard to get from the organization’s HR department, resulting in a mixed understanding of job responsibilities. This puts additional pressure on performance review or improvement plans because HR, developers and managers don’t have shared a shared understanding of roles or expectations.
- 'Home growing' developer talent - encouraging career growth within the company - is far cheaper for organizations in the long run than hiring from outside. Studies show employee retention increases as new opportunities, challenges, and paths for learning are introduced.
- Maintaining the product development lifecycle
- Keeping the status quo is encouraged or reinforced with existing product/project management processes and expectations. Developers and managers are reticent to make changes for fear of putting deadlines or product/business unit goals at risk (note that these often have financial implications for the company and individual). Working on one’s own individual contributions is seen as doing one’s part to protect this lifecycle; efforts outside one’s own individual contributions is seen as disruptive.
- Product/Business unit pressures
- HR - existing resource allocation plans & patterns
![Table of roles goes here] ![or maybe the pyramid]
Resolution to the problem
- Job Descriptions/Roles on the engineering title ladder are allocated mentorship and "Open Source Time" as fits their level (i.e. 0% expectation for jrs, 100% expectation for Principals)
- Moving up the ladder requires taking on more responsibility for mentoring, reviewing code, and bringing in contributions
- Developers may choose not to move up the ladder because of a preference for certain types of contributions ("I like just writing code" vs "I want to have a bigger impact on the team")
- relevant Skills & experience are associated with advancing titles/roles - Moving up the ladder also requires developing the social skills necessary for mentorship
- Job Descriptions/Roles can be easily associated/assimilated into employee review systems or other HR programs (comp/bonus structures, etc)
- culture has been shifted from contribution culture to learning culture
- devs & pms believe time spent mentoring and reviewing is equally, if not more so, valuable to time spent coding
- job descriptions include mentorship & contribution language to set expectations up front & make it easier to assess if candidates have requisite skills/experience required
- org is retaining and better utilizing existing talent
- devs take on professional mentorship responsibilities for their peers rather than leaving it to non-technical management
- career progression clearly identified & understood by engs and management
TBD
- Initial (brainstormed solution)
Jory Burson