Thursday, October 9, 2014

Cohesion Breeds True Synergy

Aloha and welcome back!  It has been quite a long time since my last entry and, after having dealt with "real life" on a number of important occasions, I am looking forward to engaging you in thoughtful discussions once again.

Lately, there have been examples, front and center in my professional life, where I have seen large opportunities missed.  Specific to my experience, these "cost" the company revenue in the sense that there was revenue that could have been earned but was not.  However, this could just as easily be a degradation of the professional credibility as a team (or member of a team), a lack of increase in operational efficiency (which does cost the company money in reality), etc. 

So what is cohesion exactly? Dictionary.com states the definition as the following:

cohesion [koh-hee-zhuh n],  noun - the act or state of cohering, uniting, or sticking together.

That is "content free," but Wikipedia's summary of the topic is more helpful.

When discussing social groups, a group is said to be in a state of cohesion when its members possess bonds linking them to one another and to the group as a whole. Although cohesion is a multi-faceted process, it can be broken down into four main components: social relations, task relations, perceived unity, and emotions. Members of strongly cohesive groups are more inclined to participate readily and to stay with the group.

This is more closely aligned to what I have always expected as the qualities of a cohesive group of professionals, so let's delve into the four main components in a different order from the summary, above.  (Reader's note:  the Wikipedia article does not discuss these four components as discrete entities, so the commentary below is purely my own and is not a recapitulation of what you will read within that article.)

Task relations.  Businesses have a singular, primary goal.  By definition, that is to generate revenue (which holds true regardless of whether the business is for profit or not), but even if it were possible for a company's primary goal to be altruistic, for example, that does not detract from the point that there is a singular primary goal to be achieved.  As a result, all activities within that company have the larger intention of "moving the ball forward," i.e. making progress toward achieving that goal.  It is imperative, therefore, that all employees of the company regardless of size realize what this goal is and make a conscious commitment to not only establishing smaller goals for themselves that are aligned with the larger goal of the company but also to being successful in reaching those goals.

Perceived unity.  Commitment to established goals is great, but only if the perception of that commitment is in agreement with that commitment.  For example, any senior manager will tell you that among the many skills they must have to be successful, one of the primary skills is managing the expections of the Executive Management Team.  Specifically, the senior manager has the obligation to present a unified face to their organization to those who are peering in from the outside.  This "unified face," however, is only possible with the consistent examination of the actions of each member from the perspective of how it will impact the opinion of others on their commitment.

To grossly oversimplify that last statement, each team member should be sure that they are "doing the right thing" with respect to "moving the ball forward," as was stated in task relations.

Social relations.  In order for task relations to be realized, however, it must also be recognized that people are individuals and not members of a hive mentality.  Individuals may make decisions that are perceived by those individuals as being in alignment with the goals being striven for when in reality the alignment may not be as strong or is missing entirely.  To prevent this from derailing the group's progress, the ability to foster open and honest dialog between all members of the group is also essential.  There are books galore on how to properly communicate with members of a team (The One Minute Manager and Crucial Conversations are two that immediately come to mind), but these presuppose the acceptance that, without effective communication, the group will fail in achieving its goals.

Emotions.  Finally, no one will deny that there is pressure, sometimes great, applied from the top down for every employee to perform at their best.  It is understandable, then, that one or the other may react from a place of emotion rather than intellect when they observe things that are perceived as putting the success of the team at risk.  While you, the reader, may consider this to be a natural consequence of social relations, it is worth highlighting this separately since people will occasionally allow their egos to take center stage rather than make an intentional effort to remove the emotional component of the situation so that the underlying problem may be addressed and eliminated.

I have seen the results when one of these four principles are not followed.  It wasn't because the individuals were acting maliciously, but the end result was still the same:  impacted team members reacted as individuals as statements were made or actions performed.  Ultimately, the performance of the team was impacted and the level of success achieved was adversely impacted.

As the expression goes, "there is no 'i' in team."  The equivalent expression in Mandarin describes this as "one heart, one mind."  Remember that everyone on your team (should) have the same goal and be committed to not only taking steps individually that move the team forward as a group but also discussing with each other when risks to that goal are uncovered so that they may be addressed as early as possible.

What happens when these is achieved?  Synergy is defined, loosely, as a situation where the net effect is greater than the sum of the individual parts.  Applied here, this is when the ability of the team as a whole to achieve the goal of the team is much easier than if each individual attempted to act independently.  This should be the ideal end state for everyone reading this, since there are tangible benefits to you as a professional to visibly achieving the goals that your team has.

Thursday, April 10, 2014

Death of a Programmer


During the 18 years that I was an application development professional, I took great pride in being a part of the elite group of geeks that could write an application that was needed by the business or desired by the public.  After all, I had spent 4 years in college formalizing the previous 5 years where I was cobbled away in the corner of the library or computer lab writing applications on a TSR-Model I (4K of RAM!), learning how to be a practitioner of the black arts.

And so when I first started seeing process automation solutions like BMC Atrium Orchestrator and later CA Process Automation, I was aghast.  "How dare they!" I bellowed.  "They're taking away my own secret sauce that makes me stand out from the crowd!" I yelled.  Never mind that I left application development in 2005 - I just wanted to maintain my status as one of the computer programming elite.

Lately, I've been getting more intimately involved with CA Release Automation.  And while I'm still recovering from the apoplexy of having my status revoked even further, I will grudgingly admit that this solution is...well...rather neat.

For those of you who may not be familiar with CA Release Automation or, more generally speaking, application release automation, this solution addresses the challenges in deploying a complex application to multiple environments each of which have differences in their make up.  (This normally would require a unique deployment mechanism for each environment to account for the differences.)  The CA solution, specifically, allows an author to create a deployment process that is based on the application architecture and is agnostic to the target environment.  It is only when the process is executed that the solution discovers the target environment topology and maps the process to that environment automagically.

What makes this solution so fun to play with is in the way that it implements this "logical process" concept.  Providing a nice graphical interface, the author is allowed to string together actions that are to be executed.  These actions can be interfaces with the operating environment (e.g. start a website on IIS) or programmatic operations (e.g. manipulate a string).  Variables (called parameters), parallel execution, and conditional / branching logic are all supported.

In other words, this is a graphical way to write an application.  No prior programming experience is required.  Furthermore, a library of predefined actions for doing things like interacting with various, popular infrastructure components (some related to the application like the IIS example and some indirectly related like interacting with a source code repository or ITSM solution to check the status of a change order that was entered by the Help Desk).  This action library currently contains over 1,100 actions and is updated on a monthly basis.

I realize that no one is going to write a first person shooter or the next version of Flappy Bird using this technology - since this is a process authoring solution - but I can easily imagine this concept being taken further to allow fully graphical application development much like we were led to believe was on the horizon when LOGO was first released in 1967.

Tuesday, March 25, 2014

I'm Looking for a New Job!...

...And you're reading this because you thought I was serious.

A number of months ago, an EVP and member of the Executive Management Team emailed me to say he wanted to spend a few minutes chatting with me.  He and I had met, face to face, for the first time the week prior and I left a positive impression on him that he wanted to explore further.  In the spirit of full transparency, I allowed this meeting to stay visible in my work calendar in spite of the risk of my management chain seeing it and misunderstanding.

So, of course, my manager did see it and did misunderstand.  He called me up a week after the appointment was made (but still before the actual date of the meeting) and seemed distraught that I didn't trust him enough to tell him if I were dissatisfied with my role.  This was the inspiration for a previous blog entry where I contrasted the concept of happiness versus contentedness in one's role.  Another part of my discussion with my boss, that I did not describe in that blog entry, revolved around the activity itself.

Humpty Dumpty? Who's that?
During that part of the discussion, I compared my meeting with the EVP to a sales pipeline.  Was I looking for a new job?  Not necessarily, I said.  But just as a sales professional builds a pipeline that is 4 times their quota because they know that 75% of those potential deals will fail, one cannot take a sequential approach to something as strategic as looking for the next step in their career.  Instead, you have to be willing to entertain all things even if you're not explicitly looking to change jobs at that particular moment.

Or, as the cliché goes:  "don't put all your eggs in one basket."

Expanding this to a more general discussion, devising an effective strategy for anything is part marketing, part sales, and part operations.

Marketing.  Development of an effective strategy requires effective communication of that strategy.  And that starts by understanding what, exactly, it is you're trying to achieve.  For example, when building a public relations campaign, one of the first things you do is answer the questions:  who needs to know, who needs to be involved, who will be effective, and what is the take away for each of those three groups?  Answering these ensures that you thoroughly understand the topic to which your strategy applies and are able to articulate it well.

Sales.  The actual activity of articulating that message, however, is more sales than anything.  Unless you're in a position to simply dictate your expectations and press the proverbial "Go" button, you're going to have to convince others of the strength of your position.  This means that you need to not only understand the topic, but you must also understand the benefits of its execution and the risks of not doing so.  Measurable data points allow you to objectively communicate the latter part of that and also allow you to track it going forward if your strategy is adopted.

Operations.  Tracking its success is incredibly important, as you'll undoubtedly agree, because you will need to know as soon as possible if things don't work as expected and address the problem immediately.  This may require on the fly adjustments or a complete reversal of your position.  Since a compete reversal / rollback would result in a hit to your credibility, contingency plans must be developed and ready to execute should the need arise.

You're probably asking yourself, "is all of this really necessary?"  The answer is neither yes nor no, but instead depends on the importance of the goal itself and the cost of failure.  To put it another way, execution goes a long way but without the guidance to know where you're going you'll only get lost along the way.

Monday, March 10, 2014

Apple Did What?

Figure 1.  The iOS code exhibiting the SSL handshaking problem.
(Originally published on www.servicevirtualization.com)

As a veteran of the application development industry, I can share plenty of horror stories about things that just "went wrong," from a tape backup software vendor not having a backup of my hard drive and then having the hard drive fail after I left, to projects that were canned after being in development for four years without a single beta release.

During those 18 years, however, I can recall having to go through a very rigorous process while working on Wall Street whenever any code was considered a Release Candidate for production.  Essentially, any code to be rolled out to production had to pass a code review by your peers, and we all took delight in shooting down other members' code, all in the name of quality.  In one instance, a library of common routines that I created after refactoring a few of my own applications was stuck in repeated reviews for six months before it was finally approved (after many adjustments on my part).

So, it's with this hindsight that I look at the gaffe by Apple where SSL handshaking wasn't being properly validated (that ultimately resulted in iOS 7.0.6 being released during the end of February), and I marvel that this even happened in the first place. Essentially, a superfluous "goto" statement was left in the code, causing it to exit out of the validation routine prematurely.  The code in question is shown in Figure 1 (taken from the Wired UK article with indentation reformatted to better fit here).

Although static code analysis tools such as HP Fortify and CAST should have caught this immediately, this lends itself to a discussion on why establishing a discipline such as Service Virtualization is so important.  It has been discussed repeatedly how virtualization decreases as the software progresses to the right of the SDLC (i.e. closer to a production release), but things are slightly different in reality as illustrated in Figure 2.

In this diagram, you can see that there are actually two types of virtualization that are utilized in the process of writing a software application:

Intra-application virtualization is the exercise of developing virtual services for components that exist within your own application. This occurs because components upon which a developer is dependent do not exist due to code development prioritization that is based upon the priority of the underlying business requirements. However, these availability constraints eventually work themselves out and, as a result, the need to virtualize those other components is reduced to zero at some point.

Figure 2.  The two types of virtualization
Inter-application virtualization is much different due to the underlying need that it satisfies. Here, other applications with which your application interacts have independent release cycles, independent infrastructure requirements (i.e. not typically covered by your application's CapEx budget), etc. Most importantly, these factors typically require virtualization of those systems to occur up to the go live date.

(I realize these statements about the length of usage of virtualized services is not entirely accurate because there are legitimate situations where the end of virtualization may be extended or contracted.)

Regardless of the type of virtualization being used at any given time, virtual services are developed based on the flow of data between components as part of one or more transactions. This flow of data is independent of the code in that it is frequently "designed" in advance of any code being written.  As a result, the data reflects the desired end state of the application or, to put it another way, what would be observed "on the wire" if the code were 100 percent correct.

Furthermore, because virtual services are essentially data and little more than data, the set of responses that can be returned by a virtual service in response to any given transaction is fully within the control of the owner of those virtual services. This allows the consumer to more easily test negative cases such as boundary conditions, off by one errors, etc.

This brings us back to the Apple problem. As you know, SSL is a technology that is used to facilitate secure communications between multiple software entities. And while both endpoints could be within the same application, more frequently it is used in inter-application communication.

The point is that virtual services could have easily participated in the SSL handshaking instead of live code. (More importantly, that inter-application virtualization would have existed a lot longer during the SDLC as noted in Figure 2.) And, since virtual services are just data that can be modified to setup specific testing scenarios, it would have been trivial to reproduce the condition that resulted in the premature exit of the handshaking code in iOS 7.

Monday, March 3, 2014

WhatsApp, Revisited

While researching for my blog entry about the Facebook purchase of WhatsApp, I wanted to get the opinion of someone who has industry experience in this sort of thing.  So I reached out to my good friend and former colleague Mark Pilipczuk who is a marketing veteran with 25 years of experience and a former SVP at AOL.  My question to him was simple:  did the purchase make sense when taking the cost into consideration.  His answer is below.

"I haven't spent any real time thinking about whether the $19B was a good/bad/indifferent deal.  What I have been thinking about is the YouTube acquisition by Google a few years back. Many thought the purchase for $1.65B in stock was excessive, particularly for a startup that had no real revenue model and had some serious potential copyright issues. In fact certain three letter ISPs looked at YouTube a couple of times prior to that and couldn't make the math work for an acquisition.

What Google was betting on--it turned out correctly--was the explosion of interest in the sharing and mashing up of video content. Google wasn't paying for a certain number of MAUs
(Monthly Active Users. -Larry) or how that rate of increase might continue or accelerate. Instead, they were betting that the number of minutes of video uploaded was going to explode and that the consumption of those minutes would also explode, shifting attention (and therefore media dollars) away from TV to online.

I believe Facebook's purchase of WhatsApp makes sense in general for the following reasons:

  • Facebook "and..." Facebook is no longer the "one-stop-shop" for social networking. It's also not dying among teens, regardless of what you might see in the headlines. Rather people are tending to use multiple networks and applications, depending on their needs. The basic one is Facebook supplemented by something like Instagram, Snapchat, Vine, etc.
  • Social networking moves to mobile. With the greater capabilities of mobile phones, it's easier and more convenient to do almost everything from our phones. There's no need to go back to the desktop to accomplish too much creation and all the consumption can be done from the handset.
  • All time spent online moving to mobile. It's not just social networking moving online. It's all time online moving to mobile.
If you're Facebook, you'd like that second/third app to be in your family of brands. Even if you don't monetize WhatsApp and put ads on those screens, you can certainly use the data to monetize Facebook. Getting access to that transactional and behavioral data is a good thing as it keeps it in-house and eliminates the need to license the data separately.

I think of the acquisition in terms of getting access to lots of data and gaining share of handset, particularly among the 2nd/3rd app being used for social networking. With the acquisition, the Facebook social graph on users gets more robust.

I think we'll continue to see Facebook acquire fast-growing apps, even if they don't have revenue models for the foreseeable future.

Now is $19 billion a good price? Absolutely no idea and I honestly don't believe anybody who's trying to model it out has a clue. If you're trying to value it on a per-user basis, which implies that the acquisition has some expected break-even, you're missing an important thing. Facebook, much like Google, isn't beholden to Wall Street. Zuckerberg and other insiders have control of the company's voting shares. They are already fabulously wealthy and can afford to play the long game, much like Brin and Page at Google. They don't have to justify the purchase price to anybody else and, if other shareholders don't like it, there's nothing they can do except sell the stock.

I think that for sure we'll look back and think tactically this was a good purchase. We may have a different opinion on the price, but I think that like the YouTube purchase, it'll be a few years before the jury returns.
"

Thanks for the amazing insight, Mark.

Friday, February 21, 2014

WhyApp?

"Why? WHY?"  That's the question many people are asking themselves in the light of Facebook's historic $19B acquisition of instant message maker WhatsApp.  I must admit I was puzzled myself at the price tag, but found no shortage of Internet pundits (on Forbes and CNN Money, to name just two) willing to justify the cost based on a number of factors.

Personally, I prefer quantifiable measurements.  And while my weapon of choice is typically financial metrics, such as NPV, IRR, and ROI, when it comes to M&A targets of this type where the primary driver is the size of the acquired company's user base, I switch to the advertising metric Cost per Thousand (users), or CPM for short.  ("M" is the Roman numeral for "thousand.")

CPM rates are typically used for things such as online advertising and name list rentals (i.e. when you register on a website your information is rented to other companies who can specify that they want a pool of demographic data that meets certain, very specific criteria).  Because its roots go back to advertisements in printed publications (remember those?), its use is ubiquitous and provides a consistent framework with which to analyze the quality of the acquisitions made for reasons of increasing one's user base.

Looking at the CPM of this acquisition in the context of other acquisitions made, presumably, for the same reason you see nothing interesting.


This, in and of itself, is interesting because this is the first metric I would have expected the company to evaluate when discussing a list of potential M&A targets.  (On a side note, Microsoft's acquisition of Skype is eye opening when viewed from this perspective, so it's no wonder that the acquisition is generally viewed as a failure.)

Since all of these companies bring substantial amounts of revenue from advertising, and advertising is used to drives sales, I decided to look at this from the revenue perspective.  However, this requires some context in order to properly evaluate the numbers, and since the king of all online shopping is Amazon that's what we will use to establish this context.

In July 2012, the website Internet Retailer quoted a figure from eDataSource saying that the average Amazon order value in June of that year was $47.31.  While this figure was derived from the examination of only 30,000 orders (vs. the 164 million paying customers in total that it had as of an article written in March 2012), it is statistically relevant enough to use it as the basis for our analysis.

The reason why CPM's usage as a metric to determine the quality of the purchase of advertising over the years is because "eyeballs" can be directly correlated to purchase decisions of the owners of those eyeballs.  Get more eyeballs and you get more revenue from purchases made.  But even though Internet based advertising should, in theory, allow a researcher to get a very accurate revenue figure based on advertising (psychological aspects of purchase making notwithstanding) this requires a degree of transparency that advertisers are typically not willing to share.

To assist, a second metric was developed way back when Yahoo was king of Internet advertising (remember those days?) in the late 90's.  That metric, Click-through Rate (or CTR), allows a copy to reasonably predict how well their advertisements will, at the very least, translate to a visit of their website.  2% is considered to be a very good CTR, so I decided to use 1% for my purposes.

Using these two figures, we can get an idea of the potential revenue that Facebook can expect, assuming those 450mm users on WhatsApp are not existing Facebook users.  This is highly unlikely, but in the absence of hard data quantifying the amount of overlap, I'll assume the best case scenario of 0% overlap.


The subheadings under Potential Revenue list the number of purchases per year using the $47 per order figure from Amazon to calculate revenue.  Assuming 10 purchases per year, WhatsApp (in the hypothetical base case scenario of 0% overlap) brings in a substantial amount of revenue.  But it is still puny when compared to the purchase price.

So why did Facebook buy WhatsApp for that amount?  Maybe those Internet pundits aren't so far off after all, listing reasons such as the typical demographic for WhatsApp being the younger age group that Facebook is losing profusely or the supposed $10B offer that Google made to buy the company, a move that Bridge players will recognize as a preemptive bid to shut out the other players.

What's your take on this?  Leave a comment!

As a final note, during my research I found an interesting discussion of mobile based instant messaging and its impact on telephone companies.  Bloomberg quotes research from Ovum that states phone companies lost $33B on texting fees to free instant messaging applications like WhatsApp, and says that number will balloon to $54B by 2016.  Without access to the underlying research data it's hard to say the accuracy of the analysis since large metropolitan areas (like the greater NYC area) often have high degrees of competition resulting in unlimited, free texting, but the number is still substantial enough that the carriers cannot avoid it.  Look to this to be an untapped area to be exploited by Verizon, AT&T and others in the coming 12- to 24-months.

Tuesday, January 14, 2014

Happy vs. Content

Some time ago, my manager at the time was having 1-on-1 calls with each of his staff to do a routine temperature check.  During my call with him, he asked me a common question:  are you happy?  This is not an uncommon question, to be sure, but I wanted to use this blog entry to highlight the difference between being happy and being content in one's employment situation.

You may accuse me of splitting hairs, but the answer I gave to my manager highlights the difference between the two states.  I said to him, "I am definitely happy in my job.  You are a great manager; you have earned my respect as a business professional; and you allow me some latitude to do things that are outside of the scope of my responsibilities, which keeps my job interesting."  And then I continued, "but am I content with my role?  No."

Three parts to this recipe
How is it possible for someone to be happy but not content?  You can look up the definition of the two words if you wish, and argue the philosophical aspects of this question over a cup of camomile tea, but a more practical definition is needed if it's to help you actually get to a state of contentedness.

So what is required for someone to be content?  I came up with three components:

Responsibility.  People like to know that they are valued.  And there is no greater indicator of this than to have responsibilities beyond the mundane.  There will always been the mindless activities to do, whether you are entering time in Salesforce, mopping the floor at your after school job, etc.  But to have something beyond the mundane shows a level of trust in your capabilities for which there is no substitute.

Impact.  However, responsibility alone is not sufficient.  For if the task given to you has no real impact on your group, division, business unit, or company then it's easy to come to the conclusion that the sincerity behind the assignment of the task is superficial.  In other words, it's easy to imagine the following conversation:

Manager 1:  who do you think we can convince to paint the roof?
Manager 2:  ah, let Larry do it.  If he messes it up, no one will notice.  After all, who looks at the roof?
Manager 1:  Larry!  Come here!  Boy do I have a great job for you!...

Compensation.  This final component is probably the least surprising.  Nothing will get someone riled up more quickly then finding out that their peers who have similar sets of responsibilities are being paid more than they.  I cannot count how many conversations I have had with coworkers where they have complained that they were the least paid of anyone in their role.  (Whether they were in reality is another point entirely.)  I, myself, have also had pains of jealousy when I felt I was underpaid.

There are myriad articles on the Internet about discussing compensation with one's manager, but I would argue the same principles apply to the other two components described above.  And while these discussions are not always easy to have, the possible reward of true, long term contentedness are worth overcoming the resistance you may have to sitting down, talking about your desires, and setting mid- to long-term goals for the future that allow you to reach this state of nirvana.

Tuesday, January 7, 2014

Is Success the "End Game?"

(Originally published on www.servicevirtualization.com)

I've often felt that technologists are very good at thinking in terms of whites and blacks, since problems in the realm of IT are often expressed as one of two states:  either the server is responding, or it isn't; etc.  So it's unsurprising that executives with strong backgrounds in technology (vs. the CxO who is more business focused) think that success is often a good stopping point.  After all, if the server has an uptime of 99.9999% then you really can't do much better.  Can you?

The answer depends on how you define "success."  It's easy enough to define a threshold and state that crossing that line is what success is.  But I would challenge you to justify the particular threshold that you have established.  For something like 99.9999% uptime that may be easy to do, but for something where the threshold is much lower (and, consequently, the potential upside is larger) you will have a much more difficult time convincing me that you cannot do better.

This is especially true in process related situations where automation is not being fully utilized.  In previous blog entries, I've quoted the following figures, which come from Forrester's Q4 2010 Global Release Management Online Survey:
  1. 64% of the respondents were dissatisfied with the level of automation in their software release processes.
  2. 54% of the respondents were dissatisfied with their ability to recover in the event of a problem either during release or with the application.
  3. 50% of the respondents were dissatisfied with the speed of each iteration of the release process.

Items 2 and 3 are the result of item 1, since processes that are primarily manually executed do not typically have rollback capabilities built in nor are they speedy.  This may mean that an organization has deluded itself into thinking it is Agile in its ability to respond to ever changing market conditions when, in reality, it is Fragile instead.

To the original point, your company's PMO may examine the portfolio of projects underway and determine that a high percentage of them are operating within time and budget constraints, so they are happy.  But how do you reconcile their satisfaction with the three items listed above?

To answer:  you don't.  Your processes can always improve.  And, from the same survey, when 44% of the respondents said that it would take a week or longer to roll out a change to even a single line of code, you can start to appreciate exactly how much improvement is possible, at least in the example of application release stated here.

The detriment to getting an action plan adopted and executed is one of determining the financial impact of not executing such a plan, i.e. your primary competitor is inertia.  The plain reality is that many organizations do not measure the adverse results of a lack of automation.  For example, do you know how much more revenue your company would generate if it could quadruple the number of releases of your primary revenue generating application per year?  Do you even know how you would determine this figure?

The upside potential of integrating automation into your processes (whether Dev or Ops processes) should be compelling enough to warrant investigation into the matter.  Take a look at the metrics currently used to demonstrate success.  Determine which of those are really metrics of the metrics, and then look at the core metrics to see if they are really in line with current industry expectations.  Finally, examine how automation would allow those core metrics to be raised so that your organization can become more Agile and less Fragile.