j e s r u s h . c o m

Most day-to-day project or operational decisions don’t require grand meetings and circumstance, but there are some situations where gatherings should be called to make decisions:

• Whenever group input is likely to significantly improve the quality of the decision.
• Whenever the problem is complex and requires multiple specialists.
• Whenever team members might have difficulty accepting a decision

So how does a project manager or leader facilitate these decision-making sessions? I’ll share my basic framework:

1. Identify the problem. Clearly state the fundamental problem and its context. The key thing here is to avoid framing the problem in terms of choices (predefined choices kill creativity). The WRONG way: “Should we abandon the mapping component entirely or substitute an alternative map module?” The RIGHT way: “The mapping component difficulties have put us ten days behind schedule. We need to determine the best way to move forward.”
2. Generate options. Begin by establishing a moratorium on criticism. All ideas–even the craziest ones–are wanted here. Make the point that all ideas belong to the group, nobody “owns” an idea, and everyone is free to twist and extend ideas suggested by someone else. Try to gather as many ideas as possible (quantity over quality) and be sure to prompt/include anyone who is naturally shy or not participating. Put all ideas up on a whiteboard as they come in.
3. Set evaluation criteria. The team needs some way to sort through the options. If you established an expectations management matrix with the sponsor (which prioritized scope, schedule, or budget) or if you defined a project vision (e.g. “Put a man on the moon by 1975″), then you have your basic criteria there. For example, an alternative which pushed you past 1975 would score poorly.



4. Facilitate a Decision. Provide summaries of progress and keep the group on track. Protect minority opinions and ensure that everyone has a say. Test consensus and re-state your understanding of what is being said (silence does not equal agreement!). Some conflict here is acceptable (even desirable), but if tempers flare or it becomes dysfunctional — then end the meeting and reschedule another one.
5. Follow Through. After the decision has been made, the group should later be called together for a miniature ‘lessons learned.’ Did the decision turn out to be the correct (or best) one? If not, what threw the group off? How can a better decision be made next time?

   The bottom line is that if you want good decisions, you must follow a good decision-making-process!

The HR manager at my last organization and I have a long-running joke about what our country would be like if our president were hired by HR instead of being chosen by popular vote. To make a long story short, the joke goes that we would have no president, because HR would add a requirement to the job description that the person have, “4+ years experience running the country.” As there would be no way to obtain that experience without first being given the job, there would be no qualified candidates.

I don’t mean to pick on HR. In fact, I love HR and believe that the director of HR should sit atop the org chart right next to the CFO (Yes, hiring, growing, and retaining the right people is THAT important to organizational success). But I’ve also noticed a troubling tendency among recruiters (and sometimes functional managers) to automatically reject candidates who don’t have experience doing the job which they are filling. The legendary story of the General Electric HR manager who recommended against hiring Jack Welch should forever haunt recruiters everywhere.

I hate to state the obvious, but people cannot obtain certain kinds of experience until someone gives them the opportunity to do so. Most successful managers for example, were at some point a regular staff worker with no formal management experience. Someone looked at their past performance (which–for humans–is a good indicator of future success), looked at the opportunity, and took a calculated risk by placing them into a “bigger” job.

I’m not suggesting that you should put your landscaper in charge of your IT department because they do a great job on your hedge rows. What I am saying is that whenever you encounter someone who has taken on stretch assignments, undergone training, and reached outside their formal job responsibilities, you should take notice. Many of these people will be tomorrow’s successful managers and simply need the right break to become stars. You could be the enabler who spots the next Welch.

Update 7/21/09: Patty Azzarello has echoed my thoughts in her excellent article: How to hire a star.

Crisis management is one of the most undervalued management skills: It’s rarely taught in business school and no one cares until things hit the fan. But when they do, a steady hand at the helm can guide a team through the stormiest of waters. The most important thing is to be systematic and to keep making decisions. I wanted to step through the anatomy of a recent crisis and explain what I did and why it worked.

The crisis: This particular crisis began on a quiet weekday when a customer sent us an email out of the blue stating that our system — which was installed at their site — was hogging all their network bandwidth and freezing their computers. Apparently, it was so bad that their employees could barely work. And the problem coincided with use of our system earlier in the day.

Yikes!!!

Step 1: Re-prioritize and compartmentalize.

A potential crisis must be bushwhacked with great force. If you hit it hard enough and fast enough, you can sometimes avert the crisis altogether, or at least minimize its impact. I pretty much dropped everything I was doing to focus entirely on this issue.

Meanwhile, I did everything possible to compartmentalize the issue and maintain the impression of normalcy with the customer. Crises have a tendency to take on a life of their own (if you let them) and it’s important to carry on as if everything is under control. After acknowledging the email with a quick phone call to the sender, I made a point of speaking with other people at the customer’s office about unrelated issues. They didn’t mention anything about the network and nor did I.

Step 2: Plan for Sea Animals

When someone accuses you or your team or your products of causing a problem, it’s only natural to react skeptically. Your people are good and your widgets work just fine–thank you very much.

A good manager has to fight that urge. It’s possible the whole thing could be a misunderstanding, but it’s equally possible the crisis could be real. Real crises often turn out to be bigger than their initial boundaries. They’re like those foam capsules you drop in a sink full of water, they turn into two foot alligators.

With that in mind, I assumed the worst. Maybe our system was somehow causing total work stoppage. Maybe it was interrupting crucial business process. Perhaps it had been affecting their network even before today. Could the system have been compromised? It might get even worse. By thinking through these possibilities, you help ensure that the scope of your response is sufficiently wide. And mentally, you ensure that you’re not going to be caught off guard by unexpected bad news.

Step 3: “Trust, but verify.”

In the famous words of President Reagan, it’s time to figure out whether this crisis has any teeth. Using your enlarged scope from step 2, you do some fact-finding and gather hard data. A good starting point is simply the five W’s (who, what, where, when, and why).

In this case, we delved into the system logs in question, looking for activity indicators. Of course we also looked at past days, kicked off virus scans, and asked for more details from the customer contact.

Step 4: Report

If the crisis looks legit, the next step is to immediately notify your boss. You don’t want to shirk from delivering bad news. Better now than later. I walked over to my bosses office with a fistful of data showing that our system had definitely been active around the same time that the customer experienced issues. I also notified the project manager currently using the system as well as the salesperson who sold it to the customer to begin with.

Step 5: Imagine it’s High School

Although you’re trying to maintain the appearance of normalcy, you have to plan for the possibility that in short order — everyone will know: Everyone at your customer, all of your employees, maybe even your competitors, or (gulp) the press.

If/when they do, you need to have something prepared to tell them that will maintain control and nip the rumors. I worked up a short memo laying out the facts and explaining that no link had been proven between our systems and their network problems — yet. Sure enough within a half hour, another manager was asking for information about the situation. Click! Memo sent.

Step 6: Build a Project Plan/Team

The simplest way to tackle a multi-headed dragon is to break it down into small, concrete tasks and assign them to specific people. Usually a gantt chart with tasks/due dates and a RACI chart outlining roles & responsibilities is sufficient.

I doled out a couple of tasks to the PM with a next day deadline, and outlined the steps which we would be taking to further investigate the issue.

To make a long sleeve short, over the next week we ultimately discovered two things:

1) Their network slowness did not perfectly correspond to use of our system. Meaning, they had *other* unrelated issues contributing to the slowness.

2) They had changed their network architecture, reducing throughput in the process. This was news to us and information which would’ve been useful yesterday.

So in the end, it turned out that our system was behaving normally and was fully exonerated. It was doing the same things it had always done, but the environment it operated in had changed (for the worse). After explaining this to them via a teleconference, we dialed back our system activity until they could get their network\throughput issues worked out. We followed up with a written explanation reiterating the same things said on the phone. Fortunately, they understood.

Step 7: No Pain — No Gain.

Lastly, you want to use the momentum from the crisis to change the processes (or even people) so that it never happens again. Be a change agent.

In this case, the crisis had more bark than bite since it really wasn’t our fault. But nonetheless we still used the energy to improve our system testing/planning process, so that we would be more likely to detect an environment change at the customer before things go south.

Wrapping Up

This particular crisis turned out well and they don’t always go so smoothly. The steps above sound incredibly simple in retrospect, but it’s amazing to me how few people actually follow them. Ultimately a crisis should only make you and your organization stronger, but things can and will spiral out of control if you’re not careful.

After using his super PMP study guide some time back, I picked up Andy Crowe’s other book, an obscure little text, ‘Alpha Project Managers,’ published in 2006.

This has to be one of the most under produced books I’ve ever seen.  Crowe essentially self-published on his own Velociteach label.  It shows.  The graphics are third rate and the cover is pretty bad. 

But no matter.  The information inside is fascinating. Crowe surveyed over 3,000 project managers and their co-workers/supervisors in order to identify the “top 2%” of project managers (”alpha project managers”). He tried to identify PMs who were consistently rated as excellent by the people they worked with and their customers. Once he found them, he zeroed in on their work habits and PM techniques.

Some of the interesting findings:

Career mentor extraordinaire Patty Azzarello recently made a suggestion to me that I take the ‘StrengthsFinder 2.0‘ assessment. This is a 175 question online timed test which asks questions like, “Which describes you more strongly: You get things done on time or You get things done correctly”. Painful! You want to choose both, but have to favor one or the other. The assessment was designed by Gallup and supposedly incorporates data from millions of people.

I’m notoriously skeptical of these kinds of things, especially after the Myers Briggs told me I was an introvert (my wife enjoyed a good laugh over that one). But I took the dive on Patty’s recommendation and have to say I’m really impressed. Out of the 34 “strengths”, the assessment tells you your five most prominent and this thing was spot on.

It said my strengths were that I’m:

Reading the descriptions of these was pretty amazing. They fit me to a “T”.

Why is this useful? Because so much of success both in your career and in your personal life depends on the extent to which you position yourself to take advantage of your strengths and minimize your weaknesses.

If you’re interested in taking the test yourself, you have to buy the accompanying book, which gives you an “access code” for the online test.

I wanted to share a handy little tool which I picked up awhile back: The PIECES framework. This short checklist is simply a list of things to think/worry about when designing, building, or implementing a system or application.

I suppose there are a lot of frameworks and checklists floating around out there, but this one happens to be really good. I use it not only for design, but also for change management to make sure I’m not forgetting anything. I have no idea who created it, but I’m forever in their debt!

Performance
   -Throughput
   -Response Time
Information (and Data)
   -Outputs
      +Lack of any information
      +Lack of necessary information
      +Lack of relevant information
      +Too much information – information overload
      +Information that is not in a useful format
      +Information that is not accurate
      +Information that is difficult to produce
      +Information that is not timely to its subsequent use
   -Inputs
      +Data is not captured
      +Data is not captured in time to be useful
      +Data is not accurately captured – contains errors
      +Data is difficult to capture
      +Data us captured redundantly – same data is captured more than once
      +Too much data is captured
      +Illegal data is captured
   -Stored Data
      +Data is stored redundantly in multiple files and/or databases
      +Stored data is not accurate
      +Data is not secure from accident or vandalism
      +Data is not well organized
      +Data is not flexible – cant meet new info needs from stored data
      +Data is not accessible
Economics
   -Costs
      +Costs are unknown
      +Costs are untraceable
      +Costs are too high
   -Profits
      +New markets can be explored
      +Current marketing can be improved
Control (and Security)
   -Too little security or control
      +Input data is not adequately edited
      +Crimes (e.g. fraud, embezzlement) can be committed against data
      +Ethics are breached: data or info gets to unauthorized people
      +Redundantly stored data is inconsistent in different files or databases
      +Data privacy regulations or guidelines are being (or can be) violated
      +Processing errors are occurring (people, machines, or software)
      +Decision- making errors are occurring
   -Too much control or security
      +Bureaucratic red tape slows the system
      +Controls inconvenience customers or employees
      +Excessive controls cause processing delays
Efficiency
   -People, machines, or computers waste time
      +Data is redundantly input or copied
      +Data is redundantly processed
      +Information is redundantly generated
   -People, machines, or computers waste materials and suppliers
      +Effort required for tasks is excessive
      +Materials required for tasks is excessive
Service
   -The system produces inaccurate results
   -The system produces inconsistent results
   -The system produces unreliable results
   -The system is not easy to learn
   -The system is not easy to use
   -The system is awkward to use
   -The system is inflexible to new or exceptional situations
   -The system is inflexible to change
   -The system is incompatible with other systems
   -The system is not coordinated with other systems

Outliers is quite unlike anything I’ve ever read before. Most books which storyboard successful people concentrate on the little “tells” of genius: The quirks, habits, and beliefs which seemed to have propelled their meteoric rise to the top.

With Warren Buffet its always his “aw shucks” humbleness — he still lives in the same little house he bought 50+ years ago. With Bill Belichick its always his dedication to breaking down film, hours and hours toiling in the film room. Steve Jobs had his obsession with simple design. The list goes on and on.

Outliers on the other hand, takes a completely different approach. Instead of focusing on the quirks of successful people, Gladwell says success isn’t so much about the people — as it is the culture and legacy from which they came. Gladwell concedes that that smarts and hard work are key ingredients in success, but insists that opportunities are far more important.

Exhibit A is Chris Langan, the world’s smartest man, and someone mired in mediocrity. Langan — because of his poor rural upbringing — never had many opportunities. He dropped out of college because of a financial aid mixup and couldn’t summon his mother to help him sort it out. Meanwhile Gladwell chronicles a series of lesser lights who had better opportunities, better families, better backgrounds, and made something of them.

It’s a fascinating read which turns everything we know about success on its head. It’s a paradigm shift, the kind of book that comes along only once every few years.

If there is a weakness to Outliers, its that Gladwell is a better storyteller than he is researcher. Occasionally he substitutes a good story for data, and things teeter on the anecdotal.

But no matter, Gladwell is clearly on to something and marshalls more than enough examples to prove it.

Required Reading for All Audiences \ Insanely Recommended.

The other day I witnessed a major misstep when a vendor serving my own employer recommended a solution to us which was incompatible with one of our key business constraints.  Fortunately we caught the problem, and the proposal was scraped.

But not everyone is so lucky.  Insane sums are spent on rework for systems which were built with bad or missing information.  As someone who builds and implements these systems myself, I can’t say that there is a foolproof method for uncovering every constraint, assumption, requirement, and interface which might affect the solution I propose.

But I can say that there is a process of due diligence which must be systematically followed to try and fully understand the target business.  I decided to sketch a brief list of things which the project manager, business analyst, and technical lead should look at when building and implementing a solution:

•  Corporate objectives.  The suits might be leery of sharing the three or five year plan with a vendor team, but the more information you can get about the organization’s strengths, weaknesses, opportunities and threats — the better!  Is the organization growing, innovating, changing, and/or trying to cut costs?  If so, how are they accomplishing these things?
• Competitors.  Who competes with this organization?  What does market share look like and how have these competitors designed their systems?  How can they be outdone?
• The Industry.  Checkout the trade journals, attend a conference, and join any industry organizations.  You need to become a kind of insider who can help lead the customer to a solution which they never even considered.
• Org Charts 2.0.  You need to take the plain old org chart and dress it up with some key details for each department or entity: mission, function, and current initiatives.
• Infrastructure Charts.  How do the existing systems communicate with each other?
• Location Models.  Geographically, where does everything sit?  And what laws, cultures, and locale-specific variables change from one location to the next?
• Business Events.  What events drive the business? Do they come from customers, partners, suppliers, regulators?  Who springs into action when these things occur? Do they occur on a regular schedule?
• Process Models.  Workflows and interactions.

While so many customers (and providers) want to dive directly into the requirements gathering phase, there are huge benefits to first researching these domains.  It can mean the difference between a well conceived proposal and an expensive disaster. But more than that, it can lay the foundation for a customer-provider relationship which goes beyond this project.

Imagine if you (as a provider) noticed a trend in your customer’s industry which led you to design a solution for a problem which your customer didn’t even realize they had!

I recently slogged through an underrated little number called, ‘Advanced Project Portfolio Management and the PMO: Multiplying ROI at Warp Speed‘ by Kendall & Rollins.  Despite the fact that it reads (and sounds) like a whitepaper, it’s a good book which makes two points incredibly well:

1) Too many organizations try to save money on projects (cost efficiency) when the benefits of completing the project earlier far outweigh the potential cost savings.

You might, for example, be able to complete project X with perfect resource management (all staff are perfectly busy!) in 100 days for $1 million. Alternatively, you could hire some extra people and have them sitting around occasionally at a total cost of $1.3 million, but the project would be completed in only 60 days.

What’s that 40 day difference worth? Well, if the project is strategic in nature, it could be worth everything. It could  mean being first to market with a new product or possessing a required capability for an upcoming bid which you don’t even know about yet. It could mean impressing the heck out of some skeptical new client or being prepared for a surprise audit. Sometimes the benefits outweigh the cost savings.

2) Project management exists only to better deliver benefits and capabilities. It doesn’t exist for its own sake, it’s not some kind of innately useful, primordial thing. If it isn’t helping deliver benefits and capabilities, then you can send the whole rattling project management caravan off the side of a tall cliff.

This is where so many organizations get themselves into trouble. They hire a bunch of project managers and demand they follow this or that methodology. But why? Is it because — well — this is what everybody else is doing? Or is it because this methodology will deliver 15% more projects with the same resources? Or this methodology will reduce project cycles by 20 days? Is anybody even measuring these things before/after implementing all these processes?

If you’re going to go down the project management road (and you should!), you need to understand why you’re doing it, and how you’re going to measure your success (hint: throughput!).

434 pp. Recommended.

Project managers are usually thought of as analytical types and as people who execute things.  In their analytical moments, they survey a field of options, risks, and opportunities, determining the optimum path through the landscape.  When they execute, they move mountains to get things done.

But there is a third archetype which ought to describe the project manager.  Project managers ought to be creative.  Not creative in the sense of managing their projects (e.g. finding a better way to crash a schedule), but rather creative in the sense of  strategic product and service innovation.  Let me explain.

In today’s cutthroat business world, organizations must constantly improve.  They are in  an endless cycle of cost cutting, value adding, and creating new products. No matter how well your business is doing now, it is just a matter of time until a competitor catches up and duplicates–or even improves on–your success.  Your profits shrink.  As Robert Reich has explained, at the end of the day there are essentially three strategies to stay in the game:

1) You can figure out how to cut your costs and offer your X for less than competitor’s Y.
2) You can figure out how to produce a much better X for the same cost.
3) You can use whatever expertise gained along the way to be first out with entirely new product Z.

What does this have to do with project managers?  Simply put: Everything.  Project managers are in the incredibly unique position of having one foot in their supplying organization, and one foot in the customer’s organization.  They can gather customer needs and match those up to the supplier’s offerings.  But more than that they can  identify unstated customer needs and find innovative solutions which haven’t even been built yet (but which the supplier has the capability to build).

The key of course is creative thinking and relentless focus on the three strategies.  When is the last time you asked yourself and your project team, “How can we cut costs?” “How can we add more value?”  “Is there an opportunity for a new product here?”

COMING SOON:  Part 2 — Tools for Creative Product Innovation

I finally got around to reading another one of Patrick Lencioni’s business “fables”:   The Five Dysfunctions of a Team.  This one involves an elaborate fictional scenario in which a new CEO rescues a splintering senior leadership team.  Presumably, the lessons are just as applicable down the org chart.  The format gives Five Dysfunctions two major advantages over like-minded ‘team building’ texts:  It makes it eminently readable (no dry theory here) and it makes it memorable.  No doubt readers will be able to recall the umm — confrontation — with Mikey for years to come.

After Lencioni has you hook, line, and sinker on the story, he spends the last portion of the book breaking down what happened according to the five dysfunctions, and explaining how to avoid and/or fix these pitfalls.

Dysfunction 1:  Absence of Trust

Dysfuntion 2:  Fear of Conflict

Dysfunction 3:  Lack of Commitment

Dysfunction 4:  Avoidance of Accountability

Dysfunction 5:  Inattention to Results

This is a winner.  Yes it occasionally steps into pop-business-psychology territory, but most of the time it is on point as a basic team building primer.  There is nothing groundbreaking here, but there never is with Lencioni.  He has built a nice little niche gathering assorted insights on some business subject and embedding them into something which is actually readable.  He succeeds once again here and you’ll learn a few tricks in the process.

Recommended.

My wife and I recently went to Italy and spent a lot of time studying the life and work of Michaelangelo. For a legendary genius, his day-to-day life was surprisingly tumultuous. If you thought he quietly tolled away on the world’s greatest art without interruption, you would be in for a big surprise. In fact, the process of decorating the Sistine Chapel was so crazy, that it immediately reminded me of wild and unruly software projects. Which in turn, got me thinking about some of the good (and bad) moves which Michaelangelo–chief engineer–made.

• Estimate? One year. When Pope Julius asked Michaelangelo to decorate the Sistine Chapel, the great genius estimated that it would take him no more than a year to complete the project. When all was finally said and done, four and a half years had transpired. And this was without any beta releases. What happened?
  
  It seems a perfect storm of factors converged to slow the project: There were political fights, there was miswork which had to be re-done, there were structural and weather problems in the chapel, and all variety of other complications. But the factor that struck me most strongly? Michaelangelo made the estimate himself at the beginning of the project before building his team of painter-assistants. At that time, he had not done frescoing in nearly twenty years (his focus had been on sculpture). In other words, he made a wild top-down estimate in an area outside his expertise without consulting the people who would actually be executing the work packages (his team). Sound familiar?

• Minimize your footprint. Renaissance artists had customers just like the rest of us, only they were called patrons. Patrons (be they the Pope or simply a rich businessman) would specify exactly what they wanted in the art which they were paying for… the number of figures… the scene, etc. Nonetheless, the artist would constantly make little, unplanned decisions about how the scene unfolds. Will that person in the crowd be a man or a woman? Young or old? Will they be smiling or frowning? What will they wear? Unfortunately many Renaissance artists (not Michaelangelo) were an egotistic bunch. They would do things like paint themselves side-by-side with the wise men in the nativity scene, or amidst the apostles in the resurrection scene. They look ridiculous, and one can only imagine what their patrons thought.
  
  When building software, you are constantly making the same kind of little, unplanned decisions about how the application will function. Should I display the customer name with their last name first? Should the input box be freetype or should I force selection from a drop-down list? These seemingly inconsequential decisions add up over time into a huge body of collective decisions that are often made with little customer consultation. This is the developer footprint. The bigger it is, the more likely something about it will irritate the customer. Where many renaissance artists had the audacity to paint themselves into scenes side-by-side with the apostles (a big footprint), Michaelangelo rarely painted himself and when he did it was in the most humble of places. In the Last Judgement, Michalangelo painted his face on the dead skin of a skinned martyr (Bartholomew). It was so subtle, that art historians didn’t even notice the portrait for hundreds of years!

• Start in the back. As mentioned earlier, Michaelangelo had not done frescoes for twenty years when he was commissioned to paint the Sistine chapel. With this in mind, he made a key decision: He started painting from the back of the sistine chapel first so that he could improve his technique by the time he got to the front. Indeed, there are obvious differences between the frescoes up front and those in the back. When one enters the chapel from the rear door–the eyes naturally see his best work in the front first.
  
  This reminds me of an agile development trap. With agile, the tendency is to build important, core functionality in the early iterations so that you’ve gotten something worthwhile accomplished if time or money unexpectedly runs out later. This is a wise tendency, however you usually don’t want to do the most important work in the first phase. Critical work should be done when the team is hitting stride, not when they are forming/storming. Michaelangelo nailed this.

There are many facets to hiring technical folks, but one important area is the issue of how they stay on top of the new technologies which are coming out at a frightening pace. I used to ask a standard question: Give me an example from past work experience where you learned or discovered a new technology (new at the time) and used it for the organization’s benefit?

But after asking that question many times, I realized it was too narrow. People “accidentally” get exposed to new technologies all the time through friends, school, etc. Maybe they never sought out new technology and just “stumbled” on something. I needed to tease out the real proactive learners from these casual ones.

After some experimentation, I finally nailed it with an incredibly simple question which has been extremely effective over the past year: Technology is changing all the time. What periodicals do you actively read to stay on top of it?

A good technical person who stays on top of their field should be able to rattle off a number of periodicals or e-newsletters related to their expertise. For example a network engineer might mention Technet. A security expert might say Bugtraq or Mark Minasi’s newsletter. A more senior individual might even throw in some strategy, such as CIO Magazine. If their answer seems canned, you can pry further to validate it: Tell me about something you read in that periodical in the past three months?

But here is the best part: People who don’t stay atop their field absolutely punt this question. They’ve got nothing. One candidate told me that he reads the documentation which comes with the software used at his company. Another mentioned a four year old SQL book which she had read a year ago. Many others are surprisingly honest and simply tell you, “I don’t have time to read anything like that.”

This question is a deal-breaker for me. I count on my technical people for innovation, and their capacity for such is drastically reduced when they aren’t following the industry. This has quickly become one of my all time favorite interview questions.

PS–This reminds me of a great management practice: Assign technical periodicals to individuals on your staff, formally give them an hour or two every Friday to read them, and then have them present short “book reports” to the whole team on interesting findings. Most geeks love learning new stuff and get excited about new technology. This is an easy way to keep your team both happy and on the cutting edge.