Moin.
Advertisement
(Bild:
Stefan Mintert
)
Stefan Mintert works with his customers to improve the corporate culture in software development. He currently sees the greatest potential in leadership; regardless of a hierarchy level. He gave himself the task of leveraging this potential after a career path with a few changes of course. Originally coming from a computer science background with several years of consulting experience, he initially founded his own software development company. He discovered that leadership has to be learned and good role models are rare. It became apparent that the greatest need for support from his customers in software development was not in producing code, but in leadership. So it was clear to him where his company Kutura was headed: improve leadership so that the people who develop the products can develop and grow themselves. Stefan has been writing for Heise as a long-time freelancer for iX since 1994.
When new colleagues join the team, onboarding takes place. Clear. Everyone needs access to the systems used. Email addresses, LDAP, ticket system, wiki, repo and so on. This is essential. The same applies to bringing new people on board personally and personally. My impression is that the latter is often neglected, but that is another topic.
What then remains is the technical onboarding. How do we work? How are the processes? What meetings are there? And many more questions like this.
At first glance, it is self-evident that we familiarize new colleagues with it. But does that really make sense? What are these measures for?
Essentially, they serve to trash the experiences, knowledge, good practices, lessons learned that the new team member has with them. Brainwashing of the “this is how it’s done here, forget everything else” type of brainwashing.
But if we work in a feature factory (see title of the blog), we want change, right? From this point of view, the know-how and experience of the newcomers are valuable sources for a change of perspective.
My suggestion: If you want to break out of the feature factory, don’t participate in this type of onboarding. Instead, they invite new colleagues to observe and question. And they ask questions that tap into the experience of the new team members. For example: How have you carried out code reviews so far? Our dailies are boring; Do you have an idea what we could do differently? What experience do you have with peer programming? We produce a lot of bugs, what could be the reason? Or simply: If you could only change one thing in the way we work, what would it be?
Regardless of the specific questions, the basic idea is always the same: a new team member is an excellent opportunity to question operational blindness and “we always do it this way” attitudes and replace them with something better. Take advantage of the opportunity as early and as long as possible. It happens quickly, then the new colleague has adopted the established behavior. The pressure to adapt is great and a new environment can be intimidating. It takes a lot of courage to take a stand against the current rules. A team that explicitly invites you to do so creates a prerequisite for this.
(rme)
To home page