At the highest level, hyperconvergence is a way to enable cloud-like economics and scale without compromising performance, reliability, and availability expectations, in your own data center. Hyperconverged infrastructure provides significant benefits:
Elasticity: Hyperconvergence makes it easy to scale out/ in resources as required by business demands.
VM-centricity: A focus on the virtual machine (VM) or workload as the cornerstone of enterprise IT, with all supporting constructs revolving around individual VMs.
Data protection: Ensuring that data can be restored in the event of loss or corruption is a key IT requirement, made far easier by hyperconverged infrastructure.
VM Mobility: Hyperconvergence enables greater application/workload mobility.
High availability: Hyperconvergence enables higher levels of availability than possible in legacy systems.
Data efficiency: Hyperconverged infrastructure reduces storage, bandwidth, and IOPS requirements.
Cost efficiency: Hyperconverged infrastructure brings to IT a sustainable step-based economic model that eliminates waste.
Hyperconvergence constructs
Convergence comes in many forms. At its most basic, convergence simply brings together existing individual storage, compute, and network switching products into pre-tested, pre-validated solutions sold as a single solution. However, this level of convergence only simplifies the purchase and upgrade cycle. It fails to address ongoing operational challenges that have been introduced with the advent of virtualization. There are still LUNs to create, WAN optimizers to acquire and configure, and third- party backup and replication products to purchase and maintain.
Hyperconvergence is a ground-up rethinking of all the services that comprise the data center. With a focus on the virtual machine or workload, all the elements of the hyperconverged infrastructure support the virtual machine as the basic construct of the data center.
The results are significant and include lower CAPEX as a result of lower upfront prices for infrastructure, lower OPEX through reductions in operational expenses and personnel, and faster time-to-value for new business needs. On the technical side, newly emerging infrastructure engineers — people with broad knowledge of infrastructure and business needs — can easily support hyperconverged infrastructure. No longer do organizations need to maintain separate islands of resource engineers to manage each aspect of the data center. To fully understand hyperconvergence, it’s important to understand the trends that have led the industry to this point. These include post-virtualization headaches, the rise of the software- defined data center, and cloud.
How hyperconvergence has evolved and making the most of the differences.
The IT infrastructure market is undergoing unprecedented transformation. The most significant transformation is reflected by two major trends: convergence and software-defined data centers (SDDCs). Both trends are responses to the IT realities of infrastructure clutter, complexity, and high cost; they represent attempts to simplify IT and reduce the overall cost of infrastructure ownership. Today’s infrastructure environments are typically comprised of 8 to 12 hardware and software products from as many vendors, with each product offering a different management interface and requiring different training. Each product in this type of legacy stack, however, is grossly over provisioned, using its own resources (CPU, DRAM, storage, and so on) to address the resident applications’ intermittent peak workloads. The value of a single shared resource pool, offered by server virtualization, is still limited to the server layer. All other products are islands of over provisioned resources that aren’t shared. Therefore, low utilization of the overall stack results in the ripple effects of high acquisition, space, and power costs. Simply put, too many resources are wasted in today’s legacy environments. This article explores a leading solution: convergence, which ultimately leads to hyperconvergence.
The evolution of convergence
Integrated systems
The earliest infrastructure convergence solutions have complete network, compute, storage, and virtualization capabilities, but they’re simply conglomerations of existing hardware and software, with little to no actual innovation in product features to be leveraged. Many people look at the solutions offered by major original equipment manufacturers as being ways to lock customers into their technology stacks. Integrated systems do offer a few benefits. Most notably, customers gain a single point of contact for their infrastructure, from purchase to end of life. These systems are always tested and almost always arrive at the customer site fully racked and cabled, so they’re ready to go. On the downside, these systems often have a big step size. When you need more power, you have to buy a big chunk of infrastructure. Also, these products usually don’t solve the serious challenges that so many organizations face.
Converged infrastructure
The converged infrastructure products combine the server and storage components in a single appliance, effectively eliminating the need for dedicated storage area network (SAN)-based storage. These systems provide a localized single resource pool solution, offering simplified management and faster time to deployment. They have effectively virtualized the storage layer and allow it to run in the virtualization platform. Overall acquisition cost is lower, and management (at least, for the server and storage resources) is simplified. With these systems, overall resource utilization is higher than with a legacy island-based infrastructure. Converged infrastructure has some limitations, however:
The systems include just the server and storage resource components.
The fundamental data management challenges have not been solved. It is the functionality of a traditional storage array migrated into the virtualization platform.
Resource ratios (such as CPU:storage:network) are fixed, making them less flexible than some organizations require.
The products can’t always be used by existing infrastructure. In other words, you can’t use a converged infrastructure appliance’s storage from existing legacy systems. In essence, you’re forced to create a separate resource island.
For these reasons, converged infrastructure systems don’t efficiently address performance problems in the legacy infrastructure. Likewise, on the data front, the systems don’t address all data problems, because not all data efficiency appliances are converged. Management may be improved, but it’s not unified global management.
Hyperconverged infrastructure
Enter hyperconvergence, also known as hyperconverged infrastructure, which represents the logical next step in the evolution of infrastructure convergence. Hyperconvergence delivers simplification and savings by consolidating all required functionality into a single infrastructure stack running on an efficient, elastic pool of x86 resources. The underlying data architecture has been completely reinvented, allowing data management to be radically simplified. As a result, hyperconverged infrastructure delivers on the promise of the SDDC at the technological level. It also carries forward the benefits of convergence, including a single shared resource pool. Hyperconvergence goes far beyond servers and storage, bringing into the convergence fold many services that make some legacy services obsolete, including the following:
Data protection products backup, replication)
Deduplication appliances
Wide-area network (WAN) optimization appliances
Solid-state drive (SSD) arrays
SSD cache arrays
Public cloud gateways
Replication appliances or software
Convergence characteristics
The preceding convergence options build on one another, with each having key differences. Figure 6-1 describes the high-level characteristics that define each convergence type.
Figure 6-1: Compares improvements as convergence has evolved. Each characteristic is critical to realizing all the traits that business demands of IT in the modern era: lean, mean, and green.
Hyperconvergence and why it matters for enterprise cloud.
Hyperconvergence and why it matters for enterprise cloud.
Those charged with making high-level technology decisions for the business must carefully balance potentially competing needs. For most organizations, reducing the amount of time and effort that it takes to deploy new business-facing services is just a pipe dream. The datacenter architecture is simply too rigid or too complex, so business units have to wait while IT prepares the environment and then everyone has to hope that there is sufficient horsepower to meet needs. Hyperconverged infrastructure has the potential to help solve these issues.
What is Hyperconvergence?
Converged systems are a natural progression from traditional ITinfrastructure, which are commonly silos of systems and operations. In these legacy environments, there may be separate administrative groups and systems for storage, servers, and network. The concept of converged systems combines two or more of these infrastructure components as a pre-engineered solution.
Hyperconverged systems take this concept of convergence to the next level. While converged systems are separate components engineered to workwell together, hyperconverged systems are modular systems designed to scaleout by adding additional modules.
Why it matters for Enterprise IT?
Advantages to these solutions are the relatively simple design for a complex infrastructure environment. Normally, it could take months to design an infrastructure using a mix of best in class technologies. The differences between a hyperconverged system and servers with a bunch of disks are engineering and software, hyperconverged solutions leverage improvements at the storage controller software layer to allow these systems to scale out.
In addition to the simplified architecture, there's also a simplified administration model. The hyperconverged systems are managed via "a single pane of glass." Instead of having a set of applications and a team to manage your storage array, a team to manage virtualization, and a team to manage the server hardware, one team (or in some environments one person) can manage the complete hyperconverged stack.
Hyperconverged platform or appliance?
Most common definitions of Hyperconvergence focus on appliances, the drawbacks to these appliances include the inability to make granular upgrades or tweaks to the system. Storage growth and performance tuning are also pain points for most organizations. If a cluster runs low on storage but not compute, you must still upgrade overall compute capability by adding another appliance. Likewise, if you want to tune storage disk configuration for a particular application, this can be a challenge.
In the past the remedy for these drawbacks was to build-your-own platform, for many the risk, lead-time and cost of doing so was inhibitive, causing most to wait for solutions to mature and cover their platform requirements. This wait is now over, OrionVM has built a platform that can be branded and deployed as an organization’s own Hyperconverged Cloud, the white-label functionality enables an organization to have unlimited levels of resellers and end users, bringing the advantages of simple design, decreased administrative overhead, and simplified vendor management to highly virtualized environments without the common drawbacks associated with appliances.
Simplifying the datacenter
While cloud continues to be considered unsuitable for everything the datacenter will continue to play an integral role for many companies. Even those companies that do embrace the cloud are unlikely to move everything and so there remains the need to simplify the datacenter, especially when it comes to supporting new initiatives. Building datacenter environments is a lot of work and requires significant planning to ensure capacity. The emerging hyperconverged market can be of great assistance in meeting datacenter integration needs and can scale to meet the requirements of even the largest of organizations. It also simplifies the datacenter by providing a one-stop shop for the entire environment with a single phone number for support.
With the demand for these solutions expected to rise significantly in the coming years it seems likely that these organizations will dramatically alter the landscape of cloud providers, redefining how and by whom cloud services are sold. As IT departments are continually being directed more toward the business and less toward the technology, the need and desire to turn to solutions like cloud and hyperconverged infrastructure will cause CIOs to simplify their datacenter and redistribute workloads in new and different ways.
Some of the best talent from the NSW Web Industry were recognised last Wednesday night at the NSW Web Awards. The winners all progress to the National Finals to be held on the 24th October during the Web Directions conference.
The awards are judged firstly by making it through a validation process using tools like W3Validator and Jigsaw, sites that don't validate are removed from the running for a Web Award. We then look at accessibility, this year we used the OzArt tool with some manual inspection also. If the accessibility isn't deemed to be up to standard the website is removed from the running for a Web Award.
Remaining sites are then allocated among judges who score them based on 5 criteria;
1. Visual Design
2. Content
3. UX
4. Development
5. Accessibility
Each criteria has its different attributes and we rate them on a 5 point scale.
The results are exported to a spreadsheet and we wight the scores, because some attributes are more important than others.
Things like "innovation" are used for tie breakers, so you can still win an award with a great site that is not innovative. (Except in the Innovation Category.)
Shortly we will publish all the attributes and all the weightings on the AWIA website webindustry.asn.au and you get to tell us how they can be improved.
The night kicked off with 4 showcases picked from our NSW entrants;
Showcase 1 - Anurag Chakradhar, Development Manager Thinkun
GoGet CarShare
Showcase 2 - Katie Finnegan, Design and UX Manager The Web Showroom
Salvation Army Aged Care Plus
Showcase 3 - Edmund Tadros, Data Journalist The Australian Financial Review
Australian Financial Review
Showcase 4 - Geoff Bowers, Director Daemon Internet Consultants
Sochi 2014 Australian Olympic Winter Team
Here at the AWIA, we're going to keep giving awards to companies that build well-designed, accessible web sites with well-structured markup.
These are our NSW winners;
In the hotly contested Commercial Category, sponsored by Parmia Insurance we would like to congratulate our joint winners:
Love Me Again Boutique by The Web Showroom
ONSydney by OnMedia
In the Culture and Events Category, sponsored by Partner and Prosper we would like to congratulate our winner:
Sochi 2014: Australian Olympic Winter Team by Daemon Internet Consultants.
In the Not for Profit Category, sponsored by Eduka we would like to congratulate our winner:
Wesley LifeForce Service Finder by Rowan Atkinson Photography.
In the Mobile Category, sponsored by Bankwest we would like to congratulate our winner:
Goget by Thinkun
In the innovation Category, sponsored by Web Directions South and judged by Russ Weakley and John Allsopp we would like to congratulate our winner:
Women Love Tech by Women Love Tech.
A special thanks to our sponsors for supporting the night;
Parmia Insurance
ReInteractive
Media Access Australia
and to our judges;
Buzz Usbrone and Jonathan Crossfield.
Who is the AWIA?
It stands for the Australian Web Industry Association.
It's the association that represents web developers and people who work in or around the web. We don't represent everyone. We’re actually only interested in the people and companies who have high ethical standards.
Now you probably have an idea in your head about what a professional association is. But the culture of our organisation is very much a work in progress. It’s pretty clear we’re not going to be stodgy and conservative. It's not going to be a committee and a newsletter. It's going to be events and projects and content and it's going to be an organisation that has a public voice. It's early days but here's a bit of what we're up to:
Widelines stands for Web Industry Guidelines. A Code of Conduct for the web industry. It's what separates us from the cowboys. And it's a set of useful questions that clients should be asking their web developer before they sign a contract. So when they ask you those questions, because you're an ethical operator, you'll give different answers to a shonky operator, which should win you business. It's a tool for us to show that there's more to web development than the lowest advertised price. With Widelines we're educating the market and we're giving ourselves a marketing advantage. You'll be Widelines-compliant. Dodgy Brothers will not.
Geeks for Good. We're starting a project that promotes the work we do for Not for Profit organisations. Most of us do free or heavily discounted work for NFPs and it makes a huge difference to their influence on the world. That's a story we should be telling. It promotes the charity, it promotes our members and it makes the industry look good. If you have an NFP whose effectiveness has been transformed by your generosity, let us know; we're putting 2 minute videos together.
Port80, We do Port80 meetups in Sydney, Melbourne, Adelaide & Perth. And we support the Web Design Meetup Group in Brisbane and Web Developer 42 Degrees in Hobart. People get jobs, people learn stuff, people make friends. It’s meant to be social, it’s meant to be different every time you go. It’s the place where people’s eyes do not glaze over.
EOTW - Edge of the Web, we run a conference called Edge of the Web. Next year it will be a distributed conference, running in all cap cities. Perhaps you’d like to get on our mailing list.
AWA - And we do this, the Australian Web Awards. Because we want to acknowledge the people who do good quality work and lift the level of discussion about what's happening in the industry.
Booktopia: Pure-play online retail & mobile, brought to you by reInteractive
AWIA's Port80 Sydney in conjunction with reInteractive is proud to bring you an exciting new topic for September!
Booktopia: Pure-play online retailing, building a killer mobile website and becoming the #1 online book retailer in Australia.
This Australian company has been online since 2004 and has made a positive reputation for itself amongst customers. While Booktopia has to compete with the international big names it has emerged as Australia's #1 online Book retailer.
Focusing on keeping Australian business within Australia, Booktopia is a family run company that employs Australians and supports future writers.
Regularly featured in the BRW fastest growing companies list and making it in as #28 in this year's 2013 e-commerce leaders' playbook by Power Retail this is a true homegrown success story.
Wayne Baskin CTO of Booktopia will give a technical presentation on building a web app that handles massive retail traffic using Java, an insight into what stack they use and a run down on their mobile site which is using AOP & RESS.
Steve Traurig, Online Entrepreneur and CIO of Booktopia will be giving a rundown on the business drivers and key decisions that have contributed to making this market leading website an Australian household name.
Come share knowledge, network and have some fun with other professionals in the Web Industry!
A big shout out and special thanks to reInteractive for picking up the bar tab for this event and for their annual sponsorship of Port80 Sydney!
Wednesday, September 11th, 2013 6:00 PM
King St Brewhouse 22 The Promenade, Sydney
We are located on the King Street Wharf - within walking distance from Sydney CBD, Darling Harbour and Cockle Bay.
RSVP here on our Meetup page
What can you expect from Port80?
A current, insightful and informative topic every month that matters to the web industry.
Excellent presenters that are leaders in their field and want to share first hand knowledge.
A good representation of both the Business and Technical aspects of our topics.
Great networking with your peers in the Web Industry, no sales pitches.
Learn something outside your comfort zone
Who comes to Port80?
eCommerce Entrepreneurs, C level Managers
Digital Managers, eCommerce Managers, Marketing Managers
Port80 is run by the Australian Web Industry Association (AWIA).
Founded in 2002, Port80 is proud of its informal meetings, no long speeches, no admission fees, no forced networking. Just an interesting talk, great discussion, a few drinks and the chance to meet and share knowledge with others in your industry.
This image was recently emailed to one of the senior-most technology executives at LinkedIn. In case you can't read it, the text says:
"Success is not the key to happiness. Happiness is the key to success. If you love what you are doing, you will be successful."
Contrary to what you might be thinking, the email didn't come from an eternally optimistic employee who cheerleads regardless of outcomes or a feel-good management coach whose office is plastered with posters defining "persistence," "teamwork," or "dedication."
It came from an engineer whose team has worked tirelessly over a period of years to develop and maintain an important back-end technology for the company. It's the kind of technology that just works, and subsequently, makes LinkedIn work. It's also the kind of technology that is so fundamental to what we do that it becomes easy to overlook -- unless, of course, it's not operating as expected. Then the team is inundated with questions about what's wrong, when it will be fixed, and how they can put measures in place to ensure it doesn't break again.
The engineer who sent the image to the executive added his own short message:
"This is what I feel after reading [your] email."
Other members of the engineer's team sent emails with similarly effusive sentiments. If you've ever worked closely with a team of highly talented, hardcore engineers you know that this show of unbridled happiness can be a bit unusual (to put it mildly.) So what had gotten them so enthused? An email written by the executive explaining how important the team was, how much value they had created, and his appreciation for their consistent diligence, perseverance, and excellence. Essentially, they were responding to a simple "Thank you."
The highest ROI management tool I know is one that is available to everyone, costs essentially nothing, and is a proven driver of workplace productivity. That tool is gratitude.
As obvious as this may sound to some, it is oftentimes overlooked, particularly in companies and among teams for whom seemingly no results are good enough and no bar is ever set high enough. Yet, developing a high-performance culture and one that encourages the expression of gratitude shouldn't be at odds. To the contrary, recognition can be an invaluable source of motivation and subsequently inspire people to do their best work. Looking back on my career, I've seen and experienced this dynamic more times than I can count, and conversely, have witnessed the negative repercussions of managers who take their teams for granted.
Here are a few things to consider the next time you're inclined to show your appreciation for a job well done:
1. Be thoughtful
Not all thank yous are created equal. Be thoughtful about the how. Sometimes it's best to do it in person, in the moment. Other times, an email or call might make sense, especially if the person is remote. Some of the most memorable thank yous I've received were handwritten notes (a few of which I still keep on a table behind my desk in the office).
Reid Hoffman, the founder of LinkedIn, has elevated this kind of recognition to an art form. For example, mention offhandedly to him that you like dark chocolate, and don't be surprised if several months later, he returns back from his latest trip to Europe with a few specialty bars he purchased for you, inevitably delivered with a resounding thanks for the positive difference you're making to the company.
2. Be genuine
More often than not, the words you communicate are not nearly as important as the thought and energy behind them. The person on the receiving end can tell the difference between someone going through the motions and deeply heartfelt appreciation. When it comes to expressing gratitude, always be 100% genuine.
For example, the next time an email thread starts up congratulating a team on their most recent win, try to refrain from adding the fifth or sixth "Great job!" and give some thought to why you're appreciative for their specific accomplishment. Conveying the latter will make all the difference.
Recently, I was asked to join one of our teams in celebrating their recent launch of a major product initiative. In addition to the standard t-shirts, cupcakes, and group photo, the team member who organized the event also asked another exec and me to share the best compliment we had heard about the product, and some of the key learnings we took away from the launch. The team was so appreciative of the positive feedback that we ended up receiving thank-yous for our thank-yous.
3. Pick your spots
When thinking about when to give thanks, make sure to apply The Goldilocks Principle: Compliment someone too often and your words will ultimately ring hollow; don't say thank-you enough and your top talent will ultimately feel so under-appreciated you'll potentially face retention issues. However, express appreciation at just the right time and you'll make a huge difference in the way that person thinks about their role and what it means to be a part of your team.
For those more quantitatively inclined, there has actually been research done on the optimal ratio to achieve when communicating positive vs. negative feedback. It's called the Losada Ratio (and the answer is 2.9x.)
4. Solicit suggestions
When your organization is smaller, and everyone is located in one place, it's fairly easy to be aware of who is doing what and is most deserving of praise. However, as a successful organization inevitably scales to larger numbers of employees and multiple offices around the world, it can become more challenging to stay on top of the day-to-day progress of the team. One way of overcoming this dynamic is by making sure you remain in the flow of information regarding their wins, e.g. dashboards, wikis, weekly updates, etc. At LinkedIn, we conduct a global all-hands every other week which provides a natural channel to identify and recognize some of the team's most important accomplishments.
Another effective technique is to just ask. From time to time, remind your directs to mention individuals or teams you may have less direct exposure to, but who they feel are deserving of a special call-out. The further away from headquarters they sit, and the more junior they are, the better. You'll be amazed at how appreciative the people on the receiving end of those calls and emails will be.
5. Learn how to take a compliment
The better you are at receiving a compliment, the more effective you'll be at giving one. Many people struggle when on the receiving end of a kind word, inevitably looking down at their shoes, shuffling uncomfortably, and mumbling something about how it was truly a team effort. While humility is a highly valued trait, disconnection is not, yet the latter is typically what happens when these scenarios play out.
The next time someone compliments you on a job well done, try grounding yourself from the feet up, look the person straight in the eye, and let them know how much it means to you. That sense of recognition and connection is what we're all trying to achieve. It's also what ultimately makes the difference between a perfunctory thank you and an expression of gratitude the recipient won't soon forget.
One last note: Every now and again, the same senior tech executive I mentioned earlier will remind me of the first time I shared my views with him on the importance of gratitude. Despite the fact that conversation took place nearly eight years ago, he thanks me every time. The most recent example occurred just a couple of weeks ago. It was ultimately the reason I wrote this post.
Jeff Weiner Linkedin CEO shares his Management Framework
Before Jeff Weiner took the top spot at LinkedIn, he asked founder and then-CEO Reid Hoffman three questions:
“How do you want to handle decision-making? What decisions would you like to make, and what decisions should I be making?”
Hoffman responded: That’s easy. It’s your ball – you run with it.
After leading Linkedin through a blockbuster IPO and to a current market capitalisation of over $20 billion Jeff has emerged with several incredible management lessons that he has shared in this article;
Wind in the Sails
Most startups begin with a kernel of an idea and a lot of passion. This one idea is what the founding team knows and loves. It’s what keeps them working all day and up at night. But if this small early team doesn’t lay the right foundation – a combination of the right tools, people and protocols – their idea won’t scale, and they won’t be able to deliver on their vision. It happens all the time.
“I refer to it as the ‘wind in the sails’ dynamic… companies that break through and build something that no one else has ever created,” Weiner says. This is just like being on a sailboat under perfect conditions. The wind is blowing exactly the right way. Everything is easy. “When that’s happening, your hull construction, the skill, the strength and endurance of your crew, and the captain’s ability doesn’t matter as much. Everyone on the boat is celebrating how fast the boat is moving, and you can’t see anyone in the rear view. There’s no one else there.”
But perfect sailing conditions can’t last forever. “The wind is going to shift, and other boats are going to appear,” Weiner says. Meanwhile, if no thought was put towards improving the boat or recruiting the best crew, these competitors are going to catch up. “By the time they’re close enough to pass you, it’s too late. That’s why you’ve got to lay a strong foundation in the early days. You’ve got to get the infrastructure, the processes, and the people right.”
"Vision is the dream, says Weiner. A company’s true north. It’s what inspires everyone day in and day out. It’s what you constantly need to be aspiring to."
‘Mission’ and ‘Vision’ Are More Than Just Words on Posters
Weiner believes getting your “boat” to the best possible destination requires a clearly-articulated vision and mission. These statements ultimately inform and invigorate a company’s strategy and objectives. Perhaps most importantly, leaders need to talk the talk and walk the walk on their professed values to keep the entire company unified and moving in the right direction.
That’s all nice to say — but how does a CEO enact these ideals? Too often, company values are relegated to posters on walls or preachy all-hands meetings. But Weiner believes a good leader can bring them to life – through coaching, a strategy designed to achieve the mission as it’s outlined, clear objectives and measured, communicated results.
Many people working in tech use the terms ‘mission’ and ‘vision’ interchangeably, and usually fail to implement them beyond lip service from executives. Weiner is convinced that clearly defining both, and living by them every day is a key defining aspect of building a successful technology company.
“Vision is the dream,” says Weiner. “A company’s true north. It’s what inspires everyone day in and day out. It’s what you constantly need to be aspiring to.” He defines LinkedIn’s vision as “Creating economic opportunity for every professional,”where ‘professional’ refers to every single one of the over 3.3 billion people in the global workforce.
The mission, on the other hand, defines how the company strives to fulfill that vision. For LinkedIn, that means “Connecting the world’s professionals to make them more productive and successful.” Here the term ‘professional’ is all about the company’s immediate audience of more than 600 million knowledge workers in its network, and the opportunity to change their lives.
Visions aren’t immediately achievable. They’re pie in the sky ideals that may take generations, many partnerships, and many people to achieve -- and even then, perhaps only in part. Missions, however, can be defined in terms of concrete objectives, and a company can be measured by how well it achieves them, Weiner says. Most companies, even startups, will only have one or the other. But a vision without reference to what the company actually does is unmoored from reality, and may not serve its purpose to inspire and organize employees.
Weiner uses Google as a prime example of a company with a mission that includes the hallmarks of an effective vision statement: it wasn’t “to be a faster search engine that also offered marginally better first-page results.” It was “To organize the world’s information to make it universally accessible and useful.” The search engine and the company’s other products aspire to fulfill that mission. It’s how Google built a team of missionaries and not mercenaries. It’s how you can get the best people and inspire them to be great, Weiner says.
Putting Words into Action
Once the company has defined its core values, it’s up to leadership to plan the strategy to fulfil them. “Strategy is navigating the competitive landscape to achieve your objectives,” Weiner says, likening it to planning out your next moves in a chess game. You have to anticipate your opponents’ next moves, then decide how to deploy your assets to outplay them.
This umbrella strategy can then be broken into objectives, and great leaders make it clear how everyone in the organization can work together to achieve goals set for each quarter and each year. “As organizations mature, the job of any senior executive is about coaching and strategy,” says Weiner. A strong objective is easily and clearly tied to the company’s overarching mission and vision, culture and values. Weiner says that too often even executive teams treat company values as “Dilbert-like placards throughout the office – something that Scott Adams would make fun of in a comic strip.” But if expressed values become a subject of derision in the break room among employees, then leadership loses credibility and its ability to motivate.
This is why it’s so important to continually communicate values – long past the point where it gets boring for execs, Weiner says. “You have to repeat the vision. You have to repeat the mission. You have to repeat the strategies, objectives, your priorities, and take the time to define who you are and who you want to be culturally.” Only through constant repetition do people start to internalize and understand. And at a rapidly growing company, you’re always inspiring the new faithful, the future torch carriers.
Making OKRs more than an acronym at LinkedIn
LinkedIn manages its teams using a task-tracking system called ‘Objectives and Key Results,’ abbreviated as “OKRs.” First developed by Andy Grove at Intel, the strategy was popularised by John Doerr from Kleiner Perkins. Today, this shorthand is all over Silicon Valley. But it’s easy to dismiss a corporate-sounding acronym as just another leadership trick for distilling people’s work. Nothing about OKRs sounds inspiring. It’s how LinkedIn used them that helped employees connect more to the company’s collective mission.
In Grove’s famous manual “High Output Management,” he introduces OKRs by answering two simple questions: (1) Where do I want to go? (2) How will I know I’m getting there? In essence, what are my objectives, and what key results do I need to keep tabs on to make sure I’m making progress? When you think about it, these questions are very personal, speaking to the core of how people spend their days. It makes sense that everyone within an organization should have their own OKRs every quarter. The important thing is tying these individual OKRs to team OKRs and, ultimately, organizational OKRs. This alignment packs power and efficiency.
Understanding the personal nature and motivating potential of OKRs, Weiner defines them more broadly. They should be about “something you want to accomplish over a specific period of time that leans toward a stretch goal rather than a stated plan. It’s something where you want to create greater urgency, greater mindshare.” For all these reasons, OKRs should become more important the more senior an employee becomes. When you’re in a leadership position “you are sending the signal to the rest of the organization that ‘this matters,’” Weiner says.
OKRs should definitely not be is easily achievable. Low expectations may seem to yield glowing results, but they eventually stall people, teams and companies in the long run. OKRs shouldn’t be too malleable either. They’re supposed to be quarterly beacons, not shifting from week to week. Along these lines, Weiner prefers that his team members set three to five OKRs for themselves in any given quarter. Anything more than that has the potential to distract from what really needs to get done.
How to Run Effective Executive Meetings
Weiner’s team of executives meets once a week for three hours and every six weeks for a full day. And twice per year for an offsite spanning multiple days. Each tier of meeting takes on a different purpose and scope, with the goal of guiding the company on micro and macro levels.
The weekly meeting is all about general tactical updates, how everyone’s doing on their OKRs, any big changes to plan, etc. It’s definitely not a rehash on everyone’s laundry list of activities. Instead, it’s meant to provide a high level view of what everyone is doing and to ensure that they’re all operating against the same goals and principles. On top of this, Weiner blocks out an hour on both Monday and Friday for strategic deep dives if needed. By separating out tactics from strategy, he makes sure the team stays focused and on track without constantly switching between long-term and short-term contexts.
Weiner also kicks off these weekly staff meetings a bit unconventionally with “wins.” Before delving into metrics or the business at hand, he goes around the room and asks each of his direct reports to share one personal victory and one professional achievement from the previous week. This ritual infuses these meetings with positive energy from the start. Otherwise, Weiner notes, they have a tendency to devolve into a round robin of complaints.
He’s also discovered that making these meetings as impactful as possible is just as about what he does outside of the conference room. Namely, not having too many meetings, and definitely not back-to-back if he can help it. Weiner says he’s found tremendous value in keeping a two-hour buffer that allows him to connect with his team one-on-one and collect his own thoughts. “As a leader, your key roles are coaching and strategy, and you can’t do either of those well without the appropriate time to process what’s going on around you.
In addition to creating time to think proactively, Weiner believes that success for a manager comes from being ‘compassionate’ rather than ‘empathetic.’ Empathy refers to experiencing what another person does as if you were that person. Compassion is understanding what the other person is experiencing, and maintaining enough objective space where you can act accordingly.
Weiner draws on the example of a bystander observing a man being crushed by a boulder. An empathetic person will feel the same suffocation and be unable to help. But the compassionate observer can understand victim’s pain while also taking action. The skilled leader’s task is to understand things from another person’s perspective, and use that strength to improve the situation.
Adding it all up
Incredible IPOs don’t come out of nowhere. Despite all the talk around the Valley and in the media about meaningless valuations and the crazy market, it takes great skill to make it to a public offering at all, much less one that people will remember. The day LinkedIn went public, it made instant headlines after beating analyst and public expectations. People still talk about it.
When asked how he made this possible, especially for a less flashy company – one that profits more from beating a reliable drum of utility over flash – Weiner lays out the advice he shared above. Values. Compassion. Leadership around unified goals. The issue is that most companies dismiss these concepts so easily as somehow stale or separate from the work they need to get done day to day to get to that next, coveted level. This is the error, Weiner says -- being so thrilled with your full sails that you don’t see that IPO out on the horizon. You fail to take care of your boat, and you’ll sink before you get there.
Working in the web industry I have to deal with the term DevOps fairly often. It seems there is a little confusion about the exact definition leaving the whole matter a little hard for some to understand. I found this great article by Willie Wheeler, I hope it helps.
May 8, 2012
Devops: what it is and why you should be doing it
What is devops?
Here’s my take, fluff-free:
Devops is the push to bring the development, test, infrastructure and operations domains under software management and control. It does this through the aggressive pursuit of integration, standardization and automation.
This characterization explains why developers tend to be more excited about devops than ops is. The very last thing ops wants is a bunch of software developers telling them how to manage configuration files, deploy packages or monitor servers. I’m on the development side myself, and for me devops is fun and exciting. But from the other side it has to feel something like a hostile takeover, especially in light of the history of strained relationships between development and IT.
So why does everybody keep talking about dev and ops working together? It’s because both sides have important roles to play:
First, there’s relevant technical expertise on both sides. We need people who know how to code against the AWS APIs, how to integrate tools using web services and message buses, how to build self-service user interfaces for app deployments an so on. But we also need people who can create reasonable server builds, patch them when there are issues, script against the F5s to support zero-downtime software deployments, etc.
Second, there’s also relevant domain expertise on both sides. I suspect this is a lot more obvious to developers than ops: most developers would agree that there’s a point beyond which their understanding of infrastructure becomes hazy. But it turns out that development has its own important infrastructure, such as SCM, configuration repos, CI/build servers, Maven repos, test automation and more. This infrastructure is very much a part of the picture, and developers are the experts in this case.
So it’s true that devops involves dev and ops working together, but that’s a byproduct of what’s really going on, which is using software to run increasingly larger parts of the IT show. That makes a lot of people uncomfortable, but it’s happening all over the place, ready or not.
What’s driving devops?
There are a couple of major forces driving devops.
Cloud and virtualization.
The first force is of course the emergence of services and tools that either take advantage of cloud and virtualization technoloies, or else offer a way to manage the additional complexity they bring. Examples in the former category include cloud provisioning APIs like Amazon EC2, or SaaS services like New Relic and Loggly, which offer cloud-based turnkey operational capabilities. Examples in the latter category include configuration management tools like Chef andPuppet. As VMs blink in and out of existence, there has to be some way to manage everything that’s happening.
Continuous delivery.
There’s a second force too: software engineering itself is maturing. We are seeing growing consensus as to software development best practices, in terms of both design and development process/methodology. While it would be overstating the case to say that software developers are automatically engineers, it is no exaggeration to say there are plenty of developers who practice development as an engineering discipline. Proper use of source control, versioning configuration, continuous integration, unit and integration testing, automating deployment—these are all engineering activities designed to make development predictable and repeatable.
This second force is driving devops in the following way. As a general rule, forward steps in software engineering lead directionally to the continuous delivery of software, which is essentially the ability to deliver high-quality software to users within hours or days of starting work on some development task, as opposed to weeks or months. (Obviously it depends on the size of the task, but the concept is that if you’re able to finish the development task in an hour, your delivery capability shouldn’t prevent you from releasing it hours later. It’s fine if your product folks want to prevent it, but it’s not fine if your capability prevents it.) Continuous delivery involves integrating a bunch of different tools into a deployment pipeline, and this pipeline—which includes everything from the developer’s IDE to monitoring and diagnostic tools in the operational environment—spans both development and operations toolsets. This drive toward continuous delivery in turn drives the need for development and operations to pull it together.
The previous discussion offers a hint as to why we might want to pursue a devops-style technology practice: it allows us to deliver more quickly to our customers. But there’s more to it than just that.
The devops value proposition
We mentioned earlier the historically strained relationship between development and ops. There are numerous reasons, such as different bodies of best practice (e.g. agile vs. ITIL) and the fact that they’re often separate organizations, which tends to create barriers. Where I work, the IT team rides motorcycles, whereas we on the development side drive Toyotas. I’m not sure why but that’s how it is.
One of the key points of conflict, however, is different attitudes toward change. In most operational environments, change trades against stability. In other words, the more stuff you push out into production, the more likely you are to break something. Ops doesn’t like it when things break, because they’re the ones who have to deal with the fallout. But developers are under pressure to push changes into production, and in fact to accelerate the rate of change.
These different perspectives toward change result in the dysfunctional relationship that often emerges between dev and ops. Development pushes out a bunch of new features but didn’t have time to update the knowledge base, and when something breaks ops doesn’t know what to do. Ops calls for a change moratorium, dev misses release targets and blames ops, ops blames dev right back for producing unsupportable software, and so on.
What devops and continuous delivery bring to the table is the ability to replace the change-or-stability dilemma with a world where increased rates of change actually enhance stability, because change surfaces broadly-visible issues that admit of a common and permanent fix. For example, if there’s only one deployment tool, and it’s not able to handle the delay between the time that an instance comes up and SSH becomes available, then everybody will see it, and somebody will definitely fix it. And it’s very easy to justify putting a correct fix in place (not an ugly hack) because potentially hundreds of apps are depending on it. Moreover, a proper devops practice enables speed and stability improvements beyond what are possible without it:
Integration, standardization and automation are transformational, because they create a situation in which change no longer hurts. Dozens or even hundreds of packages flow through the deployment pipeline every single day, and if there’s a problem, it’s often a common problem with a systematic and permanent fix. Dev and ops are aligned around delivering software to customers quickly and at volume, as well as around maintaining a smoothly running operational environment.
Want to learn more?
I haven’t said much about exactly how devops helps. I’ve really made some simple assertions to the effect that it does. That’s fine for an overview, but you may want to hear some details. The purpose of this blog is to explore exactly those details. So if you’re interested, check back as I’ll be posting more.
And for more information on continuous delivery in particular, it’s hard to beat Continuous Delivery, by Jez Humble and David Farley. It explains the what, why and how. It has been the playbook for the automation platform we’re building at work, which currently has 20,000 automated deployments under its belt.
Original Post here
Recommended Reading
How Red Hat killed its core product and became a billion dollar business
Democratising the Corporate Strategy Process at Red Hat
This story is written by Jackie Yeaney the Executive Vice President, Strategy and Corporate Marketing at Red Hat.
It shares Jackie's experience working with Jim Whitehurst from his appointment to the top job at Red Hat in January 2008 through to June 2011.
Jim is a great visionary who sees an opportunity for Red Hat to become even more successful and significant in the tech industry.
The story gives a comprehensive account of Red Hat's corporate strategy transformation and is packed with lessons for other organisations.
November 10, 2011 at 5:05pm
Summary
Over the years I've participated in countless strategic planning projects, having spent several years as a management consultant and then as a member of the executive team of several public companies. In my experience, typical strategy projects tend to follow the same path. Most efforts only involve a few executives at the top working to develop the strategy alone in a closed process. Once in a while they bring in some internal superstars or hire some outside help if they need validation from their board.
Even those projects that ask for input from across the organization still hold tight control on any final 'answers'. Once they move into implementation the strategy falls flat. No one understands why or how they fit in. The strategy becomes a document on the shelf.
When I first started working with Red Hat at the beginning of 2008, it was readily apparent that the traditional corporate strategy development process would simply not work in an open source company where transparency, meritocracy, and collaboration were prized elements of the culture. So, over the past three and a half years, we have built, tested, and executed on a very different model for corporate strategy. I think it's one with lessons for other organizations--and in the spirit of open source, I'll unpack as many as I can here.
Moonshots
In January 2008, I received a call from my longtime friend and colleague, Jim Whitehurst, who had just been named CEO of Red Hat, the world's largest open source software company. I had previously worked with Jim at Delta Air Lines (where he was Chief Operating Officer and ran the day-to-day operations of the airline) and before that at the Boston Consulting Group.
As Jim put it to me, in Red Hat he had joined a company with "high-class problems." The company had been growing rapidly--from about $90 million in revenues in 2003 to $400 million in 2007--and had a wide number of potentially lucrative growth opportunities in front of it. Red Hat had a healthy balance sheet, a strong, well-respected brand, and award-winning products used by many of the largest, most successful companies in the world.
Triggers
Yet Jim thought Red Hat had a chance to be more successful, to be more significant in the technology industry--in fact to be one of the most successful software companies in history. He believed Red Hat needed to:
Be more systematic about how we analyzed the market, customers, and prospects--what he/we call 'one truth'
Execute more efficiently on the opportunities that were readily apparent
Make smart choices about where to focus time, energy, and resources, while also making choices about where to say no, even to attractive opportunities
Most new CEOs come into an organization and quickly mold the company and its leaders into their own vision--not Jim. He first wanted to learn more about the business and marketplace as it currently existed.
Frankly, because Red Hat was growing and doing well financially, there certainly was no urgent need to "fix" the business--this was more of an opportunity to learn how to execute more efficiently and plan better for the future. Jim realized Red Hat already had an amazing organization; he simply hoped a more defined and organized strategy would help us become better stewards of it.
But the traditional strategic planning model would not work at Red Hat. Red Hat had a deeply entrenched and open source-inspired culture that prized transparency and collaboration. Any strategy effort would have to be run out in the open, where employees from across the organization could participate and offer their feedback and suggestions.
While many might view it is as a disadvantage or a time sink to systematically gather feedback from across the company, at Red Hat it's a core part of our competitive advantage. In the open source world, there is a saying: "Given enough eyeballs, all bugs are shallow." Here there is a firm belief that the best way to get great ideas is to get a lot of ideas, from a diverse set of viewpoints.
It's not just talk. Red Hat is truly a meritocracy of ideas--where the best ideas can come from anywhere in the organization. Many of Red Hat's most successful products and services were built upon the hard work, passion, and commitment of one or more brilliant people inside (or even outside) the organization, not a top-down mandate.
With this all in mind we knew we would have to make sure our process was democratized; less top-down, more all-around.
Key Innovations & Timeline Beginning the Process
First, leaders from across the organization worked together to develop an overall framework, identifying several areas both internal and external that we thought made sense to explore in more detail. Some examples of the types of areas we explored include the business model, operating model, technical vision, and commercial model for the organization. Then we brought in an experienced facilitator, Joe Anglim, to help everyone through the process.
We next recruited members of the leadership team to sponsor the exploration teams. All of the senior leaders of the organization were involved, and the team leads included executives like our CIO, VP of Operations, VP of Services, and VP of Marketing, among others. But rather than naming the "usual suspects," we asked leaders to step out of their comfort zones and lead efforts far removed from their daily responsibilities. For example, the head of the "People" team was asked to analyze the financial model of the company and the CFO was charged with exploring design and operational system enhancements. By setting it up this way, it wasn't just top leaders learning, but all of us. Senior leaders gained perspective and understanding of worlds they'd never spent much time in before.
An Open Approach to Communications and Engagement
From the beginning, we put engaging with;our associates ahead of;communicating to;them. The entire company needed to own the strategy if we wanted to see it implemented. Associates needed to be an integral part of developing and implementing it.
We looked for any and all chances to engage our people in a dialog, to start a lively discussion about our strategy at all levels within the company.
We also decided it was worth setting up a specific cross-functional team--a strategic internal communications team that included representatives from our people, brand, internal communications, and IT teams. This helped us ensure we didn't take our eye off the ball.
We built an internal wiki that leaders of each exploration team used to organize their thoughts and ideas out in the open where any employee could make comments or suggestions. Anyone who was particularly interested could read about the progress, and add their ideas or volunteer to help (and many did).
This information-gathering dialog lasted about 5 months. We communicated our progress along the way through regular updates at company meetings, through email, and on the Intranet. The strategy team leaders posted status updates to the wiki and replied to comments on their team's internal blog. Jim hosted a company-wide online chat session where associates could ask him any question they wanted to about the strategy process (or anything else that was on their minds), and team leads communicated key updates through company-wide announcements and discussions.
The leaders did as much listening as they did speaking on the topics. Thinking evolved as part of the process. For example, in the business model exploration, we started the conversation by talking about a defensive differentiation strategy that would halt our competitors progress, but quickly realized that focusing on ideas for how to create more value for our customers through the products and services we provide would yield even better, more compelling (and more sustainable) results.
Synthesizing the Ideas
Red Hat employees generated ideas--LOTS of ideas. In fact, they generated more than we knew what to do with. Many of these ideas were developed within the working teams and vetted via the wiki, but on other occasions, ideas from the broader associate base were incorporated in the thinking as well. Not every idea could bubble up and become part of the strategy effort, but the best ones did and spurred a lot of great dialog.
For example, it became clear that we needed to take another look at the mission of Red Hat to make it more specific and easier for employees to rally around. Jim formed a team to take on this task, and this team engaged the entire company in its development.
In another innovative example, the technology roadmap team not only engaged the best minds from within the organization to uncover ideas, but also pulled in the open source development community as well. We utilized existing networks in the open source community to "keep our minds open" and socialize ideas outside of Red Hat. By giving members of the external community an opportunity to weigh in, we not only were able to identify new and next generation technologies very early, we allowed an extremely important set of people into our process, increasing their understanding and appreciation of our direction.
By involving the larger open source community, we were able to gauge the reaction and study the ramifications of particular strategies, thus minimizing unintended consequences of those decisions. We even discussed potential strategies with the leaders of other organizations so they could understand our goals and help us work through ways that we could achieve them while not undermining the goals of the larger community.
The process to this point did a great job of coalescing market and customer insights, and identifying areas of opportunity, and some very clear themes began to emerge. But we knew deciding how to execute against these strategies was the next challenge, so it was time to shake things up.
Driving Accountability into the Organization
As I mentioned previously, each initial group had been led by a member of the senior leadership team. But now that we had highlighted our key areas of focus, we wanted to give people at more levels in the organization the freedom to decide how we would tackle the priorities.
We built entirely new teams around our new areas of focus, this time headed up by leaders a level removed from the senior leadership team. They, in turn, tapped the people with the most knowledge and the most interesting ideas to take charge of actually developing the strategy and plans in each area. True to the spirit of the Red Hat meritocracy, the people who were charged with actually developing the strategy and plans in each area were those who knew the most about it and had the most interesting ideas.
We designed a new communications plan for this phase, including creating an iconic diagram that we'd use over and over when leading conversations about the strategy process. This diagram worked like a "You Are Here" map that would show people where any discussion might fit into the overall strategy. We wanted to ensure that each associate understood how his or her work fit into a larger vision.
These groups took the major strategic themes and ran with them, building strategies and plans to execute on our new priorities. But where in most strategic planning projects, these teams would be asked to build strategies and plans and then bring them back to the leadership team to make decisions, we left accountability and responsibility in the hands of the people who knew the most--those who were doing the work.
This had three key effects: First, putting the responsibility for developing the details of the strategy in the hands of the people charged with implementing it--rather than handing down a fully-cooked plan--generated more creativity, accountability, and more commitment. By allowing the strategy to be developed at the same level in the organization where it would be executed, we empowered those who would have to implement the plans to control their own destiny. By giving them the freedom to develop the plans the way they saw fit, we increased their accountability for the end result.
Second, by leaving the responsibility for deciding what should be done deep within the organization rather than bubbling things up to the senior executive level for every decision, we avoided the typical 50,000-foot oversimplification of the strategy that so typically occurs in these projects. Much of the work Red Hat needed to do against these strategies was complex and nuanced. By letting people who understood this make the decisions, we were able to ensure the right plans were developed with the best information available.
Finally, by leaving it in the hands of the people who were working with these issues on a daily basis, we improved the;flexibility;and;adaptability&;of the strategy. As new opportunities emerged or changes in the market occurred, the team was empowered to make changes real time rather than having to go back to the senior leadership team for approval. While the overall framework and initiatives stayed the same, each individual group had the ability to ensure their plans were current and agile. This was not simply a strategy planning team, it was the strategy execution team as well.
You won't be surprised to hear that there were times when we required that the whole company shift its thinking, and in these situations, the leadership team--and Jim in particular--stepped back in. In one instance, a strategic theme was not well articulated and was being misconstrued by many within the organization. Rather than sticking with it as originally envisioned, we renamed and repositioned it so that it so that it could be better understood and more inclusive of all of the tactics being implemented by multiple groups.
Executing the plan
In all our combined years of conducting strategy exercises Jim and I have never seen an organization follow through on its plan over a three-year period like Red Hat has done. The framework, initiatives, and themes have remained intact--with every employee understanding the strategy and how they personally fit into it. The teams have continued executing and adapting. We've monitored key metrics along they way.
Every team has made significant progress, and in some cases, people's "day jobs" have changed to give them even more time to directly work on executing against the strategy.
Since we started this process in 2008, Red Hat has been executing more efficiently on its best opportunities, and it shows. Red Hat has grown from a $400 million revenue company to an almost $1 billion company and the stock price has more than doubled.
As I write this, we are beginning to address new opportunities to compete in a quickly evolving enterprise infrastructure space that we would not have been able to address in the past. As we execute systematically against our current opportunities, we have provided ourselves with more freedom to begin thinking about exciting and different opportunities for the future.
Challenges Solutions
As I hinted earlier, some of the biggest challenges came down to communications. Involving 3000+ people in developing your strategy implies a lot of information flowing in a multitude of directions. To help address this, we ensured that the strategic internal communications team remained a central element at every turn. The team continued to meet weekly to discuss any bubbling issues, or brainstorm opportunities to communicate and to spark dialogue. Where most view communications as an activity that occurs near the END of the process, we knew people would not be fully engaged in executing unless they were included up front. Years later we are still today communicating our framework, initiatives, plan and progress in company meetings, team kick-offs and in new hire orientation.
One of the issues we noticed early on was that we were not consistent in how we communicated our value proposition around the company. Different groups had different 'translations'. So, along with re-crafting the mission, we collaborated on a clear articulation of our that explained who we are, what we deliver, and how we deliver it. This became another key element that helped ensure the individual strategies fit together into a larger story.
The sheer quantity of ideas also presented a challenge, but most of the teams did a very good job identifying and nurturing the best ideas. Our open and collaborative open source culture inherently helped us do this fairly efficiently. As with any project involving this many people, synthesis--taking all of the ideas and narrowing them down to the best ones and then putting them into context--was a key challenge simply because it took a lot of time to go through all of the data.
Many people within Red Hat had never been part of a strategy exercise before. Strategy and strategic planning can mean different things to different people. I'm sure you have a definition in your mind--and I'm sure that it's different than the one in my mind. Those involved needed to better understand Jim's definition of strategy and needed extra help understanding specifically what was being asked of them. Many frameworks can certainly work but everyone needed to understand how and why Jim had crafted the one we were using.
To make it a little more complicated, those who had indeed been involved in strategic planning processes before often didn't take the exercise seriously, believing it would probably be like lots of others they'd been through. They imagined it would end up as paper on the shelf, never to be looked at again. It was after sessions with the senior leadership team where they needed to provide robust updates and got specific feedback that they began to realize Red Hat was serious.
The sheer amount of time it took was often frustrating. When strategies are formed in smaller, more senior groups you get to 'answers' fairly quickly. Here with so much involvement, we needed to be patient. And patience is hard when your market is moving quickly. We had to keep reminding ourselves that taking longer to agree on our strategies and getting buy-in was FAR more important than writing down great answers in short order.
Teams pushed for consensus, but as we know, consensus is not always possible. And often consensus can lead to a 'watered down' answer if you aren't careful. At times some people thought ideas were too far reaching while others thought we weren't reaching far enough. When we ran into these walls we tended to go to a senior leader who could look at all the options from an unbiased perspective and help get us to an answer.
One example of this was when we tried to define what the term "renewal" meant to us. Each stakeholder had a different view of what and how we should define it, so a subset of the team took a step back to develop a definition that could work for all of the stakeholders.
Benefits & Metrics
Look no further for evidence of the success of the strategic planning efforts than the Red Hat financial results. Here is a graph of the Red Hat stock price from the time the strategic planning project began in January 2008 through September 2011.
And here is a comparison of the Red Hat income statement from 2008 with the one from our most recent fiscal year, 2010, showing an increase in revenue from $523 to $909 million.
Although the time upfront felt long we were actually able to execute several initiatives fairly quickly. Where most experts will tell you that it is best to only take on 2-3 strategic initiatives at one time, we were able to take on 17 under 9 themes at once--and execute on all of them.
The speed of market change has also picked up during the last three years. Because we began the process of democratizing corporate strategy in 2008, we now have the runway to dream, analyze, prioritize, and then execute against amazing future opportunities for our company today. What's more, had we not invested in the exercise three years ago we would not be as nimble and well positioned to be a key player as the technology landscape makes a strategic shift toward cloud computing.
Our employee base is eager and ready to take on new challenges and to be part of the process all over again.
Lessons Open the strategy process up to people all across (and maybe even outside) the organization to ensure you access the best ideas.
The best ideas can come from anywhere. By making the strategy process transparent and collaborative, you can ensure the most powerful ideas are allowed to see the light of day. If it makes sense, consider involving members of the communities around your organization to help you develop pieces of the strategy in ways that help them benefit as well.
Involve all employees in a conversation about the organization's strategy rather than just informing them.
Where most strategic planning projects either are the work of a small group of people or solicit employee input before the actual strategy development work is done behind a curtain, our project at Red Hat allowed for transparent collaboration to happen through every stage of the project.
As much as possible, we tried to make the process a conversation that anyone who was interested in could join. We also employed strategies like blogs, wikis, and chats to stimulate conversation wherever we could.
One of the biggest challenges in running a strategic planning process involving contributions from a large number of people is ensuring that everyone has access to the information they need in order to make their best contribution. By involving the top communications people in the company at a strategic level and forming the strategic internal communications team, we were able to develop a communications plan that didn't just inform, but also deeply engaged people at all levels of the company in the process.
Drive the freedom (and accountability) for building out the strategy as deep into the organization as you can.
A crucial flaw in many strategic planning projects is that the team charged with implementing the strategy doesn't have a role in its creation. By driving the freedom to develop the strategy to the places in the organization where the strategy would actually be implemented and making those teams accountable for the results, we were able to build a strategic plan that was flexible, current, and took advantage of the knowledge of those who understood the problems and opportunities best.
What's more, because the people who were implementing were also developing the strategy, they felt more like they were in control of their own destiny, thus were more engaged in ensuring they met the goals they set for themselves. They also were empowered because they felt like management "trusted" them enough to allow them to develop the strategy.
The power of giving up centralized control over the strategy was a key takeaway from the process.
Be patient.
Running a strategy project the way I've described here won't necessarily give you the fastest answers. Keeping a large group of people communicating, informed, and involved takes a big commitment of time and energy. But the investment is a good one. The extra effort it takes todevelop the strategy will pay off big dividends as you begin toimplement it. Because your people were involved in the creation of the strategy, they'll be more engaged in executing against it. And because you drew from a bigger pool of ideas and involved people working directly on the specific challenges and opportunities facing your organization, you'll likely end up with better strategy as well.
Keep the drumbeat going.
The strategy process at Red Hat has been going on for three and a half years and counting. While we continue to iterate and improve the strategy along the way, many of the central themes have been driven home over a period of many years.
Regular updates on progress and regular deep dives on strategy have been a part of every Red Hat company and manager meeting for years. By continuing to keep momentum behind the strategy strong and communicating often, we've ensured that the company stays focused on executing against the strategy.
Let the strategy live and breathe.
Good strategy shouldn't change every day, but it must be flexible enough to allow implementation strategies and plans to change when they need to. By keeping accountability for strategy and execution deep in the organization, we ensure that the strategy can flex to take advantage of opportunities and challenges based on the best information available at any given time.
Credits
Original article is available here.
Recommended Reading
How Red Hat killed its core product and became a billion dollar business.
How Red Hat killed its core product—and became a billion-dollar business
Amazing story of how Red Hat change its product offering and became the world's first billion dollar open source software company;
by Jon Brodkin - Feb 29 2012, 1:00pm EST
"A decade ago, Linux developer Red Hat faced a decision that would make or break the company: whether to stop producing the very product that gave Red Hat its name. The company was built on Red Hat Linux, but when Paul Cormier—now the head of Red Hat's technologies and products group—joined the company as vice president of engineering in 2001, he knew Red Hat's devotion to open source alone couldn't create a business model capable of standing up to the Microsofts and Oracles of the world. He pushed for drastic action.
To move from small player to big-time enterprise software competitor, Cormier argued that Red Hat had to ditch the freely downloadable Red Hat Linux. Instead, it should replace Red Hat Linux with a more robust enterprise software package that maintained the principles of free (as in freedom) software without actually being free (as in price) to customers.
People within Red Hat told Cormier he was crazy. "A lot of engineers at the time didn't care about a business model," he told Ars. "They wanted to work on Red Hat Linux. We had some level of turmoil inside the company with going to this new model. Some engineers left, but more stayed."
Cormier's vision required a "bet the farm decision," and he won out over the doubters when he convinced then-CEO Matthew Szulik to stop producing Red Hat Linux. The last stable release of the operating system appeared in 2003 at the same time RHEL—Red Hat Enterprise Linux—hit the market. Since then, the company has been on a steady climb in revenue and profitability, aided by the growing popularity of Linux-based servers and Red Hat's expansion into new markets.
The company now faces new challenges as it looks to expand its empire through a big bet on the virtualization market—a market so utterly dominated by VMware that Red Hat may stand little chance. Yet Red Hat's prominence in the enterprise Linux server market ensures growing revenue and profits for some time to come.
This week, at the end of its fiscal year on February 29, Red Hat marks a major milestone: it becomes the first billion-dollar-a-year company making its revenue entirely (or almost entirely) from building and maintaining open source software.
In hindsight, Cormier's risky idea looks prescient; to some at the time, it seemed ridiculous. How did a successful company like Red Hat manage to take such a risk and turn it in to such reward?
Software, scooters, and Nerf gun fights
Red Hat was founded in 1993 by Bob Young and Marc Ewing—with its software having been named after the hat Ewing wore around Carnegie Mellon University—but Ewing had left and Young was gradually stepping back when Cormier joined. He arrived at the same time a new release of Red Hat Linux debuted, and he vividly remembers his early conversations, including one with the engineering manager.
A Red Hat timeline
1993: Bob Young founds the ACC Corporation, Marc Ewing founds Red Hat.
1994: Ewing releases his own Linux distribution—Red Hat Linux.
1995: Young buys Ewing’s business, the two merge into Red Hat Software. Young becomes CEO.
1999: Red Hat becomes a publicly traded company. Bob Young steps down as CEO later in the year, Ewing leaves the company entirely.
2001: Paul Cormier joins Red Hat, sparking a re-examination of the company’s business model.
2003: The last stable release of Red Hat Linux debuts. Red Hat Enterprise Linux hits the market.
2005: Young leaves Red Hat’s Board of Directors, officially leaving the company.
2006: Red Hat buys JBoss.
2008: Red Hat buys Qumranet, maker of the KVM virtualization platform, laying the groundwork for Red Hat Enterprise Virtualization.
2009: Red Hat enters the virtualization market with RHEV. Existing competitors VMware, Citrix, and Microsoft already have an established market share within the field.
2011: During December earnings announcement, Red Hat reports $836 million in revenue through nine months of the fiscal year.
2012: Red Hat expects to eclipse the $1 billion mark in revenue for the fiscal year ending in February.
"I said, 'So obviously we just shipped something, I assume you can recreate the bits, the binary-compatible bits.' He opened up his top drawer of his desk, a bunch of CDs were inside and said, 'I think the source is somewhere in here.' I said, 'Wow, we have a lot of work to do.' It was like that, people riding around the halls in scooters and having Nerf gun fights. It was all cool. It was all good stuff."
Most of Red Hat's revenue at the time came from telephone support, and Cormier knew the model wouldn't scale.
"We really didn't have a business model," he said. "We had Red Hat Linux in bookstores for $29.95 a box, the same Red Hat Linux people could download for free. We had, maybe, at the time, ten commercial customers that were primarily paying for us to talk on phone. We knew that wouldn't scale. They were saying, 'Why should I pay you for this?'"
Cormier recalls many late nights with top executives, hammering out a strategy to replace Red Hat Linux with Red Hat Enterprise Linux, which was ultimately sold through a subscription including updates, patches, and bug fixes. The late night talks were challenging, Cormier says, because Red Hat wanted to both satisfy open source licensing requirements and pave the way for a multi-billion dollar business.
After the transition, Red Hat didn't completely stop giving software away. While RHEL would bring in the money, the spirit of the original Red Hat Linux lived on in Fedora, a Red Hat-sponsored community project, which was first released in 2003 and initially based on Red Hat Linux code. Fedora and RHEL have a mutually beneficial relationship, with Fedora code serving as something of a testing ground for the enterprise features delivered to Red Hat's paying customers.
RHEL source code is freely available under the GPL (GNU General Public License) for those who want to compile it themselves, but the actual finished product costs money. Yes, there is CentOS, a free-to-download clone of RHEL compiled from the source code by CentOS developers. But Red Hat charges a premium for RHEL because it's (theoretically) guaranteed to work—Red Hat and third-party software vendors make sure that applications running on RHEL are not broken when the operating system is updated.
"Red Hat Enterprise Linux, the bits, the ones and the zeros, are not free," Red Hat CEO Jim Whitehurst told Ars. "The source code is free and it's freely available. But we compile those bits and we make it enterprise-class."
Most importantly for major customers, Red Hat creates a long-term support edition every two years. It commits to support this for a full decade, to the point of taking critical fixes from the Linux community and back-porting them to the older versions.
"If you're the New York Stock Exchange, the last thing you want is rapid change in your underlying operating system," Whitehurst said.
If all Red Hat did was give away software and sell technical support, "we'd be a tiny little company that is marginally profitable," he said.
Red Hat Linux was much like today's Fedora, releasing new versions quickly to get the bleeding-edge technology out to users. But new versions and patches could break old applications, and there was no ecosystem of software and hardware vendors supporting applications running on Red Hat. With RHEL, Red Hat gives the enterprise what it wants: a stable lifecycle and roadmap, and a more careful system for inserting patches without breaking application compatibility. That model has certainly proven its worth.
Patent trolls follow the money
With the increased cash flow, Red Hat became a target of patent lawsuits and a staunch defender of open source users. The company remains unusually outspoken in its opposition to even the notion of software patents, yet it also forged a pragmatic strategy of acquiring defensive patents. Red Hat fights lawsuits where fundamental issues are at stake and settles others that aren't worth the legal bills.
"If you believe in the concept of modular innovation where a lot of different people add to works that came before them, patents clearly slow that down," Whitehurst said. "I don't think we're different from any other software company, it's just we have to deal with a lot of patent trolls."
Red Hat CEO Jim Whitehurst
Red Hat
Red Hat is always busy in court, particularly in the Eastern District of Texas (well-known as a hotbed of patent lawsuits). Red Hat teamed up with longtime rival Novell to win one case against a subsidiary of "patent licensing" vendor Acacia in 2010. The pair even filed an amicus briefon behalf of Microsoft in one patent dispute.
In other cases, Red Hat simply paid up. It settled lawsuits from Acacia in April 2011 and paid $4.2 million to settle a suit brought by FireStar Software in 2008, for instance.
Among the benefits of a Red Hat subscription is indemnification against lawsuits related to using Red Hat software. Patent trolls sometimes target Red Hat customers directly, and Red Hat generally takes those cases over.
"Our customers call us and say 'we're being sued because we use your product,' and we take over the defense," Whitehurst said. "We reach whatever settlement we reach with the trolls. Some of those we fight because many of these aren't applicable patents for whatever reason, and others we ultimately settle. We generally settle not just for our customers, but for all downstream users of that code."
Despite the patent troubles, Red Hat has become one of the top names in the enterprise server market by focusing on what it does best: building great software.
"We never ever go into a customer and say, 'There's an application that's not supported on RHEL," Cormier said. "If it's supported on Windows, it's supported on RHEL."
Daniel Vande More, chief architect for a company called Net-Results and an Ars reader who has used Red Hat for more than a decade, agrees the shift to a more stable release strategy helped make Red Hat as appealing as it is today.
"Packaging for distributions that shift often is like trying to catch a falling knife," Vande More said. "Everything from new glibc versions to simple things like MySQL version changes can affect applications dramatically and often introduce so much variability that testing all possible configurations is at odds with making good use of developer time. Once Red Hat was able to smooth out these bumps by supporting their RHEL releases for years, I believe it became a much more attractive operating system for software vendors."
Reaching $1 billion
With RHEL, Red Hat expanded and soon outstripped companies like Novell, which was sold to Attachmate in 2010 after a long, slow decline. Moving far beyond operating systems, Red Hat now sells almost any type of software a data center might need to deploy and run applications, with various middleware, storage, security, virtualization, and management products. Having reported $836 million in revenue (and net income of $111 million) for the nine months ending Nov. 30, Red Hat is set to soar past the billion-dollar mark when its fiscal year concludes at the end of February (results will be reported in mid-March).
Just four years ago, Red Hat reported $523 million in revenue at the end of its fiscal year. Assuming current trends continue, Red Hat will more than double that in Fiscal 2012. Most of its money comes from subscriptions, the rest from training and services.
"It's just another validation in the line of many that open source software is a fundamental part of IT infrastructure," said Jim Zemlin, head of the Linux Foundation. "They have shown that this is a solid business model, that this is a better way to distribute software and it can be done profitably."
Red Hat's growth may not stop here. It made its most significant acquisition in 2006 when it bought middleware vendor JBoss. It has continued to expand with the November 2010 purchase of platform-as-a-service provider Makara and the October 2011 buy of storage vendor Gluster. But moving up in the virtualization market will be difficult.
In virtualization, VMware maintains a "huge lead" over Red Hat
Red Hat has occasionally boasted about providing all the goodness of Microsoft's data center offerings—without the restrictions imposed by closed-source software. But Red Hat's top executives say their biggest rival isn't in Redmond.
"We almost never see Microsoft," Whitehurst says. He notes Red Hat is mostly converting Unix shops to Linux, a market in which it competes against Oracle and IBM instead. Whitehurst says Red Hat's future growth depends on providing the back-end infrastructure for public and private cloud networks, as well as software-as-a-service vendors. Here, the biggest competition is virtualization vendor VMware.
"They're way ahead of us in virtualization, we're way ahead of them in operating systems and middleware."
This is also where many expect Red Hat to fall short. VMware dominates the server virtualization market and its most serious threat comes from Microsoft's Hyper-V. Citrix with the Xen open source hypervisor is third. Red Hat, along with Oracle, currently fight it out for fourth place.
Red Hat's virtualization platform is based on KVM, which has less than one percent of today's market share, according to Gartner analyst Chris Wolf. Red Hat's technology is solid, but Wolf said the company will "have a challenge just staying ahead of Oracle, because Oracle has taken virtualization very seriously."
Red Hat has a brand-new release of Red Hat Enterprise Virtualization out. It adds many new features and finally drops the Windows Server-based management system for one relying entirely on open source software, namely Java, JBoss, and RHEL. But Wolf said Red Hat is far behind VMware when it comes to integrating the virtualization stack with third-party backup, security and disaster recovery products.
Whitehurst, of course, gives Red Hat a better shot.
"They're way ahead of us in virtualization, we're way ahead of them in operating systems and middleware," he said. And when it comes to making applications portable across data centers and cloud networks, "all three of those components are important. They have a huge lead in one and we have a huge lead in the other two."
A question of definition
Some take issue with calling Red Hat the first billion-dollar open source company. As Linux kernel maintainer Greg Kroah-Hartman notes, Google, Facebook, and Amazon were built on open source software, and IBM made billions off of Linux.
"There are lots of companies that rely entirely on open source software, and give back in various ways to the communities involved," he said. "Loads of them are above the billion-dollar mark."
Still, Red Hat is unique when you consider that it earns its money almost entirely by selling and building open source software. Red Hat is also the top corporate contributor to the Linux kernel, something Kroah-Hartman praises. "They are doing wonderful work, allowing their community members to contribute in great numbers," he said. "I'm really happy with all they have been doing."
Kroah-Hartman points out that Red Hat "does have and sell proprietary software," calling into question the nature of Red Hat as an open source-only company.
However, even when Red Hat acquires proprietary technology, it eventually converts the code to open source. A Red Hat spokesperson tells us the only Red Hat technology today that is "not fully open source" is the OpenShift platform-as-a-service software.
"OpenShift is built on open source technologies and we are in the process of setting up the licensing and governance model for that now," a company spokesperson says. The company says RHEV, based on the 2008 acquisition of Qumranet, was fully open sourced as of November 2011.
Red Hat drew some attention to its practices for distributing source code last year when it implemented a change designed to prevent Oracle from cannibalizing its RHEL business.
Oracle's Linux distribution is based on RHEL—much as CentOS is—with Oracle trying to divert customers away from Red Hat by selling support. In retaliation, Red Hat started shipping Linux kernel source code in a big tarball with the patches already applied, making it more difficult to build Linux distributions from the RHEL source.
Kroah-Hartman claims it was a non-issue, saying it "affected the kernel developers not one bit at all." The move hasn't prevented CentOS from making regular releases. It all fits in with Red Hat's longtime strategy of making money without violating the terms of the GPL.
"To put it bluntly, Oracle has come in very clearly saying 'This is a copy of Red Hat, and we are offering it at a lower price than Red Hat,'" Whitehurst said. "We need to protect our business model because if we're not successful I seriously doubt Oracle would be giving the code away the way we do to CentOS and everyone else."
The next Red Hat?
There's plenty of room for another Red Hat, Whitehurst said. Enterprise software is a $180-$200 billion market, and the company competes for about $30-$40 billion of that.
"There are huge categories where we aren't even there," he said. "Databases, for example."
Zemlin sees a lot of innovation from newer open source companies, and he singles out Hadoop vendor Cloudera and SugarCRM. Zemlin believes "there will be some more Red Hats out there," but notes the success of open source lies just as much in companies creating innovative products builton top of open source as it does with companies like Red Hat that build and sell open source software directly.
Salesforce.com (a Red Hat customer), Google, Amazon, and Facebook couldn't have reached the heights they did without open source, Zemlin argued.
"I think there will be more companies like Red Hat, but that question limits how you characterize success using open source," he said. "You really have to look at the hundreds and hundreds of companies that achieve massive business value by taking open source and using it in different ways.""
Link to original article here.
Recommended Reading
Democratising the corporate strategy process at red
Schematic diagram for market segmentation - customer segments
Detailed Profiles of each and perceptual mapping
Company Analysis
Understanding company’s cost structure and cost position relative to competitors
Defining core competencies and competitively distinct company resources.
Analysis of profits from various products, lines and customer accounts.
Audit of brand strength and sources of brand equity.
Collaborator Analysis
Profile of suppliers, partners and possible joint ventures
Competitor Analysis
Build detailed profiles of each competitor in the market and SWOT analysis on each.
Examination of cost structure , sources of profit, resources and competencies, competitive positioning and product differentiation, historical responses to industry developments.
Context Industry Analysis
Porter’s five forces
Threat of new competition
Threat of substitute products or services (ie Cloud)
Bargaining power of customers
Bargaining power of suppliers
Intensity of competitive rivalry
Marketing Strategy
Define understanding of our customer base and our competitive position in the market.
Make the strategic decisions necessary to develop a marketing strategy to maximize our revenues and profit.
Objectives to include specific targeted revenue growth, market share and long term profitability.
Target Customer Segments (examples)
Digital houses through the partner program
Strategic High Profile Online Businesses
eCommerce
Technology ie Magento
Tenders
Corporate Websites
Tech Startup community
Government
Marketing Management and Strategy Deliverables
Account Management - upgrade opportunities - sales within customer base
Measurement of results; reporting, analytics and sales data.
Compensation, sales quotas, policies
Technology and Tools including CRM
Training and Sales Communication
Sales territories design and optimization
contests/spiffs
Lead generation/Sales Programs
Customer Segmentation
Specific Deliverables Sales Strategy
Profit based sales targets and budget.
Forecasting by region, products, services, customer segmentation etc
Demand Management
Sales Plan - following the lead of the marketing plan, strategic planning and business plan specifically detail how objectives can be achieved through the actual sale of products and services.
Incentives to drive performance - Compensation, sales quotas and policies.
Defined and structured sales process
Defined and structured guide for meetings
Delivery of working CRM and Sales tools (Keynote, Email Templates, Case studies etc)
Defined and structured handover process.
Ongoing training and communication follow up of Sales Team
Sales territory design and optimization including mini campaigns within each territory.
Sales contest and spiffs
Lead generation programs quarterly.
Customer list segmented in logical way.
Opportunity reviews and opportunity management with Sales Team
Management of sales staff, job analysis, job description and job qualifications
Reporting on KPIs to allow visibility of whether the sales process is being operated effectively and achieves the results as set forth in the sales plan.
Reporting to enable sales management to make timely corrective action to deviation from projected values.
Reporting to allow senior management to evaluate the sales management
Reporting on results - sales funnel and hit rate
Reporting for any other specific stakeholder requirement.
Sales Plan Template
Markets and marketing
The best sales results are based on sound market research and marketing research. Thus the first element of a good sales plan is a summary of your markets and marketing.
Answer the following questions and then use your answers to write the information for each section.
Summary of your business’s target market segments
How many clients are in each market segment?
Who are the people in each market segment?
Where are they located?
How do they make purchasing decisions?
Where do they find information to make purchasing decisions?
What classification have you given to each market segment (according to previous sales volume or potential sales volume)?
Factors affecting future sales, learned through market research
Why there is a demand for what you’re selling
How do your products and services meet the needs of people in your target market?
Is there a market niche that is not being satisfied?
Are people in an existing market satisfied or looking for a change?
Can you offer clients something that will satisfy them?
How much competition is in this market?
Your present market position, including any strengths, weaknesses, opportunities or threats
How does the market perceive each of your products or services?
How does the market perceive the competition’s products and services?
Is the product you’re marketing new or established?
Do your current premises and locations appeal to your clients?
How do your premises and location compare to your competitors’ premises and locations?
How do you set your prices (including discounts, specials, package deals and stock movement)?
How do your prices compare to your competitors’ prices?
How do you currently promote and market your business?
Which promotional and marketing activities are working?
Which promotional and marketing activities aren’t working?
How do your competitors promote and market their businesses?
What works for them?
How does the appearance of your premises affect the market’s perceptions of your business?
How do your staff affect the market’s perceptions of your business?
Are there any unique characteristics of your business, product or service?
How much money do you have available for marketing?
Describe your existing client base.
Who are your suppliers and distributors?
What is your price structure?
What are your profit margins?
Using the information provided above, our strengths, weaknesses, opportunities and threats are:
strengths: weaknesses: opportunities: threats:
Using the information provided above, our competitors’ strengths, weaknesses, opportunities and threats are:
Competitor Name
Are there any predicted major changes on your target markets that may impact your future sales?
Are there any opportunities or threats that may arise out of the changes you expect in the next six to twelve months or longer?
Are there any outside factors (physical, economical, socio-cultural and technological) that may affect your future sales?
The results you expect your marketing to achieve
What are your marketing objectives?
Specifically, what are the measures of achievement contained within your marketing objectives?
Assumptions
By summarising your basic assumptions you can see when your sales forecast (and, thus, your sales plan) needs updating.
What are your assumptions regarding the number of clients you currently have?
What are your assumptions regarding how rapidly your marketplace is changing?
What are your assumptions regarding the capabilities of your competitors?
What are your assumptions regarding the resources required to continue your business operations?
What are your assumptions regarding the costs of materials and labour?
Do you have any other assumptions that affect your sales plan?
Sales history
To forecast sales, also summarise your sales history.
What were your previous years’ sales, by appropriate products and product lines and by appropriate time periods?
Product or product line:
Time period
Sales
Sales forecasts
Once you’ve analysed your markets and marketing, your assumptions affecting your sales plan and your sales history, you have the information you need to forecast your sales.
Your sales forecast is a month-by-month prediction of the level of sales you expect to achieve by product or product line and market segment. When developing your forecast be realistic about the amount of sales you’ll make, given your current markets and market and marketing research results, your assumptions and sales history.
Asking for your salespeople’s input in developing your forecast can help you make the forecast as realistic and accurate as possible.
How many new clients do you gain each year?
How many clients do you lose each year?
What is the average amount of sales you make to each client?
Are there particular months where you win or lose more clients than usual?
How many products do you sell per year? Per month?
How many sales do you make to each market segment per year? Per month?
How many sales per month do you expect to achieve by product or product line?
Product or product line:
Month & Sales
July
August
September
October
November
December
January
February
March
April
May
June
Have you asked your salespeople for their input in developing your forecast?
Sales targets
The purpose of your sales plan is to develop strategies and identify activities necessary so you meet your sales targets. It’s usual to include your sales targets in your sales plan.
While your sales forecast shows the sales you expect to make, your sales targets are the number of sales of a certain product or product line you need to make to return a certain gross profit.
You can develop sales targets:
by product and product line for the upcoming year, quarters and months.
List your sales targets below.
Once you’ve listed your sales targets, compare them to your sales forecast. Are there any gaps?
If so, you can focus on these gaps when you develop your strategies and tactics in the next element. Alternatively, the gap might indicate a seasonal trend, for example. You could then adjust your sales targets for that month to reflect this forecast (so long as you’ll make the sales you need by setting higher targets another month).
Strategies, tactics and measures of achievement
To achieve your sales targets, you develop strategies and tactics for achieving these targets. Your sales planning strategies are necessary so that you can focus your efforts as well as your salespeople’s efforts. Your sales plan strategies are closely linked to your marketing plan.
What motivates your clients to buy your products?
What motivates your salespeople to sell?
Strategies and tactics
Your sales plan tactics relate more to the performance of your salespeople than to your marketing activities. You can set up strategies and tactics according to market segment.
You can use the following table to identify your strategies and tactics for achieving your sales targets.
Strategy
Attracting new clients in a particular market segment by using ? tactics.
Getting your existing clients to buy more and more frequently using ? tactics.
Improving your profit margin using ? tactics.
Retaining your existing clients using ? tactics.
Measures of achievement
Measures of achievement are numeric measures of success. These measures of achievement can help you measure:
The success of your strategies and tactics
How well your salespeople are applying your strategies and tactics.
Measures of achievement include your sales targets but also might include:
Individual sales targets for each salesperson
Call patterns for each salesperson according to market segment
Conversion rate of prospects to clients.
What are your measures of achievement?
How will you gather these measures of achievement?
Action plan for meeting your sales targets
The purpose of developing an action plan for putting your sales plan strategies and tactics into place is to help you meet your sales targets.
Some of your sales plan strategies and tactics may be similar to your marketing strategies and tactics. If so, some of the actions you identify in your action plan may be the same.
Begin by identifying the actions necessary for implementing your strategy and tactics. Then specify who is responsible for implementing the action, when it will start and finish and how much implementation will cost.
Action
Person
Cost
When
Budget allocation
Record the sum of all your individual selling activity costs below:
Sum of individual selling activity costs (my budget allocation):
Have you conducted a cost benefit analysis of each individual selling activity cost?
Using the Sales Plan
Communicate and carry out the plan
Discuss your sales plan with your salespeople
Alert your suppliers to any impact your sales activities might have on the orders you place with them
Check with your production people that they can produce the volume that your sales plan expects you to sell
Alert other appropriate staff as to the contents of your sales plan.
How and when will you discuss your sales plan with your salespeople?
How and when will you check with your production people that they can produce the volume that your sales plan expects you to sell?
How and when will you alert other appropriate staff as to the contents of your sales plan?
Have you included provisions for each of the above in your action plan?
Have you included any additional costs in your sales budget?
Monitor progress
Monitor progress as you go and adjust your actions (and sometimes your plan as well) depending on the results you’re getting. Find out in a timely way when your strategies, tactics or actions need changing.
What measures of achievement are you going to check?
How frequently?
Adjust the plan
If you’re going as well as you planned, you may need to adjust something.
What will you do if, as a result of your monitoring, you find that your plan isn’t working?
Monitor changes
Circle through Monitor progress and Adjust the plan until you reach the end of your sales plan.
When will you monitor any changes you make to your plan?
Evaluate effectiveness
After you’ve made it to the end of your sales plan, you can improve the results of future selling activities by evaluating the plan’s effectiveness.
Did you meet your sales targets, including the measures of achievement you specified?
What is selling? Systematic outcome-focused questioning.
Feature/benefit selling suited to Retail not B2B sales.
Maintaining control over the process will enable you to influence the decision makers
Your prospects are always people not companies, you have to identify what their agenda is and what their decision making drivers are.
Top Motivators of the corporate buyer
Maintain job security.
Avoid embarrassment and look good
Money (not the companies their own)
Build an empire (not the companies their own)
Preserve a relationship with a trusted colleague
Save hassle and irritation
Maintaining Control
Knowledge is power
The one asking the questions is in control
The one that controls the agenda controls the outcome
Stages of influence
1. Feeling they can trust you enough to be honest and transparent with you about their cares and concerns.
2. Reaching a realization that they are dissatisfied with their current solution.
3. Believing that you represent an alternative that will take that dissatisfaction away without exposing them to risk
4. Deciding and committing to make a change.
Structure for every Sales Meeting and Conversation
Relax: Client, establish rapport, trust and credibility
Discover: Questioning, Creation of desire for change
Solve: Realization that you have a solution that meets that desire for change
Commit: Commitment to a course of action or next step
Sales Process
Qualifier call/meeting - Initial interaction after lead is received.
Survey call/meeting - Requirements gathering, possibly with technical team involved.
Verification call/meeting - After tech review, verifying requirements understanding and giving preview of solution.
Proposal call/meeting - Presenting Proposal
Follow up call/meeting - Closing the sale, collecting signed order.
1. Qualifier call/meeting
Relax
Find common ground be genuine and don’t try! Let it happen by being interested in the person and the company.
Remember that you are talking to an individual not a company.
Take away the fear of the Stranger, don't be reluctant to talk about any common interests.
Don’t come across as a salesman – think of your negative perceptions and then act the opposite to those.
Make sure you change the subject to business, state purpose of meeting and the agenda then ask for agreement.
Ensure you explain you intend to ask a lot of questions and why, then ask “are you ok with that”.
Discover
If client does not know a lot about your business give a short dynamic overview “Elevator Pitch”.
Start by asking general questions about company to let client feel comfortable and open up to you.
Use hot buttons (known issues) to uncover pain points and probe deep into each one.
What are their objectives, hopes, dreams and aspirations?
How does that compare with current realities?
Keep probing until they start describing how it will impact them individually.
Systematic questioning to broaden, learn and understand their feelings not just their ideas.
Get clarification on the above and increasing detail of disquiet, concerns or fears.
Drill down through stated objectives to find real motivators of prospect.
Solve
Feedback the stated and perceived needs of prospect.
Combine them into a common theme.
Float a solution that meets the prospects real and stated objectives.
Test to see how it suits prospect.
Commit
The 4 impediments to a sale need to be addressed now they cannot be done later in the process!
1. Allegiance to another supplier.
2. Won’t be involved in the sales process or do their homework.
3. Not talking to the decision maker.
4. Sales losing momentum, decision never reached.
Set up your expectation at the “commit stage” in return for your commitment to going through the sales process with them ask;
If I commit to moving forward in this process and provide you with a proposal that addresses the issues and solutions we have discussed today can I ask that it will be on a commercial-in-confidence basis and you won’t disclose the nature of your offer to others?
If the solution cost justifies , will you have any problems discontinuing your current relationship?
(If they are considering your competitors) Ask for the last right of reply.
Get agreement for them to provide some information that will take some degree of effort for them to enable the proposal to be done.
Ask who else will be involved in the decision making process and probe to make sure you have everyone. Make sure you are speaking with all the decision makers.
Ask when they need this solution, find a critical date or event that you can work to closing to, If there is no critical event and you cannot make one out of a sale or promotion just ask them for a commitment to make a decision by a certain date. Most importantly you need a commitment on a date.
Note: If you can’t get agreement on all these questions you should qualify them out – leave the ball in their court but don’t waste much time on it.
