The Value and Risk of RACI

When looking towards the Delivering at Speed dimension of Excellence by Design, it’s worthwhile to understand roles and responsibilities and, more importantly, the criticality of effective communication and collaboration in delivery.  To that end, I wanted to provide a quick commentary on the value and risk of RACI as an enabler in the process.

Many who have worked with me know that I’m not a fan of the RACI tool.  In this article, I’ll cover what I consider good and not so good about it.  Hopefully the concepts will be helpful.

At the end of the day, what makes teams effective is a collective investment in success.  That takes courage and a willingness to do whatever it takes to deliver, particularly if a project is complex or high risk.  Where individuals and teams don’t lean into that discomfort, things can easily become imbalanced, inefficient, and ineffective… and the opportunity for excellence is lost.  The ultimate reality is that technology delivery is messy and complex, it involves dealing with adversity and is not for the faint of heart, which is why courageous leadership is the first and most critical dimension to driving excellence in an organization.

A Quick Refresher

For those who may be unfamiliar, the RACI tool is used to help clarify roles and responsibilities across a set of constituents against a defined set of activities, deliverables, or whatever is relevant to the conversation.

The process is generally to have a facilitator populate a grid in two dimensions, with stakeholders or teams as a set of rows and the activities or deliverables across an entire project lifecycle (as an example) as the columns.  Once the teams and work are clarified, the team then typically goes a column at a time, noting which teams have which responsibilities using the RACI notation to indicate who is:

  • R – Responsible (DOER – primarily responsible for performing the activity)
  • A – Accountable (LEADER – ultimately accountable for the execution)
  • C – Consulted (ADVISOR – asked to provide input, in a supporting role)
  • I – Informed (LISTENER – notified of the status or outcome, but not involved)

A conceptual example of a completed RACI chart could look something like this:

Generally, there should only be one “Accountable” party per activity, though there can be more than one individual or team “Responsible” for performing the work.  In many cases, “R” and “A” go together, though there can be situations where someone is playing a general contractor-type role who is Accountable, but someone else is actually playing a subcontracting-type role who is Responsible for performing the work.  In one of my previous employers, we occasionally collapsed the “R” and “A” categories into a single “Owner” (O) role, which indicated the individual or team who was both responsible and accountable and simplified the facilitation of the exercise.

 

What’s Good about RACI

In my experience, the value of a RACI discussion is in the conversation, not the tool. 

The conversation is helpful in two primary respects:

  • Clarifying the scope and breadth of activities/ deliverables/ responsibilities that are associated with whatever the cross-functional team is trying to accomplish
  • Having an understanding of the anticipated interactions of that cross-functional team against those activities

On the latter point, the exercise can be particularly helpful for a newly formed team or on a new type of effort where the combination of activities is emerging and the interactions across the team against those activities isn’t clearly understood.

The discussion itself gives the team a chance to engage, interact, experience the various communication and leadership styles and, in the process, talk about the work they need to perform.

 

Where Things Go Awry

…So what’s the problem?

Well, the problem is sometimes in the mindset of the participants as they enter the discussion and how the tool is ultimately used in practice.

Things to watch for in a RACI discussion:

  • Asserting Control / Promoting Exclusion
    • There are times when participants use the tool and process as a way to establish their authority to make decisions (as the “Accountable” party) in a way that excludes others
    • In these cases, the RACI tool can become a hammer that enables dysfunction and empowers poor leadership
  • Showing a Lack of Accountability
    • There are times when the tone of discussion shifts towards an “us” and “them” conversation and the concept of “team” is subjugated to who is accountable if something goes wrong.
    • In this situation, the tool becomes a hammer to assign blame and undermine partnership
  • Encouraging a Lack of Collaboration
    • Finally, the stronger the contrast between “RA” and “C” comes across, there is risk of an underlying level of dysfunction that goes beyond activities and deliverables
    • While the tool and process are meant to help foster healthy discussion on primary accountability and roles, an extreme version of its use can feel like there is a lot of “throwing things over the wall”… and that is normally something you can hear in the discussion itself

Summing this up, while RACI can be a useful tool, it can also be a mechanism to stratify dysfunction in an organization, enable poor leadership, assign blame, and do more harm than good.

 

Breaking Down the Model

In thinking about the above, the question arises: Ok, so what do you do about it?

In a previous employer where we conducted a lot of client workshops, we would start with a predefined set of ground rules and allow the clients to add to the list as they saw fit.  Depending on the group assembled, there were times when that flexibility actually would go astray and the rules became a long, laundry list of “what not to dos”.

If the discussion started to feel unhealthy, we would suggest that we reset the list back to two things:

  • Do what makes sense
  • Do the right thing

In practice, almost any situation that would arise in a workshop setting could be addressed with those two principles and they are simple and broad enough that they cover what you need to facilitate a session on about any topic.

Going back to RACI, when the discussions go astray, the same type of principles may be helpful to set the tone for collaboration as part of the effort.

 

Summing It Up

Stepping back from the tools and process, the critical point to remember is the importance of communication and collaboration in a cross-functional team.

In my experience, when people are effective collaborators and the underlying relationships are sound, there isn’t a need for RACI discussions.  People work past boundaries, sometimes swap responsibilities where the capabilities of individuals are roughly equivalent, and the team is focused less on “who owns what” and doing what they need to do to meet the conditions of success.  There is a mindset of mutual support and partnership… and the efficiency of the execution will be much higher by extension.

Most of the time, when I hear someone request or suggest a RACI discussion, I assume there is an underlying issue or source of dysfunction.  It doesn’t mean the conversations can’t be useful in helping to surface and address those concerns and challenges, but it is important to understand they are not a cure all if the outcome is just a snapshot of something that wasn’t working effectively in the first place.

Hopefully the concepts were helpful.  As always, feedback is welcome and appreciated.

-CJG 06/06/2022

Thoughts on Mentoring

Before addressing the subject at hand, just an acknowledgement that I’m considerably behind where I want to be in writing this blog.  With another eight topics in the backlog, it may take a while to get “caught up”, a concept that I pray is achievable in practice, or I need to hire some ghost writers.  Hopefully the concepts will continue to be worth the time spent reading them.  Feedback and other ideas for articles are welcome.  These continue to be an expression of my point-of-view.  There is plenty of room for debate and dialogue, and it’s welcome.  That is, after all, where innovation and improvement originate.

With regard to mentoring, in my earlier article on Excellence by Design, I referenced the importance of talent development in relation to Operating with Agility.  I’ll write separately about workforce and sourcing strategy in an upcoming post, but the purpose of this article is to explore the mentoring process, both from the perspective of the mentor and mentee.

 

Setting the Stage

First of all, the mentoring process itself requires two critical components: a willing coach and an engaged participant.

Mentoring isn’t something you can “kind of” do if you expect to have an impact on an individual.  You need to meet them where they are in their journey, be mindful of their aspirations and needs, and find the right way to provide guidance that will lead to sustainable, long-term growth.  Mentoring, from my perspective, is more than “feedback”, insofar as the latter is generally situational in nature and somewhat transactional or provided within the context of a current role or assignment.  Mentoring is really about longer-term capability development when done properly and requires more of a strategic focus on behaviors and overall career goals.  In a talent development sense, this is akin to why there is a difference in many organizations between performance reviews and career development plans, which contemplate longer-term goals of the individual, not limited to execution of their current responsibilities.

From the standpoint of the person being mentored, it is equally important to be engaged in the process in a healthy way.  Looking back at my own experiences, there were times when I was receiving good career advice that I was either too inexperienced, too insecure, or probably too headstrong to receive and learn the lessons I needed to at the time they were being provided.  Fortunately or unfortunately for me, as has been said many times, when you don’t learn those lessons or take them to heart, they will keep re-presenting themselves to you, sometimes painfully so, until you actually are open and receptive to them.  Success ultimately requires humility, reflection, and a fundamental acceptance that we’re all on a journey, no matter what stage we are in our careers, and there is always something to learn if we want to be better at what we do.

Said very simply: if the mentor or the mentee don’t engage effectively, the process will fail, and both individuals actually will lose opportunity as a result.

Looking back on the last thirty years of my career and seven employers, I’m very grateful to the leaders, some of whom were not my direct managers, who took the time to help move me forward in my journey.  In many ways, my success is their success because, without those little nudges and sometimes very pointed smacks upside my head to get me to the right place, I wouldn’t be where I am, and I owe very much to them for caring enough to spend that time helping me along.  While I may be very motivated and self-directed, I do want and need that advice and guidance just as much now as I did when I was a kid out of college writing software for a living.

 

Putting “Growth” in Perspective

When talking about mentoring, I believe it’s important to spend a couple moments on “growth” (in terms of promotions) by comparison with capability development.

While, in a perfect world, developing your capabilities would ideally go hand-in-hand with your level of responsibility or relative seniority in an organization (whether that’s in a management capacity or not), the reality is that they often don’t.

Promotions take three things in my experience:

  • Opportunity – There has to be a spot to which you can move with the desired role
  • Advocacy – You need someone from a management standpoint to make the case for change
  • Accomplishment – You need to have delivered something or created value that helps to substantiate your worthiness to assume more organizational seniority

If any of the above is missing, in the vast majority of cases, you won’t be promoted and, if you find yourself in an organization where advocacy and opportunity are enough for people to be promoted without actual accomplishments… you’re probably not in a high-performing organization, because results and/or proven leadership should be part of the process, otherwise it would suggest people are promoted for other reasons than demonstrated capability (yes, I’m an advocate for meritocracy).

So, the fact that these things can be out of synch having been acknowledged, here’s my overall point-of-view when it comes to career development: focus on your capabilities and the recognition will catch up in time.  Said differently, when you build your skills and knowledge, they become part of who you are and what you bring to an organization.  If those things go underappreciated over time, you will eventually find other opportunities that align to your capabilities where those talents are recognized and valued, presumably you will pursue those situations (at some point), and things will be in sync again.

 

Why being a mentor is so important

From the perspective of the mentor, it is worth stating that it is a primary responsibility of a leader to help develop others and make the organization better, whether in a managerial capacity or not.  Sharing knowledge, providing feedback and advice, and actively collaborating with others in solutioning situations are things that anyone can do, regardless of their role, and all of which contribute to helping develop and grow others.  Whether that is, in a “formal” sense, mentoring or not, informally it can very much help advance the cause of developing talent over time.  It makes others better, it creates value for the organization, and makes you a more valuable contributor to the organization as well.

Another lens to put on being an effective coach is that, when done well, it actually makes you a better performer by extension. 

Thinking back on a non-work example, I coached baseball for nearly ten years in my twenties.  As a coach, it was important to me to understand the fundamentals of what I was sharing with our team and individual players in the interest of helping them improve.  In an area like hitting, with all the years I played baseball growing up, I don’t think I ever really thought about the mechanics of a swing at the same level I did when I started trying to coach others… primarily because I was committed to doing the best I could to making them better players.  Oddly, what I found was that, aside from imparting that knowledge, I also became a much better hitter myself and the process of internalizing those things stuck in a way I didn’t expect.

Coaching in a professional setting is very much the same thing, because ideally a good mentor should be thinking through the mechanics of what they are recommending to an individual and, in doing so, it becomes a very healthy reminder and opportunity to “sharpen the saw” yourself.

 

My overall advice to the prospective “mentee”

From the perspective of the individual wanting to be mentored, my advice would fall into four areas:

  • Find and develop relationships with mentors who can help you over time and who are committed to your personal and professional success. I mention the personal dimension, because so much of developing over the course of a career involves soft skills and behaviors that extend beyond the workplace into daily life. Good mentors should ideally be people who you respect and trust, and who you view as being knowledgeable and capable in areas you’d like to develop yourself.  This doesn’t need to be an immediate manager, though it’s great when that happens.  It also doesn’t necessarily have to be someone “senior” to you in an organization, as the process is more about developing skills and capabilities that you lack than the relative position of the person that is helping you.  In reality, mentors can span positions and jobs, so it’s more important to choose the right person(s) than the expedient one(s).  Mentors can also come and go over time, and that’s fine as well, as long as you benefit and learn through the experience.
  • Have a clear idea (or a reasonably clear one) in terms of what you want from an aspirational standpoint. Your goals matter, they can be everything from a behavioral quality or actual capability you would like to excel in to a position you’d ultimately like to hold (even if that’s only a short distance from where you currently are).  Make sure your mentor is aware of those goals, and guide them in terms of where you’re seeking the most help.  A good mentor should be able to evaluate where you are and help provide the right guidance based on your needs and the circumstances, but it doesn’t mean your input is any less important to the process. It’s your life, it’s your career, and you have the ultimate vote in whether the process works for you.  At the end of the day, the only person accountable for managing your career and ultimate success is you.
  • Remember that you can learn the most from those who differ from you and you don’t need to have just “one” mentor. Over the years, I’ve been lucky enough to cultivate an amazing set of coaches who help me improve, but they come in all shapes and sizes for different needs, and that’s great from my perspective.  I have mentors who help me on a more strategic and broader level and others who help guide me on more tactical, skill-based needs.  The mixture is something that works for me.  Some of the best coaches I’ve had are also those who have behaviors or approaches that are polar opposite of mine.  Those relationships have been extremely helpful, given those with similar thoughts and approaches as me won’t as easily be able to provide insight on my blind spots or opportunities to think differently as those who actually are different.  Whether you ultimately choose to model or learn their behaviors or not, you can always seek to understand and learn from those perspectives and that will make you a more well-rounded contributor over time.
  • Finally, it’s important to recognize that your career is a long-term investment, and one of the most important ones you make in life. Investing in the right coaches and committing yourself to continuous learning is the best way to increase your probability of success, in whatever it is you choose to do (and being exceptional at it over time).

Keeping the above points in mind should help make the process more effective as long as you continue to engage with it in a positive and productive way.

 

The connection into Excellence by Design

In an earlier blog article, I wrote about the “The Power of N” and maximizing the collective potential of a team.  I will write an article about expanding that potential further, when we look at organizational aspirations and portfolio composition, but for now, I’ll wrap this up with a simple, but important point:

Where we don’t invest in ourselves and our long-term development and, by extension, when we don’t help people achieve their potential as leaders, we suboptimize the results we can achieve as an organization.  The investment is always worth the time.

 

So….

On what are you working to improve and who is helping you get there?

Who are you helping to achieve their potential?

 

As always, I hope the information and thoughts were helpful.  All the best in achieving the sum of your aspirations, and in being an inspiration and guide to others as well.

-CJG 06/02/2022

On Managing Customer Relationships

One of the challenges associated with Courageous Leadership and achieving Excellence by Design is knowing how to effectively manage customer relationships.

In the consulting environment, there is generally a measurable connection between client satisfaction and the revenue trajectory of an account (whether that’s expressed as stable annuity or growth over time).  In a perfect world, this is ideally driven based on a blend with how you are managing the relationship and the quality of your service delivery.  In the corporate IT world, it is a little more difficult to measure, but certainly there are indicators on whether a business partner is satisfied with the support they receive, whether it is expressed in feedback processes, involvement in critical strategic discussions, the collaborative dynamics of the relationship, etc.  In both cases, whether a consultant or an IT leader, the goal is generally to be a “partner at the table”, which is a very often used, but rarely achieved situation.

 

Describing What “Good” Looks Like

At an anecdotal level, some simple litmus tests on the health of a customer relationship:

  • Does the customer involve you actively when ideating or forming a business strategy?
  • Would the customer or a neutral third party refer to you as more of a “partner” or an “order taker” in business discussions?
  • Are conversations when issues arise handled as a fact-finding and joint solutioning opportunity or as a beat down/”do what I say” discussion (conceptually)? This is normally very perceivable in the tone and direction of the discussions as they occur.
  • Does the customer openly seek feedback and input as to how new/advanced technology can drive innovation and adjust plans accordingly?
  • Are prioritization discussions occurring when new opportunities arise as part of a larger portfolio management process? Are those conversations collaborative?  Are initiatives stopped or deferred as an outcome of the exercise, or are portfolio discussions largely a snapshot of all the work that has come through the demand management process and is planned for delivery?
  • Is the delivery environment sustainable from a utilization and pace of execution standpoint?
  • What are the average hours worked per employee? Is there time being spent in learning and talent development?  Are technology standards and strategies being implemented or set aside in deference to critical “priorities” on an ongoing basis, resulting in accumulated technical debt?

Worth noting, I’m calling out a number of dimensions above intentionally and not leaning on “the customer said they are happy” for a reason… namely that, there are many situations where customer satisfaction is largely based on a sense of having control over priorities and actions in a relationship and where no effective partnership exists.  Again, the simple test for this is: what happens when the parties disagree and, in those circumstances, what percentage of the outcomes are ultimately what the customer originally wanted?  I don’t know how to estimate this with any precision, but if the answer to the question is directionally something like 80% or more of the time, and the consulting/IT team taking on more work without any remedy or accommodation, it would be hard to argue there is much “partnership” in practice.

 

Where The Best of Intentions Creates Challenges

It isn’t news that being highly motivated in a delivery environment is a blessing and a curse.  On the positive side, motivation and a passion to deliver is what can propel an individual and those leading teams to achieve sometimes incredible results, despite the odds that otherwise could undermine their success.  On the flip side, a belief that anything can be accomplished can also lead to issues when leaders view tradeoffs or compromises as an inherent sign of failure or weakness in their customer’s mind and they take on too much when they should be seeking balance in the overall situation instead.

In practice, organizations often sign up for too much, stretch beyond their internal capability to support the volume of ongoing work effectively (with critical skills and knowledge where it is needed) and ultimately create an unsustainable environment.  This is generally FAR more costly than taking a reasoned, fact-based approach to portfolio management and prioritizing the mix of ongoing work effectively (something I will likely write about as part of Operating with Agility).  The resulting effects of this situation are fairly prevalent in my experience across many organizations and clients in the last 30 years, namely missed delivery commitments, technical debt, poor quality, lack of value realization, employee burnout (and ultimately attrition), and unhappy customers.

Overall, a healthy and credible customer partnership should be created by establishing mutual trust and respect, acting with integrity, and making fact-based decisions in the interest of maintaining a sustainable environment that delivers quality solutions with agility and speed at scale.  Admittedly, that’s quite a lot.  Easy, right?  Of course not, but what in that statement isn’t the aspirational end state?  If that level of partnership and delivery environment isn’t the goal, what is?  That might be a discussion worth having from a leadership standpoint.

 

Some Examples to Consider

Having been in both consulting and corporate environments, I’ve seen a number of situations where managing customer situations has been challenging.  To share some examples:

  • Where the skills were insufficient
    • Having completed a lengthy engagement with an existing customer, I was asked by the account exec on a strategic account to speak to a prospective client about a potential new portfolio of work related to data warehousing.
    • In the call, the client walked through where they were, the work done to date, the forward-looking plan, makeup of their team and areas where they could possibly use some assistance.
    • Overall, the project was thoughtfully organized, fairly complex, and the areas of opportunity were outside our organizational capabilities because the depth of skill and experience required was beyond anything we had. Subcontracting those capabilities also wouldn’t have offered any material benefit to the client that they couldn’t obtain by contracting the skills directly on their own.
    • As a result, I thanked the client for the opportunity but said we weren’t well positioned to help. The prospect’s response was literally “I’ve never heard a consultant say that before” and they thanked me profusely for being candid about our ability to meet their need.
    • As you might expect, the account executive, on the other hand, called and yelled at me for some time given I was meant to sign the client up for work, regardless of whether they needed our help or not, with the implication being that a very informed customer “didn’t know what they needed”, which is why we needed to sell the work.
    • In a positive twist, the prospect went back to their leadership and gave such a positive review of the conversation and us having done the “right thing” that they ended up offering up a different piece of work that was in our wheelhouse to deliver.
    • Was the conversation a mistake? Not in my mind.  Would I do the same thing again?  Yes, for certain, because I’d rather accept what we can and can’t do successfully than sign up for everything and ultimately have an adverse impact on the work as a whole.
    • Probably to this day, the account exec would argue that I messed that situation up, but unfortunately that’s the nature of consulting at times when revenue goals cloud matters in relation to ethics and integrity. The account team was primarily incented to reach a target, not a healthy client relationship and sustainable delivery environment (which is not unusual in consulting as a whole).
  • Where the timing wasn’t right
    • Coming out of a successful delivery engagement with a new client, our executive sponsor referred us to a peer, who had recently assumed responsibility for the integration of an acquired organization. We were asked to help develop a strategy and some new customer-facing technology that would bring together and align the existing and acquired company products into one cohesive solution.
    • With the best of intentions, we started into what was a roughly an 8-12 week scoping and visioning activity, engaging teams from both the parent company and new acquisition.
    • What we rapidly realized was the major challenges and headwinds associated with being engaged so early after the transaction had been announced and nearly every deliverable we had planned for the early portion of the engagement fell very far behind schedule.
    • In preparation for our first sponsor checkpoint (~week 4 as I recall), we realized the probability of completing the engagement within any reasonable timeframe was extremely low and we decided to pivot to providing an update on where we stood in addressing the various challenges we were facing, such as the lack of a brand strategy, team dynamics, technology integration issues, major strategy decisions that would need to be made, etc.
    • In preparing for the checkpoint, we reached out to our prior sponsor who had referred the work to us for advice on how to approach the situation. His guidance was, thankfully, to be open and direct with where we were.  Whether he ultimately gave our new sponsor a heads up in advance of the discussion, I don’t honestly know, probably because I was too young and inexperienced at the time to think of that possibility.
    • In any case, we met with our sponsor, talked through the challenges, and his response was to pause and ask us “so, you’re saying it doesn’t make sense to do this right now?” to which we responded, “yes”. He expressed appreciation for our candor, the project was stopped in-flight, and the client spent time focusing on the integration of their teams before trying to proceed further on any implementation work.
    • As it happened, the sponsor also left the organization relatively soon thereafter and, based on the impression he had of us and our work, contacted us from his new place of employment to explore opportunities to engage us again.
    • Our actual project had only lasted around a month and didn’t deliver anything, and yet built enough credibility for the customer to come back from a completely new direction.
    • In retrospect, while I believe we handled the situation correctly, we should have had a sidebar with the sponsor to give him a heads up ahead of the checkpoint so he knew what was coming before we got to the meeting itself. Thankfully that didn’t blow up in our face, but it would’ve been a more thoughtful way to handle the situation than what we did at the time (largely out of inexperience between me and other people in the account team at the time).  Overall, I consider the project a successful failure because we didn’t waste the client’s money on an outcome we never would’ve accomplished in a reasonable timeframe.
  • Where the solution made no sense
    • As part of an internal team reviewing another engagement, the delivery team introduced us to a project they were about to initiate with their existing client. The overall engagement was going very well, and the opportunity to create a “management tool” came up as an adjunct to the larger program in motion.
    • For those of us outside the account, the proposed solution seemed immediately problematic and we challenged the team on why they were pursuing the work at all, given the complexity of what was desired, the likely cost of the project, and the questionable amount of value they could ultimately produce IF they figured out a way to do what the client was requesting.
    • The response from the team, not surprisingly, was that the client was “very excited” about the project, they were eager to sign the agreement and kick off the effort, and we should be more focused on how to help the team solution by comparison with asking why they were doing the project at all.
    • As you might expect, the engagement team ultimately had the authority to move forward with the work (and business), we noted our concerns in the review material for our industry leadership and the project got underway.
    • I don’t remember how far along it occurred, but somewhere after at least a couple months of execution, a change in client in leadership occurred, the new leadership reviewed the in-flight projects, and immediately questioned the nature, scope, and value of what the team building this tool was doing. The project was stopped, the account team took a major credibility hit, the larger engagement ran to completion, and no follow-on work came to the team as a result.  Worth noting, the larger program was worth something over 10x the revenue as the smaller tool project, but the relationship impact from the trust that had been lost was significant enough that the larger engagement was damaged.
    • This is a difficult situation to assess in retrospect, because the team was eager to solve a client need and be responsive. The problem is that the solution itself didn’t make sense, added no value, and was essentially a ticking time bomb from the moment it was conceived.  At a minimum, had the engagement team raised the concern and documented it somewhere in the course of initiating the project, there may have been some resource to mitigate the damage done once the overall direction changed.
    • The other takeaway from this situation is that a solution should objectively make sense and create value so that, in the event that circumstances and sponsorship changes, the work itself should be worth continuing. If the need for a project is largely subjective in nature, there can be downstream risk that the investment itself may not be in the best interest of the company (or client).
    • It could be argued that, as an outside team, it was far easier for us to call out the potential issue than the team engaging with the client directly (and that’s 100% true). However, the entire reason we had review teams was to provide an objective lens on the ongoing delivery work, in the interest of providing input and guidance to teams, but also to help them assess revenue at risk.  We provided exactly that input, but it was largely discarded in deference to securing the revenue.
  • Where there was a historical lack of trust
    • As the start up on a first engagement with a new, large client, a teammate and I had the opportunity to meet with the client CIO for an introduction.
    • His opening statement to us was “I could buy a company of your size tomorrow if I wanted to, what makes you guys any different and why do we need to talk?”
    • After the tumbleweed blew across the room… and we drew a collective breath… my very young, overconfident, and inexperienced mind told him that we could also get a set of contractors, give them a copy of Microsoft Visual Studio, and ask them to do the project even cheaper… BUT… that’s not what buying consulting services is about. You’re buying experience, culture, methodology, passion, and a commitment to success.  If successful delivery was about tools and technology, then everyone would be great at it, but unfortunately that’s not how things work, which is where we come in.
    • In retrospect, thank goodness I was young and inexperienced, or I might have been more intimidated. To his credit, the client probably knew that, he paused, apologized for being abrupt, and then told us that nearly every consultant he works with started by saying they were going to deliver a project but “then the minute I turn around and open the safe to pay them, they are looking over my shoulder to see how much more money I have in there.”
    • For whatever reason, I suspect the fact that I focused more on successful delivery and not “partnership” (which translated into future revenue opportunity in his mind) made a difference in getting off on the right foot.
    • We left the meeting with an invitation to come back whenever we wanted which, given the size of the client and how generally inaccessible their CIO was at the time, was a notable achievement.
    • In retrospect, what I believe worked was the unfiltered nature of a genuine and honest response, and I think the client picked up on it by comparison with more “polished” consulting pitches he likely heard on a regular basis from people much more experienced than I was then.
  • Where the engagement approach itself was poor
    • The final example I’ll share relates to having an ‘all or nothing’ mentality when it comes to discussing higher risk efforts.
    • With a change in senior executives, a directional statement was made with regard to a desired amount of technology delivery (i.e., X major releases per year) the new leader wanted to be part of the future environment.
    • The CIO and leadership team assembled a set of “educational” materials to help the new executive understand why the desired pace was unachievable. The message was not met well, either by the new executive or the head of the company, both of whom considered it a lack of leadership on behalf of the CIO and technology leadership team.
    • In retrospect, the entire issue was in the approach to the response, because the reason the IT leadership believed the request couldn’t be accomplished was, aside from technology-related issues, the business dependencies in delivering at that pace were generally unmet and would require an unprecedented level of speed by the business teams working with IT overall. The team assumed those items would never change and therefore wrote off the new executive’s request without ever considering whether he’d be willing to explore ways to address those challenges.
    • This situation has actually bothered me for a long time, in part because of the risk averse nature of the CIO and leadership team at the time, but also because the discussion could have been approached in a positive and partner-oriented mentality. “We’d like to help accomplish these goals and we will do X, Y, and Z to support it.  We also, however, need your help in making sure that we can do A, B, and C from a business standpoint as well, because those are critical dependencies in our ability to meet those objectives as well.”  That discussion never happened and rather than further the idea of IT as an enabler or partner, the reputation of IT as an impediment or barrier to success was furthered.

Putting Things in Perspective

In all of the situations described, it’s safe to say that none were “easy”, all involved some level of risk, and the stakes were generally high in some way or other.

What I’d say is fundamental in all cases for having healthy client relationships is:

  • Being open and transparent in communications, noting objections where appropriate
  • Operating with integrity, no matter what the pressures of the situation are
  • Remembering to put value in the center of the conversation and the desire to make things better. A partnership isn’t about control, it’s about mutual respect and understanding, listening, and collaboration in the interest of finding the right solution to challenges

It’s worth noting that our reputation is what transcends individual decisions, projects, and jobs over the course of a career (whether within one employer or across many)… and it doesn’t take long to do substantial damage to one if you’re not careful.

Recognizing there are opportunities to improve partnership in customer or client relationships isn’t a condemnation or criticism of any current or past situation I’ve encountered.  It’s a recognition that, by acknowledging dysfunction and identifying opportunity where it exists, we create space to make things better and lay the foundation for excellence.  It takes humility, but also courageous leadership to drive change where it’s needed, and that will always be worth the effort for the betterment of an organization.

Hopefully the ideas were worth the time it took to read them.  As always, feedback and reactions are welcome and appreciated.

-CJG 04/09/2022

The Intelligent Enterprise

Setting the Stage

I’ve mentioned the concept of “framework-centric design” in a couple articles now, and the goal here is to provide some clarity with regard to where I believe technology and enterprise architecture strategy is heading.  A challenge with trying to predict the future of this industry is the number of variables involved, including how rapidly various capabilities evolve, new technologies are introduced, skills of the “average developer” advance along with the tools enabling them to perform their work, methods of integrating and analyzing data arise, etc.  I will make various assertions here.  Undoubtedly some things will come to pass and others will not (and that’s ok), but the goal is to look forward and consider the possibilities in the interest of stirring discussion and exploration.  Innovation is borne out of such ideas, and hopefully it will be worth the read.

That being said, I believe certain things will drive evolution in how digital business will operate:

  • A more “open systems” approach will be driven by market demand that reduces proprietary approaches (e.g., on various SaaS and ERP platforms) that constrain or inhibit API-based interactions and open data exchange between applications
  • Technologies will be introduced so rapidly that organizations will be forced to revisit integration in a way that enables accelerated adoption of new capabilities to remain competitive
  • Application architecture will evolve to where connected ecosystems and strategic outcomes become the focus of design, not the individual components themselves.
  • As an extension of the previous point, secure digital integration between an organization and its customers, partners, and suppliers will become more of a collaborative, fluid process than the transaction-centric model that is largely in place today (e.g., product design through fulfillment versus simple order placement).
  • “Data-centric” thinking will be replaced by intelligent ecosystems and applications as the next logical step in its evolution. Data quality processes and infrastructure will be largely supplanted by AI/ML technology that interprets and resolves discrepancies and can autocorrect source data in upstream systems without user intervention, overcoming the behavioral obstacles that inhibit significant progress in this domain today.
  • Cloud-enabled technology will reach edge computing environments to the degree that cloud native architecture becomes agnostic to the deployment environment and enables more homogenous design across ecosystems (said differently, we can design towards an “ideal state” without artificially constraining solutions to a legacy hosted/on-prem environment). Bandwidth will decide where workloads execute, not the physical environment.

Again, some of the above assertions may seem very obvious or likely where others are more speculative.

The point is to look at the cumulative effect of these changes on digital business and ask ourselves whether the investments we’re making today are taking us where we need to be, because the future will arrive before we expect or will be prepared for it.

The Emerging Ecosystem

In the world of application architecture, the shift towards microservices, SaaS platforms, and cloud native technologies (to name a few) seem to have pulled us away from a more strategic conceptualization of the role ecosystems play in the future environment.

Said simply: It’s not about the technology, it’s about the solution.  Once you define the solution architecture, the technology part is solvable.

Too many discussions in my experience start with a package, or a technology, or an infrastructure concept without a fundamental understanding of the problem being solved in the first place, let alone a concept of what “good” would look like in addressing that problem at a logical (i.e., solution architecture) level.

Looking back in time, we started with a simple premise of automating activities performed by “knowledge workers” to promote efficiency, consistency, collaboration, and so on, where the application was the logical center of the universe.  In some respects, this can still be the case where SaaS platforms, ERP systems, and even some custom built (and much beloved) home grown solutions tend to become dominant players in the IT landscape.  Those solutions then force a degree of adaptation of the systems around them to conform to their integration and data models, with constraints generally defined by the builders of that core system.  In a relatively unstructured or legacy environment, that could lead to a significant amount of point-to-point integration, custom solutions, and ultimately technical debt.  What seems like a good solution in these cases can eventually hinder evolution as those primary elements in the technology footprint effectively become a limiting constraint on advancing the overall capabilities of the ecosystems they inhabit.

Moving one step in the right direction, we decouple systems and move towards a level of standard integration, whether through canonical objects or other means, that provides a means to replace systems more easily over time.  In the case of a publish-and-subscribe based approach, there is also a way to support distributed transactions (e.g., address change in a system of record being promoted to multiple, dependent downstream applications) in a relatively linear sequential manner (synchronous or otherwise).

In a way, the “enterprise middleware” discussion has felt like a white whale of its own to me, having seen many attempts at it fail over years of delivery work, from the CORBA/DCOM days through many iterations of “EAI” technologies since.  The two largest problems I’ve seen in this regard: scope and priorities.  Defining the transactions/objects that matter, modeling them properly from a business standpoint, and enforcing standardization to a potentially significant number of new and legacy systems is a very difficult thing to do.  I’ve seen “enterprise integration” over-scoped to the point it doesn’t create value (e.g., standards for standards sake), which then undermines the credibility of the work that actually could reduce complexity, promote resiliency and interoperability, and ultimately create speed to value in delivery.  The other somewhat prevalent obstacle is the lack of leadership engagement on the value of standard integration itself, to the point that it is de-prioritized in the course of ongoing delivery work (e.g. date versus quality issue).  In these situations, teams commit to “come back” and retrofit integrations to a strategic model, but ultimately never do, and the integrity of the overall integration architecture strategy falls apart for a lack of effective governance and adoption during execution.

Even with the best defined and executed integration strategy, my contention is that they fall short, because the endgame is not about modeling transactions, it’s about effective digital orchestration.

The shift in mental model is a pivot from application and transaction-centric thinking to an ecosystem-centric approach, where we look at the set of components in place as a whole and the ways in which they interoperate to bring about meaningful business outcomes.  Effective digital orchestration is at the center of how the future ecosystems need to operate.

The goal in the future state is to think of the overall objective (e.g., demand generation for a sales ecosystem, production for manufacturing, distribution for transportation and logistics), then examine how each of the individual ecosystem components enable or support those overall goals, how they interoperate, and what the coordination of those elements needs to be across various use cases (standard and exception based) in an “ideal state” to optimize business outcomes.  The applications move from the center of the model to components as endpoints and the process by which they interact is managed in the center through defined but highly configurable process orchestration.  The configurability is a critical dimension because, as I will address in the data section below, the continuous optimization of that process through AI/ML is part of how the model will eventually change the way digital enterprises perform.

Said slightly differently, in an integration-centric model, transactions are initiated, either in a publish-and-subscribe or request-response manner, they execute, and complete.  In an orchestration-centric model, the ecosystem itself is perpetually “running” and optimizing in the interest of generating its desired business outcomes.  In the case of a sales ecosystem, as an example, monitoring associated with a lag in demand could automatically initiate lead generation processes that request actions executed through a CRM solution.  In manufacturing, delays in a production line could automatically trigger actions in downstream processes or equipment to limit the impact of those disruptions on overall efficiency and output.  The ecosystem becomes “self-aware” and therefore more effective in delivering on overall value than its individual components can on their own.

With a digitally connected ecosystem in place, the logical question becomes, “ok, what next?”  Well, once you have discrete components that are integrated and orchestrated in a thoughtful manner that drives business outcomes, there are two ways to extend that value further:

  • Optimize both the performance of individual components and the overall ecosystem through embedded AI/ML (something I’ll address in the next section)
  • Connect that ecosystem internally to other intelligent ecosystems within the enterprise and use it as a foundation to drive digital integration with customers, partners, and suppliers

In the latter case, given the orchestration model itself is meant to be dynamic and configurable, an organization’s ability to drive digital collaboration with third parties (starting with customers) should be substantially improved beyond the transaction-centric models largely used today.

Moving Beyond “Data Centricity”

There is a lot of discussion related to data-centricity right now, largely under the premise that quality data can provide a foundation for meaningful insights that create business opportunity.  The challenge that I see is in relation to how many organizations are modeling and executing strategies in relation to leveraging data more effectively.

The diagram above is meant to provide a simplistic representation of the logical model that is largely in place today to provide insights leveraging enterprise data.  The overall assumption is that core systems should first publish their data to a centralized enterprise environment (data lake(s) in many instances).  That data is then moved, transformed, enriched, etc. for the purpose of feeding downstream data solutions or analytical models that provide insights as to how to address whatever questions were originally the source of inquiry (e.g., customer churn, predictive maintenance).

The problem with the current model is that it is all reactive processing when the goal of our future state environment should be intelligent applications.

In the intelligent enterprise, AI/ML serves two purposes:

  • Making the orchestration across a set of connected components more effective. This would be accomplished presumably by collecting and analyzing process performance data gathered as part of the ecosystem’s ongoing operation.
  • Making applications more intelligent to the point that user intervention is greatly simplified, data quality is automatically enforced and improved, execution and performance of the component itself is continuously improved in line with its role in the larger ecosystem. Given there are not a significant number of “intelligent applications” today, it would seem as if the logical progression would be to first have a “configurable AI” capability that could integrate with existing applications, analyze their data and user interactions, and then make recommendations or simulate user actions in the interest of improving application performance.  That capability would eventually be integrated within individual applications as a means to make it more attuned to individual application-oriented needs, user task flows, and data sets.

The implication on enterprise data strategy stemming from this shift in application architecture could be significant, as the goal of centralizing data for a larger “post-process” analytical effort would be moving upstream (at least in part) to the source applications, eliminating the need for a larger enterprise lake environment in deference to smaller data pools that facilitate change at a component/application level.

Wrapping Up

Bringing it all together, the purpose of this article was to share a concept of a connected future state technology environment where orchestration within and across ecosystems with embedded optimization could drive a significant amount of disruption in digital business.

As a conceptual model, there are undoubtedly gaps and unknowns to be considered, not the least of which is how to manage complexity in a distributed data strategy model and refactor existing transactional execution when it moves from being initiated by individual applications to a central orchestrator.  Much to contemplate and consider, but fundamentally I believe this is where technology is going, and a substantial amount of digital capability will be unlocked in the process.

Feedback is welcome.  The goal was to initiate discussion, not to suggest a well defined “answer”.  Hopefully the concepts will stir questions and reaction.

-CJG 03/27/2022

Courageous Leadership, Relentless Innovation, and Pushing the Envelope

First of all, it’s been a while since I’ve had a chance to share some thoughts on here.  Hopefully I can make up for lost time with a few articles on short order, but time will tell. 

As I’m rapidly approaching my 30-year professional milestone, I’m reminded that the reason I began this journey was to relate and share experiences in the interest of (hopefully) helping others avoid some of the many mistakes I’ve made over the years.  In my mind, if you’re lucky, you are doing things as part of your professional (and arguably personal) life that are challenging enough to create the conditions to fail or minimally sub-optimize outcomes to the level that you’ll reflect and realize there was a better way to approach things if you had another chance.  That is fertile ground for learning and development.  Said differently, we only truly understand our potential when we challenge ourselves to reach beyond our established norms and pursue aspirations to achieve and accomplish more.  Ideally, over time, we also become more self- and situationally-aware, so we continue to adapt and adjust how we do what we do, minimizing negative impacts and maximizing the value we create while things are still in motion (versus during a “debrief”/retrospective process).  That’s ultimately a byproduct and benefit of experience and, unfortunately, it’s the kind of thing you appreciate once you have it if you’re humble enough to admit you make mistakes in the first place.

Focusing specifically on the topic at hand, I was thinking about innovation recently and a keynote address I heard a number of years ago.  The speaker made a point about the difference between “best practice” and “innovation”.  His overall point was that there was a significant difference between the two and leaders often unfortunately weren’t doing a good enough job distinguishing between them.  In the case of best practice, you have a process or approach that has been done so many times that there is a well understood and generally accepted “best” way to do it.  If that is effectively true and we seek to do things in a way that aligns to best practices, how innovative can what we’re doing actually be?  What is truly unknown or exploratory in that situation?  Arguably not very much, and yet best practice thinking is often recognized and sought out from a leadership standpoint as a way to drive process or operating improvement.  Is that necessarily a bad thing?  Not necessarily, because it could be that the nature of the area is not one where any level of significant change or transformation is anticipated or desired and the organizational goal is really just to stabilize something and make it execute well and consistently enough that it is not having an adverse impact on overall performance.

Where I’d suggest there is room for thought is whether this “status quo” is true anymore in the world of digital business.  Is there really ever a case where you have a process that is so static that there is literally no room for making it better?  I’m not sure.  Can you make it more predictive, automated, integrated with customers/partners/suppliers, quality-oriented, etc.?  The complexity of digital business, particularly in terms of integration, speed, quality, and customer centricity would tend to make me think that even the most mundane of our solutions to current problems provide opportunities to improve.  If that’s the case, then I’d offer that relentless innovation is worth consideration. 

The litmus test can simply be this question: if you had a blank sheet of paper and had to design your process in a perfect world, would it work exactly how it does today?  If you set aside limitations, constraints, the current operating environment, and opened up the discussion to the realm of possibilities on what excellence could look like in that domain, what would it be?  If it looked different from current to desired state, what would you do about it?

This isn’t to suggest change for change’s sake or having a lack of priorities as there is a point to prioritizing efforts based on maximizing value, but it doesn’t mean we shouldn’t have a vision of a desired “ideal state”.  The point is that it’s very easy to accept the status quo and the perceived safety of the known in terms of best practice and lose the opportunity that comes with continuous reinvention.

This is where courageous leadership comes into play and we should ask ourselves why we prefer the best practice solution to true innovation.  Is it the safety that comes with not taking the risk of exploring the unknown?  As leaders we can take the safe route, let others take the risks for us, learn from their mistakes and implement only those things that are generally accepted to work (and work well).  Where does this leave us, however, in terms of establishing competitive advantage and differentiation in the marketplace?

Technology delivery is challenging and it is becoming even more the case as the pace of innovation is accelerating.  Most organizations will struggle with being able to adopt and integrate new technologies as they emerge over time and limit their competitive position as a result.  That is somewhat related to antiquated architectures and infrastructures that stifle innovation and change (something I will address when I write about framework-centric design and the future of enterprise architecture), but I believe it’s also related to a lack of organizational agility and courage in terms of innovation itself.

Innovation should be uncomfortable.  By that, I mean there should be an element of the unknown that creates a healthy discomfort you may actually fail in the pursuit of what you’re doing.  If it isn’t “scary”/exhilarating at some level, are you really pushing the boundaries of what’s possible or just re-treading a path that others have explored before you?  This is not an argument for being undisciplined or taking unnecessary risks.  Rather, the point is to understand that true innovation should be pushing the boundaries of what is actually achievable to the point that you could fail.  If what you’re doing is simply an iteration of current solutions, at the pace technology is advancing overall, the odds may well be that what you’re doing will be obsolete by the time you ultimately deliver it (if it involves any scale or time to execute).  Said differently, if you’re going to set an innovation goal, make it audacious and one worth achieving in its ability to truly transform your business, because the alternate path will eventually lead you to obsolescence.

Having worked on innovative efforts at various points over my career, one thing that I have come to look for (as a watch item) is a lack of fear/awareness on a delivery team when what they are doing is still fairly new or unproven.  Experience tends to give you a sense of what to watch out for, or minimally an awareness that, as you delve into areas of technology delivery that are not very mature, you are going to encounter unexpected issues that will threaten the ultimate success of your effort.  Leaders who have operated in this space generally seem to know that, so their enthusiasm over pursuing the next “big thing” tends to be tempered by a healthy dose of humility on what they don’t know, need to understand, have on their “watch list”, etc.  That, to me, is a sign of strength and experienced leadership.  Where I’ve had a decent number of “lessons learned” in the past is exactly the opposite situation, where we took on a difficult challenge and took a “we got this” mindset (and there’s nothing wrong with being highly motivated), without really appreciating the complexities of what we were doing to the point that, when things eventually went sideways because of an unknown in the delivery effort, we were ill prepared to adapt and address the situation.  Experienced leaders know what they don’t know or minimally that they have blind spots that they need to identify.  Motivated inexperience tends to breed overconfidence and that’s dangerous when it isn’t held in check with discipline.

In creating an environment for excellence, the challenge for leaders is to create space for individuals and teams to experiment and innovate while making it safe to fail when things don’t work out.  It’s better to fall short of accomplishing something great and strive for true innovation than to excel at the routine and find yourself overrun by your competition at some point in time (and it’s only a matter of time if you encourage safety over courageous leadership).

Hopefully the thoughts were helpful…

-CJG 03/21/2022

Leadership – Setting the Tone

Having thankfully (and finally) gotten past writing about IT as a whole, I’ve wanted to write on a dimension I associate with engaged leadership, which is the role a leader plays in establishing the conditions for success.

Before diving into the specifics, I believe everyone in an organization can and should think of themselves as a leader with the opportunity to contribute in meaningful ways (see my “Power of N” article for more on that).  I’m referring to leaders in a managerial capacity for the purposes of this piece.

 

Setting the Tone

First of all, I believe it’s important to acknowledge the personal accountability that leadership involves.

While culture and core values tend to be established at an organizational level, it is the leader who sets the tone and culture for a team, and that is largely a matter of choice.

In a leadership development session many years ago, a key point was made about “externalizing” leadership, calling attention to the situation where a leader would assign blame for decisions they were making on an ongoing basis to a third party such as their customer or other leaders to whom they reported or with whom they were working.  The challenge offered in that discussion was to reflect on that situation and ask why we, as individuals and leaders were not taking accountability for the choices we were making in spite of those circumstances. 

It’s not uncommon in my experience to see this situation occur, with examples along the lines of:

  • Difficult or aberrant behaviors of a leader translating to a next level of leaders who work with them, and thereby exponentiating the impact of the overall leader’s behaviors on the broader team
  • Challenging customer behaviors leading either to an order taker mentality or similar pattern of unhealthy behaviors within technology leadership that, again, have a detrimental impact on the associated team and work efforts
  • Organizational misalignment or lack of collaboration between teams translating into fragmented solutions being defined and delivered, ultimately creating complexity, limiting organizational agility and speed, and also increasing technical debt

The key questions in the situations above is “Where does this end?” or “Why doesn’t someone do something about this?”  The ripple effect of a lack of leadership can be quite substantial and the reason courageous leadership is needed is because there will almost always be some level of negative reaction that occurs the minute the cycle of dysfunction is broken.

 

Leadership starts with each of us and the choices we make every day.

 

The right questions for a leader to be asking in the situations above are rooted in personal ownership and accountability: “What can I do about this?” and “How can I set an example for how things ‘should be’ by comparison with how they are today?

I’ve certainly been in situations in the past, particularly in consulting, where the client or personalities of a core team were not necessarily healthy or positive in terms of promoting collaboration and partnership.  It has also been the case where the direction I received from the larger organization may not have been in the best interest of my team, the client, or both.  This is, again, where integrity can be tested and doing the right thing is critical. 

In my view, a leader needs to set a positive tone for what is possible, to act in good faith, with integrity, and do their best to insulate their team from the adverse circumstances that may surround what they are doing.  This creates space for culture to be positive, engaging, and effective and for team members to do their best work.  By contrast, when a leader allows those circumstances to dictate their actions in a way that becomes unhealthy, they are effectively punting their accountability to lead in the first place.  Again, it’s a choice, and it’s one that truly matters if you want to pursue excellence and high-performance teams.

Given the above three scenarios, the outcomes of making the right choice can be significant:

  • Not transferring dysfunction to the “next level” can unlock the performance and impact of the team that had previously been under-utilized. That could have a positive impact on output, on quality, on morale, on turnover, etc.  The negative impact of poor leadership is fairly well established in terms of operating performance
  • Addressing customer challenges with effective leadership can provide greater portfolio stability, less missed expectations (because they are communicated, set, and managed properly), and overall improvement in the health of the work, not to mention the positive team impacts referenced above
  • Finally, providing effective leadership in an organizationally misaligned environment can help provide clean solution designs that increase agility, accelerate speed to value, and reduce cost of operations

Wrapping Up

In short, the point of this article was to suggest a moment of reflection. 

What are the challenges you see in the organization in which you work today?  Can you do something about them?  Does that actually require “permission”?  What or who would prevent you from making a positive change?

My experience over time has been that leadership opportunity is always there, in part because you can almost never have too much of it.  It takes courage to step into the void and challenge the status quo where dysfunction exists… and it also takes a degree of fearlessness to truly drive excellence and transformation.

I used to echo a concept to a team many years ago in the interest of encouraging personal ownership and engagement: make a difference every day… no matter how large it is, it matters over time.

Imagine the possibilities if only a fraction of the leaders in an organization tried to create positive change every day…

I hope the thoughts were worth sharing… feedback is always welcome and appreciated.

-CJG 10/30/2021

Excellence By Design

Background

As I began this journey and subsequently to assemble topics about which to write, I noticed that there were both an overwhelming set of ideas coming (a good problem to have) and a very unclear relationship in the concepts that were running quite rapidly through my mind (not a good thing).

Upon further reflection, it occurred to me that the ideas all centered around the various dimensions of leading a technology organization at different levels of specificity.  To that end, I thought I should set the stage a bit, in the interest of making things more cohesive in what I may write from here.

 

On the Pursuit of Excellence

At an overall level, what better place to start than a simple premise: Excellence is a choice.

Shooting for excellence is a commitment that requires a lot on a practical level, starting with courageous leadership, because it is a perpetually moving target, requires adaptability, tenacity, and a willingness to accept change as a way of life.  Excellence isn’t accidental, it is a matter of organizational will and the passion to pursue aspirations beyond what, at times, may feel “realistic” or “practical”.  It requires a belief in what is possible and is defined along multiple dimensions, which we’ll explore briefly here, namely:

  • Relentless Innovation
  • Operating with Agility
  • Framework-Driven Design -and-
  • Delivering at Speed

Relentless Innovation

Starting with vision, some questions to consider in the context of an overall strategy:

  • Is it clear and understood across the organization, along with its intended outcome (e.g., what success looks like)?
  • Is it one that connects to individuals in the organization, their roles and ongoing contributions, or are those disconnected concepts (i.e., is it something that individuals take to heart)?
  • Can it evolve as circumstances change while maintaining a degree of fundamental integrity (e.g., will it stand the test of time or need to be continually redefined)?
  • Is it actionable? Can tangible steps be taken to drive progress towards its ultimate goals?
  • Is it “deliberate”/intended/proactive or was it defined in a reactive context (e.g., in response to a competitor’s actions)?
  • Are day-to-day decisions made with the strategy in mind?

Overall, the point is to have a thoughtful, proactive strategy, that is actionable, connected to ongoing decisions, and embraced by the broader organization.

Where this becomes more interesting is in how we think of strategy in relation to change, which is where the next concept comes into play.  Relentless innovation is the notion that anything we are doing today may be irrelevant tomorrow, and therefore we should continuously improve and reinvent our capabilities to ones that create the most long-term value. This is much easier said than done, because it requires a lot of organizational humility and a willingness to tear down existing structures and rebuild new ones in their place.  That forces a degree of risk tolerance, because there is safety in the established practices and solutions of today, especially if they’ve created value.  On the other hand, success can be very detrimental insofar as complacency can become part of the organizational mindset and change slows down to an environment that is essentially an iteration of the present.

 

Operating with Agility

Looking at IT Operations, a number of questions come to mind that may be the subject of future articles:

  • Is there a mindset of being cost-efficient (driving the highest value/cost ratio)?
  • Is there a culture of continuous improvement and innovation in place?
  • Is there a strategy for incorporating and optimizing the relationship of project and product teams (to the extent that a full product orientation isn’t feasible)?
  • Is there a sourcing strategy in place that is deliberate, governed, optimized (whether insourced, outsourced, or some combination thereof)?
  • Are portfolio management processes effective and aligned to business strategy?
  • Is there a highly transparent, but extremely lightweight operating infrastructure in place to facilitate engagement and value creation?
  • To what degree is talent rotation and development part of the culture? Are people stuck in the same organization or silo for long periods of time, or are high potential leaders moved between teams to facilitate a higher degree of knowledge sharing, development, and improvement?

Having worked in IT Ops, the largest issue I’ve seen in a number of companies is an overly significant focus on process and infrastructure by comparison with transparency and enablement.  This is a tricky balance to strike, but arguably, I’d much rather have a less “mature” operating environment (IT for IT) that produces directionally correct information and drives engagement than a heavy, cumbersome process that becomes a distraction from producing business outcomes.  A simple litmus test on the latter type of environment being in place is whether, in discussion, teams talk about the process and tools versus the outcomes, decisions, and impact.

 

Framework-Driven Design

Shifting focus to technology, I believe the opportunity is to think differently about the overall solution architecture of future ecosystems.  Much has been written and discussed relative to modern or cloud native applications, data-centric design, DevSecOps, domain-driven design, and so on.

What fundamentally bothers me about solution design approaches is that, when focusing on one dimension (e.g., data centricity), other dimensions of the more holistic view of modern application design is left out, and then it becomes a challenge to delivery teams to integrate one or more of these concepts in practice without a way to synthesize them into one cohesive approach.  This is where framework-centric design can be an interesting approach to consider.

In my definition, framework-centric design is focused on architecting a connected ecosystem and operating environment intended to promote resiliency, interoperability, and application-agnostic integration such that individual solution components can be upgraded or replaced over time at a rapid pace without disrupting the capability of the ecosystem as a whole.

I will explore this topic further in a future article, but the base premise is to design an overall solution that performs complex tasks given multiple components integrated in standardized ways, leveraging modern, cloud native technologies, with integrated data that feeds embedded analytics capabilities as part of the operation of the ecosystem.

The framework itself, therefore, becomes a platform and the individual components are treated as replaceable parts that enable a best-of-breed mentality as new capabilities emerge that become advantageous to integrate with the framework over time.

 

Delivering at Speed

From a delivery standpoint, as tempting as it is to write about iterative development (or Agile in particular) as a cure all, the reality is that more organizations suffer from a lack of discipline than a lack of methodology. 

The unfortunate myth that needs to be explored and unwound is that executing with discipline means value will be delayed when, in fact, the exact opposite is true.  It is a generalization, but the faster a build team moves (to the extent that process or rigor is abandoned), the immediate impact is usually a level of technical debt that will create drag, either in the initial or subsequent delivery efforts.

Quality doesn’t happen by accident.  It is something that needs to be planned and built into a work product from the kickoff of a delivery effort, regardless of the methodology or operating model employed.

I will likely write more on this topic given the number of opportunities that exist, but it’s sufficient to say that you can’t achieve excellence when you don’t execute as flawlessly as possible… and discipline is needed to accomplish that.

 

Wrapping Up

Overall, the goal was to provide a quick summary of the various dimensions that I believe are important to consider in leading an organization.  No doubt, there may be questions or omissions (intentional or unintended) as this was a first blush at how I think about it. 

What about people and culture?  Well… that’s part of operating effectively… as an example.

Hopefully this was a good starting point and provided some food for thought.  Feedback, questions, and reactions are always welcome.

Looking forward to continuing this journey.

-CJG 10/28/2021

On Health and Transparency

Having spent a number of years in project and program management (as well as IT Operations), one of my favorite subjects is transparency.

For the purposes of this article, I’m focusing on “traditional” project and program delivery (irrespective of methodology), not product-based operating environments, though many concepts would apply to both.

 

Context

An inevitable truth of managing programs (especially large ones) is: Things will change.  I think of these changes as “points of inflection”, namely times when some level of pivot is needed either within a single project or across multiple work efforts in a coordinated fashion to get things realigned, stable, and back to operating in a healthy way… typically with a revised delivery schedule.

What makes a programs successful at these points of inflection is three things:

  1. Having good transparency – Knowing where you are at the present time in relation to your ultimate goal, so that you can evaluate the remedy (or remedies) needed to adjust course
  2. Making the right “turn” – Adjusting the scope, approach, plan, work efforts, risk profile, etc. so that you address the issues identified in a way that increases operating stability, plan integrity, and quality of the ultimate solution and/or deliverables
  3. Turning quickly – Making the appropriate adjustments as quickly as possible after the issues are identified to rectify the situation. This can’t be emphasized enough, given a significant amount of disruption, cost, and other negative impacts tend to come as a result of organizational inaction related to materialized risks.  As has been said in consulting many times, “bad news doesn’t get better with time”… and the sooner critical issues or risks are addressed, the better.

So looking at the above, the critical dependency is transparency because, without an understanding of where you are, there’s no way to evaluate whether the changes you make will ultimately help or hurt your delivery effort.

 

The Challenge

This is where the problem starts: Wanting transparency is different than needing lots of metrics, and the latter is where a significant percentage of projects and IT operations efforts waste time, energy, and cost that ultimately undermine delivery and/or operational excellence.  The goal of transparency is to enable governance and risk management.  Reporting in of itself is administrative in nature and adds marginal value (unless it is of a regulatory nature, of course).

What tends to happen is that, rather than approach transparency in a top-down fashion, with a focus on enabling engagement and action, leaders take a bottom-up approach, assuming that the more data they have, the more they can ultimately understand and controlThis is a critical mistake that happens on projects all the time… reporting so much information that the fundamentals are lost amidst the noise. 

One root cause of the above situation is that there are a good number of leaders who see status as organizational comfort food, as if having excessive documentation will provide “proof of ongoing work” for customers or to create a level of air cover in the event that things ultimately go wrong.  On the latter point, having led high risk and complexity delivery efforts, particularly in consulting… the minute anything goes wrong, if you’re a project or program manager, you can pretty much assume you’ll be taking the blame regardless of whether the issue or risk has been documented on a status report… and that’s the job, and it’s ok… because no one said these jobs are easy.

This is either what makes project and program management work difficult or very rewarding, depending on how you choose to see it.  Your best work tends to be happening when nothing goes wrong, in which case people may well ask what you do all day.  In the converse scenario, when things are not going well, you may find yourself in the situation where people ask what you’ve been doing, and you won’t want the answer to involve having spent hours writing or updating reports.  Our goal in delivery is producing value (i.e., business outcomes), not status.

 

Some Examples

Three different situations (each from a different organization) come to mind where “reporting” got in the way of actual transparency:

First, I was asked to cover a delivery project from an oversight standpoint while the director responsible for the work was out on vacation.  The project manager, a trained PMP, had a well-organized and documented project, with an abundance of metrics.  A source of particular pride was the earned value (EVM) calculation, which indicated that the team was 90+% complete on the project.  Upon reviewing the artifacts, we realized that the effort related to producing deliverables was not included in the plan, and therefore, the EVM calculation didn’t include the full project scope and it was actually massively BEHIND where it was supposed to be (something in the 70+% range).  In practice, the project manager had spent so much time managing metrics that they forgot to make sure the scope of the project was represented in the plan, effectively compromising what they had been reporting for weeks.  The good news is that, having recognized the gap, we made the necessary corrections, pulled in some additional help, and got things back on track.  Overall, however, the lesson learned was that metrics are only as good as the understanding they provide for the underlying effort itself.

In another situation, I inherited a client engagement where one of the divisional CIOs had the team producing a forty-page status report covering all delivery efforts in the portfolio on a weekly basis.  It was well understood that the client wasn’t reading the report, but rather requested it to force the team to evaluate their project health on a continuing basis.  The implication being that writing status helps project managers focus on their project, which is actually the opposite of what happens in practice.  The more time project managers spend in administrivia, the less time they tend to spend on activities that add value, such as communicating with customers, engaging with their delivery team(s), identifying and managing risks, reviewing the plan for gaps and issues, and so on.  It took some convincing, but this was an activity that we ultimately eliminated that not only reduced administrative effort, but also allowed us to cut a full-time position that had been staffed solely to report on that portfolio of work.

Finally, I was asked to take a short-term assignment to help a divisional CIO organize his PMO, particularly the reporting being done across a relatively large and diverse portfolio of work.  Similar to previous situation, he showed me a stack of printed status roughly four inches thick that he was receiving weekly across his delivery leaders, ultimately which we replaced with a four-page dashboard organized across financial health, strategic programs, ongoing discretionary projects, and production support.  Rather than produce information on a project-by-project basis, we requested standard information from each delivery team at a summarized level that helped highlight areas where intervention was actually required and eliminated a significant amount of the administration related to written status.  In practice, the minute the yellow or red light goes on, someone likely needs to have a conversation anyway, so writing a lot of documentation doesn’t tend to help anyone.  The end result was less paperwork and a lot of relieved project managers.

 

Focusing on What Matters

Coming back to transparency, some fundamental concepts that I believe are important:

  • If you can’t understand the overall situation, the details don’t matter
  • Qualitative information can be just as good as quantitative data, given the quality of detailed project metrics is often suspect and imperfect anyway
  • Any metric that is reported should be actionable, otherwise it is likely noise and a distraction
  • Once things get into the ‘yellow’ or ‘red’ there is a discussion coming, so there is little value in writing a lot of language in a status report that ultimately will be discussed anyway
  • It’s completely fine (and often helpful) to track detailed items within a project, but report on summary characteristics from a governance standpoint

In line with the above, these are the primary seven ‘indicators’ (all in R/Y/G) that I consider important to track across projects in a program or portfolio of work, along with their conceptual definitions:

  • Overall Health – Indication of the Delivery Quality overall, given the following six dimensions
  • Scope – Requirements are clear and understood
  • Budget – Financially in line with expectations
  • Staffing – Team is skilled and staffed to deliver the work
  • Schedule – Work is being executed in line with expectations
  • Quality – Work product is in line with or exceeding expectations
  • Risk – Concerns areas are understood and being mitigated effectively

Where the indicators are defined as:

  • Green – On Track
  • Yellow – Needs Attention (50%+ chance of an issue)
  • Red – Requires Action (Issue exists, discussion or intervention needed)

This isn’t to say that things like next major milestone, %complete, %test cases planned/ executed/ passed, etc. are not useful to report, but they generally fall at a lower level of criticality once the above indicators are addressed.  My general preference is to have details only where there is additional insight needed (for example, Schedule is “yellow”, in which case progress metrics specific to the current activities may provide useful information).

 

Conclusion

While a lot has been written about these topics, the goal of this article was simply to share a few concepts about transparency, the role it plays in effective governance and risk management, and the often questionable value of reporting in itself.

There are many best practices related to transparency and reporting, but the main takeaways:

  • If you don’t have effective transparency, you are highly exposed to the experience of the people leading an effort, and your ability to govern and manage risk and change will be limited
  • If you don’t know how you will use information (down to the individual metrics) being reported on a delivery effort (or operational dashboard), don’t collect them. It’s likely a waste of time
  • The more you measure and report, the less you’ll likely notice the critical things that matter
  • The more time you force delivery leaders to spend on reporting, the less likely they are to be focused on their actual delivery responsibilities
  • The goal of transparency is to drive engagement and action (and value), not administration

I hope the information was useful… as always, feedback and comments welcome.

-CJG 08/21/2021

The Power of N

I thought I’d start out with a fairly simple mental model for thinking about employee engagement and its role in leading transformational change.

Like others, I’ve spent many years being indoctrinated to the concept of the “individual contributor”, which is the equivalent of a non-manager/ doer / worker / employee who presumably spends the majority of their time executing against responsibilities partially or entirely defined by someone else.

While not wanting to delve into the “manager versus leader” topic right now, I can say that I never really thought too much about the language above itself and what it implies if we’re not careful when leading teams.

My assertion is that thinking of team members as “individual contributors” establishes a mental model of linear impact and marginalized value.  In the worst-case scenario, the collective potential of a team of 10 individuals is effectively 10n… the sum of their individual contributions, with no added value beyond what they accomplish on their own, in isolation, given tasks defined, created, and assigned by someone else (their “leader” for simplicity’s sake).  While I don’t know that we’d see much of this ever play out fully in practice, the situation would likely be one where team members work in silos, don’t ask others for help, don’t participate or offer ideas to better the team or the organization, and see innovation and leading change as entirely someone else’s responsibility. 

Something in there sound familiar?  I suspect it does, because it happens almost everywhere in my experience, to varying degrees, based on culture, leadership, and probably a number of other factors.  What I don’t believe the critical determinant is, however, is talent.  If talent is a concern, operating in an “individual contributor” mindset is a sure way to have an adverse effect on the overall math, because arguably there will be individuals performing at less than their full potential, and the impact will be further reduction in team productivity and effectiveness.

So, shifting to the right side of the equation, what we want is to capture the Power of N… the exponential impact that comes from engaging a team fully, maximizing their potential contributions, and shifting from a passive to an active role in innovation and change.  Turning the capability of 10 individuals (10n) to a high performing team that generates the impact of n10.

Some litmus tests for this kind of environment could include:

  • Is there a shared vision to which individuals are able to connect and see their contributions advancing?
  • Do team members work across boundaries and collaborate actively with their teammates and others in the broader organization?
  • Is there an inclusive environment where ideas from members of the team contribute to the objectives of the team as a whole, solutions presented to customers, opportunities for improvement, etc.?
  • Do members of the team actively help coach and guide others in their professional development?
  • Is it a cooperative or a competitive environment?

Enrollment is a critical lever in unlocking the collective potential of a team and the proportionate impact that they can have on an organization as a whole.  It requires awareness and humility from a leadership standpoint, because it’s very tempting to present the idea that you have all the answers, are the keeper of the keys when it comes to the vision, and have control of the greater whole at all times.  The problem is that this is the surest way to stifle contribution and innovation, because you also just became responsible for every “good idea”, limited advocacy of your greater cause, and took on the burden of having to direct the lion’s share of the execution, when a self-directed team will be far more productive (and effective) overall… and that is an incredibly limiting way to approach working with teams.

Now extrapolate this out to a team of 25, 50, 100… more… the impact of leveraging the Power of N is in our best interest when we want to promote transformational change.  It has to start with individuals, who execute against that shared vision, help define its advancement, and ultimately determine the bounds of what’s possible.  That is where the most knowledge (and capacity) in an organization ultimately resides and tapping into that potential matters.  With all the organizations with whom I’ve had a chance to work over the years (including clients as a consultant), even the most engaged and well-intended leaders don’t know the realities of the people who are on the front lines, facing the daily challenges, and seeing the opportunities that exist for sustainable change.  Closing the gap between our aspirations and daily realities is important to having an actionable strategy (something I’ll likely write about separately).

So, if any these ideas make sense, the suggestion would be to engage with your team, and ask questions… “Do we have a vision for where we’re going?”, “Are there questions/concerns about it?”, “Is this the right direction/the best we can do?”, “How should we deliver on that goal?”, “What help do we need to make it happen/Are we equipped to be successful?”, “Are we collaborating effectively?”, “How will we know we’ve been successful?”… and listen, and listen, and listen… and respond… and engage.

Today’s question for reflection: Do we want to lead a team of individual contributors producing marginalized results or a self-directed team that is engaged in driving transformation?…  It’s a choice.

Hopefully the thoughts were worth reading… feedback is always welcome.

-CJG 08/13/2021

Where to Begin…

Seven organizations… nearly thirty years of challenges and learning… what a journey it has been.

In mid-2016, I had an idea to start a blog, “The First 25…”, which I envisioned as a set of reflections to commemorate the first twenty-five years of my professional life.

I began creating an outline, starting from my first work in Windows 3.1 tax software development at Price Waterhouse in 1992, jotting down concepts, anecdotes, and learnings that I had accumulated.  I intended for it to be both a means to share my experiences as well as a mechanism to facilitate introspection and growth.  I started writing the first set of articles, ran out of time, lost interest, and put the concept on the shelf for five years… until I recently felt like maybe it was time to revisit the idea.

It’s an odd truth that we learn to value experience only once we actually have it… and how relative that all becomes over the passage of time.  In my early days as a developer, I remember looking at job postings in the newspaper, seeing ads for candidates with “15 years of experience” and thinking that you both had to be a dinosaur and some form of fully enlightened professional by the time you reached that point in your career.  Fifteen years is a REALLY long time, after all, right?  That had to be all you’d need to learn everything there was to learn and have it down to the point you were almost on autopilot with anything the business world could throw at you.  In retrospect, perhaps that logic makes a degree of sense when you are 21 years old and 15 years represents almost 75% of your lifetime…

In any case, looking back, there have been many lessons and experiences that helped me become the person I am today.  From the fear and inexperience of my first days managing projects, to the many late nights pounding away at a keyboard, trying to get that next piece of code working… the setbacks, the struggles, and quite often the painful mistakes that taught me the value of “how not to” do things.

My hope is to use this blog to share some of those experiences, thoughts on leadership, strategy, technology, and other topics as and when they arise…

A career is really nothing more than a collection of experiences and what we ultimately do with them to become better leaders and professionals… Hopefully the ideas will be worth reading, feedback is welcome and appreciated.  I’m still on the journey, seeking that enlightenment I thought I’d have when I got to “15 years”… albeit today, I know I’ll never get there and just want to keep learning and improving to have as much of a positive impact as I can on the teams with whom I work and the organization(s) to which I belong.

Thank you for taking the time to read this and/or anything else that may follow.  All the best in your professional endeavors…

-CJG 08/11/2021