Month: December 2021

Going from an engineer into a leadership role is anything but straightforward. The biggest challenge for technical minds, according to High Tech Institute trainer Jaco Friedrich, is to align and influence diverse and multidisciplined stakeholders – all from a position without power. To Friedrich, generating this buy-in doesn’t only come from your technical expertise, but from proper positioning, strong leadership skills and good communication.

 

You’ve finally done it. After years of working your way up from junior to senior engineer and architect, now you’re ready to take on a leadership role. This is your chance to show the company that you’ve got what it takes to assume the wheel and drive a team to success. With all the technical knowledge you’ve gained through your experience, you’ve pretty much seen it all and are quite advanced to less-experienced team members. This transition should be a breeze, right? According to Jaco Friedrich, a former architect and team lead turned trainer, establishing your technical credibility can be a big help, but it’s your leadership skills that will bring you to the next step in your career development.

“Spending years working my way up through the different levels of engineering and then to group leader, I’ve experienced first-hand the difficulties and the pitfalls of making the jump to a leadership role,” recalls Friedrich, a training expert at High Tech Institute. While the high-tech domain is filled with some of the brightest technical minds, for many, it’s the non-technical soft skills of interaction and communication that are lacking. “It took me years of training and education to really understand those difficulties, which is why I use my time to share what I’ve learned with the engineers of today. Sometimes, you can best teach that which you most needed to learn in your own personal development. I think that’s definitely the case for me.”

For the last 20 years, Friedrich has put his focus into teaching and helping engineers grow into leadership roles. He has trained thousands of engineers and architects, in the Netherlands and abroad, to learn the skills he wished he possessed early in his career. This includes his High Tech Institute’s two-day training “Leadership skills for architects and other technical leaders.”

Check out his training

Call your bluff

In his experience as a trainer in high tech, Friedrich notices that engineers have two main challenges, or dilemmas, to overcome when moving into leadership. The first is that leaders are expected to plan or take a specific direction earlier in the process, which means making big decisions with only a limited amount of information and clarity. “What I see is that engineers are very technical at heart. They might be 80 percent comfortable and have an idea of the way to go, but they hesitate because making big decisions without 100 percent certainty can feel daunting,” suggests Friedrich. “The problem is, someone else in the group might only understand 30 percent but be much more vocal, and this often leads to the project being steered in the wrong direction.”

The solution, Friedrich says, is not to be afraid to take a position, even if you’re not fully certain. Instead, start by conveying what you know and pointing out the potential risks. This invites everyone into a dialog and allows the group to assess risks and rewards.

“You never want to be fake in these situations. Your colleagues will call your bluff and certainly won’t buy into what you’re saying,” explains Friedrich. “In this scenario, it’s really about positioning yourself and being open from the start. Being a leader means you’ll find yourself no longer in the world of science but in the world of risk management. It’s a real mind shift that has to take place.”

Trainer Jaco Friedrich.

'To really make the jump to become a leader, you have to find ways to create headspace.'

 

Headspace

The second dilemma, according to Friedrich, is finding the right balance between the engineer’s mentality of finding solutions on your own and finding ways to delegate responsibilities to keep a broad view of a project and its stakeholders. “This is one of the more difficult shifts for engineers going into leadership roles. They still want to work like they always have but can lose sight of all the moving parts and pieces,” illustrates Friedrich. “To really make the jump to become a leader, you have to find ways to create headspace. This means you must learn to delegate tasks to others and then help by coaching them through the process.”

Friedrich points out that while your technical knowledge is a great asset to help guide these situations, coaching relies more heavily on patience, communication and an entire set of soft skills. “To be effective as a leader, you’ll need to find a way to really develop skills in diplomacy and influence to gain buy-in from the various stakeholders,” he reveals. “Teams today are extremely diverse in terms of culture and discipline. To get all the stakeholders on board with the direction you’re steering means knowing how to appeal to them and motivate them from a position without power. Formal power can be effective, but it’s certainly not a motivating force.”

Resistance

Of course, no matter how sharp your influencing skills are, it’s not always possible to win everyone over. When you’re working with diverse groups of highly intelligent, highly technical people, you’ll most certainly run into different levels of resistance. Learning to deal with this resistance is crucial to being successful in a leadership role – and is one of the focal points of Friedrich’s training.

“Something that a lot of engineers struggle with is how to turn resistance into positive momentum. In our trainings, participants are always stumped to learn that as much as 50 percent of that resistance actually stems from themselves,” teases Friedrich. “It typically comes from one’s inability to present information, options and consequences in a clear and meaningful manner. We teach some simple tactics for new leaders to maneuver themselves into a position of strength and clarity from the start. That way, they can avoid wasting time getting the ball rolling. Of course, there’s still the other 50 percent, but to learn that you’ll have to come to the course.”

 

This article is written by Collin Arocho, tech editor of Bits&Chips. Trainer Jaco Friedrich. 

How does a project leader cope with busy bosses, square techies with big egos, system architects and lonesome inventors? In the tech world, this is made easier by the common rule set of physics that everybody agrees to, according to Wilhelm Claussen. He also shines some light on his project leadership course at High Tech Institute.

Wilhelm Claussen can tell you everything about what it means to be a project leader and how to get to success with your team. But there are more angles to project leadership. You also have to ‘influence without power’: keep higher management involved and stay connected to peers like system architects. Project leaders have to be aligned to stay on the right track.

Starting with the upper layers, Claussen immediately dims high expectations. “Having been in higher management positions, I can tell you that there you have very limited insight in the projects that are running, as you’re constantly being tossed around by the various calamities.” That’s why it’s crucial that project leaders understand how they communicate upwards, he says. “You need to do that in a way that people above you can hear and understand you. It’s the first step to be helped.”

Claussen points out that it’s extremely important to have a relationship with your project sponsor or customer. “That of course builds over time. The question then should be: how do you build this relation? Communicating with management follows the same rules as communicating with your team. The main point is: be consistent in your communication. In short, for management, you must come across as straight and reliable. And you have to achieve, but that’s the name of the game.”

As a mandatory prerequisite for consistent communication upwards, Claussen mentions that the project leader himself needs to be aware of the actual project progress. “You have to honestly answer the question: am I on track or am I not on track? You shouldn’t accept bad quality in your project, just for the sake of ticking off a box in time, because this is going to haunt you. Better limit the number of boxes to be ticked in the beginning, by using a smart project setup. Otherwise, this is going to fall back on you much, much later. It’s pretty much like the statement accounted to US president Eisenhower: ‘No one has time to do it right the first time, but everybody has time to take a second look and do it over again.’”

 

What if problems arise or things really go wrong?

“Then you need to be clear and communicate bad news to the management and sponsors above you. And you must take painful decisions, in a courageous and well-balanced way, as early as possible. People have the strange tendency to close their eyes and avoid a bold decision because they might be wrong or they’re afraid of the consequences. But with every delay, you’re driving further to the cliff.”

“A very funny Roman saying goes: it’s better to be the fool of all the people than to postpone a decision because you’re afraid of becoming a fool. Yes, decisions can be wrong. Did I make the wrong decisions? Of course. But the moment you recognize that you made a wrong decision, and if you have a good track record in your project team, you can stand in front of the group and say: ‘Sorry folks, the last four weeks, we were marching in the wrong direction. By the way, yesterday evening I recognized that. This is why we’re changing today. We’re now heading for that direction.’ If you have a good team, they’ll turn with you as one man.”

After getting some headwind…

“Not at that moment, if you’re working with professionals. The worst will come next Christmas party because then everybody will make jokes about you, but that’s the price you have to pay.”

Trainer Wilhelm Claussen. Photo by Fotogen Fotostudio.

Other rules?

“Similar to the communication with your project team. Like being extra careful with silence. If you don’t hear anything from a particular stakeholder, project sponsor or supplier, it doesn’t necessarily mean that it’s good news.”

 

Do you have experience with that?

“You call it experience, I call it failure. I remember our team in Korea was waiting for a turbo booster pump shipped from our parent company as the critical delivery to the production start of a newly built factory. The agreed delivery date came and we all went to the airport to pick it up. But when the airplane landed and the hatch opened, we were staring into an almost empty cargo compartment. No pump. Only then, when I furiously called my sponsors, they told me it would arrive three weeks later as they had rerouted the device scheduled for us to some other construction site. And of course, the sponsors did know about that issue earlier but failed to communicate that. So, when the project part – in this case, my superiors – doesn’t inform you about flaws ahead of time, it deprives you of all options to counteract. That’s why you have to act yourself if you don’t hear anything.”

Does that require a specific character?

“I’ve seen lots of different characters that were good project leaders. I don’t think a specific personality is required. Of course, you have to like dealing with the unexpected and making things work. But the weak spots that arise in projects are always pretty much alike and rarely related to the character of the project leader alone. It’s usually a sequence of events that leads the project into the ditch. Failure is also a team effort. The good news is that you can learn to prevent it. If you keep an eye on those essentials and develop a sensitivity for your blind spots, you can make sure that your project has a much bigger chance of success, regardless of the chosen method or methodology or your personal character. That’s also what I transmit in my course at High Tech Institute.”

In high-tech companies, project leaders operate very close to system architects. What’s their relation and how do their tasks differ?

“For me, system architects are the caretakers and wardens of the functional integrity of the system throughout all levels. The project leader is the person that concerts, aligns and coordinates the work along a timeline to make the functions of the system available to the customer. I have very good experience in dealing with system architects. The project leader will provide them with the environment for decision-making, for example with discussions in change control boards, supporting and structuring their requests and allowing them to process their input according to an agreed rule set. The technical decisions I basically leave to them: which functions or features to include or exclude. But I hold them accountable for the technical content, for following the rules and for proper alignment. No lonesome cowboys!”

Can you tell a bit more about the interaction with architects? Presumably, there can be heated discussions sometimes.

“For sure, there can be heated discussions. It’s important to manage these people as well as the technical subjects in a well-balanced manner. Let me give you an example. I once had an issue with one of my piping architects. Through a lonesome design change, he managed to increase the amount of excess heat that had to be removed from the system literally overnight by almost 30 percent. When I challenged him on this in the team meeting, he basically replied: ‘I’ve done that because it’s necessary; you wouldn’t understand anyway.’ At that moment, the communication went completely out of control. I intended to make him explain his measures to the other architects and follow the agreed rule set for alignment. He understood this as ‘this guy is challenging my expertise’ and in return challenged my position as project manager.”

How did you resolve the miscommunication?

“Well, this is the funny part. First, I was about to jump on him, but fortunately, the miscommunication became clear to me just before I did. I started laughing, and after my explanation, he cheered up as well. He then wrote a note to his colleagues, giving the details of and the reasoning behind his design change. In the CCB meeting the following Friday, he got consent from all stakeholders in the project – for a good contribution that had almost ended in a bitter fight.”

Photo by Fotogen Fotostudio.

In technical environments, some people are more square than others. Is that a challenge for a project leader?

“I don’t think so. We’re privileged to work on technical stuff with other educated people. At the end of the day, we have an objective rule set that everybody agrees to and that’s called physics. As long as everybody agrees to this rule set, you’ll always have an objective way to settle a technical dispute in a development project. Sometimes, of course, it can bend a bit left and right before finally coming to a conclusion. We’re blessed that there are no alternative facts for physics. Or to cite the Nobel prize winner Richard Feynman before US Congress when NASA tried to cover up the Challenger disaster: ‘Physics doesn’t care about marketing.’”

Do projects in the high-tech region around Eindhoven differ from an environment like the automotive industry in Germany?

“I think they’re both high-tech, highly integrated, both are hardware driven with a strong software component. From that perspective, they’re relatively comparable. In general, the major differentiator is between realization projects and development projects. In a realization project, you usually have a clearly defined achievable goal, a lot of manufacturing people who are used to following orders and performing tasks in a structured way – you ‘just’ need to get it done in time. Development environments are more interesting. There, the path to success is less clear and even the goal is sometimes uncertain. And you’re dealing with developers, usually very intelligent individuals, who perceive themselves as hidden geniuses – some of them really are. In this case, the leadership challenge is to include them all in the common goal. For that, you have to lead them, guide them, motivate them to deliver a concerted action.”

 

Some of them will work on a new functionality every day if they have the chance.

“And if they do, you have to cope with it constructively. By asking yourself: is this benefiting my customer, is this fitting into the integration? You actually have to foster this in the early development phase. Because this is your only chance to make a product that’s different from what’s already existing.”

But you have to be very careful with that?

“Yes, I can fully subscribe to that. You must balance it in a structured way. I always rely on the technical experts and architects in my team. They make a balanced and structured assessment of this new idea to incorporate it, yes or no.”

Your new course at High Tech Institute is focused on project leadership, not on project management.

“The reason to focus on project leadership is that project leadership is the art to influence the pace, focus and goal of the project. Along the way, you provide guidance and insight to the team. You have to be the man on deck – that’s what project leadership is about. Project management is the set of means and methods to have a transparent, clear and structured communication and framework. It’s a kind of a basic condition.”

You teach this course in one day. What do participants take away?

“I don’t like the word ‘teaching’ when it comes to leadership. This course is designed for people who already have project management and project leadership experience. I prefer to say that I’m sharing the essentials I’ve gained over the last twenty years in high-tech project management. Participants will be taking away a fresh and independent view on how to manage their projects better, by focusing on a few aspects to make sure that they’re followed. It’s not a project controlling course. The key to success is to not lose the overview and I show how to keep that overview in a complex and fast-changing environment.”

This article is written by René Raaijmakers, tech editor of Bits&Chips. Trainer Wilhelm Claussen. Photo by Fotogen Fotostudio.