The role of CIO requires its own set of tools and skills. Personal Kanban boards, a business model canvas, and the enterprise application portfolio are just a few tools of the trade for CIOs. Getting your hands on these artifacts means informed decision making and data-driven conversations with stakeholders.
During your initial ramp as a new IT executive, much of your information assimilation takes place via unstructured information exchanges. A conversation here, a whiteboard sketch there. Of course there’s nothing wrong with spontaneous information exchange, except for the fact that reusing such information is challenging. While some information may be stored digitally, much of the content is in your head. And what happens when you need to share that information with a new IT leader or business counterpart? You guessed it: more meetings and more unstructured conversations!
Before going any further, I feel obligated to inform you that some of these frameworks can get a tad weedy. Many of these tools and approaches have a traceable lineage into the worlds of enterprise architecture (EA) and business systems analysis (BSA). Fortunately I’ve trimmed the fat, leaving an optimized version of these frameworks which offer the most bang for the buck. Nonetheless, I recommend delegating the work of populating these artifacts to your copilot, enterprise architect, or business analyst.
Table Stakes Tooling
Before jumping into the more methodical decision-making utilities, there are two simple tools you need straight away. I’m taking day-1 priority here. These are your personal kanban board, and organizational charts.
Your Personal Kanban Board
We all know what it means to drink from the firehose during your first few weeks in a new role. That torrent of information will ultimately turn into action items, so where will you store and prioritize these tasks?
An excellent choice for organizing your personal action items is the kanban board. It’s essentially a columnar group of tasks, organized by state of execution. A kanban board not only prevents you from forgetting tasks, but it lends a visually appealing way to visualize the work to be done, current work in flight, and what’s already been accomplished.
Many of us tend to focus on the work in front of us versus the work we’ve already accomplished. It’s been scientifically proven that reflecting on accomplishments is beneficial to both confidence and general well-being. However, there’s a more operational motive for accounting of accomplishments: reporting to your leadership.
Your accomplishments are gold, and you never want to forget even a single one. So abandon the idea of committing tasks to memory and start recording them in your kanban board. It’s ridiculously easy to manage tasks on a kanban board, it’s surprisingly satisfying to move items to the “done” column. I myself am routinely surprised at the volume of my own achievements when I catalog each and every one.
One of the basic principles of a kanban board is to set a work in progress (“WIP”) limit. The idea here is to avoid the perils of context switching and attention diffusion by working on too many things at once. Every executive will have their own limit, but a reasonable WIP limit may be between 2-6 as shown below:
The wonderful thing about kanban boards is their simplicity. They can be built with practically any tool, including simple diagram tools (Google Slides, Lucidchart, etc) or via more intelligent solutions such as Trello or Smartsheet. The goal here is to choose whatever application is already available within the enterprise and build your board as soon as possible as you can always retool later. As this is your personal work management dashboard, it should be shared with your copilot, administrative assistant, chief of staff, and so on.
Organizational Charts
The value of obtaining the organizational chart should be self-explanatory, but in essence, you want to know “who’s who in the zoo” as we often say. But here’s the dirty little secret about org charts: there isn’t just one. There’s the official organization chart, and there’s the highly elusive (and much more valuable) unofficial one. Allow me to explain the differences.
The official org chart is the familiar reporting hierarchy that lives in your HR system, be it Workday, SuccessFactors or Oracle HCM for example. It’s the interactive org chart you can zoom-in and out of. It allows you to see your boss, your boss’s boss, and peer hierarchies as shown below:
The official org chart should only take a few minutes to find, and provides useful pointers for exploring the organization and finding counterparts. The official org chart does a fine job of painting the picture of reporting structure, but falls short on articulating functional coverage across the enterprise.
The unofficial organization chart, on the other hand, may take months or even years to fully understand. The difference between reporting hierarchies and how the enterprise truly operates are often vastly different as shown below:
Assuming you’ve seen your fair share of organizational structures, you’ll know the figure above is relatively simple compared to what you may have seen in the wild. Agile pods, cross functional teams, and dotted lines of reporting are just a few phenomena we see in the immensely complex modern organizations of today.
No matter how complex the true organizational structure looks, understanding the connective corporate tissue is imperative for a horizontal function like IT; especially when the goal of IT executives is to be perceived as business partners. How functions work together is the catalyst that drives initiatives which fall squarely within IT’s wheelhouse; initiatives such as data integration and governance, business process automation, information security, and countless others.
Although unofficial org charts are exceptionally useful, the truth is, they’re also exceptionally difficult to create and maintain. The process I’ve employed with sufficient success is to commence the first pass using a summary view of the official org chart. Then, over the course of many meetings and numerous org change announcement emails, the unofficial org chart takes shape.
While nascent process mining tools show promise for automating such a task, the current procedure of maintaining the unofficial org chart remains largely manual in nature.
Business Tools
The Business Model Canvas
Understanding the business you serve is not a one-time affair. While effort may be heaviest during initial discovery, your journey never ends as businesses of today are in a constant state of transformation.
Given the highly dynamic business environments we manage, it should come as no surprise that there are dozens of business modeling tools to choose from. From Michael Porter’s Five Forces Analysis to the Balanced Scorecard pioneered by Robert Kaplan and David Norton. I myself am a big fan of one-page models, one-page strategies, and one page root cause analysis. Simplicity wins everytime in my book. This is one of the reasons why I love the business model canvas so much.
Originally created by Swiss business theorist Alexander Osterwalder, the business model canvas covers nine dimensions of business, spanning both internal and external views of the enterprise. These include:
- Customer segments – the top three revenue-generating customer groups
- Value proposition – the manner in which your firm addresses customer needs
- Revenue streams – the means by which income is generated
- Channels – how and where business is conducted
- Customer relationships – how customer lifecycle is managed
- Key activities – operations that are crucial to running a business
- Key resources – people, intellectual property, and other key assets
- Key partners – third parties enable and scale your business
- Cost structure – simplified view of the costs of business
Using these nine dimensions, we could construct a business model canvas for the ride sharing company Lyft thusly:
While elegantly simplistic, the business model canvas’ dimensions are comprehensive. Consequently, its structure provides a guided pathway during discovery conversations with IT peers throughout the business.
As an IT leader, this tool not only helps you understand your organization’s business model, it also helps paint the picture of the challenges faced by your peers. For instance, how can the Lyft business development team connect with thousands of restaurants to encourage Lyft Delivery partnership? How would the safety and compliance team ensure driver safety yet simultaneously reduce new driver sign-up friction?
In summary, the business model canvas is a simple, yet comprehensive tool that will ensure you’re at least asking the right questions. Moreover, they require no specialized software or training. Quite the amazing little tool!
The Business Glossary
There’s certainly no shortage of jargon these days, and every enterprise has its own unique dialect of terms which may feel like learning a foreign language at first. The fact that enterprises have their own lingo to learn shouldn’t come as a surprise. What is surprising, however, is that every new employee (including yourself) seems to insist on learning this new language in a slow, painful manner. That is to say: fumbling with unfamiliar vernacular until we memorize each phrase one-by-one.
In the business world, we’re obsessed with speed. Or least we like to say that we are. So how is it that we fail to operationalize things which consistently impede our ramp up time? If you’re scratching your head with these new business terms, it’s likely that others are, too.
To solve this pain point, one of the first things I do when I hit the ground at a new client site is create a business glossary page on the local intranet. Originally used for my own edification, I noticed other intranet dwellers took a common interest in these glossary pages. I always presumed my elegant data flow diagrams or capability maps would impress people. Yet this simple three-column table is routinely the most often “liked” pages I create on corporate intranets. Go figure!
| # | Term | Description |
| 1 | C-Bug | Customer-submitted bug tracker |
| 2 | DRI | Directly responsible individual |
| 3 | Ground Zero | Corporate SharePoint (intranet) site |
| 4 | Project Amber | CRO project to streamline prduct SKUs |
Getting back to business partnership: it’s embarrassing to be caught off guard by unfamiliar terms. To be treated like a business partner, you must act like you’re part of the business, and that includes speaking the local language. Familiarize yourself and your future hires faster by building a business glossary.
Business Capability Mapping
A capability measures an organization’s ability to accomplish something. Capabilities are essentially the things an organization does, irrespective of the manner in which they’re executed. In other words, capabilities focus on the what, not the how.
The most simplistic capability map an organization could have would consist of just three capabilities:
- Create offerings; typically in the form of products and/or services
- Market, sell, and support aforementioned offerings to customers
- Manage the company itself via functions such as HR, legal, and of course IT
Capabilities are hierarchical. A parent capability, such as “create offerings” will have multiple child capabilities; each of which are much more specific. A slightly more detailed view of this paradigm is shown below:
IT leaders are often inundated with immense amounts of information. They’re expected to recall dozens of functions throughout the enterprise, dozens (among hundreds) of applications, countless business processes, and so on. The beauty of a capability map is that it aggregates all of the people/process/technology minutiae into a color-coded score. When all the capabilities are stitched together, it creates a scoreboard of sorts, providing executives with a heatmap of holistic organizational health on a single page.
Capability maps are typically built and maintained using numeric scoring mechanisms. A traditional approach is to map a capability to a capability maturity model integration (CMMI) score, as shown in the sample Google Sheet below:
I myself prefer to create measurable business KPIs per capability, then score the capability based on whether we hit that KPI or not. For example, the lead generation capability should have supporting KPIs such as volume of marketing qualified leads (MQLs) and possibly opportunity win rate. CMMI and other “survey-based” scoring methodologies can lead to subjective scoring, whereas KPI-based scoring is much more objective.
One final, yet important thought around capability maps as it pertains to continuous improvement: you should not strive for perfection everywhere. Some organizations will lend more emphasis on certain capabilities, whereas for other organizations, a mid-range score may be deemed perfectly acceptable. Striving for flawless excellence across the board is simply unrealistic.
A Gentle Introduction to Corporate Financials
If you’re a finance-savvy IT leader who routinely looks at corporate financials, feel free to skip this section. Yet if you’ve never read a 10-K, or simply want a refresher on corporate financial snapshots, please read on.
The modern enterprise of today is focused on more than just profit. Corporations routinely take stances on social issues, focus intensely on customer experience, and of course aim to foster a positive environment for the employees who are the true fabric of any enterprise. That being said, finances are still immensely important. After all, a for-profit corporation must eventually turn a profit!
For an IT executive, understanding a company’s financial profile is beneficial for a multitude of reasons. First of all, if you’re considering taking on a new role within a publicly traded company, understanding profitability and what their assets vs liabilities profile looks like can lend some insight into how financially stable the company is. Additionally, understanding profit margin, and where expenses are going (sales vs research and development for example) will begin to paint the picture of corporate priorities, and potentially, corporate culture.
While there are plenty of books dedicated to the teachings of corporate finance, as an IT leader I tend to focus on only a handful of metrics; about a half dozen or so which I’ll cover here for the sake of simplicity. I’m also intentionally tabling the topic of stock analysis. In my opinion, the divide between stock price and company fundamentals is becoming an increasingly irrational chasm which I prefer to conveniently sidestep.
The Income Statement
Without further adieu, let’s take a quick look at a typical income statement. The example here is an income statement from Check Point Software Technologies Ltd, a publicly-traded enterprise security company. Note that these numbers are in thousands of dollars:
You may have heard the terms “top line” and “bottom line” in financially-focused conversations. The top line, which is literally the first or “top” line in an income statement, is revenue. Revenue is simply the total amount of income generated from normal operations; such as selling goods and services. As shown in the statement above, Check Point’s revenue has been steadily increasing to about the $2B USD mark in 2020.
As an IT leader, you may someday find yourself in the middle of a heated discussion about revenue data; especially with less mature sales and finance teams. Picture the following situation: the sales team shows the CEO all the deals won for the quarter, along with the aggregate dollar amount associated with those deals. As the quota-crushing sales teams commences their celebratory activities, the sounds of champagne cork popping and joyful cheers are quickly hushed by the critical commentary of those party-poopers in finance. Our friends from finance are keen on asking questions such as:
- Do these sales figures take credits into account?
- Did you average and/or aggregate your multi-year ramp deals?
- Are sales comps based on annual revenue received or total deal size?
As an IT leader, you likely won’t be expected to understand the revenue nuances of Financial Accounting Standards Board (FASB) standards. Yet you should be able to articulate which system is the source of truth for bookings versus revenue.
It would be great if we could bank every dollar earned, but unfortunately, it typically costs money to make money. Costs are grouped into two general buckets: direct costs, and indirect costs. Direct costs are expenses that are required to produce goods and services. If you owned a window company, glass would be a direct cost. No glass, no windows!
These direct costs are sometimes called “cost of revenue” or “cost of goods sold (COGS).” Subtracting cost of revenue from revenue itself yields gross profit. For Check Point in 2020, it cost about a quarter billion dollars to make two billion dollars. This attractive margin is one of many reasons why entrepreneurs love building software companies! If we were looking at an energy company, such as ExxonMobile for example, the margins would be far thinner due to the high costs associated with energy extraction and production.
It would be marvelous if one could simply produce software, and it automagically sold itself to consumers. In the real world, you’ll need sales people, accountants, and campus buildings to conduct general business. This brings us to indirect costs, also known as operating expenses. Check Point’s operating expense breakdown is shown below:
Take a look at the selling & marketing expense line. Are we learning anything yet? In 2020, Check Point spent about $226M dollars to produce its core products, yet it spent well over $500M dollars to market and sell its solutions. Like many software companies, Check Point is serious about sales and marketing. And who typically supports these critical go-to-market systems? You guessed it: your IT department!
The last metric I encourage you to examine is net income, or as it’s commonly referred to: the “bottom line” due to it’s placement towards the bottom of the income statement:
Subtracting all expenses from revenue, Check Point earned roughly $846M in 2020. Financial analysts will scrutinize this figure to determine profit margin, year-over-year trends and so forth. But as an IT leader, especially one considering working for a given company, you’ll want to investigate whether this number is positive or negative. Positive means profitable, whereas negative means the firm is operating at a loss; at least on an annual basis.
The 10-K
Within the United States, publicly traded companies are required to submit annual reports on a form known as the 10-K. This 10-K filing will convey financial results for prior years in the form of the aforementioned income statement, and a statement of net worth in the form of a balance sheet.
Financial figures aside, the 10-K is often a wealth of strategic corporate information. 10-Ks are routinely examined by investors, and because companies want to attract investors, it behooves the firm to convey an overall picture of sound management and wise business ventures which will grow the company, increase profits, and hopefully increase the stock value.
The dashboard below conveys corporate goals and financial performance for Ulta Beauty, and it was built entirely on publically available data such as 10-K facts posted on the SEC.gov website, press releases, and social media.
This particular 10-K conveyed corporate insights such as:
- Growing physical locations by several hundred stores
- Technology initiatives leveraging augmented reality (AR) to enable digital shoppers to virtually “try on” makeup products
- A revenue breakdown, by products and services
- Ecommerce growth
From an IT lens, you may see a company that continues to build on its brick and mortar backbone while also investing heavily into future digital offerings and channels. This is helpful not only for considering employment with the firm, but also for aligning future technology capabilities to business objectives.
Technology Views
Thus far, the majority of this chapter has focused on tools to help you enumerate your business landscape. Information technology is obviously a component of the business, and the prior business capability mapping section outlined how to analyze and score various capabilities inclusive of information technology. However, IT is your department. As such, you’ll likely want to delve much deeper into its inner workings.
The Enterprise Application Portfolio
A 2020 study the SaaS management platform company Blissfully noted that companies own an average of 288 SaaS applications. From my own personal experience, I can assert this number is on the lower side; at least for high-tech companies. A realistic benchmark is about one unique application per every fifteen employees. So in a firm with 8,000 employees, you may find over 500 applications in circulation. This creates a tremendous amount of risk, and an avalanche of operational expense which only seems to grow over time. Managing applications one-by-one, or even tracking them in a spreadsheet no longer scales. Similar to the way financial managers track stocks, we too need to use portfolios to group applications into macro-managed categories.
The goal of software portfolio management is to collect, categorize, and analyze your holistic software footprint across the entire enterprise. The collection phase of this cycle is the most important, because if you don’t even know what software you own, how can you possibly govern it? This phase must be automated, and it must be performed routinely.
Once collected, software can be categorized by business capability, by business process, or by business function to name only a few. An example of grouping applications by business capability area is shown in the figure below:
The analysis phase of software portfolio management is where things get interesting. In the highly simplified figure above, we see thirteen applications grouped by business capability area. As seen in the communication and collaboration (CoCo) space, we have two file sharing solutions: Box and Google Drive. The million dollar question is: why?
A real-world application portfolio with hundreds of applications will yield plenty of insights, and likely, even more questions. Questions I’ve come across include:
- Why do we have three Salesforce instances? Did we appropriate them via acquisitions?
- Why doesn’t marketing have a multi-touch attribution tool? Is that a gap?
- Who manages the FP&A solution? Is it IT, finance, or both?
- We have five different solutions from the same vendor. Are contracts consolidated?
There may be good reasons to have controlled redundancy within your application portfolio. The goal is not to have zero overlaps, per se. Instead, the goal is for you as an IT leader to be informed. To understand why your application landscape looks the way it does, and to take action when portfolio reconciliation is in order.
Enterprise Data Views
Not long ago, the enterprise data landscape was radically simpler than the environments of today. The sources of truth for business data were limited, IT-control of key data flows could be documented with moderate effort, and consumer marketing data could be copied among third parties with virtual impunity.
Today, data integration is no longer an IT-only game. Software vendors have made data integration a feature of many products such as Tableau, Workday, and ServiceNow; thus democratizing a once highly complex discipline into point-and-click solution. Moreover, recent mandates such those found under the European General Data Protection Regulation and California’s Consumer Privacy Act enforce strict usage guidelines for the handling of consumer data with stiff fines imposed on violations; intentional or not.
So what does this all mean for you as an IT leader? IT means the rules for data security and governance have increased while IT’s grip on data control has decreased. Basically IT has more responsibility, but less control.
Consequently, the cataloging of sensitive data objects and their associated data flows have become mandatory. At a minimum, your IT department must not only enumerate where consumer data and personally identifiable information (PII) reside, but additionally, data sharing among systems need to have justifiable business purposes which are formally documented.
Unmanaged corporate data is not an asset; it’s a liability. As is the case with enterprise applications, if you’re not monitoring and measuring your enterprise data footprint, you’re not simply managing it.
Data management is itself a capability, and therefore requires more than just tooling. Fortunately, your approach to governance can be iterative. Start by assigning a team to enumerate sensitive data and related data flows. Allocate a modest budget for data governance tooling, and focus data governance scope to higher risk data categories such as consumer and PII-centric information; at least for the first twelve to eighteen months. Over the course of time, your capability will mature, it’s scope will likely broaden, and the effort itself can be optimized with the help of automation.
Infrastructure Views
Infrastructure as a service (IaaS) providers such as Amazon, Google, and Microsoft have made the process of launching dozens or even hundreds of systems as simple as running a script. Therefore it’s hardly surprising that IaaS has its own fair share of sprawl. Continuing with the theme of managing technology assets at scale, it’s crucial to have eyes on your data centers; be them physical, virtual, or both. A good place to start, at least from an IT executive point of view, are with three Cs: clouds, cost, and connectivity.
Clouds refer to which infrastructure providers are currently in use. Before you can unravel what lives within your IaaS domain, you first need to understand which providers you’re using. Are you a traditional data center dweller, an AWS shop, or perhaps a multi-cloud player?
Costs should be self explanatory. However, the details around cloud usage are rarely cut-and-dry. One of the primary reasons for IaaS sprawl is due to the perception of infrastructuring being “free.” In other words, business units rack up astronomical fees while IT bears the resultant financial burden. Your goal here should be to use automated tooling to break down fees by cost center in order to build a financial showback and/or charge-back model. Not only is it prudent for business units to justify their spend, it’s also wise to prevent the co-mingling of general & administrative (indirect) costs from cost of revenue (direct) costs.
Finally, we have connectivity. For an IT executive, concerning oneself with network connectivity may seem tactical; perhaps even bordering on micromanagement. Yet here are some very common connectivity snafus which are damaging to both the enterprise and your career:
- Hosting mission-critical services in one availability zone
- Cloud infrastructure dependencies on legacy data centers
- Missing or poor firewall policies on site-to-site IPSec tunnels
- Failing to document network topologies
The rapid rate at which dynamic infrastructure changes is such that manual diagramming methods no longer apply, so automated discovery tooling is a must. And just like application portfolio management and enterprise data governance, infrastructure observability is a capability which also requires people and processes in addition to tooling.
Pulling This All Together with Enterprise Architecture
Enterprise architecture management, or simply “EA” for short, is a key capability you will need in some form or fashion as an IT leader. It’s a combination of people, process, and tooling which focuses on the design and evolution of the organization itself. If an organization isn’t intentionally designed, it will grow organically; which is a nice way of saying chaotically and painfully.
Enterprise architecture is a complex discipline in and of itself and such a topic is way beyond the scope of this book. Yet suffice it to say that EA “connects the dots” between business and technology. EA communicates massively large ecosystems in a palatable fashion. EA can decompose layers of organizational complexity into succinct insights. And perhaps most importantly, the practice of enterprise architecture enables transition architectures to bridge the gap between current and future states; something incredibly important in the era of perpetual digital transformation.
Many of the artifacts and tools covered in this chapter are commonly found within EA practices. If you find such approaches useful, consider investing in (or scaling) an EA practice within your IT organization.
Finally, the modern EA practice no longer represents the ivory tower of disconnected IT professionals spewing unrealistic technology platitudes. The modern EA team is more like a value chain functional business unit versus a consultative center of excellence. A modern EA practice, like any IT division, has tangible products and services. Your EA team should be at the forefront of driving enterprise observability, automation, and other highly-complex cross functional activities.
Summary Points
- Information artifacts are your first step towards achieving enterprise observability
- Collect and track your administrative tasks in a kanban board
- Assemble your own org chart based on actual corporate connectivity
- Leverage a business model canvas to understand your organization’s business model
- Keep tabs on corporate lingo by maintaining a business glossary
- Build a business capability map which can be scored with KPIs
- Learn how to read a income statement, and ideally, a 10-K if one exists for your firm
- Enumerate your business applications and organize them by capability area
- Catalog and justify sensitive data flows
- Embrace the 3 Cs of infrastructure: clouds, costs, and connectivity
- Build and/or scale your enterprise architecture practice
