Communication: Plain text. friendly, concise, no frills

Good morning.

Advertisement

Stefan Mintert works with his clients to improve corporate culture in software development. He currently sees the greatest potential in leadership; Regardless of hierarchy level. He set himself the task of taking advantage of this ability with some career changes. Originally coming from a computer science background with many years of consulting experience, he initially founded his own software development company. He found that leadership has to be learned and good role models are rare. It became clear that their customers’ greatest need for support in software development was not in producing code, but in leadership. So it was clear to him where his company Kutura was going: Improve leadership so that the people developing products can grow and develop themselves. Stefan has been writing for Heise as a longtime freelancer for iX since 1994.

Smart ergonomic furniture at a good price during Black Friday

Public speaking is a big deal. There are speaking associations, debate clubs, language coaches, and much more. If you want to make people understand your point then you will have to become an excellent speaker. Which happens only once in a generation. This person is interviewed and listened to.

“How important are communication skills?” Popular opinion on the subject is likely to be something like this. Look It is very strange that the captains of the best sports teams fail when it comes to communication in the sense mentioned above. They don’t give speeches. They don’t give any special (or any) interviews. They are quiet and speak less.

At least in public. Because things look different in a team. Here he is well connected and interacts a lot with all the team members. Sometimes through words and sometimes through body language. Eloquence and detailed explanations are not found there. But plain text. Technical message. to the point. Understandable. no frills.

What Sam Walker found about captains of sports teams and in his book “The Captain Class” As described, people can do anything in software development.

Whoever on the software team speaks with passion about the software, architecture, patterns, refactoring, tools, and methods sets the tone, sets the theme and direction.

Set direction? This is another word for leadership.

Leadership that anyone on the team can take from. Leadership that a team can never have too much of. A leadership that does not attack anyone while in office. Leadership in purpose, not hierarchy.

Walker writes: “One of the great scientific discoveries about effective teams is that their members talk to each other. They do so democratically, taking turns. Leaders of these types of teams are widely Socialize and talk to everyone with enthusiasm and energy. Even the (best) teams have this culture of interaction – and the person who fosters and maintains this culture is the captain. Despite their lack of enthusiasm for public conversation, most of these captains consistently talk to their teams through messages, looks, touch, and other forms of body language. The secret is not grandeur, it is a stream of conversation that is practical (…) and coherent.”

What do I do with this as a member of the software team?

If you don’t like the direction of your team, if you don’t like the product direction, if you don’t like management decisions, if you’re stuck in a feature factory and want out, you should lead in communication! Between kick-off and the final whistle it becomes clear whether a sports team has achieved its goal or not. During this time there are no stakeholders, no users, no managers, and therefore no communication with these people. Even the coach is on edge and this communication is also on edge.

Things are different for teams that develop software. There is no kick-off and no final whistle. This should not be a topic of discussion only within the development team. Direct communication with all (!) stakeholders is important and you should not leave the Product Owner alone in this. Otherwise, the development team will find themselves in the proverbial silo and without influence over direction. When it comes to communication, the “team” includes everyone who has an influence on the design of the product being developed. And each of these people is a “developer”.

As a software developer, it’s not enough to be able to talk to people who aren’t formally part of the team about architecture and technical debt. Successful communication across silos requires a holistic understanding of the product and its business impact. If you want to lead from a position without formal power (your team from the Feature Factory), you would be well advised to take charge of the exchange with everyone involved. For this reason, it is more important to communicate than to spend a long time thinking about nuanced statements. Just like the (sometimes invisible) captains of the best sports teams.

From you:

• What does a Product Owner want developers to avoid when going to a feature factory? I talked to longtime product owner Kathleen Janz about this. There is a recording in the podcast episode ““The Product Owner in a Feature Factory – Perpetrator or Victim?”
• Heise readers who want to expand their leadership skills can use promo code “2024heise10” when booking the workshop Leading self-organized software teams 10 percent discount. This code is valid for bookings made within two weeks of the article being published.

(rme)