J.D. Meier's Blog

Software Engineering, Project Management, and Effectiveness

October, 2007

  • 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

    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

    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

    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

    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

    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

    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

    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

    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

    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

    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

    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

    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

    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

    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

    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

    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

    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 1 of 1 (18 items)