Introducing the Lean Team Organization

/in /by

Introducing the Lean Team Organization

Why a New Organizational Structure?

Over the last 15+ years I have worked in most of the existing organizational structures currently known. This includes the line, matrix and project organization and numerous kinds of hybrid structures.

In technology companies which operate in a fast moving and a highly complex environment, all these classical structures are a setup for failure. Originally, they all were designed and chosen to provide more efficiency by separated and specialized disciplines. The price to pay for such specialization is the inability to stay innovative. This becomes especially visible when politics prevent the organization from moving forward or when silo building is used as an excuse for not seeing the complete picture. Another indication that the ability to innovate has been lost is the fight for resources in an environment where too many projects run in parallel and where it is never possible to equip them with a reasonable amount of people. I call this “filling the holes” by creating new holes. The result is that management and employees become frustrated and, more importantly, customer schedules repeatedly slip. Worst of all, this environment leads to the degrading of the product quality and starts a vicious circle.

The standard behavior of companies which recognize this is the call for an agile concept. Usually, the traditional organizational structure remains untouched or, sometimes, it translates from one classical structure to another. The outcome is just more complexity during the transformation and lower probability to succeed. After several months of transformation to an agile mindset (and hoping for the best), it becomes evident that the organizational efficiency is worse than before and, unofficially, the working behavior falls back to the old approach. For me, this is no surprise at all because old departments and silo thinking has never been removed and is still inherently built into the organizational structure.

The Lean Team Organization

I propose to tackle this problem by its roots. I believe that it is time to use a completely new organizational structure which is built in such a way that it focuses naturally on the following two goals:

  • Provide customer value
  • Continuously stay innovative

 

First, in order to provide customer value, the structure should align on the product provided to the customer instead of building departments. They lay the foundation for silo thinking and prevent multi-discipline developments.

Second, to remain innovative it is essential that there is enough freedom to experiment. New ideas must be openly discussed within many different disciplines. In other words, the creative mind needs new and open discussions instead of silo thinking. A McKinsey survey found out that 84% of worldwide executives believe that innovation is extremely important for their business but only 6% are satisfied with their innovation performance (“The eight essentials of innovation”, McKinsey, April 2015). I state that this is related to current company structures which support mono-environments (dedicated departments) instead of heterogeneous environments where new ideas flourish and innovation is created. To keep innovation high, it is essential to have cross-functional teams.

Based on this idea I propose the Lean Team Organization (LTO).

Don’t get me wrong, I don’t want to throw away any of the existing organization structures completely. There might be companies which make use of them very successfully. However, in case your organization provides innovative products and you must rely on doing so in the future, you might think of re-organizing into a Lean Team Organization (LTO). Some areas of your company might not be touched by the LTO, e.g. the production facility where the target is to build hundreds of units with the same quality standards. A lot of good and proven approaches are available and should be used. Also, company internal support structures like Human Resources or IT departments might be better off with a line organization.

The Lean Team Organization replaces departments which are primarily and secondarily responsible for innovation. Namely, the R&D departments, Product/Portfolio departments, Purchasing departments, Quality departments and Service departments. They are replaced with the following cross-functional teams:

  • Product Owner Team (POT)
  • Feature Innovation Teams (FIT)
  • Feature Optimization Teams (FOT)
  • Product Portfolio Team (PPT) – optional
  • Workflow Teams (WFT) – optional
  • Product Service Teams (PST) – optional

Three teams build the core of the Lean Team Organization. They are linked together and form the center of innovation and customer value creation. Namely, the Product Owner Team (POT), the Feature Innovation Teams (FIT) and the Feature Optimization Teams (FOT). The idea relates to the Lean Startup approach described by Eric Ries and more practically put in place by Ash Maurya in his excellent book „Running Lean“ (ISBN: 978-1449305178). But I go even further. Maurya/Ries don’t talk about the underlying organizational structures. I believe behavior follows structure. Therefore, it is essential to build the company structure around cross-functional teams and completely eliminate the so-called innovation departments.

The following picture shows a generic Lean Team Organization organigram. The must-have-teams are highlighted in orange. The optional teams are highlighted in blue and the elements which remain in their classical form are in black.

Generic Lean Team Organization

Product Owner Team (POT)

The Product Owner Team (POT) provides the vision for a new product. Members are the product manager, the leads of the FI/FO-Teams, marketing & sales, controlling and eventually legal and logistics. The POT does not develop the product directly but provides an outside view in order to decide whether the product provides customer value or not. In other words, the main objective of the POT is to guide the Feature Innovation Teams / Feature Optimization Teams and decide when to pivot or persevere. For every product only one Product Owner Team (POT) exists.

Product Owner Team (POT)

The Product Owner Team (POT) provides the vision for a new product. Members are the product manager, the leads of the FI/FO-Teams, marketing & sales, controlling and eventually legal and logistics. The POT does not develop the product directly but provides an outside view in order to decide whether the product provides customer value or not. In other words, the main objective of the POT is to guide the Feature Innovation Teams / Feature Optimization Teams and decide when to pivot or persevere. For every product only one Product Owner Team (POT) exists.

Feature Innovation Team (FIT)

The Feature Innovation Team (FIT) is responsible for innovating and validating new ideas in the market. The team consists e.g. of a mechanical engineer, electrical engineer, software engineer, technician, vision engineer, purchaser and other individuals who represent a specific discipline needed to build the product. The Feature Innovation Team builds a minimum viable product to validate new features quickly. This is done through a validated learning process. The goal is to find the best problem/solution fit. I refer to the terms and procedures defined by Eric Ries („The Lean Startup“, ISBN: 978-1524762407, Oct. 2017) and Ash Maurya („Running Lean“, ISBN: 978-1449305178). The process of validated learning is described as the implementation of a new feature combined with the validation of whether the customer finds it valuable or not. Only if key performance indicators clearly indicate that the new feature solves the problem sufficiently, it is approved, and the team continues to refine it. If the market does not find the new feature valuable, the feature is removed. The target customer market is the “early adopter” market (see “Crossing the Chasm” by Geoffrey A. Moore, ISBN: 978-0062353948).

Optional Teams

Once the organization has matured, three other teams are recommended to keep the FI/FO-Teams and the Product Owner Team productive. These teams are called the Product Portfolio Team (PPT), the Workflow Team (WFT) and the Product Service Team (PST). Let me explain these teams briefly.

The Product Portfolio Team (PPT) consolidates the individual product visions to an overall company and product portfolio vision. The team consists of the product managers of related POTs and the leads of all other teams working for this portfolio. The PPTs responsibility is to decide when to create a new team for the portfolio and which POT this team reports to. Another responsibility of the PPT is to consolidate features across different products of the same portfolio and to decide which product to end or which new product to launch.

The objective of the Workflow Team (WFT) is to build and refine the infrastructure used by the teams. They should be able to work seamlessly and as fast as possible. The Workflow Team regularly aligns with teams to find and solve difficulties they might have. The Workflow Team can negotiate specific supplier agreements in order to provide parts quickly to the teams, if physical parts are needed during the development. The Workflow Team also takes care of tools and equipment used for the development (e.g. CAD tools, Software Development Environments, Test racks, Test equipment, etc.) as well as design guidelines. Team members of the WFT are again from different disciplines and build a cross-functional unit.

I am aware that creating a Workflow Team is considered luxury in a startup condition, but it is essential for bigger companies. It is difficult to define a measure of when to establish WFTs. It depends on the business success and the maturity of the company but also on availability of resources.

The Product Service Team (PST) is needed as soon as the quantity of products in the market increases and the FO-Teams cannot continue to support customer requests directly. If they still did, no optimization on the products would be possible. As with all other teams, a cross-functional membership is needed to make Product Service Team work efficiently. When to setup a PST depends on the business success, the number of products in the market and the amount of customer support needed. Additionally, it makes sense for each PST to support a whole product portfolio instead of only one single product. Again, this depends on the product itself and the real support needed.

Differences between the Lean Team Organization and the traditional organization

The main difference of the LTO structure compared with any traditional structure is the absence of specialized departments and the introduction of cross-functional teams. The major advantage of these teams is that individuals can clearly identify with them in contrast to traditional structures where individual are assigned to their department and multiple teams simultaneously. These multiple assignments make it difficult for people to really connect and engage with one group. More precisely there are at least two issues with the traditional concept. First, it is up to the individual to decide which group is the main focal point. Secondly, the assignments to a multi-diciplined team are usually only temporal. This is indicated as dotted lines in the organigram. Department members are indicated as a straight line in the organigram. One should note the commonly used terms straight line and dotted line which imply that individuals are considered to have a strong connection to their department and a rather lose connection to the team. In such a setup humans instinctively bias their engagement towards their department, which is the opposite of what we want in order to create efficiency and a make-it-happen spirit.

The Lean Team Organization instead clearly assigns individuals to one and only one team. Responsibility and accountability are clearly assigned to this team and its members. There are no dotted lines. Individuals fully engage and identify themselves with their team. Futhermore, every member adds different skills and know-how to the team and the team becomes a cross-functional one. These cross-functional teams are the perfect hotbed for innovation and new ideas.

The second difference is how work is distributed inside the structure. In a Lean Team Organization, teams are truly teams and stay together. Therefore, products and individual features have to be assigned to teams. Be aware that this is fundamentally different to any traditional organizational structure where people are pulled into existing teams on-demand to develop features and released again to their department as soon as the feature has been implemented. The LTO requires teams to stay together, no matter which features are to be implemented or which product is assigned to them. Doing so paves the ground for teams to become efficient, productive and enthusiastic. In other words, the LTO creates a culture of employee engagement.

People assigned to features (classical) vs. features assigned to teams (LTO)

The third difference in an LTO structure is that dedicated projects and project managers are not needed anymore. The Product Owner Team takes over these tasks of project management and, when features are assigned to the Feature Innovation Team or Feature Optimization Team, it is self-organized and responsible to implement them. The FI/FO-Team is also responsible for providing data to the Product Owner Team, which clearly shows that the feature increased customer value. Regular alignments between POT and FI/FO-Teams guarantee that the overall cost, time and quality targets are met.

Finally, the Lean Team Organization does not require any kind of product development process. The product itself is constantly enhanced and validated. Forget about the one and only product version in the market. Using the Lean Team Organization several minimal viable products together with released products are simultaneously in the market and constantly undergo the validated learning process. The typical development process which starts with a concept, followed by an ALPHA prototype, BETA prototype, first series and final serial production is no longer relevant. At any point in time, multiple versions of one product are in the market. Look at your current development process. Chances are high that this is what you practise anyway in your classical organization. If you analyse in more detail why the dedicated phase gates must be prepared, you come to the conclusion that they are in place to accommodate internal budget assignments between departments or to provide a status to upper management. Realistically, the phase gates of a classical organization don’t say anything about the customer value of the product and whether it is still in the early adopter market or already able to scale into the mass market. Another advantage is time-to-market. As one can see in the comparison of a classical organization with phase gates and the Lean Team Organization below, the time until a first product hits the customer, is reduced from several quarters to just a couple of months (or even less, depending on the product itself).

Product Life Cycle comparison between LTO and classical organization

In this post I have explained the essence of the Lean Team Organization which I believe is a new organizational structure ready to support companies in the 21st century.

Now, I would like to start a discussion with you about it. Do you agree with my idea? Is your organization already structured this way? Do you see any issues to use this structure in your company?

I appreciate any comments.


Back to blog overview

Do you have any more questions?

Write a comment

Your email address will not be published. Required fields are marked with *.

Re-thinking how organizations work

/in /by

Re-thinking how organizations work

Think about the organizational structure you work in and evaluate the following questions:

  • Do you work in a line, matrix or project organizational structure pimped up with some agile methodology, but you don’t see any improvements in customer value, innovation and transparency?
  • Do you have many projects running in parallel but only a few produce revenues and move you and your company forward?
  • Is your organization difficult to control and the established processes need more and more exceptions from the standard?

 

If any of these sound familiar to you, I can reassure you: You are not alone! In my opinion, these problems become more and more visible and, at the same time their solution is crucial for a company in order to stay successful.

I believe that the root cause for all these problems are flaws of the classical organizational structures available and in use today. They are consequences of the structure itself. Consider that these structures are built during a century where specialization of departments and individuals was essential to improve productivity. In these days, productivity was considered the holy grail of a successful company. Today, productivity is only one element of success and its importance is decreasing.

It is time to re-think our organizational structures if you rely on constant innovation, time to market and a good fit between your solution and the customer problem. A new organizational structure should be built in such a way that it naturally boosts:

  • customer value creation and
  • innovation

 

I call this organizational structure the Lean Team Organization (LTO).
To get a first overview of the structure have a look to the blog on the topic. 

In this blog I want to share my thoughts about this new organizational structure and I would be happy to discuss and refine the model with you.

In my first post I explain the basic structure of the model. I am looking forward to discussing this model with you in this blog.


Back to blog overview

Do you have any more questions?

Write a comment

Your email address will not be published. Required fields are marked with *.

About teams

/in /by

About teams

TEAMs are the innovation engine of an organization. To control them, managers must understand how teams behave as a system and how to influence them in order to get maximum team performance. The difficulty, though, is that they cannot be managed directly from the outside. Instead, managers must indirectly control teams through the adjustment of environmental conditions. The key to control teams is to know which conditions influence the performance and how to determine whether adjustments foster team performance or not. To control teams is never easy, never the same and never straightforward. In the following, I show two well-known theories which can serve as tools to monitor team performance and thus, to control teams.

The team itself

Let us have a look into the system called “team” and what it takes to be a performing team. For the moment, we omit the environment in which the team exists and focus on the team’s inner development level. These levels are best described in the book “The FIVE Dysfunctions of a Team” by Patrick M. Lencioni. Note that these levels of ability can only be experienced by team members themselves and not from outside of the team.

Level 1: The team’s ability to trust
Lencioni states that “[…] trust is the confidence among team members that their peers’ intentions are good, and that there is no reason to be protective or careful around the group.”

Level 2: The team’s ability to engage in conflicts
Team members should be passionate and enthusiastic when debating. It is all about productive conflicts and the ability to sit through these tough discussions always knowing that, at the end, the team has strengthened their bonds between all teammates.

Level 3: The ability to commit
A team must “make clear and timely decisions […] with complete buy-in from every member”. This ability assumes that all opinions are put on the table. Even those members who have a different opinion get heard and finally buy-in to the team decision. There are no hidden agendas after decision has been taken.

Level 4: The team’s ability to be accountable
The willingness to address misbehavior of teammates who do not comply with the team’s expectations. It requires team members to take the risk of an unpleasant discussion instead of quietly accepting the underperformance and trying to cover it for the sake of a “good climate”.

Level 5: The team’s ability to strive for team results
The final level of a truly performing team is to strive for team results instead of individual goals.

Every level builds on all the previous levels.

How to determine the inner team level from the outside

A tool to determine the inner team level from the outside is the commonly known definition by Tuckman (Forming, Storming, Norming and Performing).

It gives outside observers the opportunity to know how the team develops and whether the team is going to provide results soon or not. For example, if you observe that the team is in the Storming stage, you should not expect significant results or progress because the team’s inner level is probably somewhere between trusting each other (level 1) and engaging in conflicts (level 2). Whereas a team which is in its Performing stage can provide results in short intervals because the team’s inner level has at least reached the level of commitment (level 3). It is the role of the team leader as part of the team and not of the management to work together with the team to lift it to higher ability levels. It also requires experience and, most of all, time for the team to work itself through all levels. The latter one is particularly important today because team members come and go frequently. Adding or replacing team members is considered the standard action taken by managers in order to increase team performance. Although it solves the current topic and gets managers the desired short-term result. The overall team performance declines, and project schedules prolongate instead.

Environmental conditions are crucial

Both theories are important to understand and to monitor team status. But how can managers control teams from the outside? The only way is to shape the environmental conditions in which teams operate. They are essential for any team development and build the foundation for achieving team performance. Think about environmental conditions as the fertile soil in which you seed a new team. Just like good soil depends on enough minerals, water, stones, etc. the hotbed of team development depends on eight environmental conditions. (see clouds below).

Team size between two to seven members

Teams with more than seven members are increasingly difficult to handle. Why? Bigger teams are more likely to build subgroups or even split and, therefore, usually have difficulties to concrescence. The ability of the whole team to easily come together and communicate, discuss, align, decide and have fun is key for team development.

Multi-disciplinary teams only

We expect teams to create innovation and new ideas. However, teams cannot serve this purpose if there is only one opinion. Only if different views are expressed and discussed, innovation and new ideas will rise.

Work in Progress (WIP) limits

This factor is most difficult to implement but, if managed properly, it has the biggest impact on the teams throughput and quality of results. Eric Willeke discussed this topic and its implications very descriptive in his speech “Escaping the tragedy of WIP” at the AgileAlliance conference in 2019 at Washington, DC. Eric explained the consequences of increasing the WIP above the teams WIP limit as follows: First, starting with zero and increasing the WIP for a team will linearly increase the throughput (more output per interval) over time at constant quality. However, if the WIP limit of the team has been reached, every new work item assigned to the team will exponentially decrease the throughput (less output per interval) and negatively impact quality. Why? Because new work items cannot be executed immediately. Every team member is already fully loaded. Therefore, the new items are added to the team’s own (usually unofficial and hidden) backlog, and this backlog is executed whenever the next slot is available. Note that this is another drawback of exceeding the WIP limit: the existence of hidden backlogs. Avoid them by any means. If they exist, you won’t be able to predict anymore when work is being completed. Fact is, if this happens, you’ll start to lose control. Team deliveries are unpredictable and aligning multiple teams becomes impossible.

Keep team affiliation

A steady team affiliation is required to keep the team development process flowing towards maximum performance and highest inner level of ability. In other words, every time a team member leaves or joins the team, the team development process starts all over again. Our goal is to reach the team stage of “Performing” as quickly as possible and hold this stage as long as possible, ditto with respect to the inner ability levels. Therefore, any unnecessary team fluctuation should be avoided.

Assign features to the whole team instead of individuals

Features or work items rarely require only one skill to be realized – it is always a team effort. Based on this understanding, assigning work items to a team instead of one member seems natural but still, managers instinctively don’t do this. One explanation for this is that managers think of who is responsible and not who will implement it. Managers do not realize that commitment and accountability inside the team are needed to complete the work items. A commitment of one member of the team to the manager is not crucial.

Define a team lead upfront

As mentioned, a team cannot be developed from the outside. Teams can only be influenced and shaped from the inside. Either by leading by example or moderating. Whatever you do, remember, the team lead is always part of the team. Also, it is human to desire a team lead in case this role has not been defined yet. Otherwise, the herd does not know whom to follow and, sooner or later, it will break up into small groups. Managers should not leave this decision up to the team and hope that, by chance, it selects the member with the best skillset for this job. Let’s turn this into an advantage and define upfront the one with the best skills to fulfil this role.

Support team gatherings

Team gatherings are the social events where teams work (unconsciously) on their own team development. While the gathering itself cannot be influenced, the environment can be setup to encourage team gatherings. This can either be a common space where the team can meet spontaneously, or a more organized form of gathering such as team dinners or just going out to the next pub. Most importantly, the organization should be open for suggestions and should be willing to invest money and time. Investments though are often difficult to justify because the return of investment is somewhere hidden in the overall performance of the team. It is the responsibility of the team leader to convince management that it is a fruitful investment.

Define a clear structure to synchronize with other teams

Teams are not independent entities within an organization. Instead, teams have a web of connections between each other. In order to simplify the alignment and the team-to-team communication, it is good practice to define common synchronization structures. For example, regular conference calls between teams, regular meetings of all team leaders or even the definition of communication channels in tools like Slack or Microsoft Teams. Most importantly, the methodology considers the culture of the organization and should be in line with it. Otherwise its benefit of team-to-team alignment is neglectable. Face-to-face visits between teams, are definitely preferable to phone calls. In practice, they are rarely done. Mainly because of two reasons: it is too costly and not all team members are willing and capable to travel. Therefore, I recommend not to spend time and effort for a single face-to-face meeting and, instead, focus on other ways to synchronize regularly. The emphasis is on “regularly” instead of one time only. Whatever you choose, the right balance between effort to synchronize and spread of information will boost your team cooperation and overall performance.

Once you have agreed with management on how to handle these eight factors, you should write them down and make them available to all employees. This helps to apply them during your day-to-day work and holds management accountable.

To Summarize

For managers who rely on teams to deliver results quickly, the only measure they can apply is to focus on the environmental conditions. It will have a negative impact on the team and its performance if managers try to interfere with the team directly. This should only be done by the team leader. He/She is the only one who can actively influence the development towards a performing team. Leaders, on the other hand, should know that everything begins with the ability to trust. They should choose their instruments of team building carefully. Remember, every level of team ability must be taken one by one and shortcuts are not possible. With the help of Tuckman’s theory of team development, managers can identify the status of a team from the outside and adjust the environment to foster team performance if needed.


Back to blog overview

Do you have any more questions?

Write a comment

Your email address will not be published. Required fields are marked with *.

7 rules to manage your backlog

/in /by

7 rules to manage your backlog

Using a Backlog for your product is one of the best ways to sort requests and to manage your development effectively and efficiently. If you do it right, you’ll always keep a clear focus on customer value. With a traditional project management background, you probably remember a similar element called Work Breakdown Structure (WBS). But be careful, a WBS is fundamentally different from a Backlog. The latter is a living element in your project that adapts to new insights and, most importantly, focuses on customer value. A WBS, on the other hand, is a static, one-time summary of the components required to complete your project and, frankly, has no value or focus on your customer.

If you want to take advantage of a Backlog and if you want to lead your team based on the most valuable features inside your Backlog you should follow the seven rules below. Otherwise, your Backlog will only be a waist of time. I am sure there are other topics to be considered when managing a Backlog. Especially, if you include tool specifics guidelines. But no matter which tool you use these seven rules are the must follow topics in order to take advantage from your Backlog.

  1. Sort items on a timeline
    You should use at least three different time horizons to group your elements. Namely, a short-term, medium-term, and long-term horizon. In agile terminology, this is typically referred to as iteration, release, and roadmap horizons. The granularity and level of detail is defined by the time horizon into which the item falls. The items closest to the timeline are the ones you should focus on the most. Items that are farther away should be discussed and worked on regularly, but not as intensely as the near-term items. Each product has its own rhythm and you need to figure out if long-term items need to be discussed monthly, quarterly, or just annually.
  2. Separate new items
    To keep control of any new items coming in (e.g., from team members, customer feedback, suppliers, management, business analysts, etc.), separate them from the rest of the Backlog. Review this area regularly and only then move them to the Backlog.
  3. Hide won’t do items
    Once you have decided not to do an item, it should be moved out of the way so that you can focus on the remaining items. On the other hand, you might change your decision in the future and, in that case, you still need to have the items in your Backlog so that you can reactivate them when needed.
  4. Group items by feature
    Especially for teams with a lot of experience in traditional project management, don’t fall into the trap of grouping your elements by components, business units or other internal scales. Always take a customer view and group your Backlog by features. Customers are only interested in features and they usually don’t care about how you are organized internally or how the product is structured. Another big advantage of features is that they can be defined much more independently. This makes it much easier to split and size them for the next iteration or release.
  5. Review the Backlog on a fixed schedule – and stick to it
    Every Backlog needs good maintenance. If you don’t regularly review, sort, detail, remove, or discuss the elements of the Backlog, it won’t help you and your team. Instead, your Backlog will run wild. A fixed time slot to review your Backlog is one of the most important slots in your calendar and you should never skip it. As the Backlog grows, sometimes it cannot be managed by one person alone. In this case, it is even more important that everyone checks the Backlog regularly so that each section of your Backlog is up to date and has the same visibility when you plan your next items to work on.
  6. Refine only short-term items
    Everyone agrees that the items for the next iteration need to be detailed enough for the team to understand and work on. But what about the other items? It is advisable to also detail the items for the iteration after next. But you should not spend too much time on all the other points. You should have just enough detail to do a relative weighting so that you can use it to estimate the remaining effort. If your team has trouble identifying when an item is detailed enough, it might help to define a clear structure for detailed items. A detailed item could have elements such as Story sentences (Who needs What and Why), Definition of Done, or any other structure you need in your project.
  7. Define a Backlog owner
    Even if the Backlog is too large to be managed by just one person, you should designate one person as the fully responsible owner. If your company has specialized technical departments such as mechanical engineering, software development, and electrical engineering, try not to assign responsibility to someone from these departments. They are usually unaware of their bias and tend to group elements into technical silos. It is better to assign a Product Owner or Product Manager as the Backlog owner. The most favorable setup, in my opinion, is a Product Owner responsible for the Backlog and a Business Analyst to support him or her. This setup has two main advantages. First, it gives the Product Owner a partner to work alongside on the Backlog, and second, the Business Analyst provides an additional focus on business value. A more traditional setup might be the combination of Product Manager and salesperson or System Architect. Be careful with traditional roles like Systems Architects. They don’t always have a customer view of the product and sometimes tend to gold plate.

I wish you success in your projects and I am sure that you will deliver valuable products if you consider these seven rules.

 

Back to blog overview

Do you have any more questions?

Write a comment

Your email address will not be published. Required fields are marked with *.

Contact

Staller Consulting GmbH
Alexander Staller (CEO)
Karlsplatz 3
80335 München
Germany

Phone: +49 (0) 152 0418 4248

Email: alex.staller@staller-consulting.com

© 2024 Staller Consulting GmbH · Realization: Dennis Köhler Mediendesign · www.denniskoehler.de