J.D. Meier's Blog

Software Engineering, Project Management, and Effectiveness

  • J.D. Meier's Blog

    Videos: Security, Performance Testing, and Visual Studio Team System


    We posted our ASP.NET 2.0 security videos, performance testing videos, and Visual Studio Team System videos to the MSDN library.

    Video Index

    ASP.NET 2.0 Security Videos
    Keith Brown explains the mechanics behind some common input and data validation security issues and how to address them.

    Performance Testing Videos
    Scott Barber explains the big picture for how to approach performance testing as well as how to do workload modeling and performance reporting.

    Visual Studio Team System Videos
    Our team takes you through key source control concepts in Team Foundation Server.

    I hope we produce more videos in the coming months.  I particularly like factoring "explained" videos from the "how to" videos and keeping the videos short and focused.  I think we have more work to do here, but I think we've learned key lessons each time we've done a batch of videos.

  • J.D. Meier's Blog

    TFS Guide: A Top Download on CodePlex


    It was a nice surprise to see that yesterday our patterns & practices Visual Studio Team Foundation Server Guide was among the top downloads on CodePlex.


    The HMTL version of the guide is available on MSDN at http://msdn2.microsoft.com/en-us/library/bb668991.aspx.

     My Related Posts

  • J.D. Meier's Blog

    Pattern-based Leadership vs. Fact-Based Management


    I found an interesting article about contextual decision making.  "A Leader's Framework for Decision Making," an article in Harvard Business Review, is about tailoring your decision making approach based on the context.  You can use the Cynefin Framework to figure out which context you're operating in, so you can choose the most effective response.  The key is whether to categorize, analyze, probe or act.

    Context's Characteristics
    The Cynefin Framework includes five context types:

    • Simple - Repeating patterns and consistent events; Clear cause-and-effect relationships evident to everyone; right answer exists; Known knowns
    • Complicated - Expert diagnosis required; Cause-and-effect relationship discoverable but not immediately apparent to everyone; more than one right answer possible; Known unknowns
    • Complex  - Flux and unpredictability; No right answers; emergent instructive patterns; Unknown unknowns; Many competing ideas; A need for creative and innovative approaches
    • Chaotic - High turbulence; No clear cause-and-effect relationships, so no point in looking for right answers; Unknowables; Many decisions to make and no time to think; High tensions
    • Disorder - This context is particularly difficult to recognize because of multiple, competing perspectives.  The recommendation is to break it down into its constituent parts and assign it to one of the other four realms.

    Fact-based Management
    Simple and complicated are part of the ordered world.  How to respond as a leader in simple and complicated scenarios:

    • Simple - (The Domain of Best Practices) - Sense, categorize, respond; Ensure proper processes are in place; Delegate; Use best practices; Communicate in clear, direct ways; Understand that extensive interactive communication may not be necessary.
    • Complicated - (The Domain of Experts)  - Sense, analyze, respond; Create panels of experts; Listen to conflicting advice.

    Pattern-based Leadership
    Complex and chaotic are part of the unordered world.  How to respond as a leader in complex and chaotic scenarios:

    • Complex - (The Domain of Emergence) - Probe, sense, respond;  Create environments and experiments that allow patterns to emerge.  Increase levels of interaction and communication.  Use methods that can help generate ideas; Open up discussion: set barriers; stimulate attractors; encourage dissent and diversity; and manage starting conditions and monitor for emergence.
    • Chaotic - (The Domain of Rapid Response) - Act, sense, respond;  Look for what works instead of seeking right answers; Take immediate action to reestablish order (command and control); Provide clear, direct communication.
  • J.D. Meier's Blog

    Harvard Business Review and The Economist


    I'm always on the prowl for sources of profound insight.  At my leadership workshop last week, I noticed the instructor had a wealth of practical insights and distinctions that aren't common knowledge.  I asked him his favorite sources of information and he listed two:

    I was surprised because I had never read either before (the titles weren't appealing to me.)  I picked them up this week and it looks like they're packed with lessons learned and news I can use.  I think of The Economist as sharing business and organizational practices.  I think of Harvard Business Review as personal development applied to the workplace.  Here's a sample of some of the titles from this month's Harvard Business Review:

    • "A Leader's Framework for Decision Making"
    • "Solve the Succession Crisis by Growing Inside-Outside Leaders"
    • "Eight Ways to Build Collaborative Teams"
    • "Mapping Your competitive Position"
    • "Cognitive Fitness"
    • "Simple Rules for Making Alliances Work"
    • "Are Your Engineers Talking to One Another When They Should?"
  • J.D. Meier's Blog

    Patterns vs. Tooling


    I'm a fan of patterns.  I think of patterns simply as problem and solution pairs.  I wandered by The Hogg Blog and noticed Jason's post on The Great Debate: Patterns vs Tooling.  Since patterns and tooling both have their place, I think there's less of a debate and more of a gap between state of the art and state of the practice.

    Why Patterns
    I think patterns are an efficient way to share insights.  Consolidating 100's of words down into a few is pretty powerful.  A pattern language is a great way to map out the terrain of a domain.  I think of the pattern language as a constellation of meaningful nuggets.  I think the most insighful nuggets are the ones that help you with the toughest forks in the road.

    Patterns in Practice
    While working on our security and performance guidance, our team was able to rapidly solve and share end-to-end solutions for incredibly complex application scenarios.  As we worked through customer scenarios, we would pattern match against our deployment patterns and application infrastructure patterns.  To put this in perspective, I remember a customer that had been prototyping a solution for six months, that we solved in ~3 hours because we had a collection of patterns to draw from.  We got to a vantage point where we could solve some of the toughest architetural issues for customers in a few minutes.  Looking back, I wish we had a more agile way for sharing our learnings with more customers, and I think patterns and pattern languages could have been part of the answer.

    Key Usage Scenarios
    There's lots of uses for patterns, but here's some examples:

    • Building vocabulary.  A lot of light bulbs went off for me when Ward pointed out that patterns help build a shared vocabulary.  It's a way to talk about our craft and to hand knowledge down from one generation to the next.
    • Sharing solutions.  This is what patterns do best.
    • Encapsulating principles.   It's one thing to talk about a bunch of underlying principles.  It's another to have a nicely named pattern.

    Key Issues with Patterns
    Here's some of the issues I've run into with some patterns and repositories over the years:

    • Problems solved.  I don't tend to see enough patterns around the more interesting, engineering problems where patterns are worth the effort.  I think quality attributes are great candidates for patterns (security patterns, performance patterns, reliability patterns, flexibility patterns ... etc.)
    • Locked in print or teasers to more.  A lot of the most insightful patterns are locked in print.  It makes it tough to share, particularly when we don't all have the same bookshelf.
    • Bad organization.  I've seen only a handful of pattern libraries that impress me.  I'm not saying they don't exist, but that I haven't seen a lot I like.
    • Relevancy.  I think one of the biggest issues is just finding relevant patterns for your problem at hand.  No matter how well a library of patterns is organized, it still helps to have a shepherd.  Web 2.0 can help here.
    • Bad templates.  Sometimes the structure of information is as important as the information.
    • Bloat.  Blah, blah, blah.  I'm not a fan of verbosity when I need to get my job done.  I've seen some patterns that were more complicated than the solution they were describing. 
    • Vocabulary.  While patterns can help build a shared vocabulary, it can be tough in the beginning, like learning yet another vocabulary.  Convergence takes time.
    • Silos and pockets of insight.  I don't think patterns are as prevalent as they could or should be.  I find a lot of the best nuggets are spread a great deal over time and space.
    • From concept to code can be a big jump.  Sometimes you can't get there from here, or it'a a painful process.  I think this is very much a tooling opportunity.
    • Silly or make-believe patterns.  I've come across a lot of patterns that seem to be patterns for the sake of patterns.  Ward always told me that the best patterns tell you something you didn't expect or that surprised you.
    • Lack of anti-patterns.  I actually think there's not enough anti-patterns.  While there's more than one way to solve a problem, sometimes there's a few places you really shouldn't go, and that's where anti-patterns fit in.   Some of the best security insights are documented as anti-patterns.

    Key Opportunities for Patterns
    I think there's more opportunity than ever for building better pattern libraries and leveraging social software scnearios and tooling opportunities.  Here's some examples:

    • Guidance Explorer.   Guidance Exploer lets you easily cross-link patterns or link them to other items.  For example, imagine a pattern that links to a code example or a how to or a set of guidelines and checklists.  We've also played with the idea of showing patterns as mind maps so you can see the related patterns.  Guidance Explorer can also help solve the relevancy issue, by providing more fine-grained organization, as well as make it easy to build a collection of the ones you want.  All we have to do is fill up our pattern node with a critical mass of more useful patterns.
    • Web 2.0.  I think Yahoo Design Patterns is a good example.
    • Tooling support.  I'd like to see more drag+droppable patterns and pattern-based modeling going forward.

    My Favorite Pattern Guides
    Here's a few of the pattern guides I've found to be useful:

  • J.D. Meier's Blog

    Human Shepherds and the Law of Relevancy


    Yesterday, Ed helped me word a "law" that I use for important decisions and that I see show up quite a bit in a number of places.  It's the law of human relevancy.

    The Law of Relevancy
    No matter how relevant the information is, it's more relevant with the help of the right people.

    The Human Shepherd
    All this law really means is that no matter how well you organize and display information, at some point, there's a glass ceiling on how much easier you can make it for somebody to find what they need.  There's always a place for the human shepherd.

    Usage / Examples

    • The obvious example is the Web 2.0 movement -- where people are the shepherds of the read/write Web.  There's lots of needles in the world wide haystack and I'm glad there's people, voices, blogs there to help.
    • I like the pattern on the Web where sites have a live chat to use a human to help you match their info to your needs, in real time.
    • I like how Second Life provides the ability to "invoke a human" over just self-help and forums. (I proposed some models for "human help" in Visual Studio and as a general platform some time back I need to revisit)
    • There's lots of implications for an Enterprise 2.0 world, but I'll save that for another day.

    A Story
    In an early version of Practices Checker (a tool meant to verify your solutions against patterns & practices recommendations), we tried to figure out relevant guidance based on the type of project (Web, winForm ...), what technologies (ADO.NET, ASMX ...) you were using, ... etc.  We did this automatically and generated what I considered more harm than help (it missed things that were important and created a lot of noise.)  I applied the law of relevancy and argued that we'd be better off figuring out how to leverage the user's own relevancy engine and pattern-matching ability over auto-magic guesswork.  We then created a tool to help smart people, rather than a "smart" tool that gets in the way.

  • J.D. Meier's Blog

    How To Build Your Own Guide with Guidance Explorer


    You can build your own guide using Guidance Explorer.  Guidance Explorer is a front-end browser optimized for our patterns & practices guidance store.  Here's some of the usage scenarios:

    • Build a guide of your favorite patterns & practices items.
    • Build a custom set of guidelines for your team.
    • Build a custom checklist for a security or performance inspection.
    • Build a customized guide for your customer.

    Summary of Steps

    • Step 1.  Create a new view.
    • Step 2.  Add items to your view.
    • Step 3.  Save your view as a Word doc.

    Step 1.  Create a new view.
    To create a new view, right-click My Views and click New View.   Name your view.

    Step 2.  Add items to your view.
    For this example, select some items from the patterns & practices library node and drag and drop them into your view.  Note that you can edit the items.  Just double-click to bring up the item, then click Edit.  Once you are happy with your changes then you can save to your read write libraries (such as My Library.)  You can also create new items.  For example, right-click My Library and click New Item.  You can then add your new item to your View by dragging and dropping.

    Step 3.  Save your view as a Word doc.
    Once you are happy with items in your view, right-click the view and save it as a Word doc.  Note that you can also choose to save it as HTML.

    Voila!  You now have your very own, custom guide.

    My Related Posts

  • J.D. Meier's Blog

    Now on MSDN: patterns & practices Performance Testing Guidance for Web Applications


    You can now find our patterns & practices Performance Testing Guidance for Web Applications on MSDN in HTML.  It's the same guidance we hosted on CodePlex.  CodePlex was our channel for agile release of the guidance.  Once we baked the guidance, we ported it to MSDN.

    Contents at a Glance
    Here's the


    You can download the patterns & practices Performance Testing Guidance for Web Applications from CodePlex.

    Guidance Explorer Scenario
    If you want to tailor the guidance for your scenario, you can download Guidance Explorer from CodePlex.  Using Guidance Explorer, you can create custom views by dragging and dropping the relevant guidance and then tailoring it as you see fit.  You can then save your view or an item to Word or HTML

  • J.D. Meier's Blog

    Performance Testing Videos Posted to CodePlex


    Today we posted our Performance Testing Videos to CodePlex.  They're a companion set for our patterns & practices Performance Testing Guidance for Web Applications.

    Video Index
    Here's a list of the videos: 

    Additional Resources

  • J.D. Meier's Blog

    Now on MSDN: patterns & practices Team Development with Visual Studio Team Foundation Server Guide


    You can now find our patterns & practices Team Development with Visual Studio Team Foundation Server guide on MSDN in HTML.  It's the same guidance we hosted on CodePlex.  CodePlex was our channel for agile release.  Once we baked the guidance, we ported to MSDN.  For some customers, MSDN is a trusted source, so being on MSDN is important.  Additionally, MSDN provides some additional hooks and channels.

    Contents At a Glance
    Here's the guide at a glance



    Practices at a Glance

    Questions and Answers

    How Tos

    You can download the Team Development with Visual Studio Team Foundation Server Guide from CodePlex.

    Guidance Explorer Scenario
    If you want to tailor the guidance for your scenario, you can download Guidance Explorer from CodePlex.  Using Guidance Explorer, you can create custom views by dragging and dropping the relevant guidance and then tailoring it as you see fit.  You can then save your view or an item to Word or HTML. 

  • J.D. Meier's Blog

    TGIF (10/26/07)


    I happened to glance at the MSFT stock.  I took a snapshot because I thought it was make believe.  Either way, it made me smile.


  • J.D. Meier's Blog

    Results-Focused Teams Over Role-Focused Teams


    In my experience, talent and passion are the keys to effective teams.  It's not better defined roles.  In PM Tip#14: Great teams have members that defy roles, Brad Abrams writes that the best teams defy traditional roles and responsibilities, and I agree.

    When role issues show up, it's usually a sign there's other problems.  Here's common problems:

    • You're missing a critical role.  In sports it's more obvious.  You wouldn't start a baseball game without a pitcher.  On a project team, where the work isn't well understood, it might not be obvious you're missing an important role, but symptoms show up over time.
    • The open work isn't obvious.  If the team isn't sure what to do next or who's doing what, it leads to problems.
    • There's too much stepping on toes.  There's probably just not enough teaming or communication.
    • The work is unevenly distributed
    • Somebody is out of their comfort zone.
    • There's a mismatch in talent for the task.
    • There's a mismatch in passion for the task. 
    • There's a lack of clarity around what good looks like.  You might think you did your job, but somebody else thinks you only did half of it.
    • There's a mismatch in values.  If you want to knock the ball out of the park, while somebody else wants to just punch the clock, you'll have role issues.

    Carving out roles to help orient the team is one thing (who's on first, who's on second ... etc.)  Carving out roles to act as contracts is another.  I'd rather work on teams where the focus is on collaboration and results over contract negotiation. 

    Here's a few keys that help with a results focus:

    • Build a shared vision of the end in mind.  If the team can't see the finish line, there's no way they can race there.  
    • Know the work to be done.  Granted this is a continuously unfolding process.  At the same time, you don't want to go off to Antartica without the right skills on board.  If you know the work to be done, you can get the right people on the team.  If you know the work to be done, people are generally more willing to sign up.    
    • Match talent to the task.
    • Match passion to the task.  Passion is the key to productivity.
    • Stay adaptable.  Adaptable teams survive and thrive, where rigid teams fail.
    • Pair up in complimentary ways.  For example, pair a dev with a tester to swap perspectives.  Pair a strong thinker with a strong doer.  Pairing up is a great way to keep momemtum and share learnings.  It's also a way to help avoid stepping on toes   

    At the end of the day, I push for results-focused teams over role-focused teams, but it's probably because I'm a fan of getting results.

  • J.D. Meier's Blog

    How To Use Time Boxing for Getting Results


    Time boxing is a way to chunk up time and get results.  If you continously miss windows of opportunity or spend all of your time in one area of your life at the expense of others, time boxing can be one of your best tools.   A time box is simply a limited set of time to accomplish a result.  Think of it as how much work can you get done in a given block of time.  I use it to organize my day, drive project results, make incremental progress on problems and spend time on the right buckets in my life.

    Why Use Time Boxing
    Using time as a constraint and forcing function for results is extremely effective:

    • Avoid missing windows of opportunity.  Time's a limited resource.  If you don't treat it this way, you end up blowing project schedules, missing windows of opportunity, or doing too little, too late.
    • Spread your results across key areas.   If you spend all of your time in one area of your life at the expense of another, you can use time boxes to allocate time for important areas (such as career, mind, body, social, spiritual ... etc.)
    • Prioritize more effectively.  If you know you only have three months for that project, you can be smarter about what you bite off that you can actually finish.
    • Chunk up a problem.  Use time boxes to slice a problem down to size.  This works well if you have a daunting problem that seems too big to take on.  Timeboxes are also a more realistic way to deal with problems that spread over time.  If you can't solve a problem in a single session, then figure out the right-size time chunks to throw at the problem.  How do you eat an Elephant?  One timebox at at time ;)
    • Deliver incremental results.   You can use a time box to show progressive results.  For example, rather than all-or-nothing thinking, use time boxing to make incremental progress on a problem. 
    • Increase focus.  Giving yourself dedicated time boxes to focus on a problem help you avoid task switching, and help you stay engaged on the problem.  If you find yourself wandering too much, then chunk your timebox down even further. See
    • Increase motivation.  Make a game of it.  For example, how many sit ups can you do in 60 seconds?  Between splitting problems down to size, staying engaged on the problem and making a game of it, time boxing is a sure-fire way to build momentum and results.
    • Improve your effectiveness and efficiency.  use time boxing to tune your results.  Using a time box can help you identify areas to improve as well as refine your approach.  If you're not getting enough done within your timebox, experiment with different approaches, while you tune your effectiveness and efficiency.
    • Version your results.  It can be very liberating if you think in terms of revisiting a problem over a period of time, versus trying to get it all right up front.
    • Defeat analysis paralysis.  Analysis paralysis can be the worst enemy of results.  Use a time box to switch gears from think mode to execution.

    Summary of Steps
    Here's some prescriptive guidance for creating and using time boxes effectively:

    • Step 1.  Identify candidate areas for time boxing.
    • Step 2.  Identify your objectives.
    • Step 3.  Identify the appropriate time box. 
    • Step 4.  Execute results within your time box.
    • Step 5.  Evaluate and adapt. 

    Step 1. Identify candidate areas for time boxing.
    Identify candidates for time boxing.  This could be anything from work projects to personal projects.  Personally, I've found it the most effective to start with something small, such as starting a new exercise program.  I've also found it effective to use it to tackle my worst time bandits (any area where I lose a bunch of time, with either little ROI or at the expense of another area.)

    Step 2.  Identify your objectives.
    In this step, ask yourself what you need to accomplish with time boxing.  Examples include:

    • Meet a deadline.
    • Show incremental results.
    • Make incremental progress on a tough problem.
    • Build momentum.

    Step 3.  Identify the appropriate time box.
    In this step, figure out what a right-sized time box would be.  For example, you might have a project due in three weeks.  Within that three week time box, you might decide that if you allocate 2 hours a day, you'll produce effective results.

    The right-sized time box largely depends on what you determined in Step 1.  You might need to grow or shrink your time box depending on whether you're trying to build momentum, show results or just make progress on a problem.
    Step 4.  Execute results within your time box.
    Execute within your timebox and stop when you run out of time.  This can be tough at first because you might be on a roll.  This can be really tough if you are used to doing things until they are done.  What you're learning at this step is how to stay completely focused, how to treat time as a limited resource, and how to tune your results.  You're also learning how to make time boxes effective for you. 

    Start with your time box as a baseline so you can evaluate your results.  The worst mistake is to give yourself an hour for results, spend two hours, and then say what a great job you did in your one hour timebox.  Instead, do the hour, then figure out whether you need longer time boxes or if your approach needs to change.
    Step 5.  Evaluate and adapt.
    If it's not working, change your approach.   Using time boxing is one of the most effective ways to experiment with different techniques to find the most efficient.

    Examples of Effective Timeboxing
    Here's some examples of putting timeboxes into practice:

    • Software development.  Because our teams within patterns & practices do iterative and incremental development, we make heavy use of time boxing.  For example, within a two-week iteration, how much value can we deliver?
    • Feed reading.  Give yourself a 10 minute window and see how many useful feeds you can read.  See how you tune your feed reading skills, including choice of reader, how you prioritize, and how you choose posts to read, as well as what links to follow.  You might choose to factor your exploratory, pleasure feed reading from your personal and professional development feed reading.
    • Email.  Use time to help you outsmart your inbox.  For example, if you allocate 30 minutes for your email, but you're falling behind, instead of throwing more time at the problem, experiment with different approaches.
    • Time bandits.  Set limits on how much time you'll throw at your worst time sinks.  For example, do you spend too much time in meetings?  Do you spend too much time stuck in analysis paralysis and not enough time in execution?  Tackle your time-bandits with some hard limits.    

    Additional Resources

    My Related Posts

  • J.D. Meier's Blog

    Actions, Insights and Notes


    I find chunking my notes from lectures and training helps me turn insights into action.  I chunk my notes into three categories:

    • Actions - this is a tickler list of things I'm going to go do.
    • Insights - this is a tickler list of distinctions and "ah-ha"'s from the sessions.
    • Notes - this is my raw tickler list and details of key notes throughout the session.

    Why It's Effective
    It's simple, but effective.  It's effective because rather than just a list of notes, it's distilled actions and reference points.

    Putting It Into Action
    Here's what I do 

    1. During the session, I can capture a lot of notes fairly quickly.  I typically use a pad of post-its and jot down key things.  These are my raw notes.  For example, during the lecture or training, I'll take a bunch of notes in a pretty linear fashion.  It represents a stream of real-time notes. 
    2. I transfer the notes to an electronic store (usually notepad).  This is a fast, focused step.  Sometimes I use Dragon NaturallySpeaking software and just read my notes rappidly.  I title this section Notes.
    3. I scan my notes and cherry pick the insights.  I put these under an Insights section that I create above my Notes section.
    4. I scan my notes and cherry pick the actions.  I put these under an Actions section that I create above my Insights section.

    The result is a crisp set of actions, a crisp set of insights, and then a full reference list of notes.  Taking  a few quick passes through my notes, reminds me of key things and helps the information sink in deeper.   Deliberately turning notes into insights and actions also helps retention.  Think of it as challenging yourself to use what you learn.

  • J.D. Meier's Blog

    How To: Create a “Hello World” WCF Service Using Visual Studio


    Here's a quick step through of using WCF in Visual Studio 2005.  In this case I used a local machine, running Windows 2003, for the service and the client. 

    There's lot of possible paths, and this is just one path through.  I focused on "Hello World" to run through the basic mechanics, but chose a path to touch enough things that might be interesting to explore another day.

    Use Visual Studio 2005 to do a dry run of creating a WCF service hosted in IIS and calling it from a console application on your local development workstation.  (Note that you don't need to host WCF in IIS; for example, you could use a surrogate console application.)

    In my case, I needed the .NET 3.0 components and the WCF extensions for Visual Studio:
    1. .NET 3.0 Runtime Components
    2. WCF and WPF extensions for Visual studio

    Summary of Steps

    • Step 1.  Create the test service
    • Step 2. Add a Hello World Method
    • Step 3.  Test your WCF service
    • Step 4.  Enable meta-data for your WCF Service.
    • Step 5.  Create the test client.
    • Step 6.  Add a Web Services reference to your WCF Service.
    • Step 7.  Add the namespace to your
    • Step 8. Call your WCF service

    Step 1.  Create the test service
    In this step, we'll create a WCF service that uses HTTP bindings, for backward compatibility (non-.NET 3.0 clients)

    1. In Visual Studio, click File -> New Web Site
    2. Select WCF Service
    3. Browse to a directory to store your project: (e.g. D:\Dev\WCF\Test1\Serve )
    4. Enable wsHttpBinding.  To do so, right-click Web.config and click Edit WCF Configuration ... Expand Services > expand MyService -> expand Endpoints.  Click (Empty Name).  Change wsHttpBinding to basicHttpBinding
    5. Create the virtual directory.  In your File Manager, right-click your Server folder (i.e. D:\Dev\WCF\Test3\Server) and click Properties, then Web Sharing, and click Share this folder, then click OK.

    Step 2. Add a Hello World Method
    In Service.cs, you'll add your Hello World method:

    1. Add the HelloWorld operation contract below public interface: [ServiceContract()]
      public interface IMyService
          string MyOperation1(string myValue1);
          string MyOperation2(DataContract1 dataContractValue);
          string HelloWorld();
    2. Add your HelloWorld method below public class MyService : public class MyService : IMyService
          public string MyOperation1(string myValue1)
              return "Hello: " + myValue1;
          public string MyOperation2(DataContract1 dataContractValue)
              return "Hello: " + dataContractValue.FirstName;
          public string HelloWorld()
              return "Hello World";

    Compile and debug any errors.
    Step 3.  Test your WCF service

    1. In IIS Manager, under Default Web Site, right-click expand Server (the virtual directory you just created)
    2. Right-click Service.svc and click Browse

    There's two issues you might hit here:

    1. You don't have ASP.NET installed/enabled.  To fix this, first run aspnet_regiis /i from your .NET installation directory (C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727)  Then, allow ASP.NET in your IIS Manager.  To do so, in IIS Manager, expand Web Service Extensions, select ASP.NET v.2.0.50727 and click Allow.
    2. You might see "Security settings for this service require 'Anonymous' Authentication but it is not enabled for the IIS application that hosts this service."  To fix this, first enable anonymous access.  In IIS Manager, right click your v-dir (Server), click Properties, click Directory Security, click Edit under Authentication and Access control, click Enable Anonymous Access, then OK your way out of the dialogues.  Next, recycle IIS.  In a command prompt, type IISreset.  If successful, when you browse your Service.svc file from IIS Manager (e.g. http://localhost/service/service.svc). you'll get a message that starts with the following:
      This is a Windows© Communication Foundation service. 
      Metadata publishing for this service is currently disabled.

    Step 4.  Enable meta-data for your WCF Service.

    1. In VSTS, right-click Web.config and click Edit WCF Configuration.  In WCF Configuration, expand Advanced, then expand Service Behaviors, then
      right-click returnFaults and click Add Service Behavior Element Extension.  Select serviceMetadata and click Add
    2. In WCF configuration, select serviceMetadata and change HttpGetEnabled to True.  Close the dialogue and save changes.
    3. Test your service again.  Browse to http://localhost/Server/Service.svc and this time you should see your service (e.g. MyService Service).  You
      will see a message that starts with the following:
      "You have created a service."

    Step 5.  Create the test client.
    In this step, we'll create a quick console app to call the WCF service:

    1. In Visual Studio, click File -> New -> Project
    2. Select Console Application.
    3. Browse to a directory to store your test client:  (e.g. D:\Dev\WCF\Test1\WCFClient)

    Step 6.  Add a Web Services reference to your WCF Service.
    In this step, we'll add a Web Services reference. 

    1. Right-click References      
    2. Click Add Web Reference ...
    3. In the Add Web Reference dialogue, add the path to your WCF Service (http://localhost/Server/Service.svc)
    4. Click Add Reference to close the dialogue.  You should then see your Web Service reference show up under Web References.

    Step 7.  Add the namespace to your   

    1. Browse to your Reference.cs file.  You'll find the file below Reference.map under your Web service reference.  You might need to click the Show All Files button on the Solution Explorer so you can see the files under your Web service reference. 
    2. Find the namespace.  You'll see a line similar to the following:
              namespace ConsoleApplication1.localhost
    3. Add the using statement to your Program.cs file.
                      using ConsoleApplication1.localhost;

    Step 8. Call your WCF service
    In your test client, call your WCF service:
            static void Main(string[] args)
                MyService service = new MyService();
                string foo;
                foo = service.HelloWorld();
    When you compile and run your console application, you should see the following:
    Hello World
    Press any key to continue . . .

    Additional Resources

    Hopefully this step through helps you quickly see some of the bits and pieces you can play with.

  • J.D. Meier's Blog

    Scenarios in Practice


    Scenarios are a practical way to organize and focus your product design, development and release.   (We use scenario-driven engineering in patterns & practices) 

    Key Benefits

    • Business value.  You can  use scenarios to evaluate business value.   What pain does that scenario address? ... What opportunity does it create? ... etc.
    • Chunking and prioritizing.  You can use scenarios to chunk up and prioritize your product.  You can think of versioning in terms of releasing incremental value or scenarios.
    • Effective design.  Walking through a set of customers scenarios and "what ifs" will help you figure out your product's most effective design.  It's not a silver-bullet, but it does help make requirements more concrete, or at least put them in perspective.  It also opens the door to more precise questions about user experience or engineering challenges..
    • Focal point for perspectives.  You can use scenarios as a focal point for user experience, business and tech perspectives.
    • Requirements in context.  You can use scenarios to put requirements in context.  A requirement makes a lot more sense when you see it in action.
    • Architectural trade-offs.  You can use scenarios to evaluate and make architectural trade-offs.  You can't evaluate an architecture in a vacuum; you can evaluate against concrete scenarios.  There's several flavors of scenario-based evaluations you can leverage.
    • Customer value.  Your customers can appreciate how well you did (or didn't) address their scenario.
    • Tests for success.  You can use scenarios as tests for success.  By measuring customer effectiveness against specific scenarios, you have a way to focus your improvements.

    Chunking Up a Project Using Scenarios
    If you think of your product as helping a user accomplish a goal, it helps cut through the fog. You can think of your product in terms of a list of user goals, business goals and technical goals.  What's the minimum set of tasks your user needs to perform with your product?  That's your baseline release.  What's the incremental value from there?  That's how you start to shape your versions and releases.

    User Experience, Business and Technical Perspectives
    Using scenarios is a good forcing function to bring together the user experience, business, and technical perspectives.  For the sake of example, let's say your scenario is "User views the product catalog."  From the user experience perspective, you're thinking in terms of "show me a relevant list" and "don't make me wait,"  From a business perspective, you're thinking in terms of "support a given number of orders per hour" and "lower the total cost of ownership."  From a technical standpoint, you're thinking in terms of "requests per second," "minimize resource utilization," ... etc.  Well, no wonder getting software right is tough!  Luckily, scenarios help you bring together and rationalize the perspectives against a common frame of reference.

    Constraints Make More Sense In Context
    Constraints are boundaries to operate within, or what the solution must or must not do.  In software, I see a lot of generic constraints passed down as policies.  When policy meets scenario, you now have a way to evaluate the effectiveness of that constraint.  You can also measure whether that scenario is actually meeting the constraint.  You can perform scenario-based testing against a set of scenarios with specific constraints.

    Walking the Scenarios
    Have you ever been sold on a great set of features, only to fall flat when you try to actually do something useful?  Obviously, that's the extreme case, but it happens to me.  It happens less now because whenever I go to buy something, I walk my usage scenarios.  Doing a dry run against a scenario is very revealing.   This approach works great on the engineering side too.  It's one thing to have generic technical requirements for security or performance.  It's another to evaluate a scenario and make appropriate and relevant trade-offs from a user, business and technical perspective.  Suddenly, generic technical requirements no longer seem as helpful, do they?  They still have their place, but when you're engineering your job is to make the right trade-offs.

    Scenarios and Solutions
    Given part of my job is to improve customer effectiveness on our platform, I regularly use scenarios as a backdrop for evaluation.  As I've gotten more effective, I noticed shifting from features and components to scenarios and solutions is the key.

    More Information

    My Related Posts

  • J.D. Meier's Blog

    Guidance Explorer: A Top Download on CodePlex


    It was a nice surprise to see that our Guidance Explorer is among the top downloads on CodePlex.


  • J.D. Meier's Blog

    Growth Mind-set Over Fixed Mind-set


    Do you have to be great at everything?  If this stops you from doing things you want to try, then it's a limiting belief.  Scott Berkun spells this out in Why You Should Be Bad at Something.

    Keys to Growing Your Skills
    Here's a set of practices and mind-sets that I've found to be effective for getting in the game, or getting back in the game, or learning a new game versus just watching from the side-lines. 

    • Swap out a fixed mind-set with a growth mind-set. (innate ability vs. learning) See The Effort Effect.
    • Call it an "experiment."  This sounds like a trivial frame game, but I see it work for myself and others.
    • Treat perfection as a path, not a destination.  If you're a "perfectionist," (like I "was", er "am, er ... still fighting it), you know what I mean.
    • Use little improvements over time.  Focus on little improvements and distinctions over time, versus instant success.  It's consistent action over time that produces the greatest results.  You're probably a master of your craft, whatever it is you do each day, every day.  John Wooden focused his team on continuous, individual improvement and created the winningest team in history.
    • Remind yourself you're growing or dying.  You're either climbing or sliding, there's no in-between (and the slide down is faster than the climb up!)
    • Try agin.  If at first you don't succeeed, don't just give up.  Remember folks like Thomas Edison, who "failed" many, many times before finding "success" (it's a part of innovation)
    • Focus on lessons over failures.  Remind yourself there are no failures; only lessons (one more way how "not" to do something)
    • Fail fast.  The faster you "fail", the faster you learn.
    • Don't take yourself or life too seriously.  If you take yourself too seriously, you'll never get out alive!
    • Learn to bounce back.  It's not that you don't get knocked down, it's that you get back up.  (Just like the song, "I get knocked down, but I get up again")
    • Give yourself time.  A lot of times the difference between results is time.  If you only chase instant successes, you miss out on opportunities. Walk, crawl, run.  Or, if you're like me, sprint and sprint again ;) 
    • Start with something small.  Build momentum.  Jumping an incremental set of hurdles is easier than scaling a giant wall.   
    • Build on what you know.  Now matter where you are or what you do, you take yourself with you.  Bring your game wherever you go. 
    • Learn to like what growth feels like.   I used to hate the pain of my workouts.  Now, I know that's what growth feels like.  The better I got at some things, the more I hated how awkward I was at some new things.  Now I like awkward and new things.  It's growth.
    • Find a mentor and coach.  It doesn't have to be official.  Find somebody who's great at what you want to learn.  Most people like sharing how they got good at what they do.  It's their pride and joy.  I used to wonder where the "mentors" are. Then I realized, they're all around me every day.
    • Have a learning approach.  For me, I use 30 Day Improvement Sprints.  Timeboxes, little improvements at a time, and focus go a long way for results.  I use 30 Day Improvement Sprints.

    There's a lot more I could say, but I think this is bite-sized working set to chew on for now.

    More Information

    • The Effort Effect - This article exposes the truth behind "you can't teach an old dog new tricks" and whether all-stars are born or made (nature vs. nurture.)  If you have kids, this article is particularly important.  Adopting a growth mind-set over a fixed mind-set can have enormous impact.

    My Related Posts

  • J.D. Meier's Blog

    Links: patterns and practices links


    I did a quick round-up of some key patterns & practices team links and figured I'd share:


    Team Blogs

    CodePlex Projects

    Community Contribution

    Surveys / Feedback


  • J.D. Meier's Blog

    Patterns and Practices for New Hires


    Whether you're a new hire or taking on a new job, here's some principles, patterns and practices to be more effective.  They're lessons learned from the school of hard knocks and they represent some of the proven practices that have worked for others and have stood the test of time.   This is a limited, but prioritized list (I gave myself a 20 minute window.)  I'll drill into areas in upcoming weeks, depending on where there's interest.

    Personal Productivity

    • Timebox your day.  Carve your day into time budgets.  Figure out how much time you should spend on administration, work time, meeting time, and think time.  Start with a day.   For example, some of the most effective people spend 1 hour on admin, 1 hour on think time, 4 hours on work time, and 2 hours on meetings.  You need to find the pattern that works for you.  The trap is to not know when the day ends and over-spend time in areas you should allocate to others.   See Timebox Your Day.
    • Manage your meetings.  You'll likely spend a lot of time in meetings.  Value your time.  Find out the meeting you must go to versus should or could.  Use meetings to build your network.  The most effective meetings have agendas and the right people.  Some meeting are more about connection versus results, so if you know that up front, you can reset your expectations.  Nothing's worse than trying to get results in a connection meeting.  One thing to remember is that connection precedes results.  You get more done with rapport (think "rose colored glasses")       
    • Manage your mail.  Doing a day of email doesn't mean you did a great day of work.  Timeboxes help.  See Clearing Your Inbox.
    • Manage your action.  Think in terms of daily results working towards larger outcomes.  See Execution Checklists and Using Scannable Outcomes with My Results Approach.
    • Manage your plate.  Underpromise and over-deliver.  It's better to nail a few things well, than take on a bunch and never finish.  Think of it like a buffet -- rather than over-flow your plate and get bogged down, take smaller plates and more trips.  The fast eat the slow.
    • Master information management.  The most important concept is to factor reference information from action.  Always use the RAT test on information you get (relevant? accurate? timeley?)  Use trusted sources and trusted people for finding the best, most distilled information.
    • Manage your energy.  You can throw a lot of time at a problem, but it's your energy that will give you the power hours.  See Manage Energy, Not Time.


    • Know what's important.  Your manager and peers will tell you if you ask.  Sanity check when you hear one thing, but see another.  Usually folks are doing what's on their commitments, so walk the commitments stack up the chain to see how and where you fit in.
    • Manage your results.  Microsoft rewards "smart and gets results."  Focus on outcomes over activities.  Think in terms of value delivered over activity performed.  You can do lots of activities but that doesn't necessarily translate into meaningful results.
    • Walk an instance end-to-end.  Know what you're getting yourself into.  Whatever your team delivers, walk an instance from start to end.  Knowing the bigger picture will quickly help you orient where you are in the bigger picture.  This will help you anticipate.  You'll also know how to pace yourself for the race (walk, jog or run.)
    • Avoid analysis paralysis.  It's really easy to fall into the trap of mistaking great throughts for great actions.  Take action and improve.  Analyze enough to start taking action, getting results and improving.  Figure out your higher risks earlier versus later.  Fail fast.
    • Learn project management.  Knowing how to do a work breakdown structure, timeline, work estimates and how to allocate resources gives you an advantage in getting results.  You can apply these skills to a micro-level (personal productivity) or to a macro-level (getting large projects done.)
    • Play to your strengths.  You have your strengths.  Use them.  Find a way.  If you find yourself doing a job and you know you really could be more effective, figure out whether it's your approach.
    • Use reference examples.  Find the best reference examples and work backwards from there.  Whatever you need to do, chances are, somebody's paved a path or there's an example you can find.  You can leapfrog results if you don't always start from scratch.
    • Know the tests for success.  Nothing's worse than to finish a major project only to find you missed the mark.  Figure out the tests for success earlier versus later.  They're might not be a lot of clarity in the beginning, but continuously refine figuring out what good looks like.
    • Deliver incremental results.  If you can chunk it down, you have a better chance for success.  Show progress along the way.  Always have a great end in mind, but be able to chunk it up and make progress on the bigger picture.
    • Think in terms of value delivered.  You can think in terms of time (daily, weekly, monthly).  You can think in terms of value (how important is this).  Just the act of thinking in terms of value delivered will help you prioritize your personal queue. 


    • Create the driver's guide for your manager.  Your manager has a high-correlation to your job satisfaction and your success in Microsoft.  What's their communication style?  Do they like email, voice or dialogue?  How frequently should you meet with them to stay on the same page?  How do they want status?
    • What's their story?  Be careful when you jump to conclusions.  When somebody doesn't do something as you expect, it's good to checkpoint assumptions.  See What's Their Story? 
    • Speak in the right currency.  Know what matters to your audience and the terms they use.  Use their terms where you can to bridge the communication gap.
    • Use metaphors and mental models.  The better you can simplify complex information into a mental model or visual, the more effective you'll be.
    • Use stories.  Use short stories to convey a point.  By short, something you can say in a few sentences.  It should be relevant and have an emotional aspect.  If just stating a point, doesn't make the point hit home, sometimes telling the right story can.
    • Use a whiteboard.  The power of the whiteboard is that people tend to put down what's important versus get lost in the details.  You can also drill in or step back as needed.
    • Speak in slides.  A slide is a great forcing function to make you consolidate your point.  At Microsoft, it's easy to pass slides around.  I use One-Sliders.

    Intellectual Horsepower

    • Ask better questions.  Thinking in just asking and answering questions.  If you want better answers, ask better questions.  You can ask question in terms of time, meaning, assumptions, truth, causes, effects and actions.  One thing I like to do is think in terms of what do I know, don't know and need to know next.  See Cutting Questions.
    • Test it versus debate it.  There's a lot of opinions on a lot of things.  You'd be surprised how quickly a simple repro test can cut through debate.  Find empirical evidence where you can.
    • Learn thinking techniques.  There's lots of thinking patterns and techniques.  You can study Disney's imagineers such as Michael Michalko, or practices such as Neuro Linguistic Programming (NLP.)

    Learning / Improvement

    • Change your approach.  Stay adaptable.  If you're not getting results, change your approach.  The best way to get unstuck is to change your approach.  You learn the most from trying something different.  Sometimes this is uncomfotable, but that's what growth feels like.
    • Model the best.  Find the people that get results.  Have at least a few examples of people that have both continuous improvement and balance.  For balance, that means both work and home, and at work it means, balance between connection and results. 
    • Take key training.  Obviously, you'll want relevant technical training, but you'll want training to make you more effective in your day to day success at Microsoft.  While I've had great tech training, some of my most useful training has been in effective meetings, personal productivity, interpersonal communication, negotiation skills, influence, leadership, and thinking techniques.
    • Use everybody as a mentor.  Everybody can teach you something.  Everybody.  Find something each person does well and find out how they do it.  Success leaves clues.
    • Use a personal sounding board.  Find some folks you trust to give you the tough feedback.  Sanity check your ideas with your personal sounding board.
    • Improve strengths, but limit liabilities.  If you spend all your time working on your weaknesses, you won't get the benefit of your strengths.  Continously improve your strength, while you master you craft.  Every day at work is a chance to practice.  Reduce your liabilities, but don't ignore improving your strengths. 


    • If you don't know, ask.  If you ask a precise enough question, you can stretch your network over time and space.
    • Build your network.  Your network naturally waxes and wanes.  Your results are a combination of what you know and who you know.  Building your network will help you get more done over time.  It's a long-term investment that builds on itself.
    • Play tradesees.  It's easier to network when you bring something to the table.  You can trade what you know or your expertise in an area with somebody elses.  This is how a lot of effective people get results.  They build a network of complimentary skills and experience. 
    • Use WIIFY.  What's In It For You (WIIFY) is a simple, but effective way to communicate.  If you always ask yourself, what's in it for the person you're brokering in, you're off to a better start.  Point out to them what's in it for them if it's not obvious.  If there's nothing it it for them, then that's a flag.  Challenge yourself to find a way for their to be something in it for them and you'll get further.

    My Related Posts

  • J.D. Meier's Blog

    My Cockpit


    A few readers asked me to show some screens of my approach in Outlook.   (I haven't used images in my blog before, so this is a good post to give it a shot.)

    My Outlook Folders
    Here's what I see when in my Outlook folders.


    Notice how I cluster my scannable action folders (Outcomes, To Dos and Daily Status) and my reference folders (Notes, Quick Stuff and Thoughts.)  The reference folders are my Collection Pools.  The folders are physically stored in my local Outlook.PST folder I named "Admin." I then dragged the folders up to "Favorite Folders" since I use them daily.






    Scannable Outcomes
    I use Posts in Outlook for my Scannable Outcomes.  This is what I see when I click my Outcomes folder:


    Each post represents a key project.  In each post, I list the outcomes and actions (like a mini queue.)  I can scan each post very quickly using the Outlook preview pane. 

    My To Dos
    I use Posts in Outlook.  Here's a shot of leveraging the pre-view pane for my To Dos.   This is what I see when I click my To Dos folder.


    Keys to Results

    • Factoring action from reference helps get results.
    • Consolidating reference information to a few collection pools helps simplify storing information.
    • Using scannable indexes for action is a low-overhead way to figure out next actions.
    • Using scannable outcomes shows me everything on my radar at a glance.  It's ultimately my portfolio of results and a quick view of where I spend my time and energy.  It continuously reminds me that I need to balance areas in my life.  When my portfolio is not compelling, I know it's time for a change.
  • J.D. Meier's Blog

    Collection Pools


    How do you store your notes and reference information in a way that’s low overhead and easy to find?  The key is to created a limited set of places to look that you trust.   I use a small set of what I call Collection Pools.  I think of them as pools because they’re effectively pools of reference information I draw from.

    Collection Pools
    I currently use the following pools:

    • Notes
    • Quick Stuff
    • Thoughts

    I create a folder in Outlook for each pool and I create posts in the folders.  It’s flat by design.  I could just as easily use a folder  on my hard drive with text files, but I like the preview pane in Outlook and sometimes the rich text helps.

    Using the Pools
    Here's how I use the pools:

    • Notes is where I store the majority of my reference information which is anything from a meeting recap to notes from a Web page.  It’s one long flat list of posts, ordered by time.  I can quickly sort by title or search for a keyword.  I used to use a local Wiki, but I find a flat lists of posts to be really lightweight and effective.  Scrolling through my notes is great with the preview pane in Outlook.
    • Quick Stuff is where I keep a lot of common lookup information and indexes, such as favorite links, lab machine names, distribution lists … etc.
    • Thoughts is where dump my ideas and distinctions I make throughout the day.  It’s my pool of insights.  It’s a very light-weight way to journal my ideas and distinguish my insights from the rest of my reference notes.

    I actually started with my Notes and Quick Stuff folder a few years back.  I thought it would be a temporary solution while I explored options.  It turned out to be the most efficient approach of all the various ways I tried.  I always knew where to put things and I always knew where to look and it was always open.  I added the Thoughts folder in February this year.  It too turned out to be the most efficient approach I have for a scannable set of ideas and insights and I like the ability to scroll through time.

    While there’s a lot of fancier things I could do, simple text notes chunked up in a few folders is a pretty efficient system.  I think the lesson here is that for a practice to stick over time, it has to be simple enough and effective enough.  Otherwise, it fails the test of time. 

    My Related Posts

  • J.D. Meier's Blog

    Vision Scope Template


    How do you convince a team of venture capitalists to bet on you?  There's a lot of ninja techniques but here I'll share the fundamentals. 

    Vision and Scope
    We use Vision Scope milestones in patterns and practices to sell management on how we'll change the world.  Knowing the vision and scope for a project is actually pretty key.  The vision will motivate you and your team in the darkest of times.  It gets you back on your horse when you get knocked off.  The scope is important because it's where you'll usually have to manage the most expectations of what you will and won't do.

    Thinking in Terms of Venture Capitalists
    When I do a vision scope, I think of the management team as the venture capitalists (a tip from a friend.)  This helps me get in the right mindset.  I have to convince them that I have the right problem, the right solution, the right customers, the right impact, the right team, the right cost and the right time-frame.  Hmmmm ... I guess there's a lot to get right.  A template helps.  The right slide template helps because it forces you to answer some important questions.

    Template for Vision Scope
    Here's the template I used from my last vision scope meeting:

    • Agenda
    • Problem
    • Vision
    • Approach
    • Prioritized Tests for Success
    • Scope
    • Key Activities
    • Deliverables
    • Execution
    • Team
    • Budget
    • Schedule
    • Asks
    • Go/No Go

    It's implicitly organized by problem, solution, deliverables and execution.  While the slides are important, I found that the real success in vision scope isn't the particular slides.  It's buy in to the vision, rapport in the meeting, and trust in the team to do the job. 

    What works for you?

  • J.D. Meier's Blog

    It's the Fast That Eat the Slow


    Using speed as a competitive advantage is less about finding ways to do things quicker.  It's more about eliminating speedbumps.  In It's Not the Big That Eat the Small...It's the Fast That Eat the Slow: How to Use Speed as a Competitive Tool in Business, Jason Jennings and Laurence Haughton write:

    "Instead of looking for magical answers as to what companies do to be fast, we began asking, "What do fast companies do to eliminate speed bumps that slow everyone else down?" ... truly fast companies that have demonstrated the ability to maintain momentum aren't naturally faster than their slower-moving rivals.  But they are smarter.  Smart enough to recognize that the speed bumps that slow everyone else down must be ruthlessly eliminated... Each has made speed -- fast thinking, fast decisions, fast to market, and sustaining momentum -- one of their unique competitive advantages."

    Friction is death by a 1000 paper cuts.  I'm a fan of reducing friction, while building speed and momentum.  I'm always asking, what speedbumps can I eliminate in my day? ... my job? ... my org? ... my company? ... my industry? ... my life?   These simple questions shape a lot of what I do.  If I'm not part of the solution, I'm part of the problem. 

  • J.D. Meier's Blog

    Testing Your Organizational Clarity


    How do you figure out what your organization is really about?  It's one thing to know it intutitively.  It's another to be able to share it or have meaningful dialogue.  Here's the tests I use lately to know what a team or org is really about:

    Tests for Organizational Clarity

    • Vision / Mission: What's the one-liner vision and mission?
    • CustomersWho's the customer?
    • Problems: What domains or problems does it focus on?
    • Business Case; What's the internal and external business case?
    • Measures of Success; What's the measures of success?
    • Catalog / Product Line: What's the product line / deliverables / results?
    • Rhythm of Results: What's the product cycle or rhythm of results?

    If you know these, it tells you a lot. 

    Why This Cuts to the Chase
    Here's a quick rundown on how you can use this:

    • Mission is who you are and vision is where you want to go. An important attribute in the mission, is some unique value or differentiator. If everybody knows the vision and mission, they can run to the same finish line.   For me, I like one-liner visions and missions that you can spit out in the hall without a cue card.
    • In a large shop like Microsoft, knowing your customers makes a big difference.  For me, while I server a lot of customers, my main focus is developers.  While it's partly a chicken and egg deal, knowing your customers helps you clarify which domains or problems you tackle.  When in doubt, ask your customers!
    • Owning important problems is key.  I think you can measure the value of an org, by measuring the value of the problems it solves.
    • Business cases are powerful because they justify existence and investment.  I think looking through two lenses helps -- what do your customers see as the business case? (why you versus some other group or service or product) ... and what does your company see as the business case? (what's the unique value to keep this group around and invest in it)  One important piece of a business case is knowing how big is the pie and what's your slice.
    • Measuring success is important.  Everybody wants to do a good job and know what it is.  Knowing what gets measured tells you what's valued.
    • Knowing the deliverables in the form of a catalog or product line tells a lot about an org or team.  I like to think in terms of portfolios of results.  When I talk to teams about what they do, finding out what they deliver really cuts to the chase.
    • The rhythm of results is important.  This tells you a lot about the cadence, work styles, value of time, ... etc.

    There's obviously a lot more you can know about an org or team, but I'm finding these are keys to cut to the chase.

Page 39 of 47 (1,165 items) «3738394041»