Unlocking Multi-Skill Learning: Inspire Growth with Personal OKRs

Everyone knows, members have to learn additional skills and become T-shaped (or even M-shaped, multi-skilled in the case of the Large Scale Scrum framework) person to increase the adaptability of the scrum team and finally optimize lead time of delivery customer’s features. But how can we promote the acquisition of new skills and motivate narrowly specialized developers? - I got this question in local scrum community and would like to share my experience on how to build a “grade” system that encourages employee growth? not only in “depth” but also in “width”, encompassing not only individual skill improvement but also team performance.? Moreover, employees usually want to know the direction they should develop themselves according to company? needs, and receive an objective assessment during salary reviews.

In the book “Scaling Lean and Agile development”, Bas Vodde and Craig Larman (authors of LeSS framework)? offer several general pieces of advice: “Avoid…Job titles”, “Try…Create only one job title”, so… First and foremost, we eliminated titles/roles - all Analysts, Designers, Frontend and Backend developers, Testers became “Product Developers”! Sounds unexpected? Yep, such a reduction in importance may not be appreciated by everyone in the company? (for instance, in this startup, the architect left us for Google, as he did not meet enough respect for his title with such a gesture). The HR department also was not in favor of this idea -? getting rid of performance reviews and merit pay, and not rating or ranking individuals.

Ester Derby (an expert in organizational change, complexity, and management effectiveness) also advises on her blog, completely in line with Bas and Craig -? to connect salary directly to an individual’s skills. As a second step, we established a simple scheme (levels/numbers are provided just for explanation, I cannot show the exact percentages due to an NDA):

• if a Product Developer has only one specialization (main skill) - they will receive this level of salary;
• if a Product Developer learns and begins to use an additional skill alongside their main skill - their salary will increase by 20%;
• if a Product Developer learns and begins? to use a second additional skill - his salary will increase by 30%;
• here you can extend the table with your own variations.

Following the next portion of advice? from Bas and Craig, teams should define their own targets and measure themselves, not management; and management, in their turn, should measure product performance instead of each team or individual contribution.

The third step involves company using OKRs (Objectives and Key Results) at the levels of the Company and Teams respectively. I used this moment to introduce “Personal OKRs” - as goals for development of each Product Developer. Personal OKRs should be defined to support Team’s OKRs, which, in turn, help to deliver Company OKRs (see Table below).

There is a subtle point to avoid the subjective assessment of a developer's growth:

• not by some Lead, nor some Manager, but a Guild (or Chapter, or union of developers per specialization, whatever) decides (column “Confirmed” in table) that it is reasonable for Product Developer to deepen a specific narrow-specialized skill. The Guild itself will check and assess (column “Assessed” in table) that this skill developed well enough;
• concerning additional skills - the skill must be confirmed by the Scrum Team that it would be helpful for the team if someone learns it (column “Confirmed”), and Scrum Team? itself will verify if skill is strengthen enough (column “Assessed”);
• when filling in the OKRs goals should be defined in such a way that later it will be unequivocally clear - whether the goal has been achieved or not, and whether the developer receives a promotion or not.

The fourth step involves making it visible which Product Developers are willing to improve specific skills. The easiest way to do this is to build StarMap with the Scrum team, thereby demonstrating members’ interest in developing additional skills without putting pressure on them. In the example below, you can see a more extended Legend rather than the simple “I can teach / I would like to learn”, but it is still shows the Backend developers’ interest in learning languages for Frontend and the Frontend developers willingness to teach them.

The fifth step involves agreeing to use existing short feedback loops (instead of an annual cycle) to know how to improve as individuals. Consequently, the setup of “personal OKRs” and assessment of results are not tied to precise dates in the schedule for everyone.

Results (how it affected the team, and how this scheme worked):

• In one company such a schema was introduced but not formally; it was just on the verge of being adopted - but it worked! In another company, it was rejected by the founders because they did not want to bring transparency to the scheme of promotions for developers, preferring to keep this aspect "manual" and vague;
• In the beginning, everyone in the company laughed at the new title “Product Developer”, but it also became a reason for everyone to focus not on their results but on the product developed by the team, emphasizing that the team is responsible for delivery and that the way to achieve it is by learning additional skills;
• Can you guess what the previously-so-called “backend developers” answered when asked? “How long will it take to learn the frontend part”? "We will put our first examples of frontend code in 3-4 weeks"!?
• The team members became inspired, and soon enough, we acquired the necessary knowledge and skills for product development - automatic tests, blockchain, cryptography security, mobile development, neural networks, etc;

Why this scheme might not work for you:

• if you work in a “red” authoritarian organization lacking values such as transparency, trust, respect in its culture;
• if stakeholders are merely trying to place more skills and responsibilities onto developers’ shoulders without offering something valuable in return (or less than what the developers considering worthy);?
• if developers are not interested in product and technologies due to overloading, burning-out, management pressure, or micromanagement;
• if developers fear becoming less professional in one speciality, thus becoming less in demand in the market;
• if developers are concerned about becoming indispensable employees, as the company has an unhealthy culture and high turnover;

You can see the radical changes we had to make in the company regarding our motivational scheme. As a result, it led to increased transparency for Product Developers, clarifying which specialized and additional skills to develop and how they will be rewarded. This also improved the capability of each product team to deliver any item from the Product Backlog, truly embracing the LeSS framework.

I hope you found my experience useful. If you have any questions, suggestions, arguments, or would like to share your own motivational schemes, please feel free to leave a comment below.