As the CEO of your company you want to be able to tell yourself in the near future that you have led the organization from crisis mode to a growth trajectory. It would be even nicer if your executives will say that, but let’s not be so greedy; your executives have their personalities and self-claim to fame, as most do, so prepare yourself to be content with your own positive self-reflection.The true test of leadership is being able to do just that – lead out of crisis.

And here’s Opportunity lying ahead, with its eyes looking straight into you; it says: show me!

It’s going to be a race, or it’s already a race. The winners will be the strongest and the fittest. When you prepare for a race, you don’t preach to your muscles about values; rather, you work with them to make them stronger. As CEO of an organization your executive team is your particular set of muscles, and in order to focus on them you first have to think less about yourself.

Over the last decade I’ve consulted dozens of technology executive teams and helped them construct a leadership process that’s both strategic and tactical, adaptive and practical. I have seen how groups of executives whose function depended heavily on their CEO turned into leadership teams within a short period, showing coordinated abilities and teamwork that were unprecedented for them. The CEO through this process turns into the ligaments that hold all these muscles functioning together in the same direction.

There’s nothing better for a company than a leadership team with a unified plan; it can make all the difference on the road to success in today’s harsh environments. As the CEO of this team, this is one obsession you should have, plan for success and revise the plan continuously – you can never do too much of that.

Whether your company generates revenue, developing products or services, or, as the case is in many companies, it has both types of programs, the examination starts with defining each revenue stream, actual or potential, to be reviewed at least once a quarter, from top to bottom, as if it were an independent business, and then, whatever decisions come out of this review, they should be compared with the other revenue streams based on their prospective ROI – the return on incremental investment. This periodical review asks the following categories of questions about the past, the present and the future of such supposedly independent businesses.

• Vital signs: How we measure success, and what is the current and forecasted success in these metrics.

• Go-To-Market SWOT: What are the Strengths, Weaknesses, Opportunities and Threats of our program relative to competitive products, or alternative ideas.

• Relevant History: What were important success and failure milestones of our program and of competitive programs, and what should we learn from them?

• Forecast for years 1,2,3: what are the milestones in our plan, and how they stand in comparison to competitive programs (as much as we can know or guess).

• Plan of action and investment: Make decisions to support the plan for success of this program (individually), and assess costs, risks and dependencies.

• Portfolio View: Once all programs are examined, their respective plans of action and investment should be compared in order to make the best choices and the allocation of investment.

This process may seem long and arduous, and it is. Unfortunately, there are no good shortcuts. However, once the structure of this Dissect – Analyze – Test process is done, the revisions are certainly less burdensome. They work like a comprehensive checklist for the entire operation of the company. As CEO, your job is to ensure that the team doesn’t take any shortcuts, all questions are asked, again and again, even if they were already asked multiple times in the past, and that’s because we’ve all seen that Shift Happens continually in the circumstances.

But I almost hear you thinking right now: Yes, this process is worthwhile, but I already have done all of this. Almost all CEOs think that, because it might in fact be all there – in their own heads. You will realize how far your team is from thinking like you only when you go through the motion, relinquish your authority during the examination process, let your team members participate freely and openly, and not under time pressure.

It might seem to you like a circuitous route to get to the same result that you already have in your own head, and that you might dictate, or semi-dictate to your team members, but it isn’t. There’s a huge difference between a plan that’s hatched in your head in which your executives partake, to one that’s hatched in team deliberations and examination. This one has buy-in built into it, no differences in interpretations, no escapes from responsibility, strong team responsibility and group pressure on divergent individuals. Just think how much time and effort are saved! Just remind yourself of all the unnecessary discussions that took place recently. Wouldn’t you think it’s worth the effort?

A case of one of my clients proves that this revenue stream analysis process can actually save a company from self destruction – so said the CEO to me after three quarters of practicing it as their regular quarterly review.

The company had three revenue streams at the time: one that was turning low profits, a second that was highly profitable, and a third stream that was in development with no actual revenues. This is how I called them at the time: the old workhorse, the winner horse and the young colt that’s being groomed for a bright future in the races. The workhorse was just getting old and his yield was diminishing with time. The winner horse was based on a new concept.

However, the company’s managers knew that it wouldn’t be long before competitive pressures emerge, and as a result profits will inevitably see attrition. They thought they had enough runway until such pressures took hold, so they were moving resources from the old revenue stream to the profitable stream – in effect starving the old horse and feeding the winner horse. The consensus was: in the time that’s left, we will make enough money on this winning steak to keep us afloat for the future, and give us the ramp-up time needed for the new project to mature to success.

As an outside consultant to the company, I could see what they, apparently, didn’t – the plan was smart, but very risky. It was based on three unproven assumptions. In hindsight, it was clear to them that all three assumptions had been wrong: the young colt didn’t grow to win races, the window of opportunity for the winner horse was cut short as the competitive pressures emerged much earlier than expected, AND, the old horse wasn’t such an old horse after all.

The revenue stream analysis that I influenced them to accept as their key strategic examination, highlighted the total risk and convinced them not to neglect the only predictable component of their strategy – the workhorse, that once it was fed appropriately showed the potential of what’s left in him.

The company avoided the inevitable disaster by uniting the leadership team in a methodical approach of Dissect – Analyze – Test. And that’s why the CEO said that I saved his company.

A good plan is the hard skill that your organization needs to succeed. All the teamwork attributes of this approach to planning – buy-in, accountability, etc. – are the soft skill that your organization needs in order to execute it effectively and efficiently. Not to mention that it will be a lot more enjoyable to you to see your executives really work together as a winning team.

Here are some additional questions and thoughts for you to consider:

We have shared goals at the executive level; isn’t this enough?.

You have shared goals at the executive level, but your experience tells you that despite that, you can’t actually say that all your organization’s units are well synchronized and coordinated. Your sales unit is ahead of R&D, or vice versa, your Customer Success team is in catching up mode, etc. The devil is in the details.

Executive level goals may seem to be specific enough, but once they are translated to the execution level, gaps are created, and because they’re rarely visible, the correction is often too late to resolve them. An organizational consultant that’s trained to look at misalignment between units will discover these relatively quickly. A thorough deep-dive into the execution strategy (the process described above) will prevent much of this misalignment.

How deep does the shared plan need to be?

Executive decision making should not be done in isolation – the people who are in charge of the execution should be involved; they’re the ones who know best how to estimate the level of effort and the execution risks. Director level managers could be invited from the start, in small companies, or in a phased approach in a larger company. Either way, the process should be iterative, going back and forth from executive talk to execution talk until the plan is well understood, and is considered doable.

What’s the best management method: MBO, OKR, Waterfall, Agile?

There’s no need to be monotheistic about your goal management systems. Our contemporary work is so complex that not one of these systems can cover all needs and ensure effective and efficient execution.

MBO, in most of its current implementations, tends to build goals with a bottom-up approach; each employee submits a proposal for individual quarterly goals with the company’s overall goals hovering above as spiritual guidelines. OKR, on the other hand, emphasizes a top down approach. Each high level goal is broken down into lower level goals that go further down in the organization with each level of the hierarchy. Because of the complexity of our work, employing OKR throughout the organization creates so many misalignment gaps at the lower level, that companies that adopted it also adopt along the way a policy that accepts “NOT achieving goals” as a norm. And this is an execution principle that I object to, and I hope you would too.

Programs or projects that have a clear path with easily identified milestones and phases, should adopt a Waterfall (phased) approach, where each phase is examined by exit criteria. Whereby projects or development work whose steps and associated efforts are not well defined in advance, should clearly follow Agile methods. In general, you should make an effort to find small places in your organization or work to practice Agile teamwork, because its underlying philosophy is to minimize gaps among interdependent activities. It’s hard to practice on a large scale, but when it’s possible to break work down to smaller pieces, Agile can work also on large projects.

A hybrid approach of work management systems is more than legitimate – in many cases it is also desirable. Think of it as the nature of work dictating the tools that should be used and not the other way around. Wouldn’t you agree that it’s healthier this way?

As CEO, how deep should I oversee the execution of this transformation?

The rule of thumb is that you should focus on the leadership team and the rest of the organization will follow. But I recommend that you look at your team with broad eyes. The execution level – the Directors – should be actively involved. If you’re a young company with a frantic leadership team, mostly centralized around you, the CEO, do a big step toward decentralization and managerial processes that are team oriented as described above. If you are a large company with established managerial processes, study the key principles of Agile methods and do a clean sheet design with an aim to drastically shorten the length of the cycles of review-plan-execute and make them more frequent. The idea is to catch gaps when they are as small as possible.

Each of those approaches is, naturally, a beginning of many detailed transformation steps that can be designed to minimize transformation pain.

Forget Command, but enhance Control!

The biggest change you will have to go through personally is to increase the length of the individual ropes with which you work with your executives, i.e., empower them more. You will actually increase the total control by reviewing the teamwork. For that purpose, to the process that I describe above you could add monthly or bi-weekly checkpoints. The idea is to create more frequent checkpoints with a structure that looks like a checklist: standard review process with pre-designed questions.

Make this the new DNA of your company: Together we are Stronger! And show them what it means to act together with the leadership’s teamwork and with checklists everywhere. You will fly safer than ever.

When you finish reading this article you will feel that I am expecting you to think as broadly as the CEO of your company. And why not? Technology is the enabler of short-term and long-term profits. Better yet, I am expecting you to think also like the CEOs of the competitors of your company, and that is in order to be a step or two ahead of them.

All aspects of the business are linked to profitability and therefore to technology. Look even as far from the products as the supply chain; if there’s an opportunity to optimize it with an introduction of a new technology, you could find real gold – incremental cents per share!

My focus is on B2B Software technology companies; my points are for you, if your company’s main asset is its ability to develop software. As the head of Technology for your company there will be many types of tasks that will naturally flow to you. They are all directly or indirectly linked to your responsibility; you should welcome them all and execute them in the best way because in any one of them there’s an opportunity to deepen your search for opportunity that lies in the technology itself.

Depending on the size of the company and that of your team, these incoming tasks will be a mixed bag of:

Chief architect assignments; for example, examining components or platforms that make up the foundation of the product or service, and looking for potential limitations that might threaten its performance at scale.

You will be the technology head communicator for the company and the main educator of the R&D staff. You will share the latest trends and developments of key technologies that are already in use, or ones that could be better alternatives.

You will also be the executive speaker representing the company in outside technology forums. For many companies the Chief technologist is like their northern star that helps position them in the industry.

Advanced development projects also find themselves sometimes in the hands of the Chief Technology team in order to qualify the validity of proposed technology before it’s handed over to R&D for development.

The more mature your company is, your role’s focus should be less on these assignments and more on the potential of technology to secure the future competitive advantage of your company. The assignments listed above will ensure that you always keep one leg solidly in reality. Your other leg should be fumbling the ground in front of you to find good grips to hold on to – one leg in reality and one leg in the future. For companies whose R&D marches to the drum of a 2-quarter roadmap, the horizon of the future will be around 18 months.

As much as the dream journey of the VP R&D is for continuity, yours is that of discovery. The technologies of the future that might, on one hand, lift your company to a better trajectory, or, on the other, threaten your company, are out there; you need to venture out – they’re not to be found inside the house. You and your team need not only to research these technologies, but also guess, or estimate, their inflection points that will change their course and might change yours as well, for better or for worse. Therefore, you should keep fumbling these fronts with your stronger leg.

You shouldn’t end up like Sidharta wandering in uncharted territories in search for enlightenment; rather, think of your journey “outside the house” like a canvas that you will fill with a painting, then erase, and start all over from scratch every quarter or so. Some areas of the painting – the sun, the house – might repeat, but the overall composition will be different every time.

The elements of the picture make up your research checklist (this checklist was inspired by Steve Blank’s Lean Startups methodologies).

Problem. What are the customer problems that the company’s products or services are solving? Is there an opportunity to broaden the products’ application? Might these products have value for other types of customers? What are the technologies that will enable expansion?

Solution. Are there competitive approaches to solving these problems with different technologies? Is our solution comprehensive enough to be called a complete solution by the customers? Or is it one piece and the customers need to get the other pieces from other vendors? Can we make our solution more complete with new technologies, and with it achieve a better hold on the customers?

Key metrics. What are the key metrics for success of our value proposition in the eyes of the customer? Metrics of effectiveness, or efficiency, or both? Can we find technologies that will improve the total performance and strengthen the value proposition?

Unique value proposition. Do we have a unique value proposition for our customers? Can we make it more unique and less vulnerable to competition? Is our value proposition a high priority for our target customers? Can we increase the importance of our product in their eyes? Can we find technologies for that?

Competitive advantage. In addition to the standard competitive table that compares products feature for feature, as head of technology you need to compare the underlying technologies of the main competitors, and estimate their development potential and the advantages they might bring to the competitors in the future. You need to find technologies to stand up to these future competitive pressures.

Channels to market. Sometimes a product’s advantage is in how it’s delivered to its user. Think of the Google Drive suite vs. On Premise applications, for example. Feature-wise it’s deficient, and yet you can’t overlook its popularity. This example should remind you to look for technologies that simplify the delivery of your company’s products and services.

If the company’s revenue depends on channel partners, take all of the questions in the checklist, and replace the word “customer” with the words “channel partner”. They – the partners – are simply an added layer of the value chain that should be your beacon when you look for value creating technologies.

Customer segments and Cost Structure. Here’s the opportunity to find technologies to reduce cost and add to profits. Your company, hopefully, differentiates customers by tiers. The threat to profitability lies comfortably in the third tier – these are the customers that are sometimes referred to as “the long tail”. Often, the number of long tail customers is much higher than in the other tiers, and in terms of support, they consume as much, or close to, the customers in higher tiers. And this is, naturally, a threat to profitability.

The response to this strategic situation could be “manual”, i.e, restricting the level of service by forming standard packages for each tier, or “inherent” by creating totally different versions of the product or service. And that’s another technology play.

Revenue Streams. Thinking correctly about the company’s strategy dictates that we analyze everything by revenue streams and not by products. For example, product A sold to high end customers dictates the quality of the product and the entire package that comes with it. Obviously, the same product sold to low-end customers, or another geography, calls for different packaging and ways and means of sales. These two are separate revenue streams and the entire set of decisions pertaining to each of them should be discussed separately; they are two different business models. From a technology perspective, they are also two separate playing fields; what’s acceptable, or in the budget, for one, may not necessarily be justified for the other. In essence as head of technology you have two jobs packaged in one role.

As beacons on the machinations of your field of technologies, you should develop relationships with small and large customers and continuously communicate with them. I propose you maintain technology profiles of key customers and key suppliers and competitors. Use a systematic approach to your research targets, and you’ll increase your chances of not missing anything significant on your search for maximizing the power of technology for the benefit of your company.

Before the crisis I could have said that your job is the most complex of them all — you’re under pressure from all directions, while you can only influence the major actors. All of the responsibility, yet very little authority. But now, in the midst of the race out of crisis and toward a winning position for your company in uncharted territories, I will say that your job is even more challenging.

While all of this is in progress, you can’t just feed every constituency with a little fodder and get them all to take afternoon naps until the next discussion on content of the following release. Now you need to bet on winning horses and convince your internal clients that these are the best bets, and that they should please have lower expectations for getting one of their favorite requests into the plan. I don’t envy you. Your job as VP Product Management is nebulous at times, but now it’s immersed in fog.

In order to clear some of the fog and help you stay focused on the essence of your executive role, I recommend that we break down your team’s responsibilities into hard and soft skills, and start examining it with the former category. Hard skills of your team are in writing user stories, the soft skills are all the communication activities around it.

More than ever the quality of your team’s work should inspire full confidence and no doubt. That means that the output of story tickets – documents designing the user experience of features – is going to be accurate, comprehensive, modular, clear to the people who need to read it, and delivered without delay. Here are a few internal techniques I employed to help my client companies raise the quality of their PM output during that key part of the work – authoring tickets.

PM Pairing. I’m sure you recall from your highschool or university years that doing homework with a friend improved the experience and the output’s quality. This is true in general – an idea is always improved when it’s being talked about (that’s why for each good idea you’ll find more than one person claiming to be its parent). Working in pairs and doing mutual reviews also guarantees that more than one person has knowledge on each work item, thus you’re avoiding knowledge bottlenecks. PM Pairing will immensely improve the quality of the tickets’ first version.

Ticket Review. You’ve seen the concept of Code Review in Engineering and you know why it’s used broadly and how it’s done. For the same reason you should create a standard process inside your team by which each ticket goes through a Ticket Review by unbiased peers, i.e, not by theauthor’s PM pair. If your team is large enough, there will be enough PMs to assign as reviewers; otherwise, create a pool of peer reviewers from outside your team. Only once it’s improved with the peer recommendations will the ticket be ready for discussions with engineering. Employing Ticket Peer Reviews will reduce the number of interactive cycles with engineering, it will improve the professionalism of your PMs, their self confidence and outside perceptions.

Tickets templates. I assume you already have templates for how to write user stories in a structured manner. I will suggest, however, that you review these templates with your mind on the readers. Developers read such documents very differently from marketing personnel, for example. Those tickets need to satisfy all varieties of reader needs.

Checkpoints with R&D. A few steps into the overall Roadmap process have concluded, and the finalist tickets make it to R&D. One of the major productivity issues that I have seen occurs right on the frontline between Development and PM teams. If you see, as I have seen in quite a few instances, that there’s some going back and forth with a few tickets once an engineering difficulty is encountered, you should put standard checkpoints to minimize the waste effect of these iterations. The idea is to catch the gaps as early as possible while they are still small. Weekly or bi-weekly checkpoints of tickets in development will prevent a lot of rework that’s usually unaccounted for, and yet it adds up to overall delays in delivery. Another side benefit, albeit important, is the learning and experience that PMs gain through these checkpoint interactions.

The techniques I described so far are relatively simple to apply; they’re regimented easily. All you need to do is to enforce the process and the discipline inside your team. The quality of your ticket factory will improve without additional effort. 

The more challenging aspect of your role lies in how you manage all the key actors who influence the content of the roadmap. It’s a huge communication challenge with components as diverse as: listening, proactive listening, satisfying interest groups with different focus and goals, considering the outside industry trends and balancing with the capacity of the development group. And if the development team is occupied with a big project, as it sometimes happens, like a change in infrastructure or architecture, you may find part of your team working for a while only for the drawer without ability to execute any of it. The following are some points that will help you put some order in the chaos and clear some of the fog.

The most helpful action is to set a standard calendar of meetings and actions for each release. If it takes 4 months to work on a release from start to finish, design all the steps and set the meetings on the calendar with all invitees, and with specific agendas embedded inside the meeting invitations. This calendar will serve as a metronome to pace a lot of the company’s internal activity that you, as VP Product Management, are charged with leading. You’ll gain efficiency because all participants will be prepared better for the meetings and you’ll save coordination time. Moreover, when all stakeholders are used to the regular steps of the process they won’t feel the need to peddle their ideas in an ad-hoc manner, since there will be a pre-designed place for every type of input.

Start the process with a meeting of all stakeholders to hear the strategic guidelines for the next two releases. This could be divulged from the head of marketing, the CEO, or whoever is the actual head of product strategy for the company.

The next phase is the parallel meetings with each interest group to collect inputs and vet ideas. Customer Success, Sales, Marketing, a sample of existing and prospective customers and R&D, they all have interests that could be conflicting to a certain extent. For example, Sales will want the feature that will enable deals, while CS might not be prepared to support customers in the usage of such a feature. Sales will want to prepare the product for a new market segment, while the strategy of the company doesn’t include this segment. And these are just two common examples. The most important aspect of the meetings in this phase is to allow every stakeholder to be heard and proactively listened to. R&D is also a stakeholder because it might have technical debt to attend to, and also because a bunch of engineers have some good ideas.

With all requests gathered it’s time to create the first version of the roadmap and run it by R&D. A good capacity allocation of engineering resources should follow a balancing rule such as: 50% for tickets coming from PM, 20% for bug fixes, 30% for code health (infrastructure, architecture, code quality initiatives). It will be a mistake to demand all of the engineering capacity for PM defined tickets. It will not pass a reality check, so better don’t attempt it. The more pressure you put on engineering for a larger allocation, the more you will pay for it later when engineering is consumed by big projects that could have been prevented. At the end of this step you will be able to divide the tickets into groups such as: likely included in the coming release, likely in the following release, not likely as defined.

Ticket development. With the output of the previous phase you already have a roughly prioritized list of requests, a rough idea of what might go into the release. You could start your team working on those higher likelihood tickets.

Final Roadmap. About one month into the work on tickets, your team already has a better grasp on the weight of each ticket. You can now prepare with your team a proposal for the final roadmap. For reviewing this proposal you have pre-set a meeting with key stakeholders (not all) to review the feature candidates and decide on the roadmap in three tiers: features that should be in, features in second priority, and features that will probably not make it into the roadmap and that should overflow as candidates to the following release. This proposal should now be reviewed with R&D to decide on the committed roadmap. With the R&D leadership team together with the PM team, you will draw a red line above which are all the committed items by engineering and below it are the “maybe items”. This final roadmap should be communicated to all internal interest groups – sales, marketing, customer success, etc.

As the funnel of requests is being streamlined from one phase to the next in the waterfall process that I described, you, the VP of Product Management, will be faced with ripples and echoes coming from all the dissatisfied interest groups as they see the evidence of their requests shifting lower on the priority list. Some of those ripples will try to circumvent you and go directly to your team members – it’s a multi-headed hydra. Your ultimate test is to stand erect, protect your team from such disruptions and stick to the process. The best communication technique for these formal and informal conversations that you will be pulled into is to let the facts do the talking, such as: “I may agree or disagree with you, the facts are that we went through a methodical vetting process and that’s the result of it. Anyone who challenges the choices we made is welcome to influence those decisions in the next checkpoint”.

As you progress from version 2 to the final version of the roadmap, you will probably enter the step with a list which is at least two times bigger than the discretionary (50%) R&D capacity to execute. Most items on the list have been prioritized as priority 1. There are several voting techniques that will help you select the items that are priority 1 from the ones that are priority 1.5. The technique I like the most reduces the list in one voting round usually, and that’s voting with a fixed “budget”. Here’s how it works. Each voter gets a wallet of 100 “coins” and they are instructed to put as many coins as they like against each item on the list. For example: 20 coins on item B, 15 coins on items A, D, G, and then 5 coins on 7 more items. This voting technique forces the participants to bet their money on winner items. It’s highly effective also in surfacing the true convictions that each participant has.

Agile vs. Waterfall. No matter if R&D employs Agile as their governing process, or if your PM team is a regular participant in it. Agile is the best process for work in progress. The waterfall process that I recommend is upstream of the work in progress. It’s meant to create the lighthouses that give direction to the Agile team. If you’re one of the lucky VP Product Management that have fixed lighthouses and no storms and undercurrents at sea, then you don’t need the process I described above. But, I highly doubt it.

Paralel calendars. Don’t get confused if by designing the calendars for two releases, the coming one and the one following, you will have during the same week two (or sometimes three) sets of meetings from the cycles of different releases. If your release cadence is every 3 months and the waterfall process for each release is 4 months, then you’re bound to have these releases step over each other on the calendar. Your role is maintaining discipline and not letting meetings drift off their pre-set agendas.

As VP Product Management you need very strong hard skills and very strong soft skills – that’s the nature of the job. Follow the guidelines above and use them as a checklist to do periodical reflections and corrections, and you will come out as an impressive VP of Product Management, totally in control in conditions of fog as well as in a sunny clear view.

Over the years as C-Level Mentor I have helped many executives in B2B technology companies. One characteristic that makes Heads of Sales – VP or CRO – stand out is that their organizations are highly influenced by their style of management. Your personality reflects in your organization like a mirror and you’d better realize it for better and for worse. There are three major styles that I have seen: If your focus is on relationships with prospects and customers, your organization will emphasize it. If you are a closer and a numbers person, your organization will be like that too, and perhaps lose on long term goals as a result. If you focus on funnel conversions, your organization will spend much time on playing with the numbers of forward looking statistics, perhaps too much.

On the road to recovery from crisis your emphasis should be on the people – the account managers and their support environment. The people and not the process will make the difference. So how do you go about improving the performance of your workforce while they’re actively seeking opportunities and working on progressing the sales campaigns? The answer lies in how you organize their support. Join me in looking at the challenge from macro and micro perspectives.

Support structure. If your sales force numbers a couple dozen or more sales account managers, you can divide them according to the 20-50-30 rule.

The top 20 % of the organization are people who know how to sell into your customer targets. The organization needs to respond to their needs, and let them run as independently as they prefer. As the head of the organization, you should listen to them and remove obstacles; fix the process if deal approvals and information flow aren’t working with quick response. You could set up a pool of people from your organization as their virtual support team so that all their needs are answered with minimal delays. Imposing extra processes on these top 20% people is a waste of their time and self-motivation. Better have someone assist them if adhering to those processes is critical to you.

The 50% majority are the average who are generally acceptable sales people. Training, group discussions, product reviews, and anything else that raises the level of proficiency should target them and their needs. Other support, mainly technical knowledge, should be as accessible as possible. I recommend that every salesperson in this tier have an assigned mentor, buddy or coach to help them with reviews and brainstorming of ideas. The direct manager could serve this purpose. However, in many cases the direct manager is the chief closer, and therefore, doesn’t have the capacity to mentor the reps. For this group that needs more coaching, the process is important, as it serves also as training to improve proficiency.

Bottom 30% of your workforce are the sales reps that are under a magnifying glass, including those who are newly hired. Your organization needs to provide them extra support, such as a senior-buddy system, to help them move up to the middle tier. With frequent reviews and higher levels of supervision you can call out the people who will not make it to the middle tier. Turnover in sales is always higher than it is in other functions of the company. It’s a tough job, and those who can’t make it in your environment shouldn’t stay.

For a small team, if your sales group has up to 20 account managers, statistics don’t apply; however, the principles of the 20-50-30 rule are still valid. You need to review your sales people periodically and decide for each one of them which category they belong to: extra supervision with a magnifying glass, or ongoing training and enrichment activities, or independence. 

Also in small companies many people from all corners of the company are often involved in supporting sales. Typically systems engineers, support engineers, CTO and even the CEO might be involved in sales. The most effective and efficient way to organize such a mode of operation is to form teams with diverse skills in them – each team is dedicated to support one sales rep. This sales support team approach ensures that the salesperson is not left alone on the front line and there’s no wasted time in the search for information. The team approach benefits both the sales and the supporting people, as they too get their needed information instantly, and therefore, their ability to support is improved. I’ve recently helped one of my client companies in transitioning to this mode of operation, and within one month, all involved voted to stay working in teams rather than falling back on prior work methods.

Sales Account Managers proficiency. For a startup just entering the market, the proficiency of sales reps can’t be measured only by level of quota achievement. Even with a quarter by quarter ramping up approach the level of goal achievement isn’t a real metric or predictor of proficiency, since so much, at this startup stage of the company, depends on other factors. On the other hand, you should assess proficiency right from the start, and you should do it by: hard skills, soft skills, teamwork and motivation. Hard skills that are relevant to sales reps are, first and foremost ,the ability to present and defend the value proposition of the product, and the ability to forge relationships. Soft skills are the ones that would be nice to have, but they can also be complemented by a support team.

In large or small sales groups, you should do a performance assessment every quarter, even if it’s as simple as deciding to which 20-50-30 tier each person belongs, so that the right support is applied.

Process. Good sales people typically view the burden of abiding by a process as a distraction and a time sink. The focus and the time should be spent mostly on winning deals and key accounts. Therefore, the process should be limited to the minimum necessary. If you were comfortable with a certain process in a previous company, it doesn’t mean that it’s necessary in your current job as well. The processes should serve, first and foremost, the sales people, and then the management layers above them. For example, I have not seen the real value in rating probability of deals in a finer resolution than: high probability, medium probability, low probability. The end result is usually widely different than what was projected, and saying that one deal has 50% probability and another 40%, doesn’t really affect the actions that the sales team needs to take or the end result.

Buying patterns of customers. Often the biggest obstacle to closing a deal is that your proposal is different from the buying pattern of the prospective customer. Large customers buy differently than small customers – they have different internal processes and buying criteria. Some customers will buy only complete solutions and others will prefer the best-of-breed approach. Educate your salespeople to study the profile of the customers also from the perspective of buying patterns, and with this improved understanding of customers you will limit the futile campaigns that waste resources and time and yield very little.

Knowledge management. The most important supply line to the sales people is access to information. Content repositories should be designed carefully to satisfy the needs of the users for quick access to content. In small companies, where content is updated frequently, there is no replacement for human support teams. As the company grows, however, the repositories become more critical for allowing experienced salespeople to progress their campaigns quickly. Ask your people how much time they spend on finding information and revising it for their needs. You will learn from them whether you’ve built a good supply line for them. Fixing insufficiencies in this critical supply line should be a high priority for you as head of the sales group.

Hiring. I’m almost sure that you, like most VP of Sales, or like most other executives for that matter, think that you are a good judge of character and that you have the ability to select good people. If that was true, the workplaces would have been filled only with excellent people. But we know this isn’t the case. By definition, most people that can be hired for a specific position conform to the average of the pool of qualified candidates. We can’t be lucky every time and hire only the best, or as some executives like to say: I hire only the top 10%.

The most important message for you is that you shouldn’t fall in the trap of selecting people based on pizazz. Test the hard skills that are needed for the job, like: knowledge of the industry, depth of understanding of technology products and how to sell them, understanding of customer environments, and above all, have the candidate show you that they can present and defend a value proposition.

As VP of Sales you’re the father, leader, and judge of your salespeople. You have to see your key activity as nurturing them and keeping their supply and support lines tuned to their needs. Your role certainly has the part of managing relationships with key accounts, and perhaps being the lead closer of the organization, and this part of your role might give you fame. And yet, your true value to your company is in operating your entire organization at peak performance levels.

A B2B startup or a company that’s beginning its growth phase will do anything to satisfy customers and build happy references; no matter the cost. As VP Customer Success your role is to deliver happy customers who are ready to buy more from the company. If your customers are happy, and are making good use of the product or service, they will not leave. Customer Satisfaction, Upselling and Churn are your key performance metrics. The pressure comes from the cost of service. A company might make nice profits selling its products, while the services arm burns up these profits. I am sure you felt this pressure, and it looks like this: support needs are increasing, and you are asked to do it with less resources.

In Customer Success organizations there is no alternative to good planning. The main cost item is the number of employees in your organization. Almost all cost items are a factor of the number of people; it’s clear you have to watch this number and this number alone before you think of other cost controlling measures. Therefore, the well known secret that’s key to being able to control the number of people, is to focus on process, procedures and automation, and with it increase the amount of work that one person can carry. The true secret, however, or the art, is to do it with just the right amount of investment congruent with every phase of the company’s development.

For example, you might have a favorite CRM system and you move to deploy it in your organization. But if the processes and procedures are not yet well developed, tried and tested, you will add to costs instead of making a step toward saving costs. Or, if you are not yet set to deliver services in tiers, your deployment of the system will be wasteful. Time and again I have seen work that’s pushed into a poorly designed deployment of a system’s use, and because it becomes a significant burden subsequently, people are hired just to serve the system. You shouldn’t buy an expensive toolbox if you don’t know how you’d use the tools in it.

Let me help you unravel the layers of this, seldom practiced, secret in the world of Customer Success. It’s never too early to start thinking and designing processes and procedures. i.e., putting structure in everything you do. I propose you employ a healthy progressive approach to introducing these processes and procedures and further up the growth curve embark on an obsessive automation journey. You start deploying this approach from the moment you assume your position, or, if you’re already there, retract and revise your current approach with the following pillar principles.

Tiered Service. You may currently have only 10 customers to support, or even fewer, and your company is investing in creating good references. You treat all customers, large or small, in the same way. You know in advance that in the future when the company has 100 customers, there’s no way you’ll be able to scale your current level of service to all of them. It will simply cost two much – you will not have the budget for it.

I propose you create 3 tiers of customers right from the start: large, medium and small and categorize your existing customers according to the expected revenue they will generate for the company. For SaaS products it will be the ARR (annual recurring revenue) according to which you segment the customers into tiers. You can give these tiers nicer names like: Strategic, Enterprise, SMB.

Cost of service is very difficult to estimate, especially if your product is relatively new. The needs of each customer are different, and before you have a significant number of similar customers, any statistics you’d try to use will be confusing more than helping. It’s a long learning process that will give you the best lessons if you do it in tiers.

For example, you may give a small customer the best possible (and expensive) service because this customer is one of the early adopters. However, as you provide this service you learn the nature of the needs, and because this specific customer belongs to the lowest tier, you constantly think of how to service the next one in this tier or the one after that. Eventually, you will be prepared to service such customers with the lowest possible human touch, i.e. automated service in combination with infrequent touch points, or none at all.

Strategic customers in the highest tier should always be treated with high touch service: frequent reviews, assistance in usage of your product, very quick response time, and solutions to bridge product deficiencies, like customized tools. You should add automated features to your service, but not as replacement for human service. For example, you might send them an automated report, but you also offer to review it with them. You should develop a partnering relationship with strategic customers; their interests are your interests.

To service the tier in the middle – Enterprise – you employ a mix of these two extreme approaches. These customers typically have very high expectations for service. You have to wean them off these expectations, lowering the level of touch gradually, until you learn what’s acceptable to them as just the right amount of human touch.

You design all other pillars of your service per tier. You should demonstrate forward thinking and show how clever your are by not getting into ratholes that in the future are going to be costly to get out of. For example, if you allow 20 small customers to receive the level of service of large customers, inevitably you will encounter what’s known as a long tail problem – customers that bring only a small percentage of the total revenue and yet, they consume services way above this percentage. Even if you wake up and introduce tiered approach at that point, it will take a long time and much effort to settle into the new service levels.

Tools and systems. There are quite a few work management systems that allow collaboration and flexible visibility on high numbers of tasks. They can be easily designed to show specific views on customer-base status, workload management and balancing, and managerial dashboards. Their collaboration features allow the needed access authorizations for cross functional communication as well. With my clients I have encountered Jira, Asana and Confluence, but I am sure there are more available in the market with similar advantages.

You should experiment with them on a small scale and commit to full deployment only when the growth signals are there, and after confirming with all types of users that their needs for information are satisfied. For example, Sales Account Executives will tell you that they want full exposure to everything that’s happening in their accounts. But they really don’t. They will be happier as you refine the information you feed to them with time. You may start with full access, then add monthly reports, then only highlights, and further down the road, perhaps only alerts on significant changes. As this example shows, your progressive deployment should be a never ending journey of continuous improvements.

Processes and procedures. Procceses should simplify and regiment the work and procedures should serve as checklists for ensuring quality. Examples:

Customer onboarding process is the period of handholding until the customer reaches an acceptable level of independence in using the product. It may include training, assisted deployment activities, etc.

Customer acceptance procedure is the checklist which includes all the information and tasks associated with handing over a customer from sales to customer success.

Customer Install Base Review is the process in which regular team forums are established to review status per customer and folow-up on actions.

Voice of the Customer process would be regular meetings (quarterly) with Product/R&D/Marketing to educate the organization on all facets of customer experience, for which Customer Success personnel are the best proxy.

Personnel and Staffing. Customer Success is a people business, not a product or solution business. On its own it’s hard to make profits unless on a very large scale; long term gross margin for such work is 15% at best. Net profits are always under pressure. For a product or a solution company, the CS arm exists to facilitate sales because a large percentage of customers won’t buy unless they’re assisted with a package of services.

You manage a people-based operation; therefore, you have to follow hard principles of keeping your group motivated and productive. Sometimes the workload is as wild as an emergency room in a hospital. Unless your first line personnel knows that their work conditions is your highest priority, the system might be compromised and you won’t be able to deliver the necessary levels of service.

Form teams based on the longest learning curve. Usually you think about it in terms of regional teams or functional teams. If learning the specifics of the customers in a region and staying abreast of their particulars is harder than learning specific skills, form a team for the region that’s diverse enough in its collective skills. If on the contrary, certain skills are required at a high level of expertise, then you form groups of experts that provide service to more than one region. Most well structured organizations adopt a hybrid approach.

Agile methods. Small teams work most effectively and efficiently in Agile processes. But, not everything is happening inside the teams. You should create layers of cross functional interactions on top of the teams, to facilitate learnings from best practices, and create a sense of unity and pride in the entire organization.

Utilization. From a certain size of the organization it will be useful to do accounting of hours. Overall the utilization of CS personnel should be about 80%, while the rest is consciously allocated to self improvements and team improvements. Activities such as training and cross-pollination among teams will send a clear message to the employees that their professionalism is the highest priority for you and the executive team you represent for them.

Motivation. Your personnel is mostly inside the trenches. The best way to motivate your group is to show them the big picture above ground and to celebrate successes. They expect you, as their VP, to satisfy those needs; therefore, you should go out of your way to search for reasons to celebrate achievements and successes. And I don’t mean parties. Rather, one public recognition is worth more than a thousand drinks.

Planned Growth. Always use the number of customers as the milestones for planning. Create a roadmap for 10: 50: 100: 500: 1000 customers in each tier. Every roadmap revision should have an outlook of two milestones ahead. For each milestone detail the required level of automation, processes and service personnel based on the pillars that I describe here.

Investing according to the plan and leadtimes. If your roadmap calls for a deployment of a new system or process, and you estimate it to take about two quarters to ramp it up, then start two quarters ahead of the anticipated milestone. Not earlier. Do not overinvest ahead of time, because you will make better decisions as you move along the roadmap. Use the rule: just the right amount of investment and process for each phase.

Monitor progress. The best way to keep track of all the activities and maintain your head above water is to construct managerial dashboards and with their monthly updates you can visualize the areas that are doing well and those that need more of your focus. For processes I especially like the Kanban visualization; it helps identify bottlenecks, and guide your thinking on corrective actions. The categories for your dashboard are statistics and assessments on: workload, paid tasks vs. service contract tasks, workload per tier, customer satisfaction, workforce analysis statistics and skills coverage, recognitions, utilization, productivity, automation, processes and procedures and level of adherence, knowledge base and reuse of work products, internal and external visibility.

VPs Customer Success spend most of their time in handling escallations and actions that are based on intuition. I hope you aren’t totally immersed in these typical behaviors, even though I am confident that your are there at least partially. With the looming uncertainty period as a result of the economic crisis, it is crucial to work according to plans that are flexible enough to adapt to changing circumstances.

Acting by intuition and urgencies will result in cost of service that dilutes significantly the profits of the company. Your reputation as an executive lies in knowing your cost structure per tier and controlling it by being methodic and intelligent, and not by being stringent. This is the perfect case where there’s no one model that fits all types of companies, neither for the customers, nor for the personnel that serves them.

The framework that I gave you here will uplift your performance as the executive who’s in charge of the people and organization that are the front line of the company.

Does it really have to be so difficult? That’s the question you should have on your mind continuously.

Let’s start with an experiment. Forget your title for a moment and think about one of your engineering projects: a new feature, across the board quality improvement, a new architecture for the software product, replacing a fundamental component of your product, changing the underlying database, etc. How would you approach such a project? First, you’d understand the problems you’re trying to solve, second, identify the main principles of the solution, third, identify qualifying tests, then you move to design and execution. And since a piece of software is a live entity, it needs ongoing maintenance throughout its lifetime.

You know from experience that in order to embark on this journey, you start with allocating quality time with yourself and then a bunch of meetings with your best engineers, until the subject is fully deliberated. Once it’s well understood and designed, your best approach for the development phase is to employ Agile methods to execute the project with minimal setbacks. Once finished you move to ongoing maintenance with whatever methods you normally employ for this kind of work. That isn’t so difficult, is it? You have definitely done this several times, or else you would not have had your title.

Now, can you realize that you are the best trained person to improve the productivity of your organization? The only difference from a software project, and it is a significant difference, I admit, is the human factor. But that too isn’t a big secret, I can assure you because I have already mentored hundreds on excellence in execution. There are a few principles to study and practice on a smaller scale, and KABOOM, all of sudden you realize that you’ve become an emotionally intelligent VP of R&D, or to put it in plain language, you are now able to get out of your organization results that are a lot closer to your high standards of execution.

But first, let’s understand why you feel that you’re inside a pressure cooker most of the time. There are objective reasons for that. Responding appropriately to these noise creating factors, i.e., removing obstacles, is an essential part of your job.

Firewall R&D is only a temporary solution.

Some VPs of R&D with a tendency to centralize everything around them will react to the general disruptive ambient noise by putting a firewall around their unit. With time, this wall needs to get thicker and higher if it is to function at all. It’s a defensive approach that doesn’t consider the needs of the constituencies outside the wall, and therefore, it creates a workable environment inside the confines of the wall on the account of chaos outside it.

As a VP in the company, you should be thinking about the benefit of the entire organization – you are a company executive after all, and a member of the leadership team. If you like to serve your ego with your executive behavior, you’d take this approach, but, the only “benefit” is to you and not to the company. I hope I discouraged you from this behavior, and if you’re already there, you should recognize it and start designing entryways into your organization that you manage and control as to minimize the disruptive effects.

What are the chronic reasons that disrupt R&D productivity? You will talk about productivity and velocity issues if there are delays in delivery, projects that overrun their original estimated hours, buglists that grow indefinitely, stops and restarts of work items. Do you recognize these symptoms? You’re not alone. Let’s review the typical reasons that cause so much disruptive context switching, and see what you can do about them.

“Ah, if only we didn’t have customers! How wonderful could life be!” is a common sentiment of development folk. Real life, however, puts the highest priority on customer issues that have to be addressed by engineering staff. If you analyze the time that’s spent on customer issues, you’d realize that most of it is spent on looking for supportive information, analyzing the problem and finding the root-cause. This skill – debugging – is actually a hard skill that many engineers are not very good at, and therefore, if tasked to do it, they will spend even more time than necessary. Moreover, problems tend to come in clusters, i.e., if you resolve one problem at a time, you’re missing the opportunity to prevent other problems that share the same or similar root cause.

If you haven’t done so yet, you should have a dedicated team to do the debugging of escalated problems. It will save you hugely in context switching – a common stealth productivity killer – and it will save you engineering hours – your scarcest resource. If you already have such a team, think of staffing it by periodical rotations; you will also contribute to improving over time the quality of your developers and their work.

“The boss wants it now!” is the worst offense if you allow it to disrupt the work in your organization. If you were the TV producer of “Iron Chef Japan”, would you allow the king of the country to interfere in the middle of a shoot? You have to put a stop to such disruptions and show publicly, albeit in a subtle way, that you did so. If you allow the boss to disrupt the work, there’s no reason why others won’t follow. This example of bad behavior serves as a lesson for everybody not to take plans seriously.

Work-in-progress in development should be protected by a freeze of two or three weeks, typically. In small companies it’s a symptomatic behavior of the CEO – the boss – to make special requests and interrupt the work. You should treat such a request as another one that goes into the queue, like customer requests or Sales requests with its appropriate priority. It’s your job to push back on high-level interrupts.

“Why are we missing estimates so badly?” You probably are so used to estimation overruns that you have tired of asking this question. The proportion of development tasks that run on overtime is large, very large indeed. There are two main reasons for these underestimations. The first, we’ve already discussed, and that is the context switching that comes from outside pressures. The second, which is related to the first reason, is that the wrong people do the estimations. If a product manager or a development team-lead does the estimation, there’s no doubt that they would have missed architectural or interfacing complications.

That’s why the Agile team approach to Sprint Design and Planning gives the best estimates. Moreover, once developers are under pressure to deliver a task on time, they will look for shortcuts. I am sure you participated in such “conspiracies” and you certainly felt the conundrum of “pay me now or pay me later”. Overall you’d pay less if you pay now – you know that, so insist more, as much as possible. Another reason for underestimations is that the definition of development requests, typically produced by Product Management, are too broad or too vague. Here the approach is to educate everyone on the principles of MVP (minimally viable product) and insist on practicing them.

What about quality of work? You keep paying for it dearly, and you’ve become complacent. “I don’t have enough QA resources” is your justified excuse, but you learned to live symbiotically with this illness. QA is so behind development that you test tips of icebergs and you miss underwater cracks and opportunities to prevent calvings.

First, complacency isn’t part of your job description, so quit accepting this as an “act of god”. Second, find someone in your organization for whom quality of software development is a passion, or hire one – they do exist. Empower this person to do Continuous Improvement initiatives throughout the organization in the forms of: Coding Manifestos, Code Reviews, Educational seminars, Study of the Principles of Test-First, etc. All aiming to raise awareness of developers and attack the quality problem at its root.

Then, over the other side of the fence, focus on QA automation, and increasing the coverage of the test suites. Unfortunately, throughout my career I have come across only one place where there were 3 times more QA engineers than development engineers. This was the one and only place where I experienced that velocity and productivity issues were kept at a minimum, to the extent that I could have declared them as non issues.

A weak structure is a formula for disasters. It’s true for all types of engineering: constructing buildings, bridges, or designing the architecture of a software product. Once the product is released and is in use by customers, the normal pressures for more features that are coming either from Sales, Customer Success, Marketing or from customers, usually push investment in the architecture to a lower priority. You know it’s a mistake that eventually you will be paying for, dearly, and your key engineers know it too. You’ve heard it called “Technical Debt”, already signifying that it is something you will have to pay for, eventually, with interest.

Your job is to put some sense behind the allocation of the – always in shortage – engineering resources. Here’s a baseline for you to consider: an allocation of 50% to satisfy requests for sellable features, 20% for addressing bugs, 30% of your organization’s capacity dedicated to underlying technologies and lower layers – the architecture. Under no circumstances should you allow this allocation to go below 20% continually, i.e., in every Sprint, or Freeze. If you are having difficulties justifying this allocation to your management, think “Performance at Scale” and there you will find how to justify it. Consider it a hard principle of your function, and with it you would build your reputation as a VP R&D of high quality.

So far I have covered those aspects of your job as VP R&D that concern the technical sides; these are always important, and in times of crisis management, they are also urgent and critical to the success of the company. But, above and beyond the technical sides, the absolutely most important aspect of your job is to optimize the nurturing of the R&D employees and relate to their unique needs, i.e., the human sides of your job. R&D work has only three types of raw material: People, Time and Tools. Knowledge is the collective brain power of your staff, and high motivation is the main productivity driver.

Here are a few points you should consider. I have seen time and again that even simple and small progressive steps in following these principles will make noticeable improvements in the contributions of individuals and teams, i.e., improved productivity.

Organizational stability has many faces, i.e., the structure itself and the vulnerabilities inside the structure.

As most VP R&Ds you will find yourself often thinking about the structure with the hope that a better structure will solve most of the problems. Unfortunately, the endemic problems often remain unsolved, because the structure isn’t at fault. We’ve already reviewed above most of the failure mechanisms of R&D organizations and none of them pointed to the weaknesses of the structure. My personal advice to you is to refrain from reorganizations as much as possible. There are only a few reasons that justify a reorg, and those are when your scope of responsibility is abruptly changing, or when you adopt a new overall process, like Agile. Especially refrain from reorganizing if you are a new VP R&D to this organization; doing so will hurt your reputation as someone who is trigger happy without knowing the situation in depth.

Inside the structure you should look for all kinds of bottlenecks and address them proactively.

When you have knowledge areas that are covered by just one person, it’s a knowledge bottleneck. Team up two people to cover two areas, as in: Rob and Emily cover two areas together instead of each of them covering one area independently. This pairing of responsibility will create the minimal redundancy and alleviate the bottleneck.

Accept that it takes three to six months to ramp up new developers to their full potential. Yes, these learning curves can be shortened with proper mentoring and by creating buddy relationships, however, they can’t be ignored. Even a star programmer needs to learn all the intricacies of the software he’s working on. And by the way, TBHs can’t do any development work. I have seen plans that calculated working hours of employees who are yet to be hired as if they were already available and in full capacity. That’s a form of lying to yourself – try not to add insult to injury.

Find those developers who have a multiplier effect, i.e., they are not only excellent at what they do, they’re also the ones making other people’s work better, either by creating tools for everybody, or by informally advising others on better approaches. Find these people and find ways to use their skill to the fullest. You could even rate your employees on a scale of 1 – 10 based on their ability to improve the work of others. Assign them as internal coaches, put them in influencing positions, team them up with others, or use your own creativity to make best use of this talent. These multipliers hold the key to resolving all bottlenecks. And don’t forget to treat them differently, recognize this special talent and contribution, even if it costs you managerial cycles.

Enhance the collective knowledge by periodical rotation of people among teams. Because expertise and teamwork are so critical for software development, I would not recommend commoditizing your developers, i.e, don’t use all developers as generalists that can be assigned to any task. I will give you a rule of thumb for rotating engineers: give engineers the right to request a transfer to another group, once a year, and ensure that no more than 20% of them rotate in one year. This way you will enhance both knowledge and motivation in your organization.

If you employ Agile as a key process, take it up a notch and follow the principles more tightly, or expand its coverage to include regularly interfacing groups such as Product Management or Customer Success. If you’re not, then at least study the method and its principles, and focus on the problems it’s addressing. There are many lessons that can be learned from Agile that are applicable without adhering to its rules.

Last, but not least, the team leads of your organization are your favorite children and that’s how you should treat them. Productivity and Quality fall directly on their shoulders; they are the last line of defence. No matter how many layers of management are between you and them, make an effort to show them recognition, and personal presence. You want them to see, each and every one of them, that you know what they’re working on, and that you appreciate them.

Management and leadership are about organizing work, overseeing quality of delivery and leading people. In R&D the distinction is clear between the needs of work and those of people. You should see this as two separate sets of skills that you should have, or, two different toolboxes at your disposal. The more you see it like that, the clearer your role becomes, and with it the rainbow that will appear in your clouds.

People working in medium to large organizations have probably taken part in 360 assessments, whether formally in an annual performance process, or less formally to improve results. These kinds of assessments are only the tip of the iceberg when it comes to the quality of management and leadership practices that also need to have a comprehensive panorama; we’ll call it: “360 management and leadership”. 

This article, written by Ofra Kleinberger-Riedrich, looks at 360 leadership, how it can be enhanced with 360 executive coaching, executive coaching methods, and their effects and outcomes. By the time you have finished reading it, 360 executive coaching will no longer be an overwhelming topic, and its value to managers and organizations will be clear.

The ultimate guide to executive coaching in 2022 (a 360 review of 360 coaching)