Business Practices for Engineers

Uwe Mierisch
  • 0.0 (0)
  • Business
  • Updated Weekly

Leadership, Processes, Best Practices in Product Engineering uwemierisch.substack.com

  1. 12/29/2025

    Turn Project Management into Relationship Management — and Leave Your Competition in the Dust

    I just can’t stand them anymore. Those consultants and smart advisors who go from company to company telling everyone—whether they want to hear it or not—how brilliantly Chinese firms are making Western companies look old and foolish. But you know what? These consultants are right about one thing: Competition has gotten tougher, there’s no denying that. If we want to survive in this new world and thrive long-term, a whole lot needs to change in our companies. But the solution doesn't lie in copying Chinese companies—it lies in being better. I won’t address all the aspects that play a role on the path to long-term competitiveness in this article. I’ll only select one aspect, but one I consider absolutely crucial. And honestly, it’s long overdue that we tackle this. We need to transform the potential of our employees and leaders into outstanding products with high efficiency and without wasting time. Today, let’s talk about how we can make this happen! Efficiency as a Critical Competitive Factor In my last article, I wrote about why individuals can achieve little alone but accomplish much through collaboration, and why building personal relationships and networks is essential to this. I described how people with many strong relationships are more successful than lone wolves. But what if we didn’t leave it up to individuals to build and maintain their relationships? What would happen if we implemented a way of working in the company that methodically and systematically promotes the formation of strong relationships between people? Exactly — we would activate the potential of our entire workforce as an integrated collective, and the company’s performance and thus competitiveness would increase! Costs decrease, products improve, customers become more satisfied. One effective way to do this is to make the Drum Beat, which I introduced as a project management method in previous newsletter articles, the general working rhythm throughout the entire company. Experience shows that cost reduction programs only produce short-term results. The Drum Beat, however, when practiced continuously as a work mode, ensures lasting efficiency that increases steadily with growing experience and ever-strengthening relationships. What I'm explaining using the Drum Beat as an example naturally works with all similar methods, such as product increments in agile project management. I think you'll recognize the parallels and be able to transfer this to your process if you're using something similar instead of the Drum Beat. If you have questions, don’t hesitate to contact me. So let’s look at the details of what matters. Shared Goals Are the Key to Company Success, but Also to Individual Success. If the potential of every employee and every leader is to be efficiently deployed to increase efficiency for the entire company, then it’s an important prerequisite that the goals and results of all process participants are aligned. From the company’s perspective, it’s simply not enough for employees to individually achieve their personal goals. It’s necessary for these individual goals to work together toward a common company goal. This doesn’t happen by chance but must be ensured through a well-structured process. The Drum Beat planning process offers an excellent opportunity for this. In the project, the project manager develops short-term Drum Beat Deliverables with their project management team. These are goals aligned with achieving project objectives and give the entire project team orientation and priorities. They are also a recognized measure of each project team member’s success, giving everyone clarity about what’s worth putting effort into. The Drum Beat Deliverables serve to clearly align and prioritize important value-adding activities, as well as to share acceptable risks. This ensures that valuable resources and funds are truly invested in the right priorities. Clarity regarding the results to be achieved helps both individual employees and the entire company. In many companies, projects are the essential part of business operations that determine success. Nevertheless, there are many reasons to use the Drum Beat method outside of projects as well, in the ongoing daily business of all indirect administrative areas. In addition to project goals, this also addresses company goals that aren’t directly influenced by projects. I’m excluding manufacturing areas here because they usually have other objectively measurable goals that enable elegant efficiency measurement. We can talk about that if there’s interest. Clear Agreements Strengthen Relationships Once the deliverables and thus the priorities are clear to everyone, it’s about all employees making their individual agreements to be ready to work and deliver. This is nothing less than well-organized relationship building. People talk to each other about who needs what from whom and document it properly so it won’t be forgotten. In this phase of Drum Beat planning, the foundation for trust and good relationships is laid here. Exactly as I described it in detail in my last article. Communication is intensive, support needs and necessary contributions become concrete and completely transparent to those affected. Remember? In my last article, I challenged you to make a personal plan for how you can intensify your relationship maintenance. The Drum Beat Planning ensures that an organizational framework is provided in which everyone simultaneously works on their support needs and commitments to others, making exactly this plan. This increases the intensity and quality of this aspect of relationship maintenance, creating a strong relationship network throughout the entire organization while also helping each individual. Through the shared rhythm and beat, an intensity is possible that couldn’t be achieved through singular individual actions. Now We Really Do It Once the planning event has taken place, it’s time to deliver on the promises. Here again, everyone is working together with the same priorities. The Drum Beat ensures that the probability of actually achieving the goals is very high. I think an achievement rate of over 80% should definitely be reached. If it’s lower, the goal ambition must be reduced so that the organization’s performance level and ambition level align. The increasing efficiency over time will ensure that ambition can also rise. So don’t plan for 100%, but aim for a range between 80 and 90%, so there’s a corridor for efficiency growth. It’s clear that this promotes the trust aspect. Achieving jointly agreed deliverables provides confidence that it will work again next time. This increases people's trust in each other. As a result, people become more ambitious and learn how much more can be accomplished. Celebrate Achieved Results and Be Grateful At the end of every Drum Beat, we review what was achieved together. This makes it clear to everyone what worked and what perhaps didn’t. This shared pause and appreciation of what was achieved is a crucial point that helps solidify relationships between people. It’s not necessarily common to take this time and talk together about what was achieved. The Drum Beat offers a unique opportunity to show gratitude for a colleague’s support. Don’t take this lightly. Here in Germany, especially in Swabia, they say: not scolded is praised enough. It’s meant to suggest that celebrating gratitude is seen as a waste of time. But the exact opposite is true! Strong relationships and trust—indispensable for efficient collaboration—only form when people receive feedback that their efforts are seen and there's willingness to show appreciation in the future. Here again, the Drum Beat offers the opportunity to handle this important aspect of relationship maintenance simultaneously and in a well-organized manner. How Can We Be Even More Successful I think you’ll agree with me that it’s not satisfying to remain at a once-achieved performance level. There are many scientific studies proving that ambition isn’t coincidental but belongs to human nature for many reasons. But we also know that the field in which each individual person displays their ambition doesn’t always lie in business. However, when a group of people work together trustfully and then consult together about how to improve as a team, ambition becomes contagious. Here too, the Drum Beat offers an organizational framework with its retrospective that makes a level achievable that’s greater than the sum of individual persons. Personal Success and Company Success Go Hand in Hand I wanted to make clear in this article that personal success and company success are symbiotic. If the majority of employees in a company are successful, then the company is usually successful too. But the reverse is also true: if the majority of employees aren’t successful in their work, then the company has a results problem and is very likely not competitive in the long term. I always start from the employee perspective, because the notion that employees automatically become successful just by working for a successful company is an unrealistic fantasy with no basis in reality. That’s why I believe the right and important path is to start with organizing employee collaboration to lift the company’s overall performance to a level that wouldn’t be achievable through individual successful employees or leaders alone. Now it’s true that there are other important factors to address as well — more on that in future articles. But let’s start with employees and their collaboration. I hope I’ve convinced you that significant improvement potential can be realized this way. However, it still needs to be operationally implemented in daily business processes, and I haven’t described all the details here in the article. So if you’ve decided to implement this proposal, contact me and I’ll discuss the opera

    15 min

  2. 12/15/2025

    Interpersonal Relationships - The Magic Formula That Makes 1+1 More Than 2

    It’s always about personal advantage! What’s your reaction to this statement? “Of course it’s about me! That’s always been my motto.” Or “Absolutely not, that’s antisocial! The common good must stand above the individual’s self-interest.” Let’s unpack this together. I hope we can agree on a common perspective. But if you have a different opinion, don’t hesitate to share it with me. You can use the comments or send me a personal message. I’m very curious! It’s About Creating Value When I talk about the business environment, we often immediately think of numbers like revenue, profit margins, or ROI. But actually, the purpose of every business activity is to create value for which someone voluntarily gives up something that belongs to them. Yes, this business value can often indeed be measured in money. However, it becomes more difficult when it’s not about companies, but about people. In human interaction and collaboration, compensation often doesn’t occur through direct exchange, but happens with a big unknown time delay. I help someone else today and get something back sometime, possibly. Another special feature is that this compensation often doesn’t consist of money, but of other, non-material values such as social status, services and competencies that I don’t have myself, or simply by having something taken off my plate that I don’t like doing. And this is where community comes into play, because the community can also give something to the individual that represents value to them. It’s not just about the relationship from person to person, but also about the relationship from the individual to the community. Take a moment and think about what other forms this compensation could take, so that it’s “worth it” for you to do something for someone else now. Precisely because this connection between creating value for others and receiving value for oneself can be so diverse and non-concrete, people must enter into relationships with each other. Relationships are necessary for the system of human society to function. If you have a good relationship with another person, you will receive something from them without having to give something back immediately. You will also give something without immediately expecting something in return. But the reverse is also true. If you believe that the other person won’t do anything for you, then you won’t do anything for them either. That’s called a bad relationship, and it develops in the same way as a good relationship, namely by gaining experience with the other person. So let’s next look at how a good relationship comes about. Trust Trust is the conviction that you will receive from someone what you expect from them. Every person has expectations of the other person with whom they interact. When these expectations are met to a high degree, trust grows. I collect positive experiences with the person and therefore assume for the future that my expectations will continue to be met. If this is mutual, then a good relationship develops between us. If my expectations are regularly not met, then exactly this experience forms. The advance trust that may have been present initially dwindles. No relationship develops, instead we distance ourselves. While trust is lost very quickly, building trust is much more effort-intensive. It’s not enough to want to meet the other’s expectations, it must actually happen. That’s why let’s now look at what’s necessary for this. Communication Very intensive and honest communication is the first and one of the most important building blocks for building trust, for two reasons: * If you don’t talk to the other person, you won’t learn their expectations and therefore you most likely won’t meet them. Believe me, random hits or intuition aren’t enough! You must communicate very intensively and broadly so that you even learn what moves the other person, what help they currently need, what problems burden them, and what support they’re willing to accept. * If you communicate frequently and extensively, your counterpart gets the feeling that you’re interested in them and their problem and want to help them. Even if the expected help perhaps doesn’t come or doesn’t work as expected, the experience remains that you wanted to help them, and that’s already half the battle. Yes, there’s a right measure for communication. Too little communication is harmful, too much communication is annoying. But communicate more rather than less! Proximity Proximity to each other is closely related to communication. It’s much more credible when you look directly into each other’s eyes during communication, directly perceive body language and emotions. Believe me, it’s no coincidence that executive assistants climb the career ladder much more successfully than other employees. You can assume that they’re capable and probably smart too, otherwise they wouldn’t have been selected for the job. But there are many more competent and smart employees in the company. The difference certainly also lies in the fact that they have proximity to the boss, which enables them to build great trust. Believe me, no one promotes someone they’re not sure is worth the trust! Now not everyone will always have the opportunity to establish this proximity. That shouldn’t stop you from communicating and building trust. Where it’s not so easy, you just have to make more effort. And don’t limit this just to bosses for the sake of your career, because if you don’t have the trust of your colleagues and they don’t help you, then the boss won’t either. Authenticity Authenticity is the next important building block for gaining trust. Be as you are! You instinctively sense whether someone is playing a role, and when you have this feeling, it’s not trust-building. You then involuntarily ask yourself: “Why are they doing that? Do they have something to hide?” This suspicion is fatal and destroys trust. Authenticity is the basis for predictability, and this in turn pays very strongly into trust. Be as you are, then the other person knows what to expect from you. They can then adjust their expectations to reality and also understand why something might run differently than they expected. This also includes openly admitting mistakes and dealing honestly with yourself and the situation. Empathy While authenticity was about you, empathy is about the other person. You must take the time and make the effort to put yourself in the other person’s shoes. It’s not enough to ask the other person about their expectations and then meet them. You must find out what really moves the other person, what they expect from you in their inner self, and what is how important to them. It helps to have known each other for a long time. Over time, it becomes easier to grasp the other’s thoughts, recognize their feelings, and identify their expectations. Reliability Meeting expectations also means being reliable. Actually, this is the simplest discipline in building trust, but it’s still so difficult: Keep what you promise! Do what you say! With expectations that you create yourself, there’s no “I couldn’t have known that!” Yes, it’s as trivial as it sounds: Those who are unreliable lose trust. You can’t build a good relationship with unreliable people. Here too, of course, there’s no 100%. Something can slip through. When that happens, authenticity and honesty can often still save the situation. However, if it becomes the rule to not keep your promises, then trust is gone, and so is the relationship. Reciprocity After talking so much about trust as the basis of a relationship, I want to come back to reciprocity. Reciprocity is the principle of exchanging values. I give you something, I get something from you. This principle forms the foundation for a good relationship and for success in a business context. Trust is the belief or certainty that this principle works between us. But it’s not enough that we both have trust, we must also actively apply it. An important basic rule is that reciprocity consists of advances. Everyone must do the right thing for the other person at the time when they need it. But at that time, they don’t know whether they will really get the return service sometime and whether the measure will be balanced. A situation can certainly arise where one person always gives more than the other in the long run. Perhaps because the other can’t give more, or because I myself don’t need more. In the end, it’s not the balance sheet that’s decisive, but that the principle works at the right time for everyone. So don’t hesitate, when the other person needs support, give it to them. Now comes the big but: There are situations where the other person isn’t willing to do their part of reciprocity. If you recognize this, you must act, otherwise you’re the fool and will be exploited. Address it, and if it doesn’t change, then draw the consequences. There are relationships that can’t be patched up and must then be consistently ended. Willingness to Compromise An important aspect of reciprocity is the willingness to compromise. There will always be situations where your own interests are in opposition to the interests of the other person. Here it’s necessary to find a compromise that both can accept. This requires willingness to compromise on both sides. If one party continuously insists on their advantages, then it’s difficult to build and maintain a good relationship. So be willing to back down sometimes, trust that the other person has the same attitude. Network Maintenance In a business environment, an extensive network of relationships is necessary to be successful yourself and to be part of a successful environment. That’s why you must develop and maintain a multitude of relationships. This costs effort and time, but it’s still advisable and even neces

    16 min

  3. 12/01/2025

    True Partnership Knows No Single Winner

    I think very few people believed we could actually pull it off! It’s been 25 years now. We were a small team with a big mission: “Build a company, develop a portfolio of heavy commercial vehicle axles, and supply the American subsidiary’s serial production with high quality and deliver reliability in 3 years.” When we tackled this impossible mission, one thing was clear: We could only do it together with strong, competent partners. Alone? No chance! The path we chose was unusual back then and still isn’t standard practice today. But before I reveal the secret, I want to describe the standard approach I typically observe—one that has nothing to do with true partnership. That way, you can judge whether this is also common in your environment. Everyone Thinks: The Most for Me! In a way, it’s even logical and understandable. When it comes to business, everyone wants to maximize their profit by using all the levers they have. If you do this consistently, you can observe the following approach: * I need something for my project that my organization doesn’t have. So I have to buy it. This could be parts or services. What it is doesn’t really matter—in any case, I have a problem on the table. * To solve this problem, I search for potential suppliers who have what I need. With some luck, I find multiple offers. * In this situation, I can now use the competition between potential suppliers to negotiate the best price for myself. The more time I have, the more I can put pressure on suppliers. I hold the stronger position and can use my decision-making power to my advantage. * I delay signing the supply contract as long as possible, specify the product very precisely, and negotiate hard on every small, individual cost item in detail. * During this phase, suppliers undercut each other, each trying to offer the best price to win the contract. * Meanwhile, development is already running at full speed. The developers have to work with all suppliers simultaneously, which means extra work and unclear relationships. * Suppliers do only as much as necessary to barely stay in the race. They don’t want to invest too much because they know only one will get the contract. * Once the supply contract is signed, the supplier holds the stronger position. Every change that becomes necessary during product development, they charge dearly for. Now is the time for them to recover what they sacrificed during the bidding phase. * When we’re in serial production and the time comes for the supply contract to expire and be renegotiated, the arm-wrestling starts again. * I threaten the supplier that I won’t extend the contract unless they lower the price. * They calculate how much a supplier change would cost me. In my business, these are substantial sums. That’s why the supplier will explain at length that the previous price is no longer profitable for them and they therefore demand a price increase. * Each side tries to extract the maximum for themselves. I’m in the weaker position because my costs will rise either way. Either I accept the cost increase or I invest substantial sums to switch suppliers. * My leverage returns when the next project begins. However, the current supplier benefits from the experience and assets gained during the previous project, giving them a significant competitive advantage over competitors. They will fight aggressively to retain the business, undercutting any rival without hesitation. The supplier knows they can increase prices again once I’m back in a weak negotiating position—which happens with predictable regularity as soon as the product is completed. * If the supplier manages this skillfully over a long time, they have the opportunity to eliminate all competitors and build a monopoly. Then I’m really in trouble! And of course, my customer does exactly the same thing with me as a supplier! Do you recognize this pattern in your environment? Were you already aware of it, or does it surprise you to see how this actually plays out? You’ll probably also conclude that this approach isn’t efficient and certainly doesn’t lead to an optimal outcome for anyone. There’s either a winner and a loser, or even two losers—which is always the case when neither side makes money in the end. The Way Out: Strategic Partnership I think it’s clear that we wouldn’t have accomplished our task back then if we had proceeded as just described. Instead: We entered into strategic partnerships with our suppliers. Now I’ll explain how that works and what prerequisites are necessary. It Starts with a Shared Vision Unlike the approach just described, my intention here is not to delay the decision as long as possible, but to make it as early as possible. The supplier decision and contract isn’t based on a detailed negotiated price, but on an agreed compromise based on mutual trust. I lay on the table what product goals I need to achieve and what costs I can afford to reach my required profitability. The supplier lays on the table what their product can do and what price they need for their profitability. Of course, this doesn’t fit together yet. Each side must move away from their optimum somewhat. I have to make compromises on product requirements and also be willing to compromise on my price expectations. The supplier may have to invest more effort in their development and also price in cost efficiencies they can’t yet prove. We agree on a mutually supported compromise that includes risks for both sides. Trust Is the Foundation, and That Always Exists Between People The essential difference from the approach described at the beginning is that the basis for the contract isn’t supposedly objective facts, but agreed-upon goals for which both sides must contribute throughout the project to achieve. That’s exactly the crucial point. Both sides must become convinced that each will do everything to realize the agreed overall optimum. There can be no “not my problem” attitude here. All problems are shared problems. This trust only develops when the compromise is intensively discussed. And specifically, the people who also have decision-making responsibility during the project’s implementation phase must talk with each other. This is exactly where the challenge lies, especially for large companies with this approach. The more people who have a say, the more difficult it is to build trust and ultimately to prove worthy of that trust. Back then, we were a very small team with full decision-making authority, and we worked with similar partners. Yet even in that situation, I can say from my own experience that it’s not easy to choose the most trusted partner over the one with the lowest initial price offer. Partnerships and Trust Grow Over Time Once you’ve successfully brought a project to completion on this basis, both sides have experienced that they can rely on each other. That the trust is justified. This strengthens the trust basis for the next project. You don’t just quickly switch suppliers then, but build further projects on this increasingly strong trust foundation. This creates long-term partnerships that provide security on one hand and enable efficient work on content on the other, because the power games don’t happen. Even though it might look like a monopoly at first glance, it is something completely different. Other suppliers still exist, even though the partners choose to stick together for mutual benefit. However, there is no guarantee that a partnership will last forever—that has happened to me as well. When it does break apart, you have to find a new partner. Profitability and Partnership Aren’t Contradictory — Quite the Opposite We’re currently experiencing where power-based business models can lead. Disrupted supply chains, exorbitant costs, and companies struggling to survive. This exact consequence occurs when one side manages to gain absolute dominance without adequate mutual dependencies. If you strive for that yourself, you must also expect that the other side might possibly succeed in building up this position. In a true partnership, this can’t happen. All sides have a common interest and common success. But it’s also important to understand that you can’t force a partnership. If a partner isn’t trustworthy, it doesn’t change anything if they offer the supposedly best price. To put it another way: Cheapness is dangerous! What’s Your Opinion? I could write many more details about partnerships in a business environment. But before I do that, I’d like to hear from you what you think about the topic. What’s your opinion? Are you interested in more details? Have you gathered your own experiences with partnerships? Please write in the comments or let’s chat about it. I will provide more detailed articles on project management topics, transformation, and change in the future. Please subscribe to ensure you do not miss any updates. If you found this helpful, don’t forget to share it with others who might enjoy it too! I’d be very grateful if you shared my newsletter with your friends and colleagues. Get full access to Uwe Mierisch at uwemierisch.substack.com/subscribe

    12 min

  4. 11/10/2025

    Why Equal Power Creates Better Project Decisions

    A Counterintuitive Approach to Better Project Outcomes In my last article, I made a provocative claim. Project team members shouldn’t report directly to the project manager. Instead, they should have a different supervisor. I know this goes against common practice. That’s exactly why I want to explain my reasoning today. The Core Problem: Power Imbalance in Conflict of Interest Situations Let me get straight to the point: Projects have multidimensional goals. Trade-offs are inevitable. The problem arises when a single person must negotiate these trade-offs alone with themselves. The result? Stress for that person and suboptimal compromises for the project. A truly optimal, sustainable compromise requires three elements: * Clear advocates: Each goal dimension needs someone who openly champions that position * Equal footing: All parties must negotiate as equals * Neutral facilitator: A Project Management Master who moderates without their own agenda, working toward consensus This is precisely why I’ve defined project management roles along these goal dimensions: * Project Manager: Responsible for project objectives. * Project Architect: Responsible for the product. * Functional Representatives/Project Team: Responsible for technical execution and content realization. The Power Imbalance Problem When the project manager is also the supervisor of other project management team members, the power dynamic becomes distorted. The project manager possesses additional leverage through their ability to conduct performance reviews and impose disciplinary measures. The consequence is predictable: Team members will carefully consider how hard they push their interests against those of their boss. It’s not easy to contradict your supervisor and consistently advocate for your position against theirs—even when that’s exactly what the project requires. Three Common Objections (and My Responses) “But good managers can make good decisions on their own!” Of course competent leaders can develop compromises independently. The real question is: Are these the optimal compromises? That depends heavily on chance—the manager’s character, their mood that day, the team’s courage to speak up. Why leave project success to chance when we can build it into the structure? “Isn’t this just about performance management?” No. Naturally, managers must monitor performance and address issues. That’s not in dispute. The core of my argument is different: It’s about conflicting interests, not performance deficits. The danger lies precisely in the dual role of project manager + supervisor, where these two issues become too easily entangled. These dimensions must be clearly separated. “In line management, the boss is responsible for everything too!” Ideally, a line manager has a single, clear interest: the functionality of their department. In the dual role, however, multiple contradictory interests systematically overlap. Similar situations exist outside of projects, and they cause significant problems in practice. Often, they’re branded as “micromanagement.” A Concrete Example Here’s a classic conflict scenario that illustrates the issue. The Situation Project Goals: * Reduce energy consumption by 5% * Keep product costs constant (versus predecessor) * Be customer ready in 3 years The Reality: The project team developed optimization measures. Combined, they would just barely achieve the 5% target. But there’s a catch: * Implementing all measures increases product costs * Some measures violate platform guidelines, others conflict with brand standards Responsibilities in a Project Organization To better understand the positions of the individual project team members, here is a brief overview of the responsibilities. Project Manager The project manager is responsible for ensuring that the project goals are achieved. Typical project goals for which the project manager is responsible include: * Delivery deadline * Project and product costs * Performance indicators defined in the project charter (quality, performance characteristics, functionalities, etc.) They owe the project team balanced, realistic goals that they must align and agree upon with the stakeholders. Project Architect The project architect is responsible for a customer-appropriate, platform-compliant product that aligns with brand characteristics. They represent the interests of the platform architecture within the project and ensure compliance with cross-project product properties and characteristics. At the same time, they owe the project manager technical architectures and concepts with which the project goals can be achieved. Department Representatives / Project Team Members The project team members are responsible for efficient and competent delivery of project work. The project team members decide on the working approach and the technical execution. In doing so, they must consider both the project manager’s specifications regarding project goals and the project architect’s specifications regarding product architecture and properties. At the same time, they owe the project manager efficient, goal-oriented procedures that minimize resource and time consumption, along with balanced risk awareness. The Three Competing Interests Those different responsibilities lead to the following perspectives. Project Manager’s Perspective: * Implement all measures * Avoid cost increases through more efficient design * Negotiate remaining cost gap with suppliers * Complete everything on schedule Project Architect’s Perspective: * Implement platform- and brand-compliant measures (even if costs increase) * Drop non-compliant measures (even if the energy goal is missed) Project Team/Functional Representative’s Perspective: * Get more time to search for better solutions * Adjust goals with stakeholders Finding the Compromise In practice, there’s rarely a perfect solution. Not all predetermined goals can be achieved simultaneously. A compromise must be found across all goal deviations: * Time compromise: How much additional time is acceptable? Can other activities be shortened to compensate, or is there flexibility in the delivery date? * Content compromise: Which measures get implemented, which don’t? This determines the gap in energy consumption, costs, and platform compliance. * Process compromise: When are project goals adjusted—immediately or after validation? This addresses how stable or volatile the compromise is. I don’t want to specify a particular compromise here; in each specific situation, a different solution will be the best one. Nevertheless, I think the example illustrates the problem. Deciding or Negotiating Compromise Compromises can be reached in two fundamentally different ways: Negotiating or deciding. In both cases, arguments need to be brought to the table, but not necessarily all of them. Finding Compromise Through Decision Every deviation from a well-considered guideline can have consequences. If there are no consequences, then it’s easy to accept the deviation. However, the consequences are usually neither recognizable at first glance nor assessable in their impact. For this reason, each stakeholder must examine the effects on their area of interest and explain them to the team. In the case of a decision by the project manager, the project managers don’t have to explain their arguments. They make the decision themselves anyway. Of course, it’s a great advantage for the acceptance of the decision if they communicate their arguments in the justification. However, I have very often had to experience that in the hectic rush of daily business, this is exactly what doesn’t happen. The consequence is then a poor collaborative climate and an “I don’t care anymore” attitude. Deciding on a compromise is undoubtedly the fastest solution strategy. However, it’s also the solution strategy with the greatest volatility. The probability of finding the best compromise through decision-making borders on the probability of winning the lottery. As long as it’s a reasonable compromise, it’s not a disaster not to decide on the very best solution. Things move forward in any case, and that’s important. However, possible misjudgments in the decision-making process and a lack of commitment to the compromise within the project team regularly lead to this compromise being frequently questioned afterward. Finding Compromise Through Negotiation In negotiation, all arguments come to the table. Each advocate explains what consequences arise for their area from each potential goal deviation. Here the project manager is part of the team. Then consensus is sought. Consensus means finding a solution everyone can live with, even if not everyone is happy. But there’s both understanding and acceptance. Prerequisites for stable consensus: * All participants are equal * A facilitator without their own agenda guides the discussion This is exactly where traditional hierarchy fails: * If the project manager is the team’s supervisor, they’re no longer equal—they have power. * If they also supervise the Project Management Master, the facilitator is no longer neutral—they’re suspected of representing the boss’s interests. When the project manager is on equal footing, the resulting consensus has significant advantages: It’s based on the entire team’s competence and a shared risk assessment, giving it high quality and acceptance. The Bottom Line I’m not claiming projects can’t function without separating disciplinary and professional authority. Many projects run reasonably well in traditional structures. But I do claim this: The separation offers substantial advantages that significantly improve both project outcomes and project climate. Good compromises aren’t found by luck or because someone decides to be nice. Good compromises emerge through structures that enable genuine representation of interests, equal footing,

    15 min

  5. 11/03/2025

    Small Rudder, Large Ship

    Sometimes it proves useful to explicitly clarify matters that intuitively seem self-evident. Upon closer examination of common project management terms, I find that not everything is as clear as assumed. This is precisely what causes misunderstandings in collaboration. People wonder why things don’t run as smoothly as they would like. For this reason, I want to discuss the following terms in this article: * Management * Manager * Project Management * Project Management Team * Project Team * Project Management Office * Project Management Support * Program Management Office You see, that’s quite a long list. So let me get started right away. This Substack is reader-supported. To receive new posts and support my work, consider becoming a free or paid subscriber. Management When it comes to the term “management,” we need to distinguish: Do we mean the activity itself or the people who perform it? I’ll first focus on the activity and then address the role. Managing Is More Than Giving Instructions! The biggest misunderstanding arises from the fact that “managing” is often understood only as interaction between manager and employee. But it’s much more than that! Unfortunately, it’s also frequently the case that managers inadequately perform these other aspects as well. Which further reinforces this false perception. So what does managing actually include? There’s an abundance of literature that defines the topic very differently. Therefore, I’m presenting a model here that I consider most effective based on my professional experience. Managing includes: Setting Goals, Planning, Commissioning Work and Deploying Resources, Preventing or Solving Problems and Evaluating Results. If you have a different opinion on this, please write to me in the comments—I’m very interested: Now let’s look at the activities which belong to managing: Setting Goals Managing begins with setting goals. Clarity about goals is the prerequisite for any efficient work. However, defining goals is not a matter of inspiration—it’s hard, time-consuming work in itself. Typically, you start with one or more predetermined goals. To avoid going too deep here, I’m deliberately leaving out goal derivation from visions and strategies. Goals to be achieved must be cascaded into sub-goals: * For topics * For organizational units or individuals * For time periods Planning Once goals are found, planning begins on how the goals can be achieved. * What activities are required? * How much time do the activities need? * Who will be needed for execution? * What conditions and prerequisites must exist? * What dependencies must be considered? * How can partial results and goal achievement be measured? * Who must make which decision when? Commissioning Work and Deploying Resources The next step is the one that management is often mistakenly reduced to. Employees are commissioned to perform their activities according to the plan and develop content. Resources such as budgets, work time, or work tools are provided. Decisions relating to content work are made or triggered. Preventing or Solving Problems Plans rarely work out as intended. Therefore: Managing includes anticipating deviations early and taking countermeasures. Evaluating Results Once results are on the table, it must be evaluated whether the set goals have actually been achieved. The evaluation forms the basis for further action. Manager Employees who perform these activities are called managers. I consider it very important that managers personally execute all these aspects of management and don’t completely delegate individual ones. This doesn’t mean that a manager can’t obtain support or input. Quite the contrary: Management is also teamwork. I’ll come back to this later when discussing the management team. Conversely, however, a manager should really only manage and not perform content work themselves. Especially in development environments, it’s not uncommon for managers to also possess domain knowledge. Mixing both fields of activity typically leads to poor management performance. Although executives are often called managers, personnel responsibility is by no means a prerequisite for the manager role. Conversely, executives can and should also manage. In fact, management activities are an essential component of every leadership role—personnel management is then added on top. Unfortunately, I frequently observe that executive-managers only personally perform the steps “commissioning work” and “evaluating results” and either omit or delegate the other steps. That’s not good! It’s the cause of many problems we see in companies. All steps require the same attention, have the same priority, and must be performed by the manager themselves. If they don’t do this, they cannot deliver high-performance management. Believe me, I’ve made this mistake myself and suffered the consequences bitterly. I frequently observe that executives neglect goal definition and planning because they believe they don’t have time for it—or because they think everything is already clear and known anyway. A Side Note: Assistants are an important resource because they support executives in management and thus contribute to better management performance. Bosses who want to eliminate assistant positions for cost reasons have not understood how top-level management works. Project Management The starting point of every project is goals specified by the project’s stakeholders. To realize these project goals, two areas of activity are required: * Managing * Implementing Managing Just as described above, management activities must be performed in the project. The project goals must be broken down into sub-goals along the three project dimensions: cost, time, and performance. Based on this, the project plan is created, the project team is commissioned, and investment funds are released. To control project risks, professional risk management is conducted: risks are regularly analyzed, preventive measures defined and planned. Work results are discussed promptly within the team and with stakeholders. Confirmed results are a prerequisite for reliable and continuous maturity progression. Implementing Simultaneously with the project, work on the project content begins, which proceeds exactly as worked out by project management. A continuous alignment must take place between content activities and project management activities. Project management takes place before the content processing of project scopes. But then accompanies the implementation activities. Goals, plans, and results must be constantly adapted to realities. Project Management Team The project management team consists of: * The Project Manager * The Project Management Master * The Project Architect * The Department Representatives Each of them has their own area of responsibility in which they perform management activities. You can read the details in the respective articles. Depending on the size of the organization, it may make sense for the department representative—who is essentially a kind of project manager for the department—to also have a department project management master at their side. These project roles exclusively perform project management tasks, should be freed up for these tasks, and work in only one project. As already indicated in the heading, too many cooks spoil the broth. It’s important to have only the minimally necessary number of employees, each with a clear focus. Only this way is it possible to ensure excellent situational awareness at all times. This is the basic prerequisite for good project management. Too many people means too many interfaces, unclear task distribution and responsibility. Project Team The project team includes all employees who work on the project scope. It doesn’t matter whether they are exclusively assigned to the project, work in parallel on multiple projects, or are only temporarily involved. The number of project team members is determined solely by necessity, as determined by the project management team during planning. The rule here is: whoever is needed is part of the team—the number of employees is determined only by necessity and therefore has no lower or upper limit. Unlike the project management team, the project team doesn’t work exclusively on content work. Members of the project team also take on project management tasks within their area of responsibility as part of self-responsibility and self-management. This includes the detailed definition of goals as well as detailed planning of workflows and coordination of collaboration. As experts, they provide important input for risk management and develop the results that are confirmed in project reviews. Project Management Office For the Project Management Office, we need to distinguish how this term is used. I know two different interpretations. A Project Management Office is sometimes the area in the office where the project management team has their workspaces. I just listed who belongs to the project management team. If project management supporters are also present, they also sit in the Project Management Office. Spatial concentration in the Project Management Office is highly recommended. It enables the visualization of important project information on the walls—from project plans to risk portfolios to task boards. At the same time, it facilitates spontaneous exchange and coordination, so that all project managers always share the same situational assessment. The Project Management Office can also be the meeting room where project meetings take place. The other version of a Project Management Office is independent of the actual project. In the Project Management Office, project management experts are brought together who are responsible for project management methods and project portfolios. Here, company-internal project management standards are developed, defined,

    22 min

  6. 10/20/2025

    How a Truck Manufacturer Lost Its Product

    Back When a Truck Was Just a Truck In the first half of the last century, trucks were beautifully simple. We divided them into three categories: * Light trucks * Medium-duty trucks * Heavy-duty trucks They were universal tools. You hauled grain, coal briquettes, beer, milk, furniture, machinery—anything that needed to get from Point A to Point B found its ride on the flatbed of the same truck. For manufacturers, the product was crystal clear. One truck type = one bill of materials. You knew the permissible gross weight, you knew the road conditions, and because inspections weren’t as strict back then, you built things a bit more robust just to be safe. Life was simple. Then Came Customer Focus It didn’t take long for the variety of truck configurations to increase. The original standard truck became increasingly adapted to specific use cases, body types, and customer preferences. At first, manufacturers simply created more types. Alongside the flatbed truck, you now had semi-trailers, dump trucks, multiple wheelbase options, and various axle configurations to choose from. Each of these types had its own bill of materials that guided production. Sales Codes Made Diversity Even Greater But then came the flood of additional customer requests, managed through sales codes. Customers could now select equipment details to customize their chosen base model. Different engine ratings, transmissions, tank sizes, power take-offs, weight variants, and much, much more became available. The truck the customer ordered was configured by the salesperson together with the customer, tailored to their specific needs. The bill of materials that guided production was no longer predetermined by engineering. It was now calculated algorithmically using sales codes and plus/minus bills of materials. Each sales code had its own bill of materials with plus and minus positions. These bills of materials modified the base vehicle bill of materials. Part numbers marked with minus were removed from the base bill of materials; part numbers marked with plus were added. A particular challenge was that there wasn’t just one sales code per vehicle order—there could be several. So you also had to list as minus all the parts that might have just been added as plus by another code. This way, a mainframe computer could calculate from the base bill of materials (the bill of materials for the base vehicle) to the correct bill of materials for the customer’s vehicle using Boolean algebra. I can hardly believe it myself, but I personally wrote plus/minus bills of materials. Not on a computer. No, with pencil on printed forms. Entering them into the mainframe was a job for specialists! You can surely imagine that this work was extremely time-consuming and error-prone. The most-used work tool was the eraser. Every designer had to know their scope across all vehicle variants in detail and explicitly document all possible combinations. Inevitably, the time came when this system could no longer be maintained and was replaced by an innovation in product documentation. This innovation was the component bill of materials. NED – The New Engineering Documentation With the new product documentation, base bills of materials and sales code bills of materials disappeared and were replaced by component bills of materials. A component bill of materials contains a small number of part numbers that are always—without exception—installed together. Each of these component bills of materials comes with a long instruction sheet of Boolean algebra, called encoding. It describes exactly in which sales code combinations the specific component bill of materials is applied or not applied. The original vehicle type is now just a container holding all component bills of materials that might be needed in any possible combination of sales codes. When a customer orders a vehicle, a computer program (the variant configuration system) calculates the specific vehicle bill of materials for the customer order based on the codes selected by the salesperson together with the customer. You can surely imagine that writing Boolean algebra for component bills of materials is not trivial. It’s probably one of the most demanding tasks a designer faces in their daily work. But there’s one huge positive effect: Everything that fits together doesn’t need to be described! This means that when writing Boolean algebra, the designer can and must focus on what doesn’t fit together or doesn’t work and must be redirected through encoding to a buildable and functional configuration. In this way, a virtually infinite number of possible vehicle configurations becomes possible without having to explicitly develop and document each one beforehand. The Modular Product Platform The next simplification step was to standardize interfaces throughout the vehicle. It’s logical: the more things that don’t fit together, the more must be regulated through encoding. The next level of simplification therefore consists of designing the vehicles architecture technically so that through cleverly standardized technical interfaces, as many things as possible fit together. Then they no longer need to be encoded in complicated ways but can be controlled with simpler code rules. Modular concepts were developed and brought into production for all construction scopes. Whether a combination is needed or not, it simply fits and therefore doesn’t need elaborate control. The result: * Fewer parts (component bills of materials) * More possible vehicle variants Everything Perfect? So we’ve almost arrived in a perfect world, haven’t we? Just add a bit of AI and machine learning to automate the remaining Boolean algebra writing, and we have everything we’ve always wanted. The manufacturer has relatively few parts in inventory, and the customer gets any variant they want. So everything’s perfect? Of course, in reality, this isn’t as trivial as I’m presenting it here in simplified form. But the basic logic is correct. I’ll take the opportunity in many future articles to go into detail about the opportunities and challenges of this variant control. Since it’s an extremely large topic, it would help me greatly if you’d ask questions in the comments about what interests you most urgently. Then I can address those aspects first. Please subscribe to my newsletter so you don’t miss any of the articles. How Variant Control Impacts Development Scope Management Why did I give this whole long preamble when today I’m actually concerned with how development scopes can be controlled? Well, it’s quite simple: I assume that someone unfamiliar with our business in detail imagines development the way it really once was, when a truck was truly one truck. If the truck needed to be renewed or improved, you simply took that specific truck and redeveloped or modified it. In the current situation, that’s no longer possible, because that one truck no longer exists! Even today, not everyone has grasped that the product of every vehicle development is no longer a truck but a truck modular platform! And this has drastic consequences, because unfortunately this platform is incredibly large and must therefore be simultaneously modified in many places for different reasons. These reasons include: * New vehicle applications need to be incorporated, requiring new vehicle variants * Legal requirements must be met, requiring either the entire platform to be modified at certain points or specific scopes to be modified for certain markets only * Technological advancement occurs in technical systems * Quality problems, supplier issues, or other unwanted disruptions must be eliminated The necessities to modify the product platform are extremely diverse and require varying amounts of time. But at all times, it must be ensured that the complete product platform functions and is customer-ready! Because otherwise, not a single truck can be configured. The Solution: A Four-Stage Project Architecture To master this complicated situation, the famous elephant must be sliced. A Key Central Element: The Project The project bundles development scopes on the product platform that can be handled by a project organization with minimal interfaces and that follow a common timeline. Minimal interfaces in this context means that project contents are assembled to bundle substantively related matters, thereby keeping the number of involved people and organizational units to a minimum. For this, it must first be clear what exactly is needed. I’ve written extensively about this in my article “Getting the Timing Right: Planning Product Development Projects the Right Way.” Typically, the need for changes to the product platform is so great that multiple projects must be organized. Otherwise the scope of work for the each project management team would become unmanageable large. For This Whole Construct to Actually Work, Project Timelines Must Be Stable and Known for the Entire Project Duration Classic project management is required here. The Project Program So that, what we’ve just separated still fits together, the newly defined projects must be combined into project programs. All projects that have their Start of Production (SOP) in a common time period are now bundled into a program and synchronized using multi-project management methods. This requires a small but excellent program management team that knows all affected projects with their mutual dependencies and orchestrates a structured process that maintains synchronicity. An important detail is that the program management team coordinate the start of projects. This ensures that project timelines are sensibly synchronized from the beginning. Since we’re developing a hardware product, prototypes must be built for testing, and these must be complete, functioning trucks. Therefore, projects within programs must be scheduled so that there are points in time when all projects

    18 min

  7. 10/06/2025

    Fast Is the New Safe: Rethinking Vehicle Development Timelines

    For the most impatient among you, here’s the answer right away: In the commercial vehicle industry, I consider it fast to bring a new vehicle to market in 4 years. With the classic approach used in the past, new vehicle development took 6 to 8 years. In the article “Getting the timing right”, I explain that in the commercial vehicle industry, it’s possible to estimate market demand over a 3 to 4-year period with reasonable accuracy. In many cases, external influences limit the available time to just 4 to 5 years. So it has to be faster anyway, and then it’s good if there’s a plan for how to make that possible. In this article, I will explain what project approach can achieve a short development time while still producing a proper product. If you work in a different industry where these timeframes are different, you may still find food for thought that can help in your environment to reduce project duration to a necessary level. I’d like to ask you to write in the comments whether you were able to find such parallels. Fair warning: this works better if you’ve actually read the article first. Why Do Classic Waterfall Projects Take So Long? Let’s first understand why classic product development projects take so long. Based on that, we can consider where we want to start making changes. Classic Project Philosophy Classic project management places the highest value on reducing financial project risk. It must be absolutely certain that large amounts are only invested and contracts are only signed when the content work is finished and the result is confirmed through complete validation. * New technologies are only developed when it’s certain they’re really needed in the market. * Suppliers are only selected and purchase prices negotiated when all technical specifications are known and their correctness is proven. * Costs for production tools and factory investments are only spent when the product has been successfully validated. * Customers and markets are only informed after project completion, so they don’t delay their purchase decision to wait for the new product. The cost of this certainty is having to accept a long development timeline before product availability. Well, and since everything is so certain, the investments can be high. If the business case shows a good payback, then this money is supposedly safely invested. - Or so the theory goes. - What Are the Problems? Let me say it right at the start: You can develop very good products with this classic approach! This has been proven in many successful projects in the past. However, all of life is a compromise, and so is the classic approach. Often this compromise is simply not the best compromise. Before I move on to a different approach, I want to address the problems and challenges that come with this classic approach. Not All Assumptions Are Safe To gain certainty, decisions need a secure data basis. As just described, in classic vehicle development projects, this certainty is created by carefully and laboriously securing all decision premises before a decision is made. Unfortunately, it’s impossible to do this with all premises. Some premises inevitably arise for which assumptions must be made that cannot be validated. These premises now introduce risk into the project that it’s not prepared for and can’t handle well, because absolute risk avoidance is also a project premise. When these risks then actually occur, they throw the project off track. Decisions are reversed, setbacks in project flow cause time delays and excessive costs. Changes in the Environment Create Instability This problem is amplified by the fact that, due to the long project duration, supposedly secure premises become outdated and generate volatility that leads to the same consequences. Sequential Work Is Always Connected with Loops Ironically, the effort to boost efficiency by having departments wait for validated data leads to considerable rework. * First the developers develop. * Then the purchasers negotiate with suppliers. * Production planners plan production next. * At the very end, the after-sales experts figure out how the product can be repaired. * The controllers always carefully ensure that money is only spent when everything is clear. When specialist functions start later, they inevitably discover issues with the supposedly validated data only at a later stage. The premises originally considered secure turn out to be wrong in the course of work, and the correction causes setbacks in project progress. Previously completed work based on the original assumptions must now be repeated. This causes time delays and significant inefficiencies. The Required Time Is Not Available The worst problem is that there’s often simply not enough time for such an approach. Then the 6 to 8 year project plan is simply compressed like an accordion. Now it’s over with the secure premises! The lack of time leads to poor results that are inadequately checked. Occurring risks are no longer a regrettable exception but a certain reality. An organization geared toward certainty is thrown into chaos and is methodologically unable to deal with the chaos. This is the point where task forces, freestyle, and excessive resource and time expenditure become the project management method. Project goals are now secondary; now it’s only about being able to deliver at all. Alternative Approach - The Super Sprint Project Philosophy An alternative to address these problems is to focus on speed instead of financial certainty. Although it may not seem so at first glance, it doesn’t mean that more money is spent. It only means that the supposed certainty is only proven late in the course of the project. * New technologies are prepared at a time when no concrete market need is yet recognizable. * Project goals are set conservatively and in close alignment with customers, without the expectation that the product must be offered unchanged for a long time. Quick availability and subsequent short-term further development are project premises. * All specialist areas work simultaneously and complete their stages at the same time. (You can read about the individual phases in DCVI in a separate article.) * Short-cycle planning and implementation phases enable situation-appropriate prioritization and proactive response. Solution to the Problems Predictive Technology Validation Technology development takes time, there’s no way around it. To understand technologies sufficiently well when they really need to be applied on a large scale, you can’t wait until the last moment. What seems like the most cost-effective approach – delaying investment until you’re absolutely sure – actually proves the most expensive. The better approach is to engage with the technology immediately and learn for little money and on a small scale. I’ll describe exactly how to do this in a separate article. This phase can be completed in a few months; for large, very innovative technologies, it can take one to two years including customer feedback. There are several important premises to maintain: * Everyone must participate, not just product engineering! Purchasing, production planning, after sales, even controlling must use this opportunity to acquire the necessary competence to assess and apply the new technology. * End customers must be involved and have the opportunity to develop qualified feedback. They must be part of the activity. * Over-development must not occur in this phase. When the technology is sufficiently well understood, pause until a concrete application project is started. When the time comes that the technology is needed in the market, the product can be developed quickly and without loops based on the identified market need and good knowledge of the technology’s potential. If the technology doesn’t meet expectations, it was better to invest little money in this realization than to bring the technology to production for expensive money because there’s no way back. The DCVI Project - The Super Sprint When the time comes to start the product development project, the DCVI approach is applied. I know, I know. The agilists will criticize me. You can’t stretch a sprint over 4 years; then it’s not a sprint but something else. Fine by me, let me call it a “super sprint” then. Nevertheless, the approach used in a 1-week sprint also makes sense over a relatively long period. The approach consists of 4 phases that all involved employees complete together. * Definition - Everyone aligns specifications with each other. I really mean “everyone”! This is an exciting phase because nobody yet knows exactly how they will solve their problems. Nevertheless, it’s important that all concepts, strategies, and premises are integrated and coordinated with each other. This is the heyday of systems engineering. At the end of this phase, everyone looks each other deep in the eyes and knows what each individual’s result must be for the product to work in the end. * Creation - Now everyone develops the concrete solutions. Intensive teamwork is required here as well. At the end of this phase, the product and all its accompanying processes are theoretically finished. Again, everyone looks each other in the eyes and says with deep conviction: “I’m sure this will work!” But everyone also knows that no one can be completely sure because there’s no proof yet. The certainty is based purely on the professional competence of the involved employees. * Validation - The product is built and tested together with all accompanying processes. From now on, only what doesn’t work is fixed, and this must happen very quickly. At the end of this phase stands the question: “Are we really finished?” * Implementation - Now only the process capability of the large-series process remains to be installed. There’s naturally a lot to tell about each phase, so I’ll write separate articles a

    17 min

  8. 09/22/2025

    The Transformation Framework: How to Organize Reformation That Actually Works

    Picture this: You're the leader of an organization that desperately needs to transform. You've identified the problems, you have a vision for the future, and you're ready to make it happen. But here's the brutal truth—most transformation efforts fail not because of bad ideas, but because of bad organization. As a leader, my job isn't just to spot what needs fixing. It's to analyze my organization, leverage our strengths, address our weaknesses, paint a clear and realistic picture of where we're headed, and—when fundamental transformation is necessary—make sure it actually succeeds. That's what real leadership looks like. Over the years, I've tried countless approaches to transformation. Some worked brilliantly, others crashed and burned. But the most recent transformations I've led have validated a core framework that I want to share with you today. Every organization, every team, and every challenge is unique. But certain principles hold true across the board—and knowing when to be flexible is just as crucial as knowing what never changes. The Top Management Dilemma: Three Levels of Executive Engagement Let's start with an uncomfortable truth: Without top management commitment, transformation is impossible. I think we can all agree on that. But here's where it gets tricky—what role should top management actually play? There are three main approaches, and each comes with its own set of challenges and opportunities. Option 1: The CEO-Led Transformation (The Gold Standard) This is my number one recommendation because it's simply the most effective approach I've seen. When the CEO or a managing director personally leads the transformation—not just announces it, but actually rolls up their sleeves and works alongside the team on both the vision and execution—something magical happens. Credibility becomes unshakeable. Priority and focus become automatic. But here's the catch: the leadership team must invest significant time working with the entire organization, not just a select group of elite employees. This approach is common in startups, and I've experienced it firsthand as a member of a startup's executive team. The efficiency is remarkable, which is why I strongly recommend choosing this option whenever possible. Of course, in the real world, there are plenty of reasons why this ideal scenario rarely happens. Which brings us to... Option 2: Top Management as the Principal This variant comes into play when leadership can't dedicate the necessary time to personally lead the transformation but is fully committed to the transformation. Here, top management appoints a transformation manager and team that has their absolute trust. And I mean absolute—this trust is the foundation that makes or breaks this model. Management and the transformation team must speak with one voice and give the transformation identical priority. Even in this setup, leadership can't completely step back. They need to invest enough time to stay aligned with the transformation team and demonstrate the transformation in their own leadership behavior. When the organization sees this united front between leadership and the transformation team, acceptance follows. Option 3: Top Management as Participant (The Nightmare Scenario) This is the most exhausting variant with the highest risk of failure—and unfortunately, it's the one I've had to navigate most often in my career. The scenario goes like this: Everyone agrees transformation is necessary. Leadership is willing to provide resources—people and money. But they don't see themselves as part of the problem. "The people down there need to transform. I'm fine and can keep doing what I've always done." Here's the harsh reality: in every transformation, top management is always affected and must transform their own thinking and behavior. In this situation, the transformation team must work on two levels simultaneously: * Achieving transformation with top management * Implementing transformation with the workforce The real killer? The workforce picks up on mixed signals from leadership, which compromises the entire effort's credibility. If you're a transformation manager in this situation, don't lose heart. You'll need unbreakable optimism, but I can tell you from experience: it can work. It's exhausting, you'll face countless frustrating phases, and it takes much longer than the other scenarios—but it's possible. Pro tip: Don't be fooled by lip service. Top management rarely admits this attitude openly. Judge them by their actions and adapt your approach accordingly. Building The Transformation Dream Team Your transformation team should consist of 3 people minimum (2 if you absolutely must), all dedicated full-time to the effort. If you get the luxury of more dedicated team members, take it gratefully—it won't hurt. The Transformation Manager is the brain of the operation. They define strategy and make tactical implementation decisions. The other team members discuss strategies with the manager, organize operational execution, and communicate throughout the organization. Here's what's non-negotiable: The transformation manager must be an opinion leader in your organization. Not in the sense that "everyone likes them," but in the sense that "when they speak, people listen." This usually requires seniority, though I've seen young professionals build this kind of standing too. Regardless of how leadership views the transformation, the transformation manager must have the complete personal trust of top management. The nature of transformation means no one can know exactly what needs to be done or where the journey will ultimately lead. Your transformation team needs solid baseline qualifications in the domain being transformed, keeping them at least two steps ahead of the organization in the learning process. Simultaneously, they must possess the leadership qualities necessary to guide an organization without being able to present a detailed roadmap. The Consultant Question Two or three people aren't enough to transform an organization. At the same time, transformation is temporary—it shouldn't become a permanent state. This is why it makes sense to engage experienced consultants who can provide both capacity and content support. It's helpful when consultants have experience in similar contexts from other organizations. Even though consultants aren't cheap, don't be stingy here. Usually, your company's future is at stake—you must invest sufficiently to make success possible, even when creating a business case and payback calculation is challenging. The Middle Management Make-or-Break Factor Here's a truth that might surprise you: Middle management is the critical success factor for any transformation. * They're deeply involved in business processes enough to understand and help shape change. * They have the leadership experience and hierarchical power to get their employees on board. * But they also have significant influence upward. It's unlikely that top management will ignore middle management's opinions—if trust isn't there, the middle manager gets replaced. So you can assume the people in these positions have their bosses' ears. Your transformation team and middle management must pull in the same direction for organizational transformation to succeed. Take middle management seriously and give them your full attention. They're the critical factor determining success or failure. To ensure middle managers invest sufficient time in transformation while still handling day-to-day business, you must especially appreciate and focus on those with intrinsic interest in the topic. They're your gold nuggets—guard them carefully so they don't get lost. Project Organization: Creating Structure in Chaos You can't work with everyone simultaneously, so you need a well-structured project organization. Consider which organizational units are represented by whom in your transformation project. Form sub-projects and appoint selected middle managers as sub-project leaders. Even though transformation isn't strictly a project (because goals and endpoints are unclear), you can and should use project management structures. I won't propose specific structures here since they depend heavily on your concrete situation. But if you want to discuss your specific scenario with me, send me a message or write in the comments, and we'll find time to talk. The Communication Imperative The final crucial pillar in your transformation framework is communication. Communicate intensively! * Communicate what you're planning * Communicate successes * Communicate lessons learned * Communicate immediate next steps * Communicate who's doing what * Communicate parallels to transformations in other organizations * Communicate praise * And more... Your transformation must always be part of the conversation, everywhere. Use every communication channel available in your organization: * Intranet * Email * Town halls * Quarterly calls * Newsletters * Communities * Training sessions * And more But use one communication form extensively: Talk to people. Discuss. Approach people in hallways, in the coffee kitchen, take them to lunch and talk about the transformation. Go into different functional areas and face the criticism—it will come, that's certain. Meet criticism constructively with a positive attitude, even when it might be unfair. It offers you an irreplaceable opportunity to get your arguments across and have people's attention. Don't get discouraged if you don't win every debate. Trust me, over time the desired effect will emerge—people will become more open to transformation and eventually start participating or even helping to shape it. But you must pay the price of investing incredible amounts of time in discussions and communication. The bottom line? Transformation isn't just about having a great vision—it's about building the organizational framework that can actually deliver

    15 min
See All (28)

About

Leadership, Processes, Best Practices in Product Engineering uwemierisch.substack.com

Information