Scrum Team. It is a cross-functional group of developers that are able to deliver complete business functionality (“from concept to cash”) to customers in a short time-frame. The easiest way to make sure that a team is cross-functional is to compose it of developers that are initially multi-skilled and possess both, primary and secondary skills. Such people are usually referred to as T-shaped, where “…the vertical bar on the T represents the depth of related skills and expertise in a single field, and the horizontal bar is the ability to collaborate across disciplines with experts in other areas…”[wikipedia].
There is a common miss-belief that T-shaped individuals are hard to find. Here, are some of the most frequently heard concerns that we hear from hiring managers and HR:
- “Most people we come across do not have enough technical diversity”
- “It is hard to find individuals with certain skill set in a particular geographic area. Best folks with a required skill set can be found only in a particular area”
- “We are having difficult time encouraging our team members to learn secondary technologies on the job”
Below are some suggestions for how to acquire or internally cultivate and retain good, multi-skilled, T-shaped developers:
Frame job requirements clearly:
Companies must ensure that their job requirements, clearly state that they are looking for multi-skilled workers. Jobs must be titled accurately, including the mentioning that people are expected to work on Scrum teams, wear multiple hats, contribute to learning of other their teammates and actively learn themselves. Still, very commonly, we see job descriptions that are titled in favor of conventional single-specialty roles (e.g. BA, Java back-end Developer, QA or Architect). While commonly used buzz words, like ‘agile’ and ‘scrum’ are still mentioned in job requirements, proper meaning of these words is not communicated well enough and sometimes is simply misstated. Also, the importance of having multiple skills is reduced by emphasizing titles of conventional, single-specialty roles. Therefore, it is not surprising that people that get attracted to such job requirements, rely merely on their original, single skill set, and don’t have much appetite for extended learning and becoming T-shaped.
Assess candidates properly, before hiring, and ask for things that really matter:
Today, in a typical hiring process, many companies still make too much emphasis on things that matter little. Mainly, due to outdated HR procurement methods and hiring policies, but also, to some extent, because companies rely on inadequately trained recruiting staff (sometimes, external), job candidates get “screened” for wrong things, and under wrong conditions. Some pre-qualifying, “templated” questions (e.g. “are you able to to work under stress?”, “are you an outstanding performer?”, “can you be a great team player?”, “can you describe a difficult situation and solution that you came up with?”, etc.) have little to do with real job requirements and should be treated as ‘common sense’.
The biggest downside of using such low value qualifiers in screening is that they cost time and shift focus of both, interviewers and candidates, away from things that really matter. Also, such phone screening by a single person (e.g. HR or hiring manager) are more prone to bias, and misinterpretation. Phone screening could still serve some purpose if it scope is reduced to something basic, and much less time consuming. For example, determination of a candidate’s legal status and work permission to work or scheduling an in-person interview.
Note: discussing compensation ranges is not advisable by phone, as some strongly qualified candidates, with slightly out-of-range salary expectations, may get disqualified by screening people that don’t have the best understanding of a relationship between “service value and cost of service” and do know know where compensation range should be tweaked for a right candidate.
It is more advisable to reduce time spent on phone screening, in favor in-person interviews with inclusion of practical assessment of individuals’ technical knowledge, their cross-functional capability, and ability to operate in Scrum team settings. To that end, it makes more sense, to involve an entire Scrum team (future team where a candidate will work for) in multiple steps of an interviewing process, including assessment of social, soft and technical skills, while using simulation techniques that mimic a team’s daily dynamics.
Pay developers well:
- “Good, cross-functional developers are hard to find”
- “There are no experienced Java coders in Chennai”
- “The best architects on East Coast of the US are in Boston”
We hear these arguments a lot.
Truth be told, good developers can be found almost anywhere; companies just need to figure out better ways of attracting them. This includes, and often comes down to, paying people fairly and competitively.
No single geographical place in the world miraculously grows “the best” technologists of a one kind. Certainly, some trends exist, perhaps, where workers relocate, as they follow large companies that offer jobs. But often statistics that describe these trends taken out of proportion, data is misinterpreted and numbers are exaggerated. Ability to find best developers of one type, in one geographic area, most likely, hints to another, more likely theory: companies that claim the above “phenomena” are themselves responsible for creating conditions for such disparity in the first place.
Often, in pursuit of cheaper labor, companies consolidate all their developers of more expensive skill set (e.g. Java developer is more expensive than HTML developer) in the cheapest geographic location. What companies don’t realize is that this decision creates the following challenges for Scrum:
- Firstly, this goes against key principles of team collocation that are critical in Scrum: consolidation of all developers of the same skill set in one geographic location, makes it hard to co-locate cross-functional teams. Effectively, with this approach, companies create collocated component teams, at expense of co-located feature (a.k.a. scrum) teams – but it is the latter that is best for agile product development.
- Secondly, being collocated with people of the same exact skill set makes it hard for individuals to learn new skills from one another (condition of technological “in-breeding”).
Ensure that work environment and team dynamics support knowledge sharing between developers:
One of the most critical requirements that ensure that individuals are willing to share knowledge with their teammates while working, is the existence of safe collaborative environment, free of internal competition. Willingness to cross-pollinate with skill set (and become T-shaped) is much higher on teams and in organizations, where people perceive each other as mutually supportive peers, not as rivals. This can be achieved by strongly supporting ideas of collective ownership and shared responsibility, by emphasizing the importance of team performance, while discouraging individual heroics, knowledge withholding and silos. Organizational cultures, where individual performance is overly empathized and individual performance appraisals drive bonuses and monetary insensitive, employees’ willingness to share knowledge, teach each other and contribute to mutual T-shaping, while delivering work together, is significantly reduced. Many other undesirable behaviors (e.g. hostility, favoritism, etc) are frequently seen as well.
This fundamental improvement in working conditions requires strong commitment and support of senior leadership.
Provide internal career path for hands-on developers, to ensure long-term engagement:
Today, a typical career path for a successful technologist requires to sacrifice hands-on work, in favor of managing other people. Developers think that by becoming a manager and getting in charge of more junior workers, will increase their own chance to be promoted, move up a hierarchical ladder and collect more pay. This is commonly seen in companies with very complex organizational structures and command & control environments but less so, in companies with less hierarchical, flattened structures. This anxious pursuit to become a “manager-in-control”, reduces a number of good developers that can deliver value, by performing hands-on work. People are reluctant to remain in the role of a developer for too long because it is perceived as stagnation of professional growth. Also, people feel that it is more difficult to get a decent pay increase by simply remaining in the capacity of a “worker bee”. Many good developers with already strong primary skill set are reluctant to acquire additional technical skills, because they view this approach as a “low return on investment”, comparatively, to pursuing a management role. To them, becoming a manger is a more certain way to grow in ranks and in compensation.
What can companies do to address individuals’ reluctance of remaining in a role of a hands-on developer?
Arguably, companies have to decouple the process of promotion (gaining seniority, reputation, organizational weight) and compensation increase from acquisition of “power tower” control. Individual workers must have assurance that by keeping their hands on-technology, deepening their primary technical skills and broadening secondary skills, they will not be missing out on career advancement and ability to make a better living. People must also be assured that by becoming higher compensated, over time, while still remaining in a capacity of “hands-on doers”, they will not be becoming an easy target for downsize/force reduction, in favor of younger and “cheaper” work force that will come from colleges and universities. Here, a strong bet is being made on the assumption that senior hands-on workers, with longer industry experience, will have much more technical expertise that is coupled to business domain knowledge – something that shall make their higher pay well justified by employers.
Again, this organizational change is dependent on decisions that come from senior echelons of organizational structures.