Context: A lot of managers, product owners try to solve the problem of hiring only based on some specific skill sets. This is problematic because it shows a control mentality. But what happens when the needed skill sets change? We modify the team based on the skillset or we let them the chance to adapt, learn?(1) Which approach is more agile?
Shu: Hi Ri. There is a thing which puzzles me, regarding the process of hiring developers. Tell me if I am wrong.
Ri: Hi Shu, which thing?
Shu: Very often I see an announcement with the following form: “We need a senior .Net/React/Vue/Java/Angular/… developer”. For sure a certain language/framework matters if it is known, but is not enough – at least not for a senior. Seniority should not be tied to a certain technology only.
Ri: Is it maybe just an unfortunate choice of words? Maybe they want to say a “senior developer with Net/React/Vue/Java/Angular/… skills”
Shu: I do not think this, because of a strange effect I saw. Is about how teams are formed, at least what I have noticed in the past.
Ri: Could you tell me more…
Shu: You have a well functioning team and a new project comes. That project needs a React developer. No one in the current team has worked with React, but they are willing to learn. But it does not matter. A well functioning team will be broken because of that. Is a framework which can be mastered in a week or two by a person who knows things.
Ri: Tell me more about other skills a developer should have.
Shu: Design, analysis, algorithms, architecture, OOP, testing, experience with at least 2 languages and platforms,…
Ri: Why at least 2 languages and platforms?
Shu: Because the elders say so? 🙂
Ri: Why do they say this?
Shu: Maybe because of biases.
Ri: And also, maybe, because a developer who will not have fear approaching multiple languages/technologies she/he will understand what unites them actually. When doing this, in the end maybe, will understand that in order to adapt fast she/he will need a common ground. And this common ground transcends the language/technology.
[Shu is thinking]
Shu: By common ground you mean clean code, architecture, domain analysis, patterns, Liskov principle, algorithms,….
Ri: Yes. So, what you are trying to say is that the problem is about the locus of attention being in a slightly wrong direction?
Shu: Yes…
Ri: There are some things, among others, to consider when hiring:
– Hiring is also about learning. We want those developers, testers to learn when the market/product/needs/conditions will change. We do not want to destroy circle and community of trust(2). “Experience is not a state but a process”(3) ;
– If the focus when forming a team is first on the technology used, then on the available people and only then on the social aspects of the persons in that team and the learning, then it will be problematic and sad.
(1) Strongly influenced by James Coplien in Scrum – Product Owner class discussion [October 2019]
(2) Jeff Sutherland, James O. Coplien, “Circle of trust”, http://www.scrumbook.org/product-organization-pattern-language/development-team/circle-of-trust.html
(3) James Coplien, Scrum – Product Owner class discussion [October 2019]