“In a beginner's mind there are many possibilities, but in the expert’s, there are few.” -Shunryu Suzuki
Numerous studies have shown that people working in isolation prefer to enter the state known as the Flow. That state is the one of intense focus. Thanks to that intense focus, the entire problem and the solution spaces are loaded into a person’s head.
It goes without saying that entering such intense state of clear focus cannot happen easily. On average, some studies claim that it takes approximately 20 minutes before a person could settle in the state of the Flow. That is in a way like sailing – before the sail is set properly and the wind picks up and the boat is effortlessly gliding, the crew needs to invest serious time to set everything up properly. Reaching the state of the Flow is an expensive endeavor.
Is the price worth paying? Perhaps. But before we jump to any conclusions, let’s also review the flip side of the coin: once in the state of the Flow, how easy is it to break it?
As it turns out, nothing is easier than interrupting the state of the Flow. Any little disturbance in the environment is enough to destroy that state. A phone rings, an email notification chimes, someone coughs, etc. When that happens, we’re back to square one – another 20 or so minutes of messing around, trying to set everything up properly.
We see that the state of the Flow is extremely brittle. Is the price worth paying?
Skills and Competencies
Skills and competencies aren’t interchangeable. There exist considerable differences between these two capabilities.
What are the differences? In short, people can usually learn skills in a matter of months (sometimes even weeks); on the other hand, it is impossible to learn competencies in less than several years, minimum. We haven’t been able to identify any capabilities that would fall in the gap between skills and competencies.
When we talk about qualifications, we must clearly specify whether we’re looking for skills or for competencies.
Skills are easily shareable. Competencies aren’t. Often, competencies could even be mutually exclusive. There could be a person who is competent in following a process, but we cannot expect that person to also be competent in being creative.
As a matter of fact, competencies are unique to an individual. As such, building a team around certain competencies might end up being a very challenging task.
Importance of teamwork
Software development is a social activity. It takes a team to continuously deliver software. But in every team, we find disparate levels of knowledge. There are seasoned professionals with many years of proven track record and there are junior members who are just starting in their career, and then there are also intermediate members. And as we know, a chain is as strong as its weakest link. In this case, the team may end up being only as strong as its weakest, least knowledgeable member. Or a team will be as fast as its slowest member.
Every team lives or dies by their products/services (to put things a bit dramatically), which is why there is a natural push to set aside the time to onramp the slowest/weakest member(s). However, any time set aside to upgrade the skills in an asynchronous fashion robs the team of the bandwidth needed to continue delivering quality software. And yet if the weakest members are not trained properly, their inexperience will eat up a lot of the precious bandwidth.
How to solve this conundrum?
Embrace collective code ownership and synchronous collaboration!
Knowledge transfer
There is mounting body of evidence that shows how working in a team in real time (synchronously) is the fastest way to achieve much needed knowledge transfer.
The typical objection to working in a team environment in real time is that it is literally impossible to get into the much-coveted state of Flow. Interruptions in the team environment abound, especially with novices asking all kinds of questions that seem so obvious to more experienced members. And even if the state of Flow is achieved, it is only good for getting things done, not good for transferring knowledge.
That’s a valid objection and is seemingly unresolvable. Such situation is forcing us to find a different way of working synchronously in a team.
The solution to the impossibility to get into and stay in the state of Flow is to abandon the focus on the Flow and to instead turn our attention to the Beginner’s Mind.
How does knowledge transfer work when relying on the Beginner’s Mind (and, what is Beginner’s Mind)?
Beginner’s Mind refers to an attitude of openness and the ability to see things as fresh and new. Beginner’s Mind includes both doubt and possibility. Because of that, a person with the Beginner’s Mind is open to change, eager to change, eager to try something new.
When a person who is working is unsure of their boundaries, that person enters the Beginner’s Mind. That uncertainty leads the person to thoroughly test their environment. That state routinely happens whenever we find ourselves in a situation outside but near the limits of our comfort zone.
For example, if I’m otherwise comfortable with my environment but I don’t understand one thing, I will tend to try stuff until I figure that one thing I don’t understand. My state of Beginner’s Mind leads me to try more approaches, and try them rapidly, therefore I am more likely to succeed at a task than a person who thinks they know how it works.
The frustration brought about my insecurity of not understanding something creates a high energy cognitive state. If we now widen the scope and involve the team in the situation where everything is comfortable except on unsolved thing, the team is likely to hit the collective Beginner’s Mind. If the competence prevails over skills, one competent team member could drag the high energy cognitive state down to the lower energy state. When that happens, knowledge transfer is not possible.
We see from the above that the best way to transfer knowledge in the group situation is to focus on skills and allow the team to rise to the Beginner’s Mind state.
Embrace instability (change)
Unlike the state of Flow, which depends on stability, Beginner’s Mind depends on instability. When working in a group arrangement (for example, a team doing mob programming), instability gets created by encountering a problem and instead of falling back on the competence of the more experienced team members/team leads, intentionally open the mindshare to embrace the Beginner’s Mind which allows the team to try out various approaches in rapid fire succession. We say that the team is surfing the edge of chaos.
It is important to maintain the instability that leads to experimentation. How do we maintain instability in the group setting? Easy. Introduce the ‘musical chairs’ rotation. Don’t let anyone’s exploration turn into hardened competence. Rotate team members who are solving the problem; that way, knowledge transfer spreads like a forest fire and much more gets accomplished in a given timeframe.