B A N A N A S Pretty much sums up the last year – It’s been bananas. Never ending Pandemic, New Brands, Growth, Working towards compliance, New Product Launches, and more. This September 2021 is a very special month for us. Pagely, and by extension the entire multi-billion dollar Managed WordPress Hosting channel, is 12yrs old! Quick Flashback: In Early 2009 I opened up my IDE and started looking at some code we wrote in 2006 for a website builder based on WordPress. I added a few features to it, picked a new leet domain name, and in September 2009 – Launched Page.ly – The world’s first Managed WordPress hosting company. All the WordPress hosting buzzwords you know and love: Automatic Backups Automatic Updates Blazingly Fast Secure like Fort Knox 1 Click Staging Caching All. Of. It. Started. Here. Yes of course it is true we did not actually create everything under the sun, however the early work we did in the space is the parent to every Managed WordPress product offering available, regardless of the company selling it. Except billing for Pageviews, eff that noise – we don’t want any part of that. Team Retreat in 2015 Always Forward As Pagely begins it’s 13th year we have a strong wind at our back once again. I’m sure in some companies, especially investor fueled ones, growth is always fast and up while profitability is tied up in ropes and cinder blocks, then thrown off the end of the pier. In our company we’ve had our periods of growth insanity and just normal one foot in front of the other measured progress to increased profitability and high NPS scores. 2018 through most of 2020 was a bit of an odd timeframe for us when looking back – we invested heavily into the development of NorthStack and gained deep technical learnings. These lessons were then applied to Pagely as the decision was made to pause the NorthStack product while we felt out how the world was going to react to a fast spreading novel Coronavirus. Team Retreat Early 2020 As we came up to a major revenue milestone in 2020 we turned our focus inward to reevaluate our processes and to create new ones, address team makeup, and revisited our mission and values. We took the time to prepare for what was coming and to lay the foundational groundwork for our future goals. Less manic startup energy – more “we’re a real business now” mentality. We hired into newly created roles in team management, finance, enterprise sales, and compliance. Sally and I handed off more and more of the day-to-day responsibilities to our skilled team so we could take stock of where we are, and where we needed to go. Then we all worked together to formulate the plan to get us there. Allison’s (SupportOps Manager) dogs: Winne and Lola (“Karen”). The last year has been all about executing on that plan. We added 30% to our headcount – while improving and expanding our benefit offerings. We’ve engaged the services of an auditing firm and will shortly achieve SOC 2 – Type 2 compliance certification. Our brand glow up – which is the culmination of months of work by our Dir of Marketing Dave Amirault, and the creative team at Struck – will be launching momentarily. We’ve delivered on many of the requested features to our Enterprise clientele such as Single Sign On (SSO) to our services, and expanded support models and enhanced SLA’s. Back of the napkin math tells me our employees significantly increased their usage of PTO – after much encouragement and prodding from myself and their team leads. We launched Mercury just a few weeks back, which is a major win for our bottom line and our customers’ site performance. 20-30% faster network speeds on every request at cheaper data rates. Truly a win-win. These and many more items that are part of our strategic plan have resulted in a steadily growing sales pipeline and a pronounced upward shift in our momentum heading into 2022. Did I mention we are hiring? Get your tech jobs here. Times have changed. The important stuff has not. Jeff Matson’s doggo – Henry 2021 was also an emotional roller-coaster as we all bared witness to the, at times, abject selfish nature of people — and — the grit, empathy, and kindness of others. Sally and I have personally seen all of this up close and personal this year, a story we may share at another time. Each day though we took heart that by and large, the world is good and things tend to work out in the end. Keep the good people in your life close, and hug your kids every day. It costs you nothing to be kind. We lean on our core values as we make decisions and plan for the future. We also relied on them heavily in the past as we navigated the ups and downs of the pandemic. Sally has always said that if we do the right thing, success will follow. Doing the right thing by the people in our lives, our companies, and our communities is typically a selfless act with no expectation of return. At times though, the universe does surprise you with a healthy payback of goodwill, tenfold. There are lot’s of new faces at Pagely, as we said goodbye to others. It seems everyone has collectively reevaluated how they wish to invest their work time. Many leaned into the stability of good careers, others felt it was time to explore new options. At each coming and going I’m thankful to see new faces embrace our vision and values and old friends take a little part of the Pagely magic with them as they move forward to a new adventure. We are just as committed today as we were yesterday, and every day prior to becoming the best version of Pagely we can be. Branding work in 2021 Looking forward is as exciting today as it has been at each one of our 11 prior birthdays. I want to personally thank the team here at Pagely, and all of our customers and the fans we have in the WordPress community for being part of our journey thus far. Happy Birthday to Us. This coming year is going be the most interesting chapter in our story yet. I guarantee it.
Since this is the internet – and the rules of the internet clearly state everyone gets an opinion, I’d like to share one of mine around website hosting billing plans. Quick backstory: 10+ years ago when we launched Pagely we did so with a simple line on our pricing page denoting a rough estimate of the expected capabilities of that plan ie: Plan – 1 was suitable for ~1 million pageviews. Along came the next several providers who did something similar with one important difference. They actually attempted to measure and cap pageviews per hosting plan, bracketing their plans by this new billing metric. In my opinion Pageviews used as a billing item is a predatory and anti-consumer practice and you should be very wary of working with any company that applies this #successtax to your monthly bill. Definition of anti-consumer : not favorable to consumers: improperly favoring the interests of businesses over the interests of consumers Hi, I’m Joshua Strebel, Co-founder and CEO of Pagely – A leading Managed WordPress hosting company – Thank you for attending my TED Talk. What are you buying when you are buying “hosting”? To host a WordPress site you need a few key components. A server (a computer) connected to the internet with software installed to process requests and responses for your application. Storage / Disk space attached to that webserver to save your files to. Data Transfer / Bandwidth. This is the pipe the information flows through. That’s basically it. Hosting providers typically lease/sell you packaged fragments of these resources for a monthly fee. Plan A, Plan B, Plan C. etc. Of course there are other items that may be line-itemed such as included support levels, CDN GB’s per month, managed services, etc. Plan A has X amount of consumables for Z price. It’s all fairly straightforward as most consumers understand what a Gigabyte of Disk space is and can at least grasp that more CPU/RAM offered should equate to more potential performance. “Pageviews” does not fit this model well – as the definition of a pageview is amorphous and subject to exploitation. Oh, and spoiler alert, PHP workers is not a valid billing metric for WordPress hosts either. What does an automobile lease have to do with hosting plans? Pageview limits on hosting plans are akin to annual mileage limits on auto leases. It’s a cap on the use of an asset you already purchased. In an automobile lease context a mileage cap at least has some merit as being a form of controlling the depreciation of the vehicle – you are essentially financing the deprecation of the automobile asset with a lease – and the lease company expects to sell that car (New retail value – Depreciation) when you return it. If the depreciation is too high, they lose money on that transaction as they have to sell it for less than they calculated. Your hosting plan is not a depreciating asset though – the hosting company is going to sell the same resources to the next customer when you are done for the same or likely higher fee. Therefore in my humble opinion: Pageviews are just an arbitrary anti-consumer fee – a penalty tax for using the service you already paid for. A Pageview is (depending on who you ask) a wrapper around these items: A measurable amount of Data Transfer in and out A measurable amount of CPU resources to process the request and render the response A measurable amount of Disk and Database activity Are you not already paying for these items as part of your hosting plan? Hint: Yes you are. But wait, there’s more – and my colleague will dig into these more in a future post. This pageview billing model is so poorly defined by the hosts that use it – it is ripe for abuse. It’s a scheme to generate revenue for the hosting company and unfairly penalizes the consumer. Hint: You already “paid” for the sum of the parts of a “pageview”. No two pages are the same. A cached page even with a few images can be served a million times a month with ease, and yet a badly coded membership-site page may tax the hardware it runs on each time it loads. They have very different cost profiles to the host – yet both are treated equally under this model. If you invested the time to optimize your site, get it caching well and then blow it up with viral traffic.. That is a GOOD day for you and costs your host pennies of the monthly fee you are already paying them – yet when you get the overage bill for exceeding your pageview cap at the end of the month, are you going to enjoy that tax on your success? If you want to keep paying twice for the same resources you are welcome to. I simply do not think that is fair. Our friends down in Austin have made millions on charging their customers overage fees for exceeding their monthly pageview cap – even to the point having to publicly respond to criticism – only to keep the practice in place. Reminds me of airline baggage fees and fuel surcharges. and An “online payment convenience fee” when they only accept payments online. and JetPack being “free”. Happy WordPress’ing – Joshua Strebel
PHP workers are getting a bad rap lately in the WordPress hosting world. Most commonly, they’re being cited as a scapegoat for a hard upsell by the host. Let’s dig in a bit deeper and discover the truth behind PHP workers and how they apply to hosting WordPress sites. Table of Contents What is a PHP Worker? Why Would I Need to Care About PHP Workers? Why Would My Site “Run Out of PHP Workers”? Wouldn’t More PHP Workers Fix the Problem? How Many PHP Workers Do I Need? How to “Tune” PHP Workers Here’s the Real Question That You Should Be Asking Don’t Believe Us? Want Proof? There you are, just minding your own business – literally minding your online business – when your workflow is suddenly interrupted with a prolonged loading page. You say to yourself, “That’s weird. It seemed to be working fine just a moment ago”, so you tap the refresh button. After a moment, you see a white screen with a 50x error printed across the top. You want to be sure that it wasn’t just a freak accident, so you give that refresh button one last tap and the WordPress admin page you were working on loads right up. It’s like nothing ever happened. Since the incident, a million thoughts of panic and discomfort are running through your mind. “Was this just a random issue? Should I worry about this? How often does this happen? Do my customers see this too?” Unfortunately, there’s no magical catch-all answer. This “blip” or “timeout” could be attributed to any number of causes throughout your hosting stack. Within this article, we are focusing on the specific and casually offered, “you need more PHP workers” reframe that far too many WordPress hosting support desks seem to respond with. What is a PHP Worker? A single-core processor on a timeline. 2 PHP workers drop tasks into the processing queue and are handled in a fairly consistent fashion. Memory usage stays somewhat constant as CPU usage modulates with workloads. In a basic sense, a PHP worker is a background computing process that runs PHP code. It hangs out on the server, waits to be told what to do, does it (hopefully in a timely fashion), returns the response, then goes back to twiddling its thumbs until another task comes in. When they pick up a new task, they’ll use whatever CPU cycles and RAM they have available to get the job done. To ensure that they always have resources available for when the next job comes in, PHP workers also reserve some resources to stay warm after they finish. Of course, you wouldn’t want to have a bunch of PHP workers sitting around and eating up additional resources just to sit there idle. In addition to being statically defined by always keeping the same number of PHP workers ready, they can also be dynamic. By utilizing dynamic PHP worker counts, they’re able to grow or shrink as necessary. In a WordPress context, PHP workers are kind of dumb. Since WordPress runs as a single-threaded application, a single PHP worker handles the entirety of the request. Because of this, a typical WordPress request looks something like the following: A request comes into the web server and passes it off to PHP. A PHP worker within the worker pool starts processing the code. If your code requires information from the database, the PHP worker then passes a query over to the database server, then waits to get the results back. Once the worker receives what it needs from the database, it then performs further processing before finishing and passes the completed work back over to the webserver. Why Would I Need to Care About PHP Workers? Most of the time, you don’t need to know or even care about how many PHP workers your hosting account has, much less how they are allocated – until you run out. When high traffic to your site, poor performing code, or a combination of the two uses up all your available PHP workers, it bottlenecks the chain. Once you run out, requests get turned away or queued until one of your PHP workers finishes a task and can take on another one. Why Would My Site “Run Out of PHP Workers”? Wouldn’t More PHP Workers Fix the Problem? As we stated above, a PHP worker stays “blocked” while active. During that time, it’s not able to perform any additional tasks until the current task has finished. The benefit of having more PHP workers is that it may allow the site to handle more tasks simultaneously. Typically, the number of PHP workers is not as critical as the type of workloads that those workers are performing. While handling more tasks simultaneously may help with making sure that every task gets finished, excessive PHP workers can also cause individual tasks to take longer. As each task takes longer to finish, this means that when resources are exhausted, it can take quite a while for spare PHP workers to become available. Typically, the number of PHP workers is not as critical as the type of workloads that those workers are performing An excellent way to think of your worker queue is like a list of tasks. If you have a few tasks that you can handle at once, you can get them all finished relatively quickly and become ready for more tasks. But if you take on too many tasks at once, you might find yourself overextended, take longer to complete each task, and see your backlog grow exponentially. Long/Slow Running Tasks Clog Up the PHP Worker Queue Code performance is the most significant factor in regards to PHP Worker capacity. Let’s take a look at a very simple instruction in PHP: print(“This is a PHP function”); This instruction alone occurs almost instantaneously. Because it happens so quickly, it consumes 1 worker for only a brief nanosecond. On the other extreme, let’s look at a complex instruction that could occur when a customer searches for a product on an eCommerce site. If the customer was searching for car parts that are compatible with a particular product, your code might handle it like this: Give me all products from my database that match the keyword “spare part”, has a price between $5 and $15, and is compatible with SKU “4232”. Now take these records and process them. For each one, get the paths for up to 3 corresponding image thumbnails. Before making the items available, make a call to my 3rd-party inventory management system API and check to see how many are available. Once you have all of the products and inventory counts, start building the web page with product reviews, social media posts, and the product images for each product. Print that content to the browser along with my header, footer, and sidebar. Relatively speaking, this process keeps 1 worker occupied for a very long time. Each task waits for its part of the instructions to finish before it can move on to the next. Combine this with that page builder plugin that you love so much to generate the 3MBs of HTML, and you’ll be left with a reasonably substantial PHP process to chew through. Now, if your database is slow for any reason, it’s going to take a few hundred milliseconds longer to return its data, keeping that PHP worker active while waiting. Let’s say that you’re hosting your product inventory management system at a different cloud provider – the PHP worker needs to wait for that API communication and transaction to take place. You get the idea. The worker has to finish a task before it can take on any more tasks. Most of the time, it’s a non-issue. It does its processing, your page renders in 300-600ms, and you move on with your life. 2 PHP workers drop tasks into the CPU timeline. They’re processed consistently at first, but then 1 task “waits” as the other worker tasks continue moving. This demonstrates how a worker can become occupied or “stuck” while the transaction takes place, unable to do anything else until the task completes. Juggling Too Many Tasks At Once On your typical WordPress site, the whole process works fine a million times a day. Except when it doesn’t. Let’s say that your marketing team just sent out a wildly successful newsletter blast. It drove an influx of traffic to your site, and the crew is popping champagne in the break room. But on your server, it’s a different story entirely. You’re getting the same types of requests, but they have now multiplied and are happening all at once. From there, your PHP workers get bottlenecked as they cannot clear their tasks fast enough. That’s when your site slows to a crawl. A Note on Request Queuing Most modern hosting stacks use PHP-FPM to manage the number of PHP workers, allowing tasks to queue up gracefully while waiting for CPU resources to become available. If you are running Apache and mod_php, request queuing won’t happen gracefully, and any new request is unceremoniously dumped. Queuing is an excellent solution to handling short bursts of traffic, but has a downside that becomes apparent when your sustained traffic occurs at a higher level than you can process. When every request spends time in the queue, all you are doing is adding additional time to the response. If the queue size is large enough, you can even get into a scenario where each request is waiting for greater than 30 seconds before work even starts. At this point, you aren’t completing any requests in a useful amount of time. You would have been better off serving errors to half of the traffic and content to the other, rather than make everyone wait half a minute or more. 4 Workers drop tasks into the CPU timeline, which are processed in a fairly consistent fashion at first, but then begin to queue up waiting for available CPU. In summary, the PHP-FPM request queue lets you use the optimal number of PHP workers while still handling traffic bursts. However, it still needs to be capped at a size that allows it to process the entire queue in a short amount of time. Otherwise, you could end up in a runaway delay situation. Exhaustion of Server Resources As we’ve previously mentioned, each PHP Worker consumes a bit of RAM and CPU cycles. Even if you have 50 PHP workers to handle your workloads, your run-of-the-mill WordPress hosting plan likely does not have enough resources allocated to run all of those workers efficiently. One cannot merely add more PHP workers in a vacuum. Increasing capacity to serve additional website requests means increasing CPU and RAM (server/container size) in proportion to the PHP workers, based on what your workloads demand. 4 Workers drop tasks into the CPU timeline. As the volume of tasks increases and all available memory is occupied, tasks are unceremoniously killed off to make room for the tasks coming in behind it. This is a demonstration of the Out of Memory (OOM) task killer which, when active, causes all sorts of unpredictable performance issues. The 4 variables of CPU, memory, PHP worker count, and workload (code efficiency) all need to be in harmony when it comes to right-sizing a hosting stack. It’s worth mentioning again that code efficiency is the most important. Increasing the other 3 may just let you do more of the slow and inefficient tasks (concurrency) with no effect on how fast those tasks complete (performance). Cache is King Caching, of course, helps alleviate many of the bottlenecks described above. Caching at the database layer with native MySQL query caches (going away in MySQL 8), leveraging the WP Transients API, and/or a Redis Object Cache, saves the PHP worker from having to communicate as often with the database and wait for a response. Caching further up the stack in the webserver prevents the PHP worker from even being asked to do anything. Unfortunately, it’s not always possible due to session cookies or dynamic requests. Caching responses from 3rd party APIs, like the inventory management system that we described earlier, reduces that “waiting” time as well. The more efficiently you can cache and still meet your business goals for the website, the less PHP work needs to be done, which means an overall smaller demand on server resources. Newer PHP Versions are Faster Than Older Versions There are several benchmarks you can view online, and they all say the same thing: PHP 5 is faster than 4, 7 is faster than 5, and 7.3 is faster yet again than 7.2. You get the idea. You may not have any control over what version of PHP your host provides, but if you do, always opt for the latest version. The speed (and security) gains of newer PHP versions are real and quantifiable. How Many PHP Workers Do I Need? There is no universal answer to this question as each WordPress site and workload is different. Generally speaking, you want to tune the number of PHP workers to consistently use 80-100% of your available CPU capacity. Complex workloads may only allow for 2 PHP workers before consuming all available CPU. In contrast, efficient and optimized workloads may allow for 4, 6, or 8 workers per core with identical server specs. Too many workers for the available CPU simply makes everything slow down as they get queued up, and the CPU spends much of its time switching between tasks, rather than getting work done. Too few PHP workers for the available CPU wastes resources, since some percentage of your CPU remains idle, rather than getting work done. A good optimization of workers to CPU cores. 4 PHP workers leverage 2 CPU cores and have ample memory to process each task efficiently with a little (but not too much) buffer before maxing out. How to “Tune” PHP Workers Tuning PHP workers is a fairly straightforward process as long as you follow a few basic rules: You want to run as few workers as possible. You should have a hard limit on the number of PHP workers based on the memory used by each worker, and the amount of RAM on your server – this is very site-specific, as each website may have a different usage profile. Once your CPU is at 100% utilization, adding more workers simply makes each task slower. If your worker CPU usage is low, but your requests are still slow, your bottleneck is in something PHP is making a request to (Database/Cache/API). Increasing the number of simultaneous requests to that component might make it slower, so you have to monitor it. An excellent question to consider is this: why are you trying to tune your PHP workers? Is it maximum concurrency or maximum performance? At Pagely, we always try to understand the customer’s business goals when recommending which “hosting plan” to use. From there, Pagely tunes each plan to the specific customer’s needs. Dozens of small sites have a very different workload footprint than 1 large site on the same spec hardware. Tuning PHP Workers for Many Low Traffic Sites on the Same Server With lots of sites, you have two main worries: memory overhead and noisy neighbors (this can include just your own sites on the same VPS). Memory overhead is mostly static, based on the average memory usage of each site. For simple brochure-style sites, you might plan for 128-256MB of RAM for each site (plus some fixed OS overhead, depending on your stack). At your average cloud provider, you are going to be looking at instances with a higher memory-to-core-count ratio on the smallest size. As you scale, you’ll then switch to a lower memory-to-core-count ratio. As for PHP workers, you are going to want to use dynamic worker limits, generally with a minimum of 1 PHP worker to reduce latency and setting a maximum that only uses 25% or 50% of the server CPU. Setting these parameters lets a couple of sites burst at simultaneously, without causing performance issues on the other sites. Each site gets access to the CPU, but no one site can consume all of it at once. Setups like this tend to have a ton of unpredictability, so you are better off focusing on stability in worst-case scenarios instead of maximum performance and efficiency for any single site. Tuning PHP Workers for a Single High-Traffic Site With a single site, you can match the hardware and worker counts to get the most bang for your buck. You will almost always want to use cloud instances that are optimized for computing power (number and speed of CPU cores). From there, you should use either a fixed number of PHP workers or a dynamic configuration with a high minimum number of workers. If your database is running on another server, a good starting point is to take the number of CPU cores and multiply it by 2. Increase workers-to-CPU-cores when: You are making a lot of database or API queries. Your average response time is minimal (< 100ms). Decrease the workers-to-CPU-cores ratio when: Your codebase has low efficiency You aren’t making many database or API queries You are generating very large responses Just Throw More Hardware At It This is our least favorite solution – and one that we only recommend after we’ve gone through everything else. Sometimes it just has to work, right now, and refactoring poor performing code is time-consuming and not always feasible. Throwing hardware at the problem usually works, but with a major downside – it gets really expensive, really fast. You can typically increase concurrency and handle more tasks, but those tasks will never get any faster until the code efficiency is addressed. As our CTO says, “it just allows you to do more of the slow things”. Here’s the Real Question That You Should Be Asking We get it – several of the hosting companies have trained the consumer base to be concerned about the “number of PHP workers” and to think that number has some magical effect on how their WordPress site performs. We also understand that many of these same WordPress hosting companies have successfully brainwashed everyone to concern themselves with “number of Pageviews” as well. (Pageviews as a bogus billing metric is a topic for another blog post entirely.) These are both the wrong questions to ask when shopping for a scalable and reputable host for your WordPress website. The question you should be asking is simple: Does this host have the skill and knowledge to configure my plan specifically to my needs so that I can get the most bang for my buck (performance to value)? If they keep pushing plan upgrades and telling you that “you need more PHP workers” without any background analysis offered, you already have the answer you need. Don’t Believe Us? Want Proof? We’ve run a full analysis of the impact of PHP workers, including all of the source code for our tests. If you want to take a deeper dive into our data, a full write-up is available within our PHP worker benchmarking and analysis article. Happy WordPress’ing.
It’s the first day of April – 2020 Big Sigh Be stay safe out there, please.
Ten years ago this month, we launched Pagely and kicked off what has grown into the $2-3 Billion dollar channel known commonly as Managed WordPress Hosting. At the time, people questioned the need for the services they now take for granted, and which are increasingly becoming commoditized. Over the last decade, the wider WordPress ecosystem has clearly benefited from faster and more secure websites, better deployment workflows, and knowledgeable, WordPress-specific technical support. I’d wager to say the wider hosting market, in general, has also taken notice and adapted to serve a more discerning clientele that has come to expect more than Level 1 call center upsells when interacting with their host. It’s been an exciting and, at times, terrifying journey for Sally and I as we’ve put our efforts towards building a product and then building a company. We’ve become parents during this time and watched as our employees started or expanded their own families. We’ve seen competitors enter, grow, and dominate wide segments of the market. We’ve also stayed true to our simple philosophy of “business is personal” and have endeavored to interact with every employee and every customer with integrity and empathy. Thank you to all our customers past and present for joining us on this journey. As the Managed WordPress Hosting channel expanded, and the service offerings coalesced around similar feature sets and positioning, we remained laser-focused on moving up the value stack. Our approach was driven in dual parts by instinct and survival. For the type of company we wanted to be a part of, one that put our employees and customers first, we had to seek out and serve the top-tier customer base that would support and value that ethos. It’s not a stretch to say we, a revenue-funded company, were also being squeezed by the venture-funded companies with massive war chests and the overseas players that enjoyed lower expenses on labor. If a company does not adapt, it does not live. I would be remiss to not recognize WP Engine, SiteGround, Pantheon, GoDaddy, and the rest of the now saturated mid-market and B2C WordPress hosting field that have played a significant role in this channel Pagely created. They most definitely have done more than we ever could alone to expand and broaden the landscape… as they continue to bludgeon each other for mass-market supremacy. It’s near impossible to forecast what the next 10 years may bring. At Pagely, we are investing heavily into a new product we feel is the logical next iteration of managed application hosting, NorthStack. As technology changes at a quickened pace inline with the evolving tastes of consumers, we are exploring additional application ecosystems beyond WordPress such as Node.js, Laravel, and Gatsby, while leveraging and building the next generation hosting infrastructure to support it. Hi, I’m Joshua Strebel, CEO and Co-founder of Pagely, a 10yr old profitable “startup” and the innovator of Managed WordPress Hosting. Thank you for attending my TED Talk.
To wrap up this series on my WordCamp Phoenix keynote, I’ve once again embedded the video below. In this post I will unpack a couple of new concepts and ideas from that talk. Catch up here with part one and part two. Set the Employees Free In a typical corporate hierarchy most, if not all, key decisions are made at the top and handed down to teams below for execution. Those teams are then held accountable for the outcome. If the idea was sound, and the execution successful, the executives at the top take credit and the world keeps going. If the idea itself was a poor one, regardless of the quality of execution, the team that was told to execute will likely take the brunt of the blowback, and the CEO will get a golden parachute as the company falls into bankruptcy. I’m kidding, that almost never happens. Or in a different context, a lower level employee will be hamstrung and boxed into a tightly defined role with clear boundaries and permissions. They’ll be unable to adapt to edge cases or surprises, as the process they must follow is dictated by levels far above them. In my eyes, this is the wrong way to run a company if your goal is to build a vibrant, forward-thinking organization powered by intelligent and engaged people. What we have tried to do is give the authority to think and act to every member of our team, by trusting them to be the critical thinking and intelligent humans that we hired. As leadership and employees define the mission goals and take ownership of its execution together, multiple opportunities arise to sanity check ideas and revamp process before they are too far gone. Trust is the mechanism that makes this work. Leadership has to trust in the training and cultural indoctrination of their employees to make wise decisions. Similarly, employees have to trust leadership to not micromanage and second guess their work. At that point, the responsibility and accountability for outcomes can be fairly judged and assigned. For example, if your company screens for and hires competent support agents, then why not free them to help the customer thoroughly and effectively? Yes, this means you have to attract the caliber of talent you can feel comfortable with working off leash, be willing to pay them well, and be ok with the occasional learning mistake. The long term outcomes for the company and the customer will be more positive in the long run. A more skilled and capable team actually saves money in down the line and can drive additional revenue via increased customer satisfaction. I do, however, realize this does not work at every company. McDonald’s can’t let every employee get creative in how to prepare, package, and deliver fast food to the customer — but most knowledge economy companies can adopt a bottom-up approach, and be more successful than otherwise. This concept and others are found in the books below, which all share in common military themes in leadership, but each one also takes a critical look at the failings of top-down leadership and how it can be improved. Team of Teams Turn the Ship Around Extreme Ownership No Really, Set Them Free Everyone has the best intentions and an employee’s journey with a company will be a long and fruitful one for everyone involved. Of course, we know that is not always the case. Strategic shifts, morale, the likelihood of advancement opportunities, culture, relocations… the list goes on of reasons why employees and companies part ways or stick together. The situation that I think is the most dangerous is continuing the employment relationship with the employee that seems to waffle on the lines between mediocre and poor performance. In these cases we’ve always looked back and thought to ourselves we should have parted ways sooner. Hindsight is always that we did them and the company zero favors by delaying parting ways. In the larger context, we must consider the dozens of other families we are responsible for and put that greater good ahead of the discomfort of letting go a single worker. While I did not mention the above specifically in this keynote, It’s been a common theme in my talks as it seems to be a mistake we often repeat. Get the right people on the bus, and the wrong people off it. Take a look at my keynote in its entirety below, and please do follow up with thoughts and comments.
This is part two of a series on my recent keynote for WordCamp Phoenix, where I took the stage in front of my local business and WordPress community to share some insights and lessons learned. The video is embedded below and in this post, I will unpack a couple of the concepts and ideas from that talk. For more insight, see part one of the series. The Blue Ocean Strategy I read this book several years ago, and it was vital in shifting how I thought about our company and how we compete in the marketplace. I was also a particularly receptive audience to the primary lesson: differentiation. I have a screw loose somewhere that has always forced me to do things in a unique way or to make something mine. Not so much as reinventing every wheel, but for some reason, I could never just do things the same way as everyone else. The gist of the book is that to succeed and grow in business, you must move out of the competitive red water and into open blue ocean. Identify an opportunity to differentiate yourself from your competitors, draw those lines with messaging and branding, and then own the new open channel you created. When we launched Pagely in 2009 we had the market all to ourselves, a blue ocean. Within a few years, there were a dozen or so competitors all saying the same things. Many of them were massive companies moving into the space, or well funded VC backed companies hellbent on growth at all costs. In this very, very red ocean, we had to ask ourselves how we were going to survive as a revenue-funded small team. We elected to seek open water and over the course of a few years we re-positioned our brand, revamped our service, and began to target a different segment of the widening channel. We left the volume driven B2C segment to everyone else and focused on the needs of value-driven B2B, higher education, media, and enterprise companies with a flexible and high-touch approach. That kicked off a multiyear run of growth for our company and most likely saved us from sputtering out. Your company’s unique selling proposition should be defined by you, not by your competition who will happily paint you into a disadvantaged position if you let them. The compelling narrative of your story can aid your buyer in selecting your firm out of many. In a side-by-side comparison of solution providers in your space, what makes your firm stand out? During my keynote I described our journey to discover and sail to new blue oceans and cited how in my mind the new block editor in WordPress v5 is an example of this process. In order to stay relevant and continue the WordPress OSS dominance in the CMS space, it had to modernize a bit and seek a novel way to differentiate from a growing list of competitive platforms. There is disagreement within the community if the new block editor was the right thing to do, or was implemented correctly, but I believe something is better than nothing to keep WordPress relevant. As business owners, we always need to be thinking about the future, and a key question to answer is how we’ll stay competitive and prosperous. The last time we asked this question the answer we came up with was NorthStack, a new service we’ll be launching in the coming weeks. In the next part of this series, I’d like to look at how we empower our team to be successful. For now, please check out the video below and let me know your thoughts.
