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