The Power of Intention (in software development)

In my previous article, “Designing an Accountable Software Development Organization Part 2: Vision, Levers, and Tensions,” I discuss the tension that exists between requirements, governance, and technical delivery activities within a software development organization. The tension between these activities is a necessary part of developing truly great software since they provide checks and balances between sometimes competing agendas. In that article, I illustrate the effects that tension on misaligned organizations and discuss how better organizational alignment helps the software development leader manage those tensions and keep them healthy.

Even after achieving the best organizational alignment which allows tensions to bubble up to the right level where they can be managed, the requirements, governance, and technical delivery folks will occasionally go toe-to-toe over issues that arise. The question is when things get heated between disagreeing parties, how do we ensure that tensions stay healthy or more importantly, how do we restore health to an already unhealthy tension? The answer is both simple and complex and comes down to a single word: Intention.

The Right-Wrong Game

The need to be right and to avoid being wrong is hardwired into people. Unhealthy conflict is defined in terms of what I call right-wrong games. Right-wrong games are usually characterized by zero-sum thinking where one party believes that to be right; the other person has to be wrong and vice versa. Also by definition, there is no middle ground and no giving ground. When I see people engaging in these conflicts whether, through email, text messages, or other means, I imagine them sitting opposite one another at a table doing verbal battle face-to-face. When you dig deeper into these conflicts, there is usually a single root cause: each party has attributed a contrary intention to the other party and is allowing that preconception to drive their actions and emotions.


Let me give you an example. A product manager and software architect are locked in a battle over software requirements and how to implement them. The product manager insists that the requirements must be accepted in their entirety in order to meet the customer’s needs while the architect is looking for requirements flexibility in order to make a more maintainable implementation. The product manager believes they have the customer’s best interest at heart because requirements are paramount and that the architect wants to take shortcuts to make their job easier. The architect believes that making a more maintainable solution will benefit the client by ensuring higher quality and that the product manager is taking a short term view and being inflexible.

So what’s happened to make the relationship fail? The product manager and architect have attributed bad intentions to their opponent and then allowed their perception to drive behavior and emotion. In short, each party believes that that other is out to thwart their best intentions, and each party is hell-bent on stopping the other because each party is convinced of the virtue of their position.

Breaking the Right-Wrong Game

When faced with these conflicts, the best outcome is to get both people on the same side argument working toward a mutually beneficial solution. In short, they end up side by side on the same side of the table looking out together toward a common solution.


So, how is this accomplished? The parties in conflict need to come to the understanding that they both share the same intention. Namely, to provide the best solution for the customer. They will come to realize that they both want the same outcome and only differ on the means to achieving that outcome. They must realign on their intention and acknowledge that the other party shares that intention. This does not usually happen in the heat of a right-wrong battle and requires a cooling down period first. Even then one party or the other may not what to give ground. It’s the job of the software development leader to bring the warring parties together and get them to reveal their own intentions and acknowledge the good intentions of the other person. With a little guidance from the software development leader as the a third-party, the two parties will come to realize that they both have the same intention at heart. The goal is for two parties to become allies in finding a solution that aligns on their common intention.

Reducing the Occurrence of Right-Wrong Games

The key to reducing the occurrence of conflict in software development organizations caused by intention misalignment issues is to prevent such conflicts from starting in the first place.  To do this, the software development leader must define the intention in collaboration with their team, seek alignment on the intention, and constantly reinforce it. In my own software development organization, we have three primary intentions: Delivery software that is the best fit for the business, deliver high-quality software, and deliver it when we promise we will. These three intentions may seem intuitively obvious for a software development organization but, often, they are assumed rather than made explicit and are spoken about in a trite manner.

Recently, our team delivered a major software release designed to allow more customers to migrate to our new platform. The team pushed extra hard to meet a deadline and succeeded in delivering on time despite numerous obstacles. At the weekly status meeting near software delivery time, I made sure to reinforce with the team how they supported the business by delivering the right functionality, with high quality, and on time. All throughout the effort, the team was focused on the goals and aligned on our common intentions. When obstacles occurred, they came together and found ways to overcome them…usually on their own and without management intervention. They made a hard task look easy all because they worked together. I couldn’t have been prouder of the team for their commitment and the results.

Be Easy on Yourself

As a software development leader, it’s all too easy to get frustrated and annoyed when inter-team conflicts arise. I know this first-hand because I sometimes feel this myself. When I have a moment to step back and reflect, I remember that software development is the art of balancing tensions to get the best results. Software development is a human endeavor involving high-performing people who sometimes see their peers as obstacles to meeting their intentions. When you want to jump out a window out of frustration born of interpersonal conflict caused by misattribution of intention, remind yourself that your software development staff is well-intentioned and wants to do the right thing whenever possible. In short, be easy on yourself for not being able to avoid these conflicts and be easy on your team since we all share the same virtues and vices when it comes to relationships. Your team needs a periodic and gentle reminder that they all aligned with the same intentions. Rather than forcing a result, more likely than not,  you will find that your team will come together and find their own solutions and get a sense of satisfaction in doing so.



Agile Software Development Team Empowerment: A Holistic View

Over the past six decades, software development has evolved from what was thought to be an engineering discipline complete with rigorous methods and processes to much more of a crowd-sourced social engagement involving skilled craftsman and iterative collaboration.  Executives and managers have had to adjust their thinking from a “command and control” style where every aspect of software development was tightly timed and controlled to a “servant leader” style where the goal is to empower the team to make decisions and remove obstacles to their success. I have written previously about these  “softer” aspects of software development. In this article, I will pull together the previous concepts into to a holistic view of Agile software development team empowerment. My intention is to create a framework which can lead to more productive teams that produce high-quality code stemming from of business-focus, trust, and collaboration.

Before I begin, there are a few assumptions I make as precursors for any software shop as follows:


Good Talent. Any high performing team needs to be staffed with talented staff. Most well-functioning agile teams will police their own ranks and either help to raise the performance of mediocre members or identify those that need extra help and support. This self-policing comes from a strong sense of team and focus on the development goals. If you don’t hire the best talent and then allow Agile team dynamics to work their magic, then you may be forced to resort to command and control means to reach your goals. Resorting to command and control methods with Agile teams usually produces the undesirable outcomes of demoralized teams and high turnover.

Best Intentions. Most software development staff, given half the chance, will strive to understand a align with the business goals. In cases where they don’t, it is usually traced to a failure of the culture to support employees’ line of sight to the business. We must assume from the start that both software development staff, management, and executives work from a common set of good intentions. It is when we attribute mistakes to bad intentions that software projects spiral out of control in a frenzy of finger-pointing.

Supporting SDLC and Tooling. Agile software development is adaptable to many industry scenarios. Teams need an established software development lifecycle which sets expectations for how Agile is applied and governed. Agile works equally well at any point along the spectrum from loosely to highly regulated industries. Teams also need appropriate tooling to support their use of Agile and these are abundant. Open source shops might use tools from Atlassian or HP while Microsoft shops might use Team Foundation Server. The tools are mostly fungible across target technology stacks, but it is important to use a toolset to enforce SDLC quality gates and to automate manual tasks and tracking.

With assumptions out of the way, let’s drill down on the steps toward the empowerment of software development teams.

Organizing the Teams for Success by Keeping Tensions Healthy

In the three-part series, “Designing an Accountable Software Development Organization,” I discuss the principles of organizing a software development shop for success. The very nature of software development includes the tension between project requirements, the ability to translate those requirements into high-quality working code, and the governance to ensure that it’s done in an orderly and timely fashion. It is impossible to avoid these tensions, but it is possible to design an organization that acknowledges and harnesses the healthy tension while avoiding the tensions from becoming destructive. Put another way, the tension between requirements, technical delivery, and governance are necessary to producing great software. It is entirely up to managers and executives as to whether the tensions will remain healthy or turn toxic. Software developers will flock to healthy shops and flee toxic ones.

Supporting Decision-making by Maintaining Line-of-sight to the Business

All too often, business keeps its software development staff in the dark about key business strategies, goals, successes, and failures. At the same time, we expect our software development staff to make key decisions about software requirements and their implementation to drive business success. To use an old 1950’s B science fiction movie quip, “This does not compute.” In the article, “The Technology Executive and the Software Craftsman,” I discuss treating software development staff less as vendors who simply produce a product and more as partners who share a common desire for favorable business outcomes. The goal is to create a line-of-sight from the business to software development to enable better decision-making at the closest point of impact. This turns software staff from simple doers to thinker/doers who constantly weigh the needs of the business in their decision-making process. This is best summarized by L. David Marquet in Greatness. Creating line of sight and empowering decision-making at the closest point of effect will not merely provide incremental gains in team effectiveness, but will increase effectiveness multi-fold.

Aligning Intentions and Setting Expectations Between Management and Software Development Teams

In addition to the disconnect between business goals and software development, there can also be a disconnect between the senior executive team and software development staff. In the face of this lack of understanding, software developers sometimes fail to understand how and why decisions are made. In the article, “The Technologist’s Guide to the C-Suite,” I discuss the various roles at the executive table as well as what each role is concerned about and listens for. My intention is to foster an understanding on the part of the software development staff so that they will be more effective at synthesizing requirements stemming from and evangelizing solutions to senior executives. The end result is to create better collaboration that ultimately engenders trust.

Identifying Risks, Removing Obstacles, and Continuously Improving

Once we have a well-organized and well-informed software development team, we move onto the nitty-gritty of developing software. As mentioned in the introduction, software development management is transitioning from a traditional “command and control” style of tight control to a “servant leadership” style of team empowerment and removal of obstacles. With a well-functioning Agile software development team, the obstacles to success are frequently external to the software development effort itself that manifest as inefficiencies in the development of software. The obstacles may be related to requirements instability, churn on architectural design, unmanaged tensions between groups, or any number of other issues. In the article, “Better, Faster, Cheaper: Picking Three,” I discuss a model for managing risks to the timely delivery of software in Agile projects. The purpose of the delivery risk model is to identify obstacles to team efficiency as early as possible them work to mitigate those risks. When the delivery risk model is applied judiciously, the end result is higher quality code, more timely delivery, and less time spent fixing defects later, i.e., better, faster, and cheaper. The delivery risk model is an essential part of any servant leader’s toolkit. Without it, risks accumulate and snowball precluding the opportunity to head off problem while they are manageable. Further, the delivery risk model is a gateway to continuous improvement efforts where teams learn from and correct mistakes rather than get punished for making them.

Before concluding, there are some management caveats follows:

Management Traps

Sprint Micromanagement. Agile software development is by definition a highly iterative and self-correcting process. This works when teams are permitted to make mistakes, be honest and transparent with themselves and their management about issues, and work to correct those mistakes. A “command and control” mindset often drives managers and executives to micromanage Agile teams at the sprint level by holding teams strictly to burn down goals and punishing teams when they do not meet those goals. This is a grave mistake since it drives Agile teams to artificially pad estimates, limit transparency, and hide mistakes. Rather, I recommend setting interim delivery goals spaced throughout the project and have executives and managers hold teams accountable for those deliverables. The team should then be allowed to experiment and adjust their own processes within the sprints to improve velocity and quality without fear of punishment. Obviously, the teams need to deliver the agreed-upon functionality for the interim deliverables and may need to push harder to do so. But if the team is permitted to control the progress of sprint, they will usually willingly find a way to meet the interim deliverables.

Agile Dogmatism from Above. Agile methods are a fluid and changing set of guidelines stemming from the original manifesto. Agile software development is designed to adapt to the business and technical challenges at hand. In a strange twist of irony, I have encountered managers and executives who take a dogmatic approach to Agile methods and strive to impose strict doctrine around process and procedure. I recommend starting with a well-defined Agile process then listening to the teams about what’s working and what’s not. Experimentation and adaptation are at the heart of Agile, and the team should be allowed to make adjustments within reason. Depriving the team of this opportunity not only stabs at the heart of the spirit of Agile methods but disempowers Agile teams to influence their own destiny.

Agile Dogmatism from Below. Agile practitioners can sometimes be dogmatic as well. One of the  more persistent narratives I’ve heard says that Agile is not about committing to or hitting deadlines. My response continues to be, “Any software development methodology that cannot deliver on a predictable timeline does no good service to the business.” Another chestnut asserts that Agile is about producing software rather than documentation when, in fact, Agile values working software over documentation but does not preclude the need to produce documentation. As from above, there is a certain irony about dogmatism when applied to Agile by its practitioners.


Developing truly great software has never been easy. Software is among the most complex things produced by humans. Its complexity stems from the vast number of states that a software product can assume. In short, the “soft” is software assumes complexity and flexibility. Getting software right is as much a social engagement as a technical one. There are vast tomes and training materials about getting the technology right but woefully little guidance on addressing its social aspects. In this article, I have endeavored to highlight the social aspects of software development and provide a framework for getting best from the skillful and well-intentioned professionals who develop it. In the end as with any social endeavor, we get better results when people are fully engaged in a trusting, collaborative environment. Great software happens where talented people and great software development culture intersect, and that’s what empowerment is all about.



Mining for Diagnosticians

There are many diverse talents among technologists. Some excel when challenged with creating new applications. Others love to maintain and enhance existing systems. Others thrive when developing system-level tools and utilities. Still others gain validation from designing and implementing exceptional user experiences. One of the most intriguing and compelling skill sets is that of the diagnostician.

Complex and vexing problems arise throughout software development projects. Developers are constantly diagnosing and solving these problems which make the diagnostic skill set part of every developer’s repertoire to varying degrees. Having been exposed to many software projects and many developers, I’ve noticed that diagnostic abilities are a key discriminator between good developers and great developers. Further, I’ve also noticed that the more exceptional diagnosticians often eventually find themselves in leadership roles. I have asked myself what distinguishes the skills of a great diagnostician and what these skills might have to do with career progression. I have come up with some key factors that I believe are implicated in the phenomenon:

Holistic View

The best diagnosticians maintain a broad view of the systems they develop. They may be experts in some parts of the system, but they understand the coupling between components and the flow of information between them. They are able to understand the system at multiple levels from logical design to physical implementation. This holistic view represents a mental map of the system and helps the diagnostician to navigate rapidly through its parts. This ability to create and maintain a big picture view is also commonly found in those who end up leading technology endeavors.

Deep Bag of Tricks

Complex problems frequently require complex solutions. Master diagnosticians maintain a deep and varied set of tools to help them explore problems. I have witnessed developers abandoning their canned tools altogether and resort to lowest common denominators techniques akin to print statements and traps when the most advanced tools give up the ghost. Innate resourcefulness and a willingness to try anything are traits found in many leaders.

Avoids Wild Goose Chases

Getting stuck on a problem is a common occurrence when diagnosing a software problem. The best diagnosticians seem to have an intuition about when they are traveling down a fruitless path. They actively and quickly eliminate fruitless paths and move onto other opportunities. Put another way; they focus on the goal of solving the problem and follow problems wherever they lead. The best leaders intuitively temper dogmatism with pragmatism to find more efficient paths to goals.

Values Accuracy over Guesswork

Making assumptions and testing hypotheses are part and parcel of the diagnostician’s trade. However, great diagnosticians temper guesswork with accurate assessments of their findings. How many times have you seen a developer insist that the source of the problem must be XYZ only to find out later that they were far off the mark? The best diagnosticians spend very little time being attached to their assumptions. They accept the evidence and move on. Leadership also requires testing assumptions based upon data and changing course when the evidence does not fit the assumptions.

Keeps Their Ego at Bay

It’s human to believe that our own efforts are probably not the cause of problems. In software development, it’s all too easy to assume that the problem is caused by someone else’s code. The best diagnosticians often assume that their software could very well be the cause of the problem and will look there first. They park their egos at the door in their search for the answer leaving no stone unturned. Leaders that are best at empowering teams frequently exhibit this same ego-less approach to social interactions. They are not afraid to admit mistakes and change course as a result.

Avoids the Blame Game

It’s all too common too for technical staff to point the finger at each other when difficult problems emerge. Master diagnosticians avoid this game altogether. They know that blame is pointless and harmful to the diagnostic relationship where collaboration is the key to efficiently solving the problem. Great leaders also focus on moving disparate teams toward a goal and know that cohesion is more effective than division.

I’ve made it my business to keep on the lookout for great diagnosticians. Frequently, these are the people who make the best leaders since they understand the overall structure of the system, know how to explore paths to solutions efficiently, value accuracy, and seek to operate with low egos and high collaboration. I see the best diagnosticians as “diamonds in the rough” when considering people for positions of technical leadership. Whatever the business or technology domain might be, I encourage the reader to keep an eye out for the best diagnosticians. I think you will find that the best among them could be your own raw materials for the next wave of leaders within your organization.



Of Cars and Career Development

OK, I’m a car guy. Ever since I was a kid, I loved everything about them. My boyhood best friend Jimmy McGowan and I took keen delight in being able to identify cars at night by their headlight and tail light patterns. And we knew that the Chrysler 225 Slant-6 and 318 small block engines were the pinnacles of 1960’s Chrysler engineering. Turning sixteen years of age was a rite of passage because we would learn how to drive…a gateway to new adolescent freedom! When we owned our first beater cars, we learned how to tune them up ourselves as a point of pride. After all, how hard was it to gap the points and replace the rotor, condenser, cap, plugs, and plug wires on a pre-catalytic converter jalopy! Timing light? Who needed one of those when you could set the timing by ear just by giving the distributor a turn!

All these years later, I’m still passionate about cars. Even though I no longer tune up my own, I still enjoy reading about and talking about them with like-minded folks. The process of determining my next car is a particular source of excitement since I get to do research, window shop, and test drive! Well, during my most recent car search and after much research and salivating, I decided that an Audi A7 was in my future. I had done my homework and visited my friendly Audi dealer for a test drive. Of course, I fell in love with the car and drove away pondering my strategy for acquiring one of these beauties.

Now the A7 is not exactly a common car, and you don’t see too many on the road. But almost immediately, I starting seeing them all over the place. I could barely turn a corner without one popping up. What the heck happened? Did Audi start giving them away in my area? Did extraterrestrials implant a cybernetic device in my brain and start beaming visions of A7s into my head? Of course not. I experienced the Baader-Meinhof Phenomenon also known as The Frequency Illusion. Simply put, my recent experience with and my desire to own an Audi A7 biased my perception of my surroundings toward noticing A7s. There clearly were not more A7s on the road before I decided to buy one. I was merely more attuned to seeing them since I wanted to own one. My desires had shaped my perception of the world!

And so it is with career development!

Before I decided to embark on a journey leading to a technology leadership role, I pondered what I wanted to do with my career. I had spent almost 20 years as a software developer with a high degree of success. I had worked on military, medical, and financial systems and I liked technology, but I knew I wanted to put my passion for applying technology to more than just developing software. After much thought, I narrowed my career direction choices to three. First, I could earn a law degree and practice intellectual property law. After all, there is a market in the legal profession for former software folks who know their way around technology. Second, I could earn a Ph.D. and move into academia. I had tutored students and taught undergraduate labs in college and thought teaching would make a satisfying career. Finally, I could broaden my business skills and find an opportunity leading a technology organization within a business. Being a classic Myers-Briggs INTJ who not only likes the intellectual challenge of exploring a technology but likes to see that technology applied, I decided on the latter…I would set my sights on a CTO-like position.

After deciding upon my career direction, I started researching the role in more depth and discussing what it meant with those around me. Within a short time after committing to a new direction, a funny thing happened. I started noticing new opportunities to learn and talk about topics adjacent to my existing software development skills that might help build my career. The Frequency Illusion had kicked in!

At the time, I occupied and office next to the infrastructure folks. Their conversations about hardware, networking, and storage became more interesting to me, so I joined in. I was home-building computers as a hobby, so it was a natural fit. I was already helping answer technical RFI questions for the sales folks. Discussing the intricacies of sales opportunities with them became more interesting. Business discussions around procurement and budgeting that had felt a bit tedious became more interesting. And things that previous would not have appeared as opportunities for advancement seemed to almost miraculously present themselves.

A year or two later, the company I worked for had developed a new hosted solution for the core product, what is nowadays called SaaS. They needed someone to accompany the sales people on sales calls to explain the technology underpinning the offering. Ordinarily, I would not have seen this as an opportunity, and I would have shied away. Since I knew that understanding client needs were key to being a technology leader, I saw this as my chance to learn more about the sales process and client engagement. I raised my hand to volunteer. Oh yeah, and the prospect of facing off with clients scared the heck out of me but, as they say, no pain no gain! A sales person and I then spent close to a year selling the new solution. We were so successful that year that we won a sales award! I learned a lot about the business and what clients cared about throughout that year. It was one of those truly pivotal moments in my career. Further, I discovered that I really enjoyed evangelizing technology solutions to clients! Not too much later, a CTO position opened up in the company, and I applied. The rest is history.

In hindsight, it’s clear to me that committing to a career direction changed my perception and provided a new focus on opportunities that might help me achieve my goals. In short, I biased my view of the world toward the direction I had set.

Put some bias into your career development!

It continues to be my privilege to work with some incredibly talented technologists. Their skill and passion for their trade inspires me to believe that the future of software development is bright. Occasionally some approach me for career advice. The common thread of these career development encounters is that each person in their own way has committed to a direction for their career. In reaching out, they are looking for experiences and opportunities to help them grow. Maybe without knowing it, their commitment to their future has introduced some healthy bias into their perception of their world.

I urge the reader to explore what you desire in your career. At some point, make a commitment to yourself about your career passions and what you want to achieve. In doing so, you might just put the Frequency Illusion to work for you! Miraculous opportunities could very well come into focus that will help propel your career forward!



Better, Faster, Cheaper: Picking Three

The old chestnut in software development goes, “Do you want the software better, faster, or cheaper? Pick two!” This dilemma has increasingly plagued technology executives as the pace of technology change accelerates, and the business challenges the software delivery organization to “pick three.” Historically, software development organizations have balanced these apparently competing dimensions by assuming that such balance was a zero sum game where one dimension must be traded off for the other two. In this article, I will challenge the conventional wisdom and discuss a risk-based software development management model where we assess the risk to on-time delivery and mitigate those risks to keep the project on track. In doing so, we more efficiently use software development capacity ensuring that the optimal time is allocated to each software development activity to ensure that we deliver high-quality software. I call this the “Delivery Risk” model.

The Relationship Between Better, Faster, and Cheaper

As a technology executive responsible for software delivery, there are three primary responsibilities I have to the business that I serve. First, and because I work in the clinical trial software domain where patient safety and data integrity are paramount, I have the responsibility to deliver high-quality and defect-free software. Next, since our software is used to generate top-line revenue, I have a responsibility to the business to deliver our software within predictable timelines so that our production, support, and business development organizations can operationalize the software and plan their promotional and sales activities. Finally, since the software development organization is a cost center, I have the responsibility to exercise disciplined stewardship over the resources entrusted to me so that I don’t adversely affect margins beyond the costs predicted in the budget. In summary, the business holds me accountable to balance “better, faster, cheaper” and to strive to deliver on all three.

The primary reason for the “pick two” nature of the relationship between “better, faster, and cheaper” is because much software is delivered late and can be of questionable quality. When this happens, software development capacity is lost to subsequent late project starts and to capacity that must be spent fixing defects when it could be used developing valuable new features. These two impacts conspire to raise the cost of software development. Further, as a software development project becomes late; the slippage is frequently mitigated by limiting activities that that tend to occur late in the software development cycle like integration testing. Pinching quality-enhancing activities reduce the overall quality of the software. In short, the key to delivering software more cheaply is to keep projects continuously on track to ensure that all software development activities, especially those that improve quality, are not subject to short cuts.

In the Delivery Risk model, we seek to identify and monitor the events that conspire to make software projects late and mitigate their effects early enough so that they don’t adversely affect the estimated delivery date. The events to monitor are requirements scope, resource availability impacts, and delivery risks. There are three assumptions that serve as precursors to implementing the Delivery Risk model. First, we assume that the software teams can provide reliable software estimates. We provide time to work out the design before the team commits to a date. Second, we assume that an aggressive software quality assurance mechanism is in place. In our case, we use aggressive automated unit testing covering more than 95% of the code to ensure that defects introduced by new code are detected and corrected quickly. Third, we assume that the product managers appropriately manage project priorities. Once a project is underway, it must not be preempted to service higher priority development efforts. Project “context-switching” not only drains development capacity but it also adversely affects staff morale. Estimation, automated testing, and project prioritization merit discussions of their own and are beyond the scope of this article.

The Delivery Risk Model

The intent of the Delivery risk model is threefold. First, it identifies tactical impediments to software delivery that need attention. Second, it identifies trending potential impediments to software delivery that might need attention. Third, it identifies and classifies risks that need monitoring and mitigation. The overarching goal of the model is to identify and track risks while there is still time to react and before their effects become detrimental to the overall delivery of the project. In short, the Delivery Risk model seeks to give early warning if the train is running off the tracks!

The first component is the tactical assessment of risk across all projects slated for the proposed release. In this assessment, we track scope, capacity, and delivery status.


In the above sample, each project contains a RAG (red/amber/green) status for each status element as well as the estimated delivery date. Scope status refers to the requirements or use cases that make up the project. Failure to lock down scope is among the highest risks to timely completion. In cases where an external customer provides requirements, as is common with data integration projects, we often track scope more granularly to ensure that the customer has agreed to the requirements and the development teams thoroughly understand them. We are less granular when the subject matter expertise is internal to the company. Resource status refers to the project staff itself. Resource risks can arise from unexpected staff attrition, illness, or paid time off. The delivery status refers to the project burn down as we will see shortly.

The five sample projects listed above are managed as a proposed release that we often refer to as the “program.”. The program team meets weekly and uses the representation above to discuss the current status of the project.

The second component is an assessment of the overall trending of each project comprising the release. For each project, we are especially interested in the deviations from expected burn down of project use cases against estimates. In a typical burn down chart, we compare ideal to actual burn down within an iteration:


In our case, we are interested in the deviations from expected burn down of project use cases against expectations. In short, we are more interested in the deviations around the ideal burn down rather than the burn down itself using the ideal burn down as the zero point on the x-axis and comparing against actual burn down on the y-axis. Further, we want to track and watermark the deviations across iterations to get a holistic view of how we are tracking against the target delivery date:


In the above example, each iteration is listed on the x-axis. The y-axis represents the deviation in use case burn down (velocity) from the expected team velocity needed to achieve the estimated delivery date. We translate this into a percentage increase or decrease from the expected delivery date. We then watermark the percentages to establish the RAG status. Finally, and to get a clearer view of the source of the risk, we break out the data by development role including Design, Development, Testing, and Product Management. We can do this because our SDLC contains process gates that allow us to track use case transitions through the process. There are some artifacts to note above. For example, if an activity has not started, it shows up as pegged to 100% overrun as in the case of Product Management approval of completed use cases. We know that such approvals are trailing indicators, and we are not typically alarmed by them unless they persist for long periods of time.

The delivery risk chart is probably the single most important tool in the model. It enables the team to see events trending over time. We have some simple rules that we apply to the trends. Green means that no action is needed. Amber means that we need to watch and plan for mitigation. Red means that we need to act on our mitigation plans. Using this tool helps us avoid a “happy path” mentality by showing us how we are trending well in advance of the delivery date. The team is constantly evaluating risks to delivery and considering mitigation strategies and helps us to avoid “fire drills” at the end of project since it spreads mitigation throughout the project.

The final component is the enumeration and assessment of potential risks. In our case, we maintain a risk register and review it weekly. When properly managed, the risk register contains those risks that the team needs to overcome to keep the project on track, rather than risks that caused the project to be late. Here is an example:


In our example above, we classify each risk for its probability of occurrence and the impact should it occur. We then note the strategy for dealing with the risk should it become real. Again, these are reviewed and adjusted weekly.

Cautionary Notes

I need to caution the reader on the use of the Delivery Risk model since there are limits to its use.

The Delivery Risk model IS:

  • A means to visualize current delivery status and risks.
  • A means to visualize trending status to allow staff to react earlier.
  • A means to ensure that all development activities get appropriate capacity attention, especially testing.
  • A vehicle to identify process improvements as part of a holistic, continuous improvement discipline.

The Delivery Risk model IS NOT:

  • An exact science. It is the combination of art and science intended to identify risks and mitigation early. The model is deliberately organic and depends upon the combination of data, insight, and trust.
  • A team or project performance metric. It should never be used as part of formal goal planning for individuals or teams. Nor should it be used as a mechanism to punish or intimidate teams or individuals.
  • A magic bullet. It can help you limit project overruns but may not help you avoid them altogether.


Bob Ponticiello and Phil Gower first proposed the Delivery Risk model while working at Princeton Financial Systems. Bob and Phil managed a large globally distributed software development effort and noticed that software quality seemed lower the later the software was delivered. They took years of waterfall delivery data and created a risk factor spanning many years of software releases. The “risk factor” was expressed in days expended beyond expected waterfall milestones (requirements, design, code, test) and was cumulative over the life of a project. They graphed the risk factor against the post-release defect count:


Their data revealed a 0.6 correlation (see the trend line) between risk factor (lateness) and post-release defect count (quality). We tested whether the relationship was causal by deliberately managing delivery risk against key waterfall milestones in subsequent projects. The theory was that if we managed to waterfall milestones, we would ensure sufficient time was allocated to each software development activity, especially thorough software testing. After a very short time, we were able to demonstrate that managing the risk factor not only brought the software in on time but allowed us to deliver higher quality software. I borrowed Bob and Phil’s idea and adapted it to Agile development methods. I feel fortunate to have worked with two such insightful and committed software development leaders.

Final Thoughts

The Delivery Risk model is an aid to getting projects completed on time while mitigating the risks to quality. When it comes together, it helps makes the most efficient use of a software development organization that translates directly to cost efficiency. Further, when used as an aid to continuous improvement, it can tap into the teams’ common commitment to delivering great software while promoting team communication and building trust. I truly believe that when open and honest communication takes place within a software development organization, the business can get results better, faster, and cheaper and will never have to settle for just picking two!



Designing an Accountable Software Development Organization Part 3: Roles, Organization, and Culture

In part 2 of “Designing an Accountable Software Development Organization,” I discussed creating a vision for the software development organization that serves as the desired end-state. I explained that levers and tensions exist between the organizational components of the end-state model as well as how they could be harnessed to drive stakeholder behavior in healthy directions. In this third and final article. I will show how to align the roles and organization of a software development organization with the levers previously discussed. Finally, I will enumerate a set of behavioral guideline that help to keep healthy tensions healthy while avoiding unhealthy tensions.

Roles and Organization

As a software engineer by training and education, I have always believed in a pragmatic “form follows function” approach. With few exceptions, I’ve been fairly successful when applying it to organizational dynamics or software development organizations. My goal then is to define roles and align organizations along the natural lines of the levers I previously defined. This way, I assign authority and responsibility that is inherent within the vertical domains directly to directors and their organizations. This alignment encapsulates authority and responsibilities within the discrete organization and assigns leadership to a single director who manages his/her team, negotiates healthy tension-related issues with his/her peers, and provides me with a single point of contact to report on the status of the lever under their care.

In my software development organization, I have defined three key organizations: product management, technical delivery, and operations. The roles flow from the responsibilities and authorities defined earlier:


I have made a few accommodations to a straight one-to-one alignment based upon the mission and skill sets. First, because my mission is to create a next generation product while maintaining and supporting the existing product, I have created two technical delivery teams. I found it prudent to ring-fence development staff within product domains to avoid having staff distracted by issues outside of their respective domain. For example, when I have had product teams intermingled, there was a temptation to divert key next generation product staff to solve knotty problems within current product domain. All too often, this proved a distraction to the mission of developing the newer product that I sought to avoid. Second, since the roles of risk tracking and process adherence are closely related without having inherent tensions between them, I collapsed both roles into an “Operations” domain and leverage the project managers in both roles.

Culture and Ethos

Now that we have defined the roles and organization along the lines of the levers, it’s time to turn to the management of tensions. The essence of developing great software lies with balancing the various forces at work within and between the organizational components. I have designed my organization such that healthy tensions bubble up to the director-level within each organizational role while minimizing the occurrence of overlapping unhealthy tensions. However, where there is tension, there is the opportunity for conflict. In keeping with my goals of engendering communication and trust, I have a simple set of rules for dealing with this that focuses on rules of engagement as well as encouraging professional maturity and development.

As described in the levers and tensions section, I make the responsibilities and authorities of each role explicit. I take a “carrot and stick” approach to describing the behaviors I expect and those that I wish to avoid. I set clear expectations for the directors as in the following example:


Setting clear expectations about authority and responsibility boundaries is frequently reinforced within the organization. The directors understand this and set development goals for their staff accordingly.

When inevitable conflicts do occur, I prefer to set expectations for appropriate means of resolving them. At the risk of sounding “preachy”, our business partners and peers expect and deserve to be engaged in a respectful and dignified manner even when disagreements arise. If a software development organization is to communicate effectively and engender trust, I believe that a high level of personal integrity must be maintained in interpersonal relationships. If we don’t behave appropriately, then we have little right to expect trust and respect in return. We have all seen recent reports where a major automobile manufacturer was caught cheating on emissions tests after marketing their engines as clean. This was a clear example of where a technical delivery organization broke the trust with their consumers by acting with low integrity. Consumers are correct to no longer trust their claims.

I provide a simple set of guidelines for engaging staff, peers, and their managers. I again mention behaviors I expect that those I wish to avoid:


I think most of these speak for themselves. I would like to comment on “taking the high road” a bit further. There are political issues and rivalries in any organization. Frequently, it is easy to take the approach of “fighting fire with fire.” I reject this approach for the simple reason that while such an approach might be emotionally satisfying, it will almost inevitably lead to regrets. Regret, whether in personal or professional affairs can be emotionally corrosive and ultimately self-defeating. I try to avoid situations leading to regret whenever possible.

Getting Results

So what results can you expect from a truly accountable software development organization? In my most recent experience, the software development teams saw positive quantitative and qualitative results over a three-year period. The teams’ on-time delivery went from hitting the mark less than 60% of the time to achieving on-time delivery over 90% of the time. The software quality as measured by post-delivery fixes increased by over 75%. While we applied the Agile Scrum methodology to an inherently risk-averse business domain, we have consistently passed client audits with only minor findings.

Qualitatively, our business partners report that they are more consistently satisfied with the software solution. This increased satisfaction has led to increased confidence in the software development organization. The software organization itself has developed a new confidence and sense of satisfaction knowing that they deliver high-quality solutions when the business needs them.

My experience is limited to software development and infrastructure technologies and I have applied the above techniques within those domains. However, the principles of empowerment and alignment should apply to any business domain. I would love to hear back from those who try their hand at the application of these principles!

Best, Charlie

Designing an Accountable Software Development Organization Part 2: Vision, Levers, and Tensions

In part 1 of “Designing an Accountable Software Development Organization,” I laid the foundation for software development accountability by translating the business needs required from the software development organization into a clear statement of purpose. I went on to define tenets and principles to support the mission and underpin its implementation. In this article, I will discuss creating a vision for the software development organization that serves as the desired end-state. Levers and tensions that exist between the organizational components of the end-state model will be covered as well as how they can be harnessed to drive stakeholder behavior in healthy directions. Finally, since behaviors can become unhealthy, I will discuss the source of such behaviors.


Other than in cases of natural staff attrition, new software development leadership is installed when the software development organization has not met the goals of the business that it is entrusted to serve. The new leadership has an opportunity to reset the organization to meet those needs. In almost all cases and after some reconnaissance, the new leadership defines a new organizational end-state. That end-state is intended accomplish specific goals. First, the end-state serves to operationalize the mission of the software development organization. Second, it points to realistic expectations and outcomes for the organization. Third, it provides a baseline for a regimen of continuous improvement. Finally, it helps establish a clear line of sight to the business goals and helps each member of software development organization understand how they contribute to those goals. In keeping with the principle of subsidiarity I discussed in the previous article, I recommend that you share the development of the end-state with your software development organization as it’s developed. Doing so both enlists the staff’s support in realizing the vision and gives them a chance to add criticism and correction in cases where you might fail to understand nuances in the existing culture or personalities.

In the example I used in the part 1, I was hired to shape a historically consulting-based software development organization into a product-centric and customer-focused one. The primary goal was to create and deliver new high-quality, innovative solutions predictably to the business while maintaining and enhancing existing products. I will add that this was in the domain of software supporting pharmaceutical clinical trials. For those who aren’t familiar this business domain, patient safety is of paramount concern. Because of this, it is among the most highly regulated and audited sectors of the software development space. Consumers of the software tend to be highly conservative and risk-averse. For example, customers routinely audit the software and the SDLC to ensure complete traceability between requirements and tests as well as to ensure that the SDLC is sound and followed meticulously. (As an aside, we implemented an Agile Scrum-based SDLC discussed in the article, ”Agile/Scrum Adoption in Regulated Industries.”) To address the patient safety concerns, we needed to produce exceptionally high-quality software that was well fit to the business need. To address the regulatory needs, we needed a strong focus on the software development lifecycle and its governance. We also needed to continue to support the existing product suite even as we developed its successor. It was clear that I needed strong alignment of authority and responsibility within the requirements, technical delivery, and SDLC governance domains. The organizational end-state was as follows:


The gray boxes to the left represent the sources of business requirements feeding the product pipeline. The arrows at the top represent the product development process including product management and development steps while the boxes below represent the organizational landscape needed to support the process. In short, this depicts the end-state for the software development organization. It also helps underscore the strategic goal of reliably delivering innovation while pointing to the organization needed to realize the tactical implementation.


The leaders of a software development organization constantly adjust the direction of the organization as the needs of the business change and as risks arise. They do so by exerting leverage on key areas of influence. In the case of the organization I was designing, I identified 4 “levers.” Requirements fidelity refers to the fitness for the business purpose and prioritization of the feature pipeline. Technical delivery refers to the development capacity, timelines, architecture, and quality. Process adherence refers to SDLC governance including audit fitness. Risk tracking refers to the reporting of project status and risks. The responsibility and authority within the domains are as follows:


As you can see, it was crucially important that the authority and responsibility aligned vertically within each domain. This vertical alignment ensures that each domain can act independently within their area of responsibility and drive efficient execution. The domains intersect at areas where healthy tension is required to balance the responsibilities of the domain. Those intersection points are precisely the leverage points where influence is best exerted. You will also notice that the intersection points are also places where the most discord can occur within a software development organization. These intersections were placed purposefully to ensure that healthy tensions rose to the level of the technology leadership visibility rather than being hidden from them.


I spoke of healthy tensions in the last section. In my organizational design, I wanted requirements fidelity, technology delivery, risk tracking, and process adherence to act as independently as possible while having the freedom to report risks without fear of consequence. For example, those responsible for the requirements have the goal of ensuring the product meets the needs of the customer. If some requirements complexity made it harder to develop technically, then I wanted that tension to be explicit so it could be adjudicated at the right level and by the right people. By the same token, insufficiently detailed requirements could create risks to timely technical delivery that needed similar adjudication.

I say these are “healthy” tensions because balancing them is necessary for the development of great software. However, I have seen organizations where the authority and responsibility overlap to create unhealthy tensions. Here are a few examples:


In the above example, I have taken the four levers and shown what can happen when inappropriate superiority/subordination occurs between the domains. For example, I once inherited a technical delivery team where the project manager reported to the technical delivery management. In some cases, projects were delivered late. I discovered that that project manager did not feel free to report risks to the delivery timeline leaving those risks largely hidden. Clearly, the project manager felt that there could be consequences if risks were reported that painted the technical delivery team in a bad light. Leaving these risks unaddressed was frequently the source of late technical delivery. Conversely, I have seen organizations where the project managers had the authority to set delivery timelines on behalf of technical delivery teams solely based upon when the business wanted the software delivered. It was no accident that the technical delivery teams seldom met the timelines since they were never given the opportunity to produce realistic estimates. In both of these examples, the morale of the staff suffered because they felt, correctly I might add, that they lacked the authority to execute on their responsibility to the business. The project manager in the first example and the technical delivery team in the second felt victimized. The remainder of the unhealthy tensions speak for themselves.

When designing your organization, it is important that you align the vision for the organizational end-state with the mission of the software development organization. The organizational components should balance vertical authority and responsibility with the requirement to make healthy tensions explicit. Care should be taken to avoid authority and responsibility overlaps that create unhealthy tensions that could sabotage meeting responsibilities and produce low morale. It can be a delicate balancing act. But when done with a deft hand, it can ensure that execution is efficient, and morale remains high since the teams have the proper authority to ensure that they can meet their responsibilities. Accountability is the natural outcome of a successful balance of authority, responsibility, and adjudication of healthy tensions. As each domain delivers on their responsibility, their confidence in their delivery capabilities grows. High morale for the software development organization and trust from their business partners are natural side effects of true accountability.

Preview of Part 3

In part 3 of this series, I will discuss aligning roles and responsibilities along the lines of the organizational levers. I will also describe engagement guidelines that can create a culture or “ethos” intended to keep healthy tensions healthy while limiting the expression of unhealthy tensions.

Stay tuned!

Designing an Accountable Software Development Organization Part 1: Tenets, Mission, and Principles

All too often the word “accountability” is associated with the word “blame” when used in the context of software development organizations. In these situations, the software development organization was viewed as somehow failing to meet the business need. Either the software solution came in late, or it contained insufficient features or quality to pass muster. Sometimes the software was seen to fall short on each dimension. When examining the causes of these failures, I have found that they usually result from three broad categories of issues. The mission of the organization was unclear, the technology leadership did not align the software development organization for success, or those same leaders did not empower their staff to be successful. Frequently, all three were the case.

In my previous article, “The Executive and the Software Craftsman,” I discussed how technology leaders can prepare their software craftsmen to make better business decisions. In my subsequent article, “The Technologist’s Guide to The C-Suite,” I went on to explain what the business expects from software craftsmen and other IT professionals. In both cases, it was important that the business and technology leadership built and maintained a strong relationship with their technology delivery staff based upon communication and trust. In a series of three articles, I will lay out a framework for harnessing that trust into an accountable software development organization by accomplishing three key goals:

  • Clearly enumerating a mission for the software development organization to ensure that all parts of the organization are pulling in the same direction. Basic tenets and principles must be spelled out that support the mission and underpin implementation.
  • Creating a coherent vision for the software development organization that defines the desired end-state. Flowing from the vision are levers and accompanying tensions that must be placed in proper alignment and managed to reach the desired end-state.
  • Aligning roles, culture, and ethos to help keep the tensions healthy while continuing to drive the organization in the right direction.


As with many other technology executives, I have had the benefit of working with and for some talented managers. Along the way, I have synthesized some basic tenets that guide my organizational design and development. These include:

  • In a principle called “Subsidiarity” problems are best dealt with at the most immediate or local level consistent with their solution. L. David Marquet describes this as locating authority close to the information needed to make decisions in his talk on Greatness. In a software development organization, this requires that the staff is armed with the best information to make good business decisions. Establishing line-of-sight to the business problems to be solved is critical to arming people with the best information to make decisions.
  • Healthy tension exists between departments and when properly aligned, can provide checks and balances to yield better outcomes. The tensions must be identified, explicitly called out, and managed, so they don’t become unhealthy. The assumption is that tension is a healthy and necessary part of the software development process. Misalignment or mismanagement of healthy tensions can quickly turn healthy tensions into unhealthy ones.
  • Clarity of purpose within the organization, alignment of responsibility and authority with a departmental domain, and management and adjudication of healthy tensions between departmental domains are the antecedents of accountability.
  • Good and bad culture (Ethos) is no accident and is a consequence of setting expectations for and management of healthy and unhealthy tension, or a failure to do so.


I’m sure most readers helped develop departmental or corporate mission statements and had rolled their eyes along the way. I’m no exception. All too often such statements are developed by committee and end up being watered down or so esoteric as to be meaningless. However, when done right, such statements can be essential to providing valuable context and clarity needed to align a software development organization with the business domain it serves. I have developed some simple questions and rules for developing mission statements for software development organizations that I have found helpful:

  • How does your software development organization specifically contribute to the business?
  • The mission should inform both organizational strategy and tactics.
  • Five or fewer bullet points should be sufficient to capture the essence of the mission.
  • The mission statement should be a reflection of the technology executives character and not reflect group-think.
  • The mission should stand the test of time and not significantly change from year to year.
  • The mission should be reinforced repetitively with the staff at every opportunity.

As a concrete example, I was hired at my most recent job to shape a historically consulting-based software development organization into a product-centric and customer-focused one. The primary goal was to create and deliver high-quality, innovative solutions predictably to the business. After two months of reconnaissance, I developed the following:


This mission has not changed in close to three years and continues to provide clarity to the department. I also reiterate it at every opportunity, especially during departmental briefings and strategy/goal planning sessions.


Just as I have development tenets that guide and inform my organizational design and development, I have developed principles that guide the development of great software. I use these to help my staff understand “what makes me tick” and help them understand what I expect from them and how I make decisions. As such, I humorously call them “Charlie-isms.”I like to think that some of these principles have helped in the career development of my staff. These are:


I will not delve deeply into all of these, but two are particularly near and dear to me. Since I was a developer myself for many years, I have a running joke that goes, “Software developers have two jobs: Fixing bugs and creating bugs.” When we consider this seriously, unfit solutions and low-quality code sap the development capacity of a software development organization. A persuasive business case for solution and code quality beyond the obvious ramifications emerge. Namely, that the production of quality software means that you can devote more development capacity to developing more great software rather than fixing what you’ve previously built. Hence, “Product quality increases development capacity.” There are sometimes valid reasons for taking quality shortcuts especially when timelines are critical. However, delivering low-quality software is seldom beneficial in the long-term.

As a second point, development organizations frequently feel besieged by their business partners when the software development organization does not meet the goals of the business. When this happens, the confidence of the software development organization can erode and lead to a culture of negativity within the organization that manifests itself as “no, but” responses to requests from the business. For example, when a software development organization is asked if they can deliver a given software component within a fixed time, the response will frequently start with a “no.” “No” is then followed by the enumeration of the conditions that will lead to a successful outcome. By the time the discussion turns to meeting the request, the people making the request have already decided that the software organization is an obstacle to progress rather than a partner to success. I counsel software development organizations to understand that most requests are reasonable given the right combination of requirements, time, and staff to deliver the solution. When engaging the business, I turn the conversation into one where the software development organization discusses costs of delivering the solution to meet the goals of the business. Once the business understands the costs of meeting the request, a “yes we can” rather than “no we can’t” tone becomes apparent. The business then views the software development organization as a partner committed to understanding and meeting common goals.

Preview of Part 2

In the next article, I will discuss creating a vision for the software development organization that serves as the desired end-state. Levers and tensions that exist between the organizational components of the end-state model will be covered as well as how they can be harnessed to drive stakeholder behavior in healthy directions. Finally, since behaviors can become unhealthy, I will discuss what can be done to prevent that from happening.

Stay tuned!

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?