We’re technically leaving the world of soft skills now, but moving on to skills and knowledge that will still be of benefit to any technologist looking to create a more successful career. The world of business—and that includes nonprofit businesses and many government organizations—has its own language and its own mathematics. If you’re going to play the business game for your livelihood, it can be an immense help to understand a bit about how businesses talk about themselves, how they measure themselves, and how they handle their internal math.

I’ll note that this chapter does gloss over many of the fine details of the topics I’m covering in an attempt to better convey the high-level importance of these terms and concepts. Consider this to be just a starting point, and you should definitely think about exploring these topics in more detail as you flesh out the skills you need to succeed in your career.

20.1 How much do you cost?

After many years in the working world, I have come to the conclusion that the most valuable piece of information I can have as an employee is knowing how much I cost the company. (When possible, I like to know how much everyone else costs too, and not just because I have salary jealousy—kidding!)

Here’s why: let’s say I spend a hundred hours, over the course of a couple of months, working on a project that will automate some important business process. I might wonder, was I right to spend that time? Did I spend too much? Could I have spent more? Should the company be thankful? How thankful? Knowing what I cost the company can help me answer these questions.

Let’s say I make a salary of $100,000 (I like easy numbers for this explanation). My actual cost to the company is much higher: in the United States, the company has to pay payroll taxes (those are on top of the income taxes withheld from my check that I pay) too. They also cover my healthcare, contribute to my 401(k) retirement plan, and cover the cost of stock options and other benefits. My existence as an employee, along with my fellow employees, also requires the company to employ Human Resources staff and pay for other overhead costs,. To account for all this, most companies in the United States add about 40% to the base salary, which means I’m actually costing about $140,000 a year as a “fully loaded” salary. Fully loaded refers to the base salary I see on my paystub, plus all the employer-paid taxes, benefits, and similar costs.

There are roughly 2,000 working hours in the year. Again, that’s a United States-specific number. Here’s how I figure it:

• There are 52 weeks in the year.

• Most employees have two weeks paid vacation, so that leaves 50 weeks.

• Most US companies observe about five paid holidays like Christmas, so that leaves 49 weeks.

• There are about 40 official hours per work week: 40 hours x 49 weeks = 1,960 hours, which we can round up to 2,000.

So dividing my fully-loaded salary of $140,000 by around 2,000 hours, I get an hourly fully loaded rate of $70. That’s what I cost the company per hour.

Now, going back to my automation project, at $70 per hour, this means my 100-hour time investment cost the company about $7,000, plus the cost of however much coffee I drank during that time, the cost of the electricity I used, and other overhead that’s too complex to go into. So was the investment of my time worth it?

That all depends on the return the investment creates. Let’s say the business process I automated had formerly been done by an entry-level help desk person, who spent about 10 hours a week doing that task. They make a base salary of $50,000, or a fully-loaded hourly rate of $35. Doing the task manually therefore costs $350 a week, which means we’ll recoup my $7,000 investment in 20 weeks—about five months. That seems like a pretty solid return on investment: after 12 total months, the company will have saved $11,200 in time.

Put that in your résumé When you create savings like that, track it. That’s solid résumé material: “Saved previous employer $20,200 annually through a $7,000 one-time investment in automation.”

I find it incredibly helpful to do this kind of calculation. First, it helps me make smarter business decisions, such as where should I spend my time and what projects make fiscal sense for the company. It helps me better communicate the value I bring to the company, in terms that the company itself understands and can relate to.

What about what other people cost? Many companies don’t publicly share peoples’ salaries, so it can be difficult to calculate costs across a team. In those cases, you can sometimes work with your Human Resources and/or Finance departments to get a “model salary.” That won’t represent what any one person gets paid, but rather an average or other “generic” salary that you can use for calculations.

20.2 Reading a P&L statement

A Profit & Loss Statement, or P&L, is one of the high-level tools that you can use to understand a business’ finances—and often, its most basic motives. Now, I want to once again point out that I’m going to be really glossing over some fine-print details in my explanation of these things. This isn’t intended to be a CPA-quality explanation; it’s meant as an orientation.

A P&L can tell you a lot about a business. So much that most businesses don’t want them floating around in public (and publicly traded companies often aren’t allowed to share them broadly outside of certain legally specified engagements). Even a high-level P&L will show you where most of the company’s revenue comes from, and where most of it is spent (payroll is often an enormous percentage of the overall expenses). A detailed P&L can reveal much more, and help you truly understand how a company runs.

It’s worth asking if your company is allowed to share a high-level P&L with employees. If it is, consider showing an interest and reviewing it. You’ll often run across stuff that doesn’t seem to make sense, and that’s where you can truly dig into the details that a company deals with. You can see an example P&L statement for a fictitious company in figure 20.1.

Figure 20.1 An example P&L statement showing revenue, costs, and expenses

Every business does these a little differently, but broadly speaking, the top section will usually include what I call the Good News. That is, revenue.

20.2.1 Revenue

At the top of every P&L statement is the company’s income, which includes revenue. Other types of income can include interest earned from bank savings accounts, but revenue is the big deal because it’s the money you make from actually running the business.

You first want to understand if the company operates on a cash basis or accrual basis. Sometimes the P&L will state that (my example doesn’t), while at other times you’ll need to ask someone in company leadership. Most small companies use a cash basis, which means that the cash they have in-hand is real cash and counts toward revenue, and the expenses they’ve paid are actual settled pay-outs of cash, and count as expenses. This is how every private household operates, and it’s the easiest to understand.

Accrual basis is a little more complicated, and it’s what most big companies use because it gives a more well-rounded picture of a company’s financial health. Something counts as revenue when you’ve invoiced for it, or billed for it, even if you haven’t gotten the cash yet. Something’s an expense when you receive an invoice or bill for it, even if you’ve not yet paid it. Basically, cash basis means you count the actual cash and expenses that have occurred in a given time period, while accrual counts actual plus expected income and expenses.

So who cares about cash versus accrual? It can make a big difference on things like taxes. When a cash-basis company receives an invoice from a vendor, it doesn’t “count” until the invoice is actually paid. If you receive an invoice at the end of one tax year, but don’t pay it until the next one, then you can’t deduct the expense from the prior year—it’s deducted in the year in which the expense is actually paid. That’s why a lot of cash-basis companies rush to pay invoices at the end of the year. Accrual-basis companies are the opposite: they often rush to get invoices at the end of the year so they can deduct the expense, but don’t pay them until the next year—which can sometimes frustrate the people who sent those invoices!

There are different types of revenue, too. The most common one is ordinary income. This is, quite simply, the revenue you make from most forms of business, where you sell a product or perform a service and then get paid for it.

Percentages vs. actual amounts In figure 20.1, you’ll notice that I have a big arrow pointing down over the “% of income” column. For many businesses, these percentages matter more than the actual monetary values. For example, payroll in this example is 26.3% of income, making it the single largest expense. If you needed to reduce expenses, that big chunk might be a first place to look.

Subscription income is a bit different. Let’s say you run a service that charges $10 a month, but you actually bill for it a year at a time. So you’ve sent a $120 bill to a customer, and they’ve paid it. You can’t actually “recognize” all $120 of that as revenue as soon as you get it; instead, you have to recognize $10 per month, because that’s what you’re actually earning. This is all due to a set of rules called the Generally Acceptable Accounting Practices, or GAAP.

Cost of Goods Sold, or COGS, is another form of revenue, and often shows in the Good News, or revenue, section of the P&L. COGS itself is a bit complicated to explain. Let’s say you buy a few thousand small, empty cans, and a few tons of raw nuts. Your company then fills the cans with raw nuts and sells the completed package. Both the cost of the nuts and the cost of the cans are COGS, or “the cost you need to incur to sell the goods that you sell.”

From a tax perspective, you can’t write off those costs until you’ve completed the accompanying sale. So if you sell half the nuts in the year you bought them, then you could write off half the cost of nuts and cans in that same year, and you pay taxes on the rest. If you sold the rest the next year, then you couldn’t claim those expenses until that year. This is why some companies hate inventory so much: you’re basically paying income tax on the money you used to buy the inventory until you actually sell it. It’s why car dealers have end-of-year blowout sales—so they can sell the inventory and write off the costs.

Many companies have other kinds of income, such as interest on bank accounts or investments, recovered debts, and the like. It should all show on the P&L in the revenue section.

All of a company's revenue, minus the cost of whatever it sold, results in its gross profit, and this total is also listed on a P&L. So if a business spent $1 million on nuts and cans, sold them all in a year, and generated $2 million in revenue, it would have $1 million in gross profit, and a 50% gross profit margin, or gross margin. Most industries have more-or-less standard gross margin goals, and it’s one way to compare your basic profitability with your industry peers.

20.2.2 Expenses

Next is the Bad News section, or Expenses. This is money a company spent aside from the cost of the goods you sold. This includes advertising, payroll, taxes, office supplies, and pretty much every other penny it spent. This also usually includes discounts they’ve offered to customers, which is why so many CEOs hate discounts: they’re like this vast negative number on the “bottom line,” right before you find out if you’re bankrupt or not.

Gross profit, minus total expenses, is your net profit or net loss, which is where a P&L gets its name. Again, most industries have benchmarks for their net profit margin (expressed as a percentage), and most companies try to meet or beat their industry norm.

Take Apple. In 2007, they introduced both the first iPhone and the first iPod Touch. Both devices ran iOS v1.0, but when Apple released the first iOS update, iPhone users got it for free, while iPod Touch users had to pay $20 or so. How come?

At the time, Apple was getting monthly payments from AT&T, and so there was a small amount of monthly revenue attributed to each iPhone. Apple could say that the iPhone was complete as initially shipped, and that the monthly incremental revenue was what paid for the subsequent “improvements” in the form of a new iOS.

But they couldn’t say that with the iPod Touch because they’d charged full price for it up front. Releasing an “improvement” meant that they’d increased the value of the product, which meant having to go back and restate all their revenue. Much like on a subscription service, they couldn’t claim that the original $250 or whatever was all revenue when the product wasn’t “complete” at the initial release; some of the “new value” from a new version of iOS would have to correspond to revenue. To simplify the bookkeeping, they just charged for the update so that the update was “paid for” by its own revenue.

It was a few years before Apple revised the way they handle bookkeeping and how they attribute revenue so that they didn’t have to do that anymore. A glance at their earlier P&Ls would have revealed the oddity and driven questions that revealed all those interesting behind-the-scenes details.

20.3 Averages

Averages are useful things in lots of pursuits, and business is certainly one of them. But people often misunderstand averages. I once read an article about men’s razor blades. The reporter asked a representative of Gillette how long, on average, a blade lasts. The person’s reply was along the lines of, “Well, everyone is so different that an average isn’t meaningful.” Which will come as a huge surprise to every statistician ever because that’s the whole point of averages.

There are actually three kinds of averages. Each of these seeks to take a set of numbers and come up with a “middle ground” that represents the entire group. A mean does that by adding up all the numbers and dividing by the quantity of those numbers. Also called the arithmetic average, it’s the one most people are thinking of when they say “average.” Its downside is that it can be artificially dragged one way or another by outlier values. You might have 99 values at 50, for example, and 1 at 7,000,000. That’s a mean of over 70,000, but 70,000 is in no way representative of a group of numbers that are mostly at 50. So in looking at averages, you really need to look at the underlying data to understand how many of the values are actually clustered around the mean.

The median is the middle point of a sample, where half your values are above the middle and half are below. This is good for finding a literal “middle ground.” It’s actually a bit better of a value than the mean for a lot of business situations because it automatically takes outliers into account. It does diminish those outliers, though, because a far-flung outlier value won’t “move” the median any more than a “closer-in” outlier.

The mode is simply the most common number in the sample set. In a set with 1, 2, 2, 3, 4, 5, 6, and 7, the mode is 2, because that’s the most common sample value. So when might you care about averages, from a business perspective?

• If you’re looking at developer productivity, you may look at metrics such as number of code commits where all unit tests passed. Obviously, different developers are going to have different levels of productivity, in part depending on the type of project they’re working on. A median can be useful for getting an idea of where the entire organization sits as a whole. You can then look “above and below the line,” that is, above and below the median, to start understanding why those numbers are what they are.

• If you’re looking at server uptime, you might look at the mode of the number of days a given server is up or down within a specified time period, like a month. If the most common number of “up days” in a month is 28, you could then focus on servers with less up time to understand why they’re different.

• If you’re looking broadly across the organization and wanted to measure the average amount of paid time off people are taking, you could look at an arithmetic average. In most organizations, paid time off won’t have a lot of outliers, and so a mean and a median might be close. And of course, you could look at both the mean and median, and if they differ greatly, you’d know that you probably have some outliers to consider.

There’s a fun book called How to Lie with Statistics, by Darrell Huff (W.W. Norton & Company, 2010), that I recommend. It’s a great look at how people bend numbers and psychology, and can make you a lot smarter at business math.

20.4 OpEx and CapEx

Broadly speaking, businesses incur two types of expenses: operational expenses, or OpEx, and capital expenses, or CapEx. Understanding how each of these works, and how your company approaches them, will give you some insights into some of the business decisions your company makes.

20.4.1 Understanding the two types of expenses

Operational expenses are recurring expenses that are required in order to run your business: rent, payroll, utilities, recurring services you purchase from vendors, and so on. Operational expenses do not increase the value of your company. For example, just because you double your payroll doesn’t mean you double the value of the company. By doubling your payroll, I would presume you hope to double (or more) the output of whatever your company does, and that might increase the overall value of the company.

Capital expenses are either one-time expenses, or expenses that are paid for over a fixed number of payments. Buying new machinery (like computers!), building a building, or buying another company would all be capital expenses. These generally increase the value of your company by whatever the new capital investment is worth. That is, if you spend $1 million building a new warehouse, then presumably your company is worth $1 million more, because in theory you could always sell the building, converting that asset to cash.

Companies often pay for big capital expenditures by taking out a loan. In that case, the principal of the loan is a capital investment, while the servicing of the loan—that is, the interest you pay on it—is an operational expense.

Different companies feel differently about OpEx and CapEx, and their feelings are often driven by the industry they’re in. For example, a small technology startup might prefer to make as many expenses as possible OpEx: they’d rent office space rather than build it, and they’d deploy their services to cloud providers rather than building a data center and buying their own servers. That approach might cost them more money in the very long run, but in the short term it helps them control their cash burn, or the rate at which they spend their investors’ money. Spending $10,000 a month on office rent lets you spread the expense out, versus spending $1 million all at once to build a new building.

Tax laws can also drive a company’s approach to OpEx and CapEx. For example, in the United States the Internal Revenue Service (the federal tax agency) requires companies to depreciate durable goods. Computer equipment is generally depreciated for five years, for example, and office furniture for ten years. That means if you spend $100,000 on computer equipment—a capital expense—you can’t write that all off on the company’s taxes in the first year. Instead, you write off 1/5th of that amount, or $20,000, on your taxes for each of five years.

Problem is, computers don’t always actually last for five years, so you’re stuck depreciating a piece of obsolete equipment. I worked for one company that got around the problem by leasing their laptop and desktop computers for three years—a far more realistic time frame for the equipment to remain usable. That converted the CapEx into an OpEx, since rent is an operational expense. When the lease was up, the manufacturer refurbished the machines and sold them to someone else, and brought my company a semi truck filled with brand-new computers on a new three-year lease.

20.4.2 Driving business decisions

Understanding how OpEx and CapEx work, and how your company feels about them, can help explain a great many financial decisions. For example, it might seem weird to have your CEO tell you that the company is going to slow down hiring to preserve cash, and then turn around and announce an $80 million acquisition of another company. What gives?

Payroll is an operational expense. Broadly speaking, companies don’t take out loans to pay for operational expenses. That’s because OpEx doesn’t increase the company’s value. If you have a $1 million annual payroll, and you take out a loan to pay that, you might wind up paying $1,250,000 by the time you factor in interest on the loan. So you paid 25% more than your actual payroll, and didn’t increase the value of the company at all. Your investors will not be amused.

Mergers and acquisitions are usually capital expenses. Rather than spending on-hand cash, you could take out a loan for that $80 million, and pay it off over a couple of decades. Investors are fine with that, because you’re increasing the value of the company by $80 million or more at the same time. The actual $80 million is a “wash,” in other words; you’re turning cash into a new non-cash asset. The operational expense involved—the interest on the loan—is the “price of doing business” to increase the company’s value, and you’d normally expect to see the company use the new acquisition to increase overall company revenue, thus offsetting the operational cost of the acquisition.

Today, especially with regard to technology expenses, most companies are moving as much as they can to OpEx—meaning they’re hosting software in the cloud, rather than on their own data centers. That can let them lower other OpEx (like the salaries of the people they paid to maintain their own data center), and potentially convert CapEx to cash (like selling the building the data center was in).

OpEx can sometimes also enable a company to scale faster and more granularly. For example, one dot-com I worked with ran its entire website on three servers that we owned. When we were about to get a big marketing push on a daytime television show, our CEO asked if the server “farm” could handle the load. “No way,” we told him. He asked if we could increase the site’s capacity. “Sure,” we said, “but it’s going to cost like $40,000 in hardware and take a month to put in place.” We didn’t have the $40,000 to spend, unfortunately—that’s a big CapEx for a small startup. Today, we’d just scale out our Azure or AWS assets by pushing a button, pay a little bit of additional OpEx for the duration of the increased load, and then scale back when things die down, reducing our OpEx.

20.5 Business architecture

Business architecture refers to how a business is structured to get its work done. This may seem a bit esoteric, but I find it fascinating, as well as helpful in understanding the internal framework of a company and how it drives a company’s behavior. There are many different ways to express this architecture, but my personal favorite is the approach that uses the concepts of functions, services, and capabilities. Many people use these terms, along with others, as if they’re interchangeable, but in the real deep-thinking world of business design, they each have a distinct and vital meaning.

Perhaps the most granular level is a capability. A capability is a set of tasks that someone, or some group, within the company can do. Capabilities can include things like loading boxes onto a truck, processing the data needed to underwrite a loan, booking a hotel room, and so on. On their own, most capabilities aren’t things you could sell directly. For instance, being able to make a good hamburger is an excellent capability, but you can’t make a restaurant out of that one capability. You also need to be able to take an order for one, accept payment for it, clean the table when the customer leaves, and so on; those are all distinct capabilities.

Figure 20.2 Business capabilities are the granular things a business can do.

A business function could be defined as an outcome, such as an element of a product or a service, which a customer might want. Consider a fast food menu: it might include an item like a burger, which a customer wants. But the burger gets broken down a bit with options that the customer cares about: meat temperature, toppings, bun type, and so on. Those options are functions. In a more business-y example, consider a customer that wants to ship a package. They take it to a shipper, and “shipping a package” is a capability of that shipper. Within that capability are functions like shipping speed, ability to go to specific destinations, ability to handle certain package sizes, and so on. You can’t just have a business that offers “ketchup as a topping”: that topping is merely a function of a business capability.

Figure 20.3 Business functions are outcomes that a customer might want.

Internally, services combine capabilities, usually in a specific order as defined by a process, to help fulfill the promise the functions have made to customers. Shipping a domestic package is a service: it requires specific capabilities, like calculating a cost, selecting a form of transportation, planning the logistics, and executing the actual movement of packages, and it requires that you perform those capabilities in a particular order.

Figure 20.4 Business services are collections of capabilities.

The business process defines the order in which those capabilities happen. So capabilities, executed in a specific process, create a service; services usually correspond to functions so that when a customer orders a function, the service executes and the customer is served.

Figure 20.5 A business process assembles capabilities into a sequence that leads to an outcome.

It is also possible, and quite common, for higher-level processes to exist, which themselves consist of distinct services that are executed in a particular sequence. A service, in this case, is some standalone, self-contained set of capabilities that may be called upon by multiple processes. For example, a “clean-up” service might be called upon by multiple different processes, including processes like “respond to spilled beverage on aisle 4” and “respond to severed limb on the loading dock.” Those processes might include other services as well, such as “call an ambulance.”

So a process can consist of more than one service, and each service can have, within it, its own processes for accomplishing that specific service. Functions—because they’re an abstract, customer-facing definition of something the business offers—can often serve as a clue to what an organization’s org chart should look like. I’ve often said that customers should be able to infer at least the top layers of a business’ org chart simply based on what the business appears to sell. In a Las Vegas casino-hotel, for example, I would expect top-level org chart divisions to include things like Hotel Operations, Gaming, Entertainment, Food & Beverage, and so on. If I were to find a resort whose org chart didn’t basically line up with that, then I’d expect that resort to operate inefficiently and to have a difficult time providing customers with a great product. If your functions—your menu of offerings—are what you sell, then almost by definition your org chart should be designed to facilitate the delivery of those corresponding services. If you want the short version:

• Functions are an abstract, customer-facing definition. The only thing they call upon are processes.

• Processes combine services in a specific sequence to deliver on a function.

• Services combine capabilities, usually executed according to their own internal process.

• Capabilities are the granular, individual tasks that, collectively, make things happen.

All of this implies a level of modularity. A well-designed service can be used across high-level business processes. For example, if your company has four different departments that ship things to customers, they should ideally all be using the same internal service to do so. If they’re not, you’re likely less efficient than you could be, and you’re probably wasting time, money, and effort, as well as creating inconsistent outcomes for customers. That is why “business architecture” is a thing: analyzing a business to understand where unnecessary service duplication exists (which happens all the time in companies that have grown organically) and deliberately architecting the situation into a more efficient and consistent model.

I fully acknowledge you’ll see other definitions for these terms, but by and large, the most common ones align roughly with what I’ve described here. Even if your business uses these terms or others somewhat differently, just understanding that there is a structure to these things can make it easier to learn the structure of your business. The “rightness” or “wrongness” of how I’ve used these terms should be less critical to you personally than knowing that they are essential terms that relate to essential concepts of business.

So what’s all this mean to you? If I make pizza for a pizza shop, I should understand actually how my capability contributes to the services my business executes, and I should understand the processes in which my capabilities are performed. I should understand how the corresponding functions are presented to our customers. I should, in other words, start by reading the menu customers see. I should understand the process of how the kitchen works. All of that information helps me to understand the full context of my job and helps me make sure I can perform it smoothly. I should understand that changing how I perform my capability will impact other people who perform other capabilities within the same processes that I do: sticking a pizza in the oven at the wrong time is going to disrupt the entire down-chain process, resulting in a lousy delivery to the customer. My pizza-making service, combining as it does capabilities like dough-making, topping-applying, and cooking, is a service that should be consistently usable by multiple processes, such as “make pizzas to sell by the slice,” “make pizzas for dine-in customers,” and “make pizzas for delivery.” The function “order a pizza,” which is what customers see, can then call on any of those processes as appropriate, knowing that the outcome will be consistent.

20.6 Further reading

• Business Mathematics, 12th ed., Gary Clendenen, Stanley A. Salzman, and Charles D. Miller (Pearson, 2018)

• How to Lie with Statistics, by Darrell Huff (W. W. Norton & Company, 1993)

20.7 Action items

• Calculate the hourly cost of yourself in fully loaded terms. Ask your manager, or even your company’s Finance team, what multiplier they typically use to calculate fully loaded salaries.

• Can you think of an activity that you and your team perform on a regular basis that is overly cost-consuming? That might be working with a difficult source-control system, unnecessarily rebuilding servers, troubleshooting DNS problems, or some other technical activity. How much would be saved per year, based on the fully loaded salaries of the individuals involved, if those activities could be made to consume less time?

• Thinking about functions, processes, services, and capabilities, what is your team responsible for? What about the larger department that contains your team? What about your company as a whole? It can often be helpful to understand how a company’s services, for example, boil down to the functions of your particular team. That understanding can make it easier to understand your specific impact on company-level outcomes.

• What are some of the OpEx and CapEx expenses your company experiences on a regular basis? (Hint: payroll is an OpEx.) What CapEx expenses could be shifted to OpEx, if the company had a desire to do so?