Get in touch
Agile organizations are characterized by the fact that value is created by small teams that are, if possible, independent from one another. After all, small teams are noticeably better at adapting to an ever-changing environment. This “responding to change” is responsible for the eponymous agility – and for the strategic competitive advantage Agile companies expect thereof.
However, so that small teams are even possible they must be set up cross-functionally. This means that such a team should be able to carry out all tasks independently of persons or resources, even if, for example, those resources aren’t part of the team. A team member of an Agile team therefore has a “T-shaped profile”.
T-shaped people have skills that figuratively correspond to the letter “T”: The have a very broad knowledge in many relevant areas as well as expertise in a particular field in which they have specialized.
In a team consisting of T-shaped people, tasks can be taken care of if an expert should be sidelined (for example due to illness or being moved to another team), because all other team members also have know-how in that particular field.
Furthermore, this approach helps avoid bottlenecks, since tasks from any given area aren‘t restricted to individual persons, which would lead to increased throughput time.
The question now is, however: How does an organization find employee with such profiles?
A first step: one hires only T-shaped people.
Unfortunately, it‘s not that simple. On the one hand the knowledge the employee brings to the table should not only be broad but also relevant. It is therefore nearly impossible to find a person who covers everything that a single team needs. In addition, technologies and requirements change, so that extensive knowledge in a given sector can be absolutely irrelevant tomorrow for a new corporate project. In the project business this often happens simply when one project ends and another begins.
The goal of the recruiting process must therefore be to identify those candidates who learn quickly and can adapt to change. Agile people.
Agile people are capable of quickly broadening their “T” – and build up a second area of expertise if necessary.
Of course, employees might already have the potential to learn quickly. But, in order to tap this resource, companies must also actively promote learning.
To accomplish this traditional corporate structures know classic downstream solutions: A department for developing employees that is responsible for staff members to develop skills that they will need within a clearly defined career path. Furthermore, the manager is often responsible for developing employees within the current job profile.
These solutions don‘t sound Agile – and they wouldn‘t even work in an Agile organization without hierarchical structures. The question therefore is “How can Agile companies proceed in this matter?”
For starters, every employee of an Agile company also has leadership responsibilities – in the sense of servant leadership. Therefore, everyone is responsible for his own continuing education – as well as for the training of his colleagues.
But even in traditional organizations extremely active employees call for support for their own continuing education. But how can Agile organizations actively support this? And how do we support this at AOE?
The most important factor influencing talent management is probably culture. At AOE we have a strong culture of mutual support and encouragement. This starts with mentors who are assigned to every new employee. The mentor‘s role is to help the new employee to become integrated into the company as quickly as possible so that he can optimally carry out his job.
In addition we just enjoy helping each other, because tasks are taken care of as a team – and not with everyone competing with each other. This is accomplished by pair programming or simply – by communicating. A basic Agile principle.
Another aspect of our corporate culture that has a significant impact on learning is the concept of “slack time” – that is, time an employee takes to work on topics that have no connection to the project at hand. It‘s not unusual for an employee to work on smaller side-projects, for example to try out a new technology. A current example from my team: A team dashboard that displays current team information as React - and node.js application. Or: A 3D “recruiting” video to bring more people on board our Minecraft server game within the company. And yes, we learn here too.
In addition to all of these factors that are integrated into our daily work, we sometimes still need input from the outside – be it through external training or conferences.
For this purpose each employee has a continuing education budget available that they can use at their discretion and according to their individual needs.
In this way AOE ensures that everyone who wants to learn more about any given topic also has the opportunity to do so – even if there isn‘t an expert immediately at hand who can support the employee in the matter.
In addition to external conferences we also decided to establish an internal AOE conference during our last Open Friday to exchange knowledge between teams and functional areas. We‘ll see how that works out.
But, even the best conference can‘t adequately replace practical work experience. It‘s difficult, though, to gather that experience when one is involved in a long-term project.
To solve this problem, we introduced the concept of the Job Chicken. During this time an employee can work in another team for approximately one- to five days to learn about the stack of the other team and transfer knowledge to and from other colleagues.
In practice this approach is used less often than would be possible. We‘re striving to motivate more colleagues to participate in Job Chicken though.
In total AOE is doing a lot to ensure that new ideas are rapidly absorbed and spread within the company. This is the right approach, as it would be naive to think that merely carrying out projects in an Agile manner would lead to a learning organization.
The heart of the matter is this: Build your Agile organization with people who want to learn – and then give them as many opportunities to learn as possible. After all, “responding to change” only works if you know what you‘re doing.
