Most people reading this will know my time is currently being consumed by the KumoMTA project. This high-volume messaging engine has been super exciting to develop, but the business model behind it is even more interesting than the software itself. To say we are challenging the rules would be an understatement. I wrote about the concept of open-source software before, so let’s start the conversation there.
Developing open-source software is one thing; building a business around it is a whole different story. I have been writing and selling commercial software for decades, and I have also created freeware I’ve shared publicly, but I had never thought about how to earn income from free software. The whole idea seems “upside down“. The key here is to think of the software as a “vehicle” to the income as opposed to the “source” of the income. It is the raw medium for our paid support and professional services work.
Revenue is only one part of a business model, though. What about sales, marketing, support, customer success and HR? When one part of the business model changes, it usually affects the others, so why not radically rethink all aspects of the business. What if we chose not to have a sales and marketing team at all? What if we spent that energy on building a community of users and supporters. What if we combine customer success and support into a new role that is more technical-customer-success-engineer? Let’s get radical and have no office, no official hours, and performance-based compensation and recognition?
When you start to dissect every component of the business model, there are so many opportunities to turn ideas on their head and ask “why”? Why do we do it this way? How important are titles and roles? Do we really need that process/expense/function? What really matters at the end of the day?
I have built (and helped to build) a number of businesses in the traditional way, some of them actually successful. This new adventure with KumoMTA is a whole new ballgame and offers an opportunity to examine the way business, in general, functions. I’m looking forward to turning it all upside down.
I have been thinking a great deal about Customer Success lately. Just some minor things like : – What it is, really? – Who should do it? – How should it be done?
The function of Customer Success is both one of the oldest fields of professional interaction and one of the newest, depending on how you slice it and I’ve had some time lately to reflect on it a bit. Titles like “Customer Success Manager” have really only been commonplace for less than a decade but the things those people do have been the keys to success for high-performing people for much longer.
To explain some background, my first actual paying job ever was washing dishes in a restaurant about 40 years ago, back when everything was manual, before cell phones and the Internet. It was only a few weeks before I moved to a food prep station and eventually to a grill. The following years of working in the hospitality industry taught me some of the most valuable lessons of my life. I worked as a waiter, tended bar, pumped gas, rented out jet skis and boats on the beach, and cooked everything from mushroom soup to Chateaubriand and Coquilles Saint-Jacques. After working in kitchens helped pay my way through college, I landed a job as a technician, fixing office equipment in a variety of busy offices where I was exposed to a wide range of business conversations. Mostly, I spoke to people – many, many people. These experiences laid the foundation for the rest of my career working with people, building solutions, and filling people’s needs, something we now call Customer Success.
One very important thing that is key to the role of any CS person is to understand that your job is all about making people successful, not just doing whatever makes them happy. It is even in the title “Customer SUCCESS”. Customers can be blissfully ignorant of features that will make them more productive and you could just let them be happy using your products as is, but eventually, some competitor will come along and show them how to be more successful with their competing product and you will lose that customer – possible over a feature you had but never took the time to demonstrate. But isn’t that “sales”? Hmmm…
You have probably heard the phrase “We are all in sales” and it is true to some degree. While the people with “sales” in their titles are really responsible and tasked with achieving targets, everyone in your company has to take some role in helping in the sale of your product. Similarly, “We are all in customer success”, and similarly, while the people in the Customer Success team are directly responsible for customers being successful, everyone in the company needs to take some role in helping them get there.
Talking to people and genuinely listening is not just a role for Sales and CS, it is critical for Product Managers, Marketers, and Developers as well. But this is really the area where CS leaders shine. A skilled Customer Success Manager, or Solutions Engineer, or Technical Account Manager, or Support Engineer can help a customer ask the right questions and guide them to an effective solution that may or may not include adding a product or changing the way they use a tool. They can probe into how the customer actually operates, and what effect it has on their business, and examine the outcomes that could be possible with a little additional guidance.
The work doesn’t stop at the customer conversation though. A good CS person is all about thought leadership and will take those customer conversations back to Product and Marketing and Sales to further develop them with a wider audience. They are investigators, collaborators, helpers and fixers. They can empathize with their customers but also understand the business drivers for mutual success. Front-line Support Engineers and Technical Account Managers are goldmines of direct customer usage intelligence. Solutions Engineers often hear key data points about what your product does well, but also where it is missing in the competitive landscape. All of them together are the voice of the customer.
So, What it is, really? Customer Success is the function of ensuring your customers are making the best use of your products and services in the most productive way. That may lead to sales or product enhancements, or accolades for your website, but mostly it is about understanding and empathizing with your customers and prospective customers.
Who should do it? Everyone, at least to some degree. If you are not in business to make customers successful with your products, then what is the point? Of course, the answer you were expecting was “The Customer Success Team”, but they are just the tip of the spear. These are your front-line people outside the Sales team who talk to customers and prospects every day. They are the voice of the customer and are key to every product and planning decision your company makes. They hold key intel and manage the relationships that make or break your organization.
How should it be done? So many organizations still try to do this with the Sales team, or volunteers from Engineering, or loosely filtered from the support team. But to truly be successful in today’s world, CS needs to be an official organization driven by a leader with a solid team who are dedicated to the function of making customers successful. That team needs to have clear lines of communication with Product, Marketing, Legal and Finance, and then needs to be empowered and have the autonomy to do what is needed to make customers successful.
Do I have all the answers? Not even close, but I do have had a few decade’s worth of conversations, successes and failures to inform an opinion that has been valid so far.
I have seen this question start popping up again recently and I am actually kind of amazed this is still an issue. The revolution already happened and was accelerated by COVID sending everyone home for two years. The global workforce was forced to figure out how to work remotely and (feign shocked expression) many of them found it productive and don’t want to go back to the office.
This question of “9-5 in the office work dying” is not as simple as just a ‘yes’ or a ‘no’. Every company is different and every person is different. The ideal work environment should offer the flexibility of both. The most efficient company I ever worked for had all of the above.
Many worked 8-4 in the office at a desk Mon-Fri because that is the way they worked best.
Many worked from home 100% and created their own schedule to accommodate family and coworkers. In my case that was sometimes 4 days at 12 hours and other weeks required more or less but I had the flexibility to make my own hours.
Yet others were on a structured 4-day, 10-hour plan in the office 1 day a week because that worked for them and their team.
The answer is really “it depends” and smart companies will evolve to provide a hybrid work environment that allows people to work efficiently. The days of cookie-cutter business models where everyone works the same way are over. Not because any one particular person said so, but because the global workforce was allowed to explore that possibility for two years and the world attitude toward “work” evolved. Business owners need to catch up and evolve if they have not already.
I have heard the argument that some businesses just can’t work that way, that they HAVE to be 9-5 in the office Monday to Friday. I don’t believe that, and I have seen no evidence to support that. Even long-standing traditional institutions like schools, law offices, and banks have changed shape and will need to continue to evolve to support the on-demand world we live in today. Those people who have shifted to some form of remote work and flexible schedule, now want to do their banking on Saturday or speak to a lawyer or doctor at 10PM, when it is convenient for them, as opposed to waiting until 9AM Monday morning.
The concept of “work” and what that means to both business owners and employees continues to evolve. Businesses that want to thrive in this new reality need to evolve with it.
I didn’t know how to set tile before I did it the first time. I didn’t know how to lay flooring before I did it the first time. I didn’t know how to install cabinets before I did it the first time. I didn’t know how to plumb a sink or wire a light switch or install a ceiling fan or hang blinds before I did those things the first time.
By the time we tackled the kitchen in this photo we were on home renovation #5 and had learned from a ton of mistakes. But that is the lesson learned on this journey. Everyone needs to practice and learn before they can be good at a thing. For everything there is a first time.
So be patient with those who report to you, because everyone needs to make a bit of a mess before they can master a thing. Be patient with yourself as you learn new things, because every new task comes with new and unknown challenges.
A very long time ago, I started a new job as a Sales Engineer (SE) at a company that would eventually be a very big deal in its space. I found myself learning new products, processes, and a new industry all at once. Add the fact that my “territory” was HALF THE PLANET, and you can imagine how overwhelming the learning curve was. I knew that to survive this massive influx of information and possibly teach it to others in the future, I would need to document everything, so I started writing.
I wrote down everything from demo conversations to install instructions and HR processes. This grew into flowcharts and lists, gotchas, and guides. Being a relatively young startup, almost all of the information was being shared organically, and there was a ton of tribal knowledge. After about 30 pages of these personal internal notes, it became pretty apparent that this was going to become a “how-to-do-your-job” guide that I would constantly be referring to, so I added a title page – “The SE Survival Guide.”
And it grew, and it grew. By the time we hired our next SE to join the team, there were entire sections in this novella for HR processes, demo activities, and undocumented debugging tricks, so I used it for training material. This is where the story takes a twist. I remember saying, “this is a living document, and it is your responsibility to contribute to it as needed.” That turned out to be incredibly powerful and has been an invaluable lesson in my career. Over the next decade, that document was contributed to by a dozen Sales Engineers and was used as training and reference material by product managers, salespeople, engineers, and implementation teams. Since we all used it, we all owned it and nurtured it.
Empowering teams to manage their documentation proved to be a powerful tool for efficiency. The learning curve is shorter because all the tribal knowledge is actually written down, not passed on verbally. It is easy to look up processes that change periodically. It is highly accessible, so anyone with new information can update it when needed. The team can benefit from fast on-boarding times and fewer knowledge gaps.
Since then, I have used that same concept in many different places – starting with my own notes, then turning them into open docs and sharing responsibility with a team. Notice I said “responsibility”, not just “edit rights”; The phrasing is important. When you share a document with edit rights, there is an understandable assumption that the person that shared it is just asking you to contribute edits. However, it is imperative that when you share a living document, it is clear there is shared ownership and responsibility. That is the key to making it work.
As I now embark on new ventures, I find myself creating new living documentation – one of the things I consider an essential building block of good teams. I look forward to seeing what this next iteration looks like.
Skyscraper Los Angeles Downtown 2013 by Tuxyso / Wikimedia Commons / CC BY-SA 3.0
Recent events in the tech world have made me rethink the way I talk about work. The company you work for is not your family. It won’t be there at your funeral, and it certainly won’t be available to help you move that sofa into your new apartment. It simply can’t because, although a company pays taxes and is allowed to vote (in many regions), it is not a real person and just cannot be “family”. The arguable definition of a company is to be a vehicle to generate profits for shareholders, not to hand out free hugs and make sure the vending machine is full for you.
The people you work with, on the other hand – your team, your clan, your tribe – can definitely be considered extended family. There are many people I have worked with over the past several years that I consider extensions of my family. The recent layoffs that separated us from our daily meetings and reporting responsibilities have not changed the fact that I still enjoy seeing that picture your kid drew this morning. I think the mass layoff events of 2022 and 2023 are a good reminder that the financial vehicle that is a company is populated with real people who build ties, form bonds, and create the bedrock that a company stands on, but they are not one and the same.
I have been guilty of conflating these myself.
“Welcome to the family”
“We are all family here”
“Sorry to see you leave our little family”
Of course, I knew these were different, and I intended this to mean “our team”, not “the corporate entity”, but in practice, the meanings get mangled, and they should not. This term “family” has become pervasive in corporate culture, and while it may be nice from an HR and talent marketing point of view, it is a misnomer at best.
Companies are made up of groups of people who may or may not get along together, but with some effort, they can gel to become a productive group of humans. If you are lucky enough to work with a group of people who share a common passion and also enjoy sharing or discussing off-hours interests to the point you become actual friends, hold on to that. When the company you work for needs to make staff adjustments, your feelings will likely not be a factor. Your friendships and the coworkers you invite to become extended family are invaluable.
TBT: circa 1976 It doesn’t look like much, but this was the first rocket I ever built. From a materials point of view, it was just cardboard and balsa and glue, but it represents so much more. From my earliest memories, I wanted to be an astronaut and for almost as long, I remember people telling me it was an impossible dream.
In spite of the naysayers, I persisted. I built rockets and learned the science required to launch a thing into the atmosphere and beyond. I taught myself how to handle rocket motors, align stabilizers, and pack parachutes. I calculated trajectories, planning to miss the residential properties around the launch facility school field. I was ten.
Today, I am not an astronaut, but it was not for lack of trying. Ignoring those who flat-out told me to stop wasting my time was absolutely the right decision. The lessons I learned about flow mechanics, construction techniques, the need for precision, and the value of math were immeasurable. Failure is a brilliant teacher. The benefits of focus and persistence cannot be overstated.
If you have a dream, a vision, or an idea that just won’t let go, pursue it. Ignore those people who don’t understand where your path is leading. You may not actually hit your goal, but you will learn a great deal about your target and yourself in the process.
Family, friends, and friends I consider family. That is what this season is all about. That is ALL it is about. The presents, music, travel, the boxes and ribbons, and bows are meaningless without the people you care for. This year, in particular, I see that truth with a fresh perspective.
In the last 60 days, I have lost an uncle who was both teacher and guide, a father who taught me more than he ever knew, and a job that was so much more than just a “job”. I should be drowning in grief. I should be lying in bed under the covers in the dark, waiting for the next shoe to drop. But, instead, I am writing. I am planning my next move. I am taking immense pleasure in spending valuable time with people I could lose at any moment. Carpe Diem.
Dr. Seuss was right. Christmas does not come in packages, boxes, and bags. It radiates from the hearts of people who care about each other. This time of year, the feeling is amplified, but it is there all year long. It connects people regardless of their genetics or status. That is the genuine care family and friends have for each other. We just let it sing a little louder in December.
“And the Grinch, with his Grinch-feet ice cold in the snow, stood puzzling and puzzling, how could it be so? It came without ribbons. It came without tags. It came without packages, boxes or bags. And he puzzled and puzzled ’till his puzzler was sore. Then the Grinch thought of something he hadn’t before. What if Christmas, he thought, doesn’t come from a store. What if Christmas, perhaps, means a little bit more.”
– Dr. Seuss, How the Grinch Stole Christmas!
So I find myself thinking more about my cousins and coworkers than I usually would, even at Christmas. I’ve doubled down on charitable donations, regardless of the lack of employment. For the first time in many years, I am able to spend valuable hours with family at the skating rink, or playing board games, or testing recent gifts, as opposed to worrying about work projects.
Charles Dickens’ personification of the Ghost of Christmas Present has been ringing in my head for many days. “Come in! and know me better, man!”. With all that has happened in the last few months, I am acutely aware that it could be worse. Others are less fortunate, need support, and perceive no one to care for them.
“Come in!” exclaimed the Ghost. “Come in! and know me better, man!”
Scrooge entered timidly, and hung his head before this Spirit. He was not the dogged Scrooge he had been; and, though the Spirit’s eyes were clear and kind, he did not like to meet them.
“I am the Ghost of Christmas Present,” said the Spirit. “Look upon me!”
– Charles Dickens. A Christmas Carol.
I am awash in the bounty of friends and family who care and send warm thoughts and hugs and will just listen.
I extend warm wishes to you, my friends, family and friends I consider family. May you have a peaceful winter holiday season and a prosperous new year ahead of you.
In August 2008 (I am pretty sure it was a Thursday), my good friend 🚚 Mike Hillyer reached out and told me about this small startup he had joined that was going to change the way people communicate, but he needed help explaining and deploying it for customers. He introduced me to founder George Schlossnagle, who quickly became another good friend. George had a vision of a robust messaging platform that would enable a service to reach millions of customers in mere minutes anywhere and provide deep data and reliability. I got it immediately, bought into the vision, and never looked back.
The 14-year road to this point has been an absolute blast. There have been so many unforgettable events with icons of the #email industry. It will be a long time before people forget the San Diego conferences or the lasting bonds we forged there. I am thankful to have been associated with absolutely brilliant creators like Wez Furlong, John Peacock, and so many others who built messaging magic way ahead of the industry curve. Together we not only built an awesome place to work, but we also helped make the email industry better and improve the lives of so many people. Aside from the direct product work, the amazing minds here contributed to security, anti-abuse, and community projects you may never be aware of, but your personal inbox is a safer place today because of the work this team contributed to.
A self-proclaimed “lifer”, I never expected to leave this company I helped to build, but this week it happened as part of this event. Sad as I am now, I take a great deal of solace in knowing I have been blessed to work with amazing leaders and incredible humans who worked to build much more than a company and a product. We built a very special community of people who really did change the world for the better. I will miss working with the likes of Scott Habicht, April Mullen, Kieran Cooper, Katie Rose, Harold Vass, Casey Martin, Hal Muchnick, … way too many incredible people to list here – many of whom are on this list.
There are so many people to thank for their impact on me during my time with MessageSystems / Sparkpost / Messagebird that it would fill a book, so I will save you the list and know that they know who they are. I would be remiss, though, if I did not specifically mention Steve Tuck and Darren Smith for helping me build the latest version of the Solutions Team, which continuously pushed the envelope, improved customer deployments, and raised the bar every single day.
At the risk of dating myself and inviting ageism, I’ll share with you that I am celebrating a strange anniversary. I just realized that I wrote my first useful code 42 years ago; It looked something like this:
FOR X = 1 TO 10000 LPRINT "I will not talk in class." NEXT X
My apologies to the eighth-grade teacher who received a stack of tractor-feed printer paper on his desk the next morning.
In 1980, the Tandy TRS-80 and its BASIC programing language were my creative escape and a way to explore automation in a way that had not been available before. I know you are probably thinking this was the path to a software career, but you would be wrong. I was far more interested in the hardware, and what I could make it do in the physical world.
The programming was a piece of cake – I had mastered BASIC in only a few days and moved on to Macro Assembler (MASM) to see what I could make the processor do directly. I started and failed my first computer sales and service business in the following years.
When I moved on to college a few years later, it was for the Electronic Engineering space, not software. Getting a VAX or PDP minicomputer to do anything useful meant Assembly, COBOL, or C and frankly, waiting around for hours to get a time-slice of access on a VT-100 terminal. Running Pascal on the relatively new IBM PC’s was a little easier, but in general, writing code was a pain back then and hard wiring a circuit board was easier and more satisfying.
After graduating from college (the first time) in 1987, my tech world was largely embedded controllers, C, and Assembler. ARPANET and BBSs were the disjointed glue connecting people together, and software was still primarily only available on physical media or painfully slow downloads. In those next few years, I wrote several small utility applications with MASM, C, and Perl, but distribution and tracking were always an issue. Then the Internet was born, and 1990 was the beginning of a whole new ball game.
Fast forward to 1994 and the start of yet another business. I was learning to bend Visual Basic and C++ to my will, this new thing called the Internet had replaced ARPANET and the world was going crazy with the ability to build Internet-connected applications. By 1996, the rest of the world was finally realizing the Internet was a real thing as I was launching my first web application, the Aasland Office. Sadly, the masses were not yet ready for a fully remote workspace until Google tackled it nearly a decade later.
The side effect of the Aasland Office work was a number of small web applications and a very successful custom software business creating “smart websites” for savvy customers. Perl’s Common Gateway Interface (CGI) capability empowered my world (Thanks Larry) and resulted in some powerful inventory control and data search tools that paid my bills for many years.
My desire to focus on hardware and automation lead me back to school, but all the hardware needs software, so I was again deep into C, C++, C#, Assembler, PHP, Matlab, Lisp, and Java. The world had changed considerably by 2005 though and there was a constant stream of requests for “Active Pages” and web applications. The tools had matured and this concept of a “Tech Stack” was starting to take shape. I’m not sure when I first said the words LAMP STACK, but I know I had been using Linux, Apache, MySQL, Perl and PHP together for several years prior to it being a “thing”.
The work I do now at the leading edge of the digital communications frontier requires some extreme flexibility and agile thinking. Languages like Lua, Go, Rust, and NodeJS are just as likely as PHP and Python to appear in a customer deployment. There are multiple tech stacks to consider and the API revolution has introduced a whole new element of foreign system security and connectivity to consider while writing applications.
Back in 1980, when I was writing that 3 lines of Basic to annoy my teacher, I imagined a future where computers would be in every home, tiny ones would be strapped to your wrist, and embedded ones would be helping to automate daily routine tasks. But the reality of today’s integrated infrastructure has surpassed even my overly zealous imagination. As I celebrate this strange code-iversary, I am incredibly excited to watch as new tech develops, how my children adopt and adapt it to their lives and how we embed it to empower a better world.
The Bleeding Edge 