The Technologist’s Guide to the C-Suite

team-1238087-639x442In my previous article, “The Technology Executive and the Software Craftsman,” I described a new breed of software developer who cares deeply about the fitness and quality of their workmanship, namely, the software craftsman. I also described how technology executives can better leverage this new breed of developer by ensuring that they are included in a broader business dialog to prepare them to make better business decisions. In this article, I will explain the various roles and voices that sit around the executive leadership table in most businesses. Further, I will explain what these roles expect and listen for when describing solutions they desire or are presented with solutions respectively. I call the latter their “listening.”

Previously, I said that the keys to better collaboration are communication and trust. The aim of this article is to help the technologist (software craftsman and most other technologists alike) raise their awareness of the dynamics within the “C-Suite.” Only through better communication will the technologist understand his/her business partners’ needs and through demonstrating that understanding, engender trust. The end game is to prepare technologists to ask better questions when developing solutions, present their solutions more persuasively, and ultimately to provide the best solutions to their business partners. In my journey from software developer to technology executive, I learned most of what prepared me for leadership by understanding and listening to these voices wherever they appeared, whether within the business or in customer settings in front of those looking to procure our solutions. When I face off with my technical staff to discuss solutions, I usually revert to my old standby question, “What is the business problem we are trying to solve?” The goal of this article is to add texture to the understanding of business problems and to suggest ways to evangelize technology solutions effectively to your business partners.

Voices in the C-Suite

There are four primary voices within the C-Suite. Those are the Chief Executive Officer (CEO), the Chief Operations Officer (COO), the Chief Financial Officer (CFO), and the Chief Technology Officer (CTO). They are sometimes known by other names in different industry sectors or company types. For example, in privately held firms, the CEO role can also be known as the President with the COO role being referred to as Vice President of Operations but their respective voices and listening remain the same.


As is commonly understood, the CEO sits at the head of the executive table and sets the tone and direction for the company. In most organizations, the CEO is strategically focused and is mostly concerned about setting strategy and aligning the various operations within the company to support that strategy. Components of that strategic vision can include growth within existing markets, breaking into new markets, finding novel sales channels for products and services, and expanding products and services to diversify the customer portfolio. In most cases, the end goal of aligning business with strategy is to increase top-line revenue, reduce expenses, and increase margins. The balancing act the CEO does between these is most often a function of the business sector and type of company. For example, US public companies usually manage to analyst’s expectations on a quarterly or annual basis while private companies can sometimes take a longer view since they are not at the effect of the stock market. Companies in the startup phase seeking to go public or get acquired are more often focused on generating revenue and growing the sales pipeline. Costs and margins are sometimes secondary since the acquisition price of a company is usually based on revenue or pipeline.

When a CEO is defining or evaluating a solution, they are usually listening for how the solution aligns with the strategy of the business. Common questions a technologist can ask a CEO include, “Where do you see the company being in 5 years?” and “What obstacles do you see to your guiding the company there?” These two questions will lead to richer and more detailed dialog.


The COO is figuratively at the right hand of the CEO. The COO’s job is to turn strategy into action by effectively leveraging the core activities of the business. In most instances, the COO heads the manufacturing and services arms of the business. In some instances, the COO owns the sales, marketing, and support activities as well. These will be discussed in the “Other Voices” section. The COO is supremely concerned about conducting business efficiently since efficiency translates directly to generating revenue while controlling expenses and maximizing margins. At the same time, the COO is concerned about continuously improving the operation to adapt and align it with strategy. So, most COO’s have a short-term efficiency goals and longer term improvement objectives. In some companies, software development effort falls under the COO especially if that development involves standardizing the production of products or services.

When a COO is defining or evaluating a solution, he/she are usually listening for how the solution makes the operation more efficient or aids continuous improvement objectives. For example, if your solution reduces the manual processes and the related errors, the COO pays attention because less error-prone processes mean the staff can focus on issues more critical to the business than fixing problems. Common questions a technologist can ask a COO include, “What do you think you can do to make your business run more smoothly?” and “Can you describe your objectives for process improvement or process re-engineering?” Again, these questions will serve as an opening to a deeper dialog.


The CFO controls the purse strings of the company. Among the many concerns of the CFO, two are primary: Are revenue projections on target per company strategy and budget and are expenses being controlled responsibly per the budget. Most other concerns flow from balancing revenue with expense as the business ebbs and flows throughout the fiscal year. Based on these concerns, the CFO is the gatekeeper of most spending. For example, if hitting a margin target is key for the company then the CFO will attempt to tighten expense controls if revenues fall short. Expense spending is prioritized based upon business need. It is critical for technologists to make good business cases for their expenditures lest the CFO becomes the CF“No!”.

When a CFO is defining or evaluating a solution, they are usually in alignment with the COO but more from a financial perspective. They also tend to focus on return-on-investment for money spent. CFO’s also balance capital expenditures such as computing assets and operational expenses such as technical services, so it’s best to understand where the CFO stands in such purchases. Common questions a technologist can ask a CFO include, “What’s the primary focus of your efforts, revenue generation or expense saving and how do you balance those?” and “Are you looking to affect those in the short term or do you have a longer term view that is more important?”


Since this article focuses on the technologist, the CTO is the probably the best understood by the target audience. The CTO’s job is to leverage technology effectively to support the business. This job can include client-facing software development, infrastructure management, internally-facing software development, and deployment and management of any of a broad spectrum of other technologies that power business. In the vast majority of businesses, the CTO acts in the service of the other facets of the business. As such, the CTO must be in close and constant communication with their executive peers to understand how best to deploy supporting technical resources. In companies pushing out the frontier of technology, the CTO is at the forefront of generating innovative solutions so their role can sometimes heavily overlap with those of the CEO and COO. The CTO usually creates and maintains a technology strategy and roadmap to support the prioritization and orderly deployment of technology. One of the key balancing acts done by the CTO is balancing what is needed to advance client facing strategy and what is needed to advance internally facing support. The question becomes one of what is critical to the core mission of the business and what is not. Increasingly, CTO’s are looking for external hosting support for non-mission-critical systems to focus internal technical resources on mission-critical systems. The mission of the system frequently gives rise to the internally versus externally hosted debate and where the “cloud” enters into the discussion.

When a CTO is defining or evaluating solutions, in addition to business fitness, he/she is concerned about how solutions align with technology strategy and mission-criticality. Common questions to ask a CTO include, “How would you expect the solution to align with your technology strategy?” and “Is the proposed solution critical to the core mission of the business or ancillary to that mission?”

Other Voices: Business Development and Customer Support

There are two additional roles and voices that are frequently at the executive table but can sometimes report up to those seated around the executive table. Those are the Business Development (BD) or Sales role and the Customer Support role. Both face off to customers but bring different and sometimes opposing perspectives to the table.

The BD role is concerned with selling products and services to the customer. As such they tend to be focused on the alignment of the features and benefits of products and services to the customer’s needs. I have seen both strategically focused and tactically focused BD organizations. The focus varies with the business climate faced by the company. BD is frequently the area of the business best aligned with the corporate strategy since they handle generating the revenue needed to realize that strategy. I mention this role in the article since forming an alliance between technologist and BD staff can be the key to understanding the corporate strategy in very practical terms. I urge you to seek out your BD peers and understand their motivations and pain points. It will pay dividends when defining or evangelizing solutions.

The Customer Support role brings a very different voice to the table. Most often, these are the people that have to live with technology solutions for the long term and benefit by their virtues and suffer from their vices. In short, the Customer Support voice is the best to identify product risks and where the most solution benefits can be gained. Where the BD role focuses on features and benefits to the customer, the Customer Support role focuses on making the solution work for the customer in very practical terms. As such the Customer Support staff will frequently be the most risk-focused since they are committed to customer satisfaction. Risks when realized often lead to unfulfilled expectations and unfulfilled expectations lead to unhappy customers. Understanding what it takes to support and satisfy customer needs usually results in key product and services differentiators that the technologist would be wise to consider when developing solutions.

Practical Applications

So now let’s explore putting the appreciation for the “voices” and “listenings” at the executive table to use. Among the jobs facing technologists, there are two that benefit the most from this understanding: Gathering requirements for solutions and evangelizing solutions to your customers.

When gathering requirements, I urge you to list the various voices I have discussed. Seek out representatives of each voice and have a conversation about their objectives for the solution under development. You need not necessarily seek out c-level executives to obtain these views since the staff under the executives are frequently aligned with their leader’s positions. Once you have amassed these views, attempt to prioritize the strength of the voices with the features you wish to build into the solution. You can then review your findings with the business representative to verify your understanding and seek correction. In doing so, you will not only arm yourself with better information needed to develop a better solution but you will demonstrate to your business partners that you understand and are in alignment with their needs. Demonstrating understanding is the key to engendering trust!

If you are in the position of evangelizing a developed solution to internal or external customers, I urge you to list the various voices I have discussed. Note alignment of features and benefits of the solution with the “listening” of each voice. From this, you can create a narrative designed to explain your solution to each “listening.” Here’s a tip: When you’re facing-off with your customers evangelizing your solution, ask them where they work in the business (Operations, Support, Finance, Sales, Strategy, etc.). Armed with their answers, you can explain the features and benefits of the solution in a way that aligns with their particular view of the world. I think you will find that you will build more persuasive arguments that help you more effectively communicate and build trust.

If any of the above resonates with you, I would like to hear about your experience trying it out!

The Technology Executive and the Software Craftsman


Back in the Day

As a technology executive, I’ve been around software development for over three decades. Those who entered the development workforce as developers in the 1980’s as I did were typically educated as and thought of ourselves as software engineers. We were taught structured methodologies of the day based upon the writings of notables like Yourdon, Ward, and Mellor. We were drilled in development techniques including data hiding and encapsulation focusing on the disciplined used of data structures and algorithms with the aim of making our software more flexible and maintainable. The development tools of the day consisted of compilers, assemblers, linkers, and loaders and little else. Often, we were not only developing software but we were simultaneously developing better tools to help us develop that software. Simply put, we were not only developing software products but were also developing the tools to fill the gaps in the tool sets of the time. In spite of these hindrances, we managed to produce fairly robust code.

Using these methods and tools, we were often employed in medium to large scale projects using traditional waterfall project models which valued rigorous documentation to communicate requirements, design, architecture, code structure, and test cases. Those of us who worked on military projects were exposed to such software development standards as DOD-STD-1679A and DOD-STD-2167. I was involved in military, medical, and financial software projects. In spite of our best intentions to “engineer” software following the models and standards of the day, many projects were delivered late, only partially met the requirements, and were fairly bug-laden. As software engineers, we intuitively knew that something was fundamentally flawed with our methods and that developing great software was more iterative than we were taught. However we often felt at a loss to know how to change things. We knew that close collaboration with our clients and subject matter experts often yielded better results since we could better understand user needs through such collaboration, but the waterfall process created barriers to collaboration in deference to formal documentation and methods.

A New Breed

In the intervening years, I have seen development tools mature to a point where they enable better productivity through means of integrated visual IDEs, real-time code analysis, and automated unit testing tools. The tools not only enable developers to manipulate code and resources better but often do tedious tasks automatically and offer helpful guidance to produce better code. In fact, many recent tools support the ongoing refactoring of code to ensure quality and maintainability as the features and functions of the software evolve over time. This helps reduce the entropy that often seeps into software products making them bloated and unwieldy to maintain over time. In short, the tools have evolved to not only reduce the friction between developer and code but have become an ally in producing high quality code faster. In addition, more iterative development methodologies arose as development teams realized that tight collaboration with the customer was a key project success factor. Today, the various flavors of Agile (with a capital “A”) development are the de facto standards for most software development since it acknowledges the inherently iterative process needed to develop great products that are better suited to the business needs.

As the development tools have reduced the friction between developer and their code and Agile development methodologies brought developer and customer into tighter collaboration, I have seen a change in the ethos of developers. Under the guidance of technical experts and mentors like Robert Martin (aka Uncle Bob) and others, developers are trained, or maybe more accurately indoctrinated, in a new way of thinking about software development which focuses on the delivery of well-crafted, high-quality code. This goes well beyond traditional training in techniques and methodologies to a level of almost Zen-like devotion to fitness and quality. Having read some of the materials by modern day software gurus like Uncle Bob, I have found a theme where some developers see technology executives as a hindrance to the crafting of great software. This is almost a “we’ll build great software in spite of the obstacles placed before us by our managers” feel to the discourse. Developers are now challenging and entreating the business to support them in building the best products possible because they care about their craft to which they put their name! This new breed refers to themselves as “software craftsman” and with good reason. As craftsman, they understand that software is only partially engineered. They understand that truly great software development is an organic mix of close collaboration with their customers to guide the application of the technology and tools. In short, this is what many developers from “back in the day” intuitively understood but could not instantiate into real solutions for software development shortcomings of the day. It has been and continues to be my privilege to work with these craftsmen. I find myself in admiration of their dedication as I reflect on the earlier days of software development.

Vendors versus Partners

So as the developer ethos has changed and evolved into that of the software craftsman, the mindset of the technology executive must also evolve to better leverage the ethos and skills of their software craftsmen. A former executive colleague had a saying, “Squeeze a Vendor, Hug a Partner.” All too often, technology executives see their development staff almost as vendors whom they engage to produce a product. I must say that I have been guilty of the same outlook. Treating developers like vendors often means that developers are given the requirements and access to subject matter experts and then set loose to come up with a solution. The technology executive then monitors progress and squeezes the vendor to deliver the product as efficiently as possible. In short, “squeezing” vendor relationships often lack trust and that shows through to the software development “vendor.” All too often, the technology executive is left disappointed as the solution falls short in features, quality, or delivery timelines. Based upon my own experience, there were two simple reasons for this. First, the technology executive was squeezing the development staff to hit a timeline without arming the development staff to make the right tradeoffs needed to deliver quality software. Second, the developers did not understand the full context of the solution they were asked to develop including such things as market forces at work, sale pipeline pressures, the competitive landscape, and any other number of factors influencing the making of good business decisions. Like a vendor, they were only told as much as the technology executive thought they needed to know. Based upon the information available, the developers did the best they could.

Now let’s contrast this to a partner relationship. Partnerships are based upon the alignment of intentions and motivations between parties. Partners share the full vision of the goals to be attained with the hope that they can arrive at mutually beneficial solutions. Partnerships are based upon trust that each party has the others back and that success will be achieved through the mutual nurturing of the partnership. Partnerships aspire to add value to both parties in a “rising tide lifts all boats” ethic. Partner relationships are for the long term while vendor relationships last for the duration of the product delivery.

Believe it or not, technology executives and software craftsmen share the same intentions. They both want the best product possible, they both care deeply about the fitness of the solution to meet the customer need, they both want a sustainable high quality outcome, and they both want to avoid putting their name on a poor outcome. In short, when the technology executive and software craftsman come together as partners, they find that they want the same thing!

A Call to Action

So how can a better partnerships between technology executives and software craftsmen be forged? It’s really quite simple and can be explained in two words: Communication and Trust.

The technology executive needs to arm the software craftsman with the information required to make the best decisions possible based upon the true business need. Simply communicating requirements is insufficient. The technology executive needs to engage the software craftsman in a continuous and ongoing dialog about the business including a transparent discussion of the opportunities and challenges facing the business. I think you will find that the your software craftsman will eagerly absorb and digest this information and use it to design and develop better solutions that transcend the boundaries of the requirements to make their solutions more fit for a broader business scope. I hold periodic meetings, usually over lunch, where I brief the senior technical staff on the state of the business and how their solutions fit in. We have spirited discussions and action items resulting in improved development methodologies, tooling, and product features to help achieve superior results. This has been like a bit like letting the genie out of the bottle. With a little effort and trust, software craftsman can produce magical results!

The software craftsmen need to make their executive partners understand that they care deeply for their craft and demonstrate that they are aligned with the goals of the business. The technical staff needs to understand that it’s healthy to challenge the business and bring executives to the notion that it is not only a good idea to include the technical staff in the business dialog but it’s essential to the development of the best possible products!

Only through a true partnership between executive and craftsman can superior results be achieved. As a result you’ll get side benefits in return: a new sense of trust and satisfaction. Aren’t those at the heart of what both technology executives and software craftsmen desire?