I am almost obsessively preoccupied with this question!
For me, leadership means setting a good example.
This requires very broad knowledge, the ability to familiarize oneself effectively with new topics and also the willingness to do a lot of groundwork, even though the outcome is uncertain.
Let me tell you a story …
What I encountered
When I started my last job as a Solution Architect, I was originally hired as a regular employee.
I was involved in an internal project where a group of developers were “sitting on the bench” waiting to be deployed to a key customer.
The project had been launched two years earlier and lacked a clear structure due to the fluctuation towards customer projects. It followed the primary benefit of training developers on a common technology stack.
Motivation was low as employees were waiting for their turn and felt like a second choice.
The CTO, who had taken over the project shortly before, was very respectful in his tone and actions, but didn’t really seem motivated to invest much energy in the project at the time.
When I started on the project, I began analyzing the source code, even though the frontend and backend were written in languages I hadn’t used in a while. I encountered complex constructs of microservices and developers taking days to complete simple tasks. The frontend was split into different modules, each using different design and technology approaches.
The backend took a botched approach to implementing microservices that would have led to significant performance issues if the system had ever gone into production.
It was a disaster that I had gotten myself into!
Familiarization and preparation for change
I started discussing the details with some developers and soon had intensive discussions with the CTO about the aim of the project.
The developer who previously held the role of Scrum Master was removed to a customer project, so someone had to take over his role. The dailies and scrum ceremonies were largely technically driven and often ended in nerdy discussions.
How would you proceed in such a case?
I could have just done my time and tested some concept ideas in a sandbox environment.
Guess what? I’m not the type to waste my time being unproductive.
The takeover
A month after I started on the project, I told the CTO that I would take on the role of Scrum Master and start by giving a demonstration of how I run Scrum ceremonies.
At the time, the Scrum board was a collection of mostly unrelated tasks with a collection of ideas in the backlog to be tried out.
While I was leading the meetings, I continued to talk to the CTO. It took three months to convince him to completely rewrite the front-end code. In the meantime, I had designed a new solution architecture and created initial design drafts for the system to be implemented.
I took the original idea of the project and began to define a solution that was worth working on.
The company’s lead frontend engineer had joined the team and together with the CTO we developed an initial draft of the tech stack for the frontend.
I have always been very careful about criticizing the work of others, because as a consultant I have often seen new consultants take over a project and talk badly about their predecessors – usually with the aim of making themselves stand out.
This is high-risk behavior, because you first have to prove that you can do a better job and achieve better results than those before you.
I have always found software developers to be extremely competitive. All my colleagues had studied and gained experience over time.
Who are you to come and criticize? First show that you can do better!
Basically, there is no right or wrong when writing code. Many aspects of software development are philosophical in nature. The decisive factor is whether the finished solution works, meets the requirements and can be sustainably maintained and further developed during the lifecycle.
If you want to lead a project successfully, you have to convince the key players of your vision and your approach. For me, this was initially the CTO and the lead front-end developer.
When the decision to rewrite the frontend was almost made, we involved the developers in the discussion in order to jointly determine the most suitable tech stack in detail and get them on board.
If we had confronted them with a ready-made decision and an already defined tech stack, it would have been like being dictated to.
I myself don’t like it when things are dictated to me and managers don’t consult with me before making a decision – so I assume others feel the same way.
Nevertheless, it is an art to find the right time and the right type of communication in order to avoid creating uncertainty in the team by postulating things that will never be implemented.
Dealing with the vision and mission
I think as a manager you need a clear idea of what you want to achieve. However, you need a good sense of when to communicate different aspects to different stakeholders.
You need a vision and a mission!
You have to be so convinced of this that you can withstand criticism.
In principle, employees will follow an employee if they can understand the vision and mission and accept them positively.
Dealing with a competitive environment
As you can imagine, not all developers were thrilled with the new colleague who was ready to challenge the status quo.
Who was he? Why does he think he knows better? What did he do that gave him the right to tell everyone what to do?
Such questions arose in the team at the time.
The company has a very polite culture. I had experienced it differently before.
I like challenging discussions and I am aware that my personality is sometimes polarizing. Therefore, this process of finding the vision, mission and action plan was anything but smooth.
I was working a lot at the time and also like to work at night as it’s quiet at night and I can concentrate without distractions from messages, calls or social media. Team members would see my code commits at 3am and on weekends. However, I made it clear that I don’t expect anyone to work at night or on weekends.
As the people on the project team were also part of a line team, there was a meeting where they were asked about the status quo, their overall impression, ideas and similar topics. There was a Confluence page where each member could write down their points.
Some time later, I came across this page and went through the comments. Some opinion leaders were highly critical of my commitment, questioning whether I was trying to impress others and management by working nights and weekends. Do I think I’m better than that? Why the CTO and management would listen to me and what makes me think I could take on the role of a manager even though I am a regular employee of the company?
I’d be lying if I said it didn’t annoy me personally, but I didn’t mention that I knew about the rumors.
My response was to reach out to each individual one by one, challenge them and communicate the vision, with a focus on aligning the team around a common mission.
I used influencing to create consensus and motivation.
The team had demonstrated true junior behavior to me, showing complete ignorance of politically correct and smart actions.
Never try to bully smart and hard-working people you don’t know.
If you have a clear plan yourself and are ready to face the competition – go for it!
Be courageous and defend your position in 1-to-1 discussions. Use your criticism wisely to achieve your goals. This will probably earn you respect.
I usually write things down to make my point.
While some managers prefer direct verbal communication, I like to be able to understand processes and decisions made.
The future will show whether I was right.
I generally avoid personal attacks as I don’t see them as helpful and my interest lies solely in working through an issue and finding solutions.
However, I can’t avoid people feeling personally attacked when they identify with work and ideas that don’t lead to solutions or don’t work!
I consider self-reflection to be one of the most important skills. I constantly subject my actions and ideas to tests and see it as important to expose myself to criticism, reflect and correct possible mistakes.
Efficient and target-oriented solution finding
Working with the CTO and convincing him was a challenge. This was possible because he looks at issues abstractly and reflects on them just like I do. Decisions are corrected when better options are put forward, which I think is particularly important in an agile and fast-moving environment like IT.
If errors occur, they are corrected, just as permanent optimization is part of the implementation.
I’m not interested in imposing my ideas on others, and while concepts evolve, my approach is never set in stone. For many topics, I know there are others with deeper expertise and I consult them extensively to find the best solution.
I think it’s important to leave room for compromise in cases where the options work equally well and the choice is just a matter of preference, so that others are satisfied.
Nevertheless, in leadership it is sometimes necessary to clearly represent certain positions. This is especially true if they do not fit into the bigger picture of the mission. Another reason may be when it is foreseeable that approaches will not work in the future.
Sometimes this is difficult. Others hate you for it and everything, but in the interest of the cause you have to take a clear position.
If you don’t do this and the project fails, you were part of the problem, could be held responsible and in certain cases even become part of a criminal offense.
As a manager, the biggest challenge is probably not to compromise your own integrity.
How do I conduct meetings in a modern way?
When leading meetings with a team, I think it’s important to start with something motivating – possibly small talk, but definitely a summary of the status or an agenda. Those attending the meeting need to know why they are spending their time in the meeting.
Especially in online meetings, they are unlikely to focus if the purpose is not clear.
Developers generally tend to be introverted.
In Scrum dailies, for example, everyone makes a short statement about what has been achieved, what is planned and what obstacles have arisen.
For strong leadership, I use certain techniques in meetings to provoke motivation and exchange within the team:
- In online meetings, my camera is always on and I’m always present.
- For important topics or critical points, I ask the employees concerned to provide more details.
- I give praise specifically to 1-2 team members who contribute important value and make sure that each team member is praised in rotation.
- I keep criticism brief so as not to expose team members in plenary and address problems in individual discussions.
- I ask long speakers to be brief in order to focus on the relevant points and ask more reserved team members to explain their work in more detail.
- I move topics that are too dominant directly to separate meetings if they require more space.
- I repeat background information and goals (both short-term and long-term) to ensure that everyone in the team is pulling in the same direction.
- I actively promote collaboration by motivating team members to work together.
Motivation through initial successes
Rewriting the front end quickly had a positive impact on the project, and two months later we also tackled the back end. This task was easier and faster than expected. Within a month, we had a working solution with a clear concept of a new microservice and code structure.
Motivation in the team increased, the members used pair programming more often and identified more strongly with the project.
Leadership through change
An important step was the renaming of the team: the name “Bench” was completely abolished and the team was now called “Innovation”. With this new name, we increased awareness of the mission and the importance of each individual’s work.
Around the same time, we introduced another important change to the Scrum meetings: Each team member took over the moderation of the meetings in rotation so that all team members could practice their presentation skills in a trusting environment. This strengthened team cohesion and prepared the members to present their topics confidently in customer projects.
Motivation through further expansion and internal recognition
Due to the success of the newly written backend and frontend, the project took shape. I started defining milestones for the feature integration, refining them with management and keeping the team informed in a timely manner.
As the project took shape, we had the opportunity to present it at the monthly company meetings. The team could be proud of its achievements and the goal was further consolidated.
Our goal was to develop an ERP system and after six months we were able to replace the old ERP system at company level. The start of production went smoothly and without stress, as the team worked together excellently and supported each other.
Dealing with employees who do not perform
Unfortunately, there are also situations in projects where team members don’t deliver as expected. I tend to give people lots of opportunities and also act as a coach.
But what to do with employees who are unable or unwilling to deliver?
Working as a team creates a personal connection with all members and it is usually difficult to make decisions about dismissing a team member.
Even if an employee is loyal to the company, they can become a real risk to the success of the project and jeopardize the motivation of the team if they do not perform.
Is it expedient for the employee to remain in a position in which they are constantly exposed to criticism? Should they stay anyway and will the situation possibly improve again?
When a team grows together, some employees will have difficulties and may no longer fit into the team.
In larger companies, switching to another project can be a solution, and I know of many examples where this has worked well for both sides.
In some cases, when I see that an employee is overwhelmed or has lost their motivation, I assume that they probably need a breath of fresh air and a new challenge. I know that resigning is not easy for anyone. But at the same time, it’s an opportunity to reflect on life and start afresh with new energy instead of wasting time in an unsatisfactory role.
While the well-being of the individual is important to me, as a manager I am also responsible for the well-being of the team, its motivation and the progress of the project. If the team is being held back by one or two members, it is the duty of the manager to protect the team spirit.
Developers in particular are often very competitive and if you keep weaker members in the team, you risk losing the top performers.
As a manager, you always find yourself in the difficult situation of having to make decisions regarding the workforce. Those who have to leave the team may be angry, but the top performers who ultimately ensure the success of the project will be grateful in the end.
Removing toxic team members can raise team spirit and productivity to a new level.
My credo is: take clear measures, but always remain fair.
The scaling approach
I wasn’t just aiming to successfully implement the system. Our goal was to establish a functioning tech stack for the implementation of similar systems for customers.
While we were still working on the internal project, a customer project with a similar use case developed.
In order to further develop the tech stack that had just been established, we did not split up the team. We integrated almost the entire team into the customer project and distributed the tasks of both projects.
The idea behind this was to give developers the opportunity to refine their approaches to certain topics.
With a growing team, the development effort can be expanded in other similar projects. The aim was to benefit from not having to reinvent the wheel over and over again.
We used the same tech stack, which eliminated many of the discussions we had previously had. This allowed us to start the second project effectively and present the first results quickly.
Efficiency through repetition vs. experimental approach to new ideas
Most developers don’t like doing the same things over and over again. They want to experiment and learn new things.
In a modern environment, I believe it is necessary to find a balance between learning new technologies and consistently applying proven techniques. It must be clear to employees that allowing the workforce to try new things is an investment. This investment must pay off through the application of expertise in customer projects.
In many cases, I found that developers are more interested in experimenting with technology than focusing on delivering a working solution or system.
When I learn and apply technologies, I always focus on solving a problem and delivering a working solution. Perhaps my entrepreneurial spirit is responsible for this.
Scaling of resources
By using the same team for two projects at the same time, we were able to allocate resources dynamically.
As is the case with all customer projects, more resources are needed towards the start of production. This approach enabled us to reallocate resources accordingly to avoid bottlenecks.
When I compare internal projects with customer projects, I have noticed that the team members show more professionalism in customer projects.
For me, it is a question of professionalism to treat internal projects with the same dedication as projects for customers, even if the environment is more familiar.
After a year, we had a strong team at the start and it was interesting to see how the various members developed in their areas.
We had experts for specific topics as well as members who focused on training and coaching new team members and juniors.
Initially, we only had one designer and one DevOps engineer in the team.
It was a great relief for these employees when an additional designer and another DevOps engineer joined the team. I find it very valuable to have colleagues to exchange ideas in my area of expertise.
However, one challenge remained: Finding developers who were interested in the entire overview of the project, took a market-oriented perspective and developed ideas for new features for the product. In all my projects, I only found a few colleagues who could cover these topics.
While I was working on the UI/UX of the internal project, the designer explained to me that the designs had become complex and it was difficult to keep track of them due to the many different designs.
That was certainly true, but I also had to manage the front-end and back-end code as well as the cloud infrastructure setup, which added to the complexity. I also worked on concepts for a go-to-market strategy and wrote acceptance criteria to describe the overall project requirements in detail.
The complexity of IT projects in modern environments is very high and a great deal of knowledge is required to make the right decisions and successfully complete systems.
Both projects ended up being great success stories for the team. Within less than two years, we had completed marketable MVPs in both projects.
The team members who had bullied me at the beginning were the ones who regretted my departure the most in the end.
High performers are competitive, but they also respect and appreciate those who show strong leadership and drive things forward.
During the two years, I worked continuously to refine the team’s vision and mission, its position within the company boundaries and the projects.
One of the most important prerequisites for success was the great collaboration with the CTO. The support from management for such an experimental journey was also not a given.
For me, it is crucial to always have management on board and to keep them informed about the status of projects at a reasonable frequency.
Control vs. micromanagement
Project management needs a framework of control, but not micromanagement.
If you want to be involved in all the details as a project manager, your day is not enough. Micromanagement is not an option. You need to trust the team members and give them room to take responsibility. This is a risky challenge, especially at the beginning of the collaboration. As a project manager, you need to find out who can take the lead on certain issues and then give them trust. At the same time, you need to find a way to make checks in an agile manner and make corrections if necessary.
If you try to control everything all the time, you deprive others of the opportunity to take responsibility.
As a project becomes more complex, this leads to a destructive spiral where every issue ultimately falls back on your desk and potentially derails the entire project.
There was a moment while we were concentrating on the backend when the frontend became a mess because every developer was following their own programming approach.
This led to a heated discussion and I had to clarify what I expected from each team member. The refactoring took almost a month and annoyed some developers.
Looking back, refactoring was definitely the right decision, as it enabled us to establish a uniform programming style within the team.
For me, it is very important to understand the personality of each team member, what they like to do, what they don’t like to do and what they are good at.
The philosophy of Scrum is that each team member takes on tasks independently, but I am not convinced by this approach. As a project manager, I have a clear vision of how I want to encourage, support and develop the members of the team individually. My focus is on the personal development of the developer as well as on ensuring that this leads to greater efficiency in future implementation.
I measure my success as a manager by the extent to which I have been able to promote the career and personal development of each team member, in addition to the business successes.
As a manager, you are left with many issues and a lot of work.
You need to prioritize and manage your time and energy wisely!
This story contains many insights into my personal leadership style, but focuses heavily on the aspects of team leadership.
There are many more topics to cover in the area of leadership. Stay tuned!
How do you lead? What are your stories?
