Information Technology Dark Side

Struggles of a Self-Taught Coder

Information Technology Dark Side header image 2

Building Balanced Influence Using the FEWD Pyramid

April 3rd, 2007 · 3 Comments

I’ve been thinking a lot about centralized groups lately. Centralized groups are usually created as an attempt to leverage common skills and practices in a uniform, cost-effective way. It’s most common in matrix organizations, and I’ve seen them formed for many different purposes, including:

  • Development
  • Analysis
  • Testing
  • Project Management
  • Governance
  • Architecture
  • Infrastructure
  • Centralized organizations have been on my mind lately for two reasons. Partly because I belong to one, and partly because I’ve had several occasions over my career to watch them be created, succeed and grow in influence, or fail, lose the ability to drive adoption of its services, and eventually be disbanded.

    I’ve observed a common thread in the centralized groups that succeeded, and a motivational model that offers one explanation why some groups become influential and others do not.


    Here’s the common thread: the centralized groups that succeed tend to create a product or service offering that is valuable across the organization. By across the organization, I mean the products or services they provide are valuable UP and DOWN the chain – they add value both to management and to teams, specifically project or maintenance teams. I have seen groups that focus their products and services exclusively up the chain (to management) and groups that focus exclusively down the chain (to teams).

    When products/services focus entirely up the chain, they are at the mercy of management. A new leader blows in with a different vision, and they disappear. Conversely, when their focus is entirely on teams, they become too embedded in the team and, without the strong support of management, eventually get absorbed into the various groups they support.

    Centralized groups that never develop useful products or services are simply failures. In a perfect world, they don’t last long. Somehow, these manage to persist longer than they ought to, sometimes much longer. I’d go on a rant, but let’s save it for another day.

    I believe it’s important to build influence in a balanced way, so the value of your products and services is understood across the organization. This thinking led to the following model, which I call the FEWD Pyramid (pronounced food). It is based on the idea that organizations and individuals tend to get what they want, and that getting the right thing is really dependent on wanting the right thing.

    Anyway, here is the FEWD Pyramid:

    The FEWD Pyramid

    Here’s what I believe:
    1) Excellence and influence are built first out of a desire to be an asset to the whole organization. In other words, you must want to provide more value than it costs to keep you around. This desire is the base of the pyramid.
    2) The desire to be an asset means you are looking for opportunities to help, even if it means changing the way you operate, perceive a problem, or ideas/principles you value. This willingness to change, when observed by others, helps others to believe you can be a useful resource to them.
    3) Since you are willing to change, others will have more confidence in your ability to do so and will begin providing more opportunities for you to change through feedback. This feedback loop will help you gather data about the products and services that will most benefit your organization.
    4) Quality feedback necessitates execution. Acting on feedback results in the creation of valuable products and services. Since they are based on effective feedback loops, others will want to use them, and they will provide further feedback you can use to perfect them.


    Admittedly, this is a pretty simplistic explanation of a complex problem. Now that I’ve written it down, it seems fairly obvious to me. I hope it’s useful to someone – if it is, let me know. If it’s not – let me know that too. Feedback is a gift, even when you tell me my ideas suck.

    One final thing. How do you develop the desire to be an asset in yourself and/or an organization? I think it’s simple – start with a question, and ask it every day, out loud with your colleagues: What can I do to be a resource to others? How can I help?

    If you enjoyed this post, make sure you subscribe to my RSS feed!
    Stumble it!

    Tags: Job Advice

    3 responses so far ↓

    • 1 Sheryl H. // Feb 17, 2009 at 4:49 pm

      David,
      FEWD is certainly food for thought. Well done. I appreciate your insights.

    • 2 Getting a jump start on software test collaboration - Software Quality Insights // Sep 23, 2009 at 9:31 am

      [...] a jump-start on collaborating with the development often have a closer relationship, and are thus viewed as an asset. It is these testers who are often pressed to help isolate a defects, even if it wasn’t logged by [...]

    • 3 mapquest // Apr 15, 2010 at 2:01 am

      totally it is food for thought ,great stuff

    Leave a Comment