Definition of a Great Programmer - Part Three

April 30, 2009

This post covers the last four items on my list of what makes a programmer great (highly productive):
  1. Motivation.
  2. Critical thinking skills.
  3. An understanding of software design: Architecture and design patterns.
  4. A solid working knowledge of the programming language being used.
  5. Communication and collaboration skills.
  6. Continual learning and exploring.
  7. Domain knowledge of the problem being solved.
  8. Experience.
Communication Skills
Communication is all about conveying your message clearly. And since software these days is increasingly more about teamwork, communication skills are increasing in importance. Have you ever seen energy wasted because of a miscommunication? Basic communication comes in a few forms:

Written skills
Both e-mails and instant messaging are used quite frequently these days. Too often, people don’t pay enough attention to making their messages clear and concise. My experience is that writing clearly takes time and effort, and many times written messages can get muddled. The best tend to express themselves clearly and succinctly. And the most productive also choose wisely between the quicker, verbal conversation versus the longer, written form of communication.

Verbal skills
Clear and succinct apply equally here as well. Ever had to listen to “rambling man” at a meeting? How about someone who speaks too softly, lacking in either confidence or conviction? How about those team meetings where that special someone always wants to take the conversation completely off-track? It takes time and practice like anything else, but being able to deliver well-considered, articulate input or questions is a huge productivity boost to everyone involved!

Presentation skills
This may not come up as much for programmers, but in my company we have had occasion for senior-level programmers to participate in sales presentations as well as product demonstrations at our annual user conference. Interestingly enough, some of our best programmers happen to have good presentation skills, helping to produce sales in the process. I would never make presentation skills a requirement for any programmer, but it is included in my list of what great programmers have in their repertoire.

Collaboration Skills
Collaboration skills directly speak directly about the participation and interaction with peers on project teams. This skill is growing increasingly important, and I've observed that high-caliber programmers are often high-caliber teammates. There are certainly exceptions to this rule, but the need for increased teamwork is reducing the tolerance for difficult personalities, regardless of the skill brought to the table.

Part of being on a team means that you must exercise some flexibility about what you are working on at times, demonstrating a willingness to help the team reach its common goal. I've observed that many high-caliber programmers are ready and willing to share responsibility with the team. As a manager, I've been challenged with another scenario that is only natural. High-caliber programmers want to work with other high-caliber teammates!

Continual Learning and Exploring
This comes in many forms, but the high-caliber programmers that I’ve seen keep up with the industry. They read books, trade journals, have their favorite web sites and read blogs (and blog themselves), and ask to go to specific conferences and training. They’re always looking to learn and do more.

Another trait of high-caliber programmers is the fact that they don’t limit their programming to just what they’re working on as part of their formal assignments. They work on mini-projects that expose them to new things.

Sometimes these are projects are of use to the company and done “on the company’s dime,” and other times these are simply self-exploratory projects aimed at learning and growing, done off-hours on their own time. And I’m not against allowing use of down-time between projects for this type of activity.

I’ve always encouraged any junior developer who wants to improve their game to pick a project and do this same thing. In fact, mini-projects are a great way for a junior developer to walk a project through soup-to-nuts, starting with requirements, creating a design and ultimately developing a finished product.

Domain Knowledge of the Problem Being Solved
I work for a company that writes insurance software, and I find that the more our programmers understand insurance, the faster we can develop software. Any discussions about requirements are made faster and easier because business analysts can spend less time talking about the business basics and move straight to the needs/requirements.

There was a concern expressed when I included domain knowledge in my list of what makes a programmer good in a LinkedIn question. The person responding felt that a developer with detailed domain knowledge adds risk because if there are ambiguous or incomplete requirements, that developer will make assumptions, whereas one who does not know the domain will ask the functional analyst.

I certainly agree that this is a risk. My counterpoint is that someone who deems themselves to be a professional should – when those incomplete requirements or ambiguities exist – get back to the business/functional analyst and determine what the real requirements are. Assuming is something that professionals should never do.

In general, it is my experience those with domain knowledge also have more efficient and effective dialogs with the functional/business analysts, creating greater overall productivity.

Just for the record, when I hire, my preference is to always hire good programmers first, and then look for industry-related experience. I value development skill first and foremost, and I always assume that any business-specific background can come through training and on-the-job experience. I don’t pass up a solid programmer because he or she lacks industry-related experience.

If you have all of the above, you fit my ideal of a great programmer! The final contributing factor in making someone a high-caliber, high-performing programmer is experience. While you can argue that technology is constantly changing and evolving and that yesterday’s skills aren’t important, I maintain my position here. And bear in mind that this is the lowest-ranking criteria that I have.

The way I see it, a seasoned programmer has been through a lot. They’ve lived through good projects and bad. They’ve worked with other skilled programmers and those who shouldn’t even be in the profession. There is nothing wrong with having someone around who has the “I’ve been there, done that before” wealth of experience that could mean the difference between success and failure of a project.

In Conclusion
As I’ve mentioned, I’m a manager these days. Can I “manage” someone to greatness? Not really. I can understand it when I see it, and I can coach you about what you need to do to become great. I can help make opportunities available for you as a programmer to demonstrate your worth.

At the end of the day, the individual has a role here too. I’ll close with a quote from Steve McConnell, as he said in his book Code Complete 2.0, “If you want to be great, you’re responsible for making yourself great. It’s a matter of your personal character.”

Definition of a Great Programmer - Part Two

April 26, 2009

In my last post, I provided my list of what makes a programmer great:
  1. Motivation.
  2. Critical thinking skills.
  3. An understanding of software design: Architecture and design patterns.
  4. A solid working knowledge of the programming language being used.
  5. Communication and collaboration skills.
  6. Continual learning and exploring.
  7. Domain knowledge of the problem being solved.
  8. Experience.
As promised, I’ll dig into the details.

Without this, everything else is in the tank. A motivated programmer will apply his or her self towards producing results. A motivated programmer will want to get to the bottom of any vexing issue, to work through a logic maze to produce elegant code that works – and works well – over time.

Motivation comes from within, but is influenced by the work environment. The tone set by management is vitally important. I always try to keep Dilbert in mind; I don’t want create a scenario where I’m treating intelligent, hard-working programmers like they are clueless idiots! A poor work environment, even one bad boss, can suck the life out of an otherwise talented staff.

From an individual perspective, you really need to want to be a programmer. It takes some long hours, and given the time you put into a programming career, you had better enjoy it.

My wife Lauri-Ann, someone who is not in the computer field at all, would support this assertion. In fact, she once steered a college student away from programming based on a conversation she had with him. This student was taking computer classes because his father had pushed him towards a programming career. This student confided to Lauri-Ann that he didn’t really want to be in the computer field at all, but the money seemed good.

Lauri-Ann immediately advised this student to find something that he truly wanted to do. She pointed out that she has referred to herself as a “software widow” during times when I’ve been working night and day on projects with tight deadlines (bless her), just to illustrate the point to this student that programming is a demanding profession.

I’ll sum up my view on motivation by quoting Steve McConnell from his book Code Complete 2.0: “If you want to be great, you’re responsible for making yourself great. It’s a matter of your personal character.”

Critical Thinking Skills
Highly productive, highly valued programmers exhibit certain traits that I find important as a manager. When the time comes to assign someone a difficult task, managers always have their “go-to” people that have proven that they can handle difficult assignments. And more than likely, critical thinking skills played a role in enabling someone to handle that difficult assignment.

Critical thinking is a large topic in its own right, but I found something developed by Peter Facione that captures the essence of critical thinking. He developed the IDEALS model that includes six steps for effective thinking and problem solving:

Identify the problem. — “What’s the real question we’re facing here?”
Define the context. — “What are the facts and circumstances that frame this problem?”
Enumerate choices. — “What are our most plausible three or four options?”
Analyze options. — “What is our best course of action, all things considered?”
List reasons explicitly. — “Let’s be clear: Why we are making this particular choice?”
Self-correct. — “Okay, let’s look at it again. What did we miss?”

I have observed highly productive programmers using this type of thinking, though I'm not convinced everyone that exhibits this type of thinking can actually explain it.

The absence of this tends to have people asking things like: “What do you want me to do? How do you want this to function?” Basically, those who don’t apply critical thinking tend to ask for direction and very rarely provide options or recommendations. That means that someone else has to step in and work through determining the options, involving additional dialog and time on everyone’s part, and a reduction in overall productivity.

An Understanding of Software Design: Architecture and Design Patterns
Understanding software architecture is about organizing and structuring the system at a high level, concentrating on the components and interfaces between the components. While not all programmers are architects, it certainly helps to be grounded in basics of functionally decomposing systems into a cohesive, organized, and structured system.

Use of design patterns is about all about leveraging industry expertise by re-using good design (and prior thinking) to solve frequently occurring programming problems, increasing productivity as a result. This comes under the “why reinvent the wheel if you don’t have to?” category.

There are numerous books on software architecture and design patterns available in book stores. Like everything else, there will be some subjectivity in terms of architectural design and differences of opinion in code reviews on just how well design patterns are implemented in actual code, but highly productive programmers are always keeping themselves up to date and striving to apply these concepts.

A Working Knowledge of the Programming Language 
I cited a real-world example in my post Does a Software Productivity Metric Exist? where someone wrote a function without leveraging date routines available with the language that we were using. While the function worked, it was difficult to understand and I'm sure required extensive testing before it was deemed correct.

Highly productive programmers always want to make their lives easier, and this means applying leverage wherever and whenever you can. While some may call this “lazy” programming, I call it smart programming.

Call it what you will, but it does take time and effort to learn what features are available, but in the end it sure pays dividends because you are using previously developed and tested code – because you are leveraging what is readily available. And that will save you time and aggravation later.

I feel that I've covered enough for this post, and I’m only part-way through my list! Next post, I’ll cover the remaining four.

Definition of a Great Programmer - Part One

April 22, 2009

Since I have both a programming and management background, and since software development centers around programmers writing code, I thought I would explore my views on what makes a great programmer. And by great I’m talking about being highly productive, someone who consistently delivers quality results in a timely manner.

A common metric in the software world, based on studies, is that there can be up to a 10:1 difference in productivity between different programmers with the same level of experience. Since programmers want to be regarded as productive, and managers need to understand what programmer productivity is, the question of the day becomes: What goes into making one programmer an order of magnitude better than another?

Other questions that you might have:
  • How can productivity be measured so precisely to determine a 10:1 difference?

  • Dave, isn’t your position that since both the inputs and the outputs of software development are variable, actual productivity couldn’t be measured?
Perfectly valid questions!

First, my list of what makes a programmer great, in priority order:
  1. Motivation.
  2. Critical thinking skills.
  3. An understanding of software design: Architecture and design patterns.
  4. A solid working knowledge of the programming language being used.
  5. Communication and collaboration skills.
  6. Continual learning and exploring.
  7. Domain knowledge of the problem being solved.
  8. Experience.
I’m sure that this list will drive a few comments, and I’ll explore my thinking in more detail in subsequent posts.

What about the question of measuring of productivity? If I’m right and productivity cannot truly be measured, then how did someone arrive at the often-quoted 10:1 productivity difference between programmers?

I provided a clue in the sentence – "A common metric in the software world, based on studies, is that there can be a 10:1 difference in productivity between different programmers with the same level of experience."

My point? You can study programmer productivity and you can determine that differences do exist, but you can’t accurately measure productivity in the real world. To study differences, you need to devise a common programming problem that can be given to a variety of programmers to work on independently, and then judge the results, asking things like: Who finished first? Who solved the problem using the least lines of code, with the fewest errors?

In the real world we aren’t handing the exact same problems to different developers, though, are we? In the real world, day-to-day work inputs and outputs are truly vary, which makes measuring productivity and making completely accurate comparisons a virtually impossible task. However, it is possible to coach people and teams to improve performance.

When talking about individual programmer performance, the secret is to understand the key performance indicators (my list) that allow one programmer to be more productive than another in order to achieve greater productivity.

I’ll explore my list in greater detail in my next post. I’m interested in the opinions of the readers out there!

Definition of a Great Manager - Part Two

April 15, 2009

This is the second part of a two-part post, where I've elected to put my thoughts out on the table on those qualities that I feel are important in being an effective manager.

My disclaimer: I'm not claiming perfection on these fronts, but this is what I strive for. And if a manager has all of these qualities and executes well on them all of the time, I’d categorize that person as great in my book!

Ability to Switch Gears
This is one that I often cite as the BIG DIFFERENCE to those considering a move from a programming role into management. Often times, those who aren’t in management seem to think that managers have some type of attention-deficit disorder, because they only spend what seems like minutes on any one issue.

I have found that my time is very fragmented. Between one-on-ones, quarterly and annual reviews, managing the budget, budget forecasts, requests for equipment and tools, time off requests, planning for new projects, meetings to review projects (and in the software business, these are always facing some challenge), customer calls, etc., etc., I have a highly fragmented day!

As a manager, you need to be able to jump from one topic to another in the blink of an eye. This is quite a mental gear-shift, and it is also why I caution any new manager that comes from a development background to make sure that they do not volunteer to code to “help” teams that they are now managing. You need that quiet concentration time to be an effective programmer, and this becomes almost impossible once you are into the management role full-time.

Organization Skills
Since I have a large number of things going on at all times, I find that keeping organized is necessary and highly beneficial to my productivity. I have a TON of e-mail folders to group relevant communications where I can easily locate them later, all arranged in a hierarchy. For example, I have a Customers folder that has a sub-folder for each customer that we deal with.

I also organize my documents in a similar hierarchical manner. Project proposals, resumes, RFI responses, internal planning folders -- you name it, I've categorized it and placed each document in their rightful place. What I try to keep to a minimum is actual paper.

Sure, I still print things out, but I find that filing and organizing paper is more time-consuming and rarely pays any benefit. I print for convenience – and sometimes for proof-reading while I’m waiting for a meeting to start (but not during the meeting, that would be rude). If I attempted to print and file everything, I would need a HUGE filing cabinet! And generally, when I need something, I need it in electronic form to forward to somebody via e-mail anyway...

I also need to keep track of my staff, the projects and work that they are engaged in, both from a performance review standpoint and from a resource-allocation standpoint. If someone runs into a roadblock, I find that it is usually me that is part of the unblocking – such as knowing that someone else might have the knowledge and spare cycles to assist.

Finally, I have deadlines for getting key things done. If it is a big priority, I block off time on my calendar to do the work. If I didn't do this, the likelyhood that someone would schedule a meeting is high, and would prevent me from completing that high-priority item. I track other tasks as tasks that can be addressed as I have time, provided the high-priority work is addressed.

Communication Skills
As a manager, I have found myself speaking and writing a lot. My wife loves to dish out a little good-natured ribbing to me, reminding me how I used to spend large amounts of my time with lines of code on my screen, and now it’s in e-mail, composing documents, or preparing presentations. I also spend a lot of time in every day engaged in dialog, helping teams work through issues, on the phone with customers, talking with my peers about budgets or setting direction, you name it.

No matter what form communication takes, it does take time and practice to be clear. I've found that when it doubt, spell it out explicitly! Don't bank on someone "reading between the lines," or implicitly understanding the urgency of completing a task by a given date. If you have a need and expectation to have something done in a certain time frame, make sure that your message is plain and clear.

Clarity takes some extra time, but it's worth it in the long run. I've kicked myself every time that I've short-changed the clarity in my own messages, because something didn't get completed to the level it needed to be, or by the date required.

Another skill that I have found will come into play during your routine communications: Negotiation. Business people negotiate routinely, and as a developer transitioning into management, I readily admit this was one area that I was weak in. Early on, I even failed to recognize that I was even in a negotiation in some cases! I allowed myself to commit my team to schedules that I should have negotiated, and the results were painful. Live and learn...

I find that I'm always involved in some type of negotiation, whether it is for time-off requests, raises, project schedules, resource allocations, vendor contracts/rates, or career direction in some cases... Bottom line: As a manager, you name it, you’ll be negotiating about it!

Ability to Delegate
First-time managers tend to have a problem with this, but my advice here is simple: Get over it, and quick! I was hesitant to delegate when I first became a manger, but I became over-loaded in a short period of time.
And then I asked others to do things...

And it wasn't a problem! They expected it, and more often than not, welcomed taking on tasks at my request.

Fortunately, I learned that one early on. Over the years I’ve found that effective delegation provides me with the time to do those things that I should be doing in the first place. These days, I'm still finding that because of my longevity with the company, my challenge is not to get drawn into as many things as I do, as it is causing me some problems with getting high-priority tasks completed.

Strong Desire to See Others Succeed
A great manager is more interested in developing those that report to him or her than anything else. In order to accomplish this, I maintain regular contact through bi-weekly one-on-ones along with walking and talking during the course of the day. I try to understand what people are doing today, where they want their careers to go, and what I can do to help.

Yes, there are times when there is little that I can do, but being armed with this information is extremely useful. I might not be able to do everything for those that report to me, but even little things can help improve job satisfaction and set a positive tone.

When it comes to guiding the success of others and the organization, I have one golden rule: If a task is important enough to start, it should be important enough to complete.

I keep a handle on our organizational priorities and the relative priorities of tasks that are assigned to my staff at all times. It can be very frustrating for people to be continually pulled off one task to work on some new, "hot" issue before the finishing the task that they are on. If you do this often, entire quarters (or even an entire year) will slip by where you will find that you were very busy, but your actual accomplishments were very low. I make it an exception to pull someone off of a task to work on something else.

Since we've adopted Agile (Scrum) development, we negotiate the priorities on our product backlog as a stakeholder exercise. This forces a routine assessment of priorities, but if you are allowing teams to operate in the true spirit of Scrum, those teams work the priorities that they've started to completion. I have heard of some companies implementing Agile/Scrum in different ways, including not having a product owner or a product backlog, but that is a different story...

Of course, the end of each year brings the subject of the annual performance review to the fore. Interestingly enough, this can bring feelings of dread by both managers and employees. The reality is that this will only be agonizing if you don’t spend the time throughout the year truly managing. My personal style is to put significant time and effort into performance management, and the annual performance reviews I've given over the years have not been surprises. Sure, I've had some give-and-take negotiation, and I'm always willing to engage in that dialog.

After all, performance management in the software world is largely subjective. Another reality is that in most organizations, as a manager you are walking a line between high-level corporate objectives and the individual expectations of your staff.

I've had occasion to go to bat for someone because I missed, drawing too hard a line on an individual and given them a lower rating than they feel that they earned. However, because that person convinced me that I was off the mark, I've reversed my decision. I've had this happen a couple of times, and I always enter performance appraisals with the notion that if someone disagrees, I am open to discussion on the topic.

When it comes to the actual appraisal, I've always included an entire year's worth of accomplishments in every employee's assessment. I strive to be as thorough and detailed as possible, which keeps everyone generally satisfied and in agreement with the end result. In fact, I've had times where people have told me that they had forgotten some things that they had done throughout the course of the year, but were grateful that I didn't forget.

A positive result of continually staying on top of the performance management process is that I've never experienced that feeling of dread going into any performance review. I've also never done someone the disservice that I have experienced myself in years past, where the only notable accomplishments on my review were the things I worked on in December.

In fact, I’ve thoroughly enjoyed some performance reviews that I’ve given over the years! There is nothing is better than seeing someone really succeed at their job and you being the person recognizing and rewarding them for it, praising them with a list of accomplishments, and feeling great yourself because you helped them get there, even if it was only to align them with the opportunity that fit their skills and interests.

Definition of a Great Manager - Part One

April 10, 2009

A good many of my recent posts have discussed management in terms of what managers can do to contribute, and why I feel that the management role is an important role. This post, I've elected to put my thoughts out on the table on those qualities that I feel are important in being an effective manager.

Note that I’m not differentiating between a manager and a leader, either. I don’t abide by that distinction; if you are in a management position, you are in a leadership position!

My final comments before continuing: I'm not claiming perfection on these fronts, but this is what I strive for. And if a manager has all of these qualities and executes well on them all of the time, I’d categorize that person as great in my book!

Visionary Direction, Results-Oriented
A great manager knows where he or she wants the organization to go, and how it needs to get there. Establishing this vision requires a lot of research, brainstorming, discussion, and soul-searching. In the end, not everyone will agree with you; even if they do, they may not agree on the intermediate steps that are required to arrive at the destination.

However, allowing people to participate in the process and voice their opinions will build buy-in and commitment, something that I feel is well-worth the investment in time. I’d rather front-load efforts this way instead of continually having to “sell” the vision to people who don’t have buy-in because they weren’t in the loop early in the process.

I have experienced times when I've been focused on results and felt that I truly needed to make a quick decision to keep the ball rolling. And yes, when I’ve done this there have been occasions when people have been put off with me because they weren't part of the decision-making process, even though circumstances might have prevented them from being immediately available to participate. It's a difficult position, and the best that I've found that I can do is discuss why the call was made, why it needed to made when it did, and the factors that drove my decision.

I’ve also been judged from the advantageous position of 20-20 hindsight, particularly when a call didn’t work out as well as it could have or should have. Since it is rare to have complete information when making a decision, the best that I have found that I can do is to collect as much information as feasible, and time-permitting, leverage the collective wisdom available to determine the options and best course of action.

The real trick is many situations is being able to discern when a decision really needs to be made. I’ve seen where pressure for an immediate decision was nothing more than a negotiating tactic to gain agreement from me before I have had an opportunity to fully consider the facts and options. If I’m being pressured, I ask:
  • “Why does this decision need to be made now?”

  • “Is it worth taking extra time to gather more facts and opinions?”

  • “If it is worth taking extra time, when does the decision need to be made, and who should be involved?”
There’s the old sentiment that setting direction is better than being rudderless, but I also bear in mind that there is a timing aspect to many decisions, and not all are as immediate as they always seem. Sound, timely decision-making saves a lot of thrashing.

Which leads me to my next point.

Visions are great, but they are of no help if you aren't getting the right things done. Great managers understand the need to get things done today. And because great managers are armed with a crisp vision of where they want to go, they fully understand the organization's priorities and what will move the organization closer to the vision.

Equally important, understanding the vision helps great managers understand what their organizations should stop doing. Change is difficult and old habits die hard, but it is an uphill battle to focus on projects aligned with a long-term vision if you don’t take those low-value activities off of the plate.

Business Knowledge
I feel that managers need to understand and keep abreast of the following:
  • The economic climate
  • The industry and competition
  • The customer base ( likes & dislikes)
  • Technological changes that influence the industry
  • Human Resource management
  • Finances & budgets
  • Personnel assessment & development
  • What drives the business today, and what will drive it in the future
There’s a lot of ground to cover here, but my point is that there are various forces that push and pull companies, many of which are under anyone’s direct control. As a manager working in a small company, I find that it is essential to monitor and understand what is going on, identify the key drivers and opportunities and how the organization is positioned to respond and (ideally) take advantage of those opportunities.

Critical Thinking Skills
This is high on my list for anyone who considers themselves a knowledge worker, manager or not. Critical thinking is the willingness and approach towards exploring the root cause – the true nature – of a problem, collecting facts, considering and probing for options, and working towards reasoned conclusions about what action to take.

Critical thinking shows itself in people in various ways, but overall those who employ solid critical thinking skills are:
  • Inquisitive and well-informed
  • Flexible and open-minded
  • Willing to reconsider and revise their own views
  • Persistent
  • As precise as possible, given the circumstances and time available
  • Logical in their approach, and able to explain their reasoning
I feel that as a manager, I should be transparent in my own thinking; ready, willing, and able to share my thinking with my peers and staff, particularly what I felt was the key driver(s) and my reasoning for arriving at a certain conclusion. This helps to drive those healthy dialogs that could influence my thinking enough to alter it.

Managers also have a need to guide others in the organization through critical thinking exercises. This is important for two reasons:
  • Not everyone has highly-developed critical thinking skills and will need help in the process.

  • I find that it helps to understand why someone is advocating a certain direction, as there could be an underlying personal agenda that needs to be surfaced – something that is easier to do when approaching problems by “objectively examining the key elements and reasoning.”

Improving the Business

April 5, 2009

There's doing things right, and then there is doing the right thing. This post is all about doing the right thing. And just how do you go about that, you ask?

Let me back up and explain that in addition to my regular management duties, I’ve been functioning as a product owner for what is now our tried-and-true, in-production, legacy system. The term product owner is in the Agile context, which is roughly equivalent to a product management role.

My job is to define and prioritize the product (feature) backlog, working with other members of our management team and our customer base to define what will provide value in the product. In Agile, a product owner is also the “single, wringable neck,” the person that is responsible for the success or failure of a product. In short, I’ve been challenged with keeping our product moving forward, defining the features that will keep our product relevant in the 21st century.

One thing is certain in these situations, and that is that customers will not provide strategic insight on where you need to take your product! We’ve seen many instances where customers can and will provide small improvements to our existing product, but where to go next from a strategic standpoint? Well, that’s our problem. Or mine, as the single wringagble neck.

Some components of the vision were easy. Since I’m in the software business, it wasn’t hard to be in tune with the technology trends that were influencing other products in the market. In addition, some requests for access to our system mirrored technology direction, like Web Services and browser-based, Internet access. We needed to open up our tightly-coupled system and expose interfaces.

I’ve always read business books, and I found two in particular to be very helpful. Between these books and a little thinking on my own, I was able to craft a five-year vision for our product that was well received.

I’ll discuss two books that helped me approach this problem:

Good to Great, © 2001 by Jim Collins

The Innovator’s Solution, © 2003 by the Harvard Business School Publishing Corporation

Good to Great
From a product or services standpoint, this book outlined the “Hedgehog Concept,” meaning that for companies that want to become great, you need to ask yourself three important questions:
  • What can we be the best in the world at?
  • What drives our economic engine?
  • What are we deeply passionate about?
This book recommends that companies should not use technology as a primary means of igniting transformation. Instead, companies need to pioneer the application of selected technologies. Walgreens was used as an example of this.
If you recall, during the “dot com” boom, the notion that brick and mortar outlets were doomed to extinction. Wallgreens, as a traditional brick and mortar store was faced with significant pressure and lost 50% of their stock value.

In response, Wallgreens – who understood what truly drove their economic engine – assessed how the Internet could connect their convenience concept and profit per customer concept. Wallgreens determined that they could tie the Internet directly to their sophisticated inventory and distribution model, and ultimately to their convenience concept.

This resulted in the capability for customers to fill a prescription online, hop into their cars and drive up to a convenient (brick and mortar) drive-through window and pick up their prescription.

Great stuff! (No pun intended.)

The Innovator’s Solution
This book really lived up to its title, in my opinion. It offered a lot of great insight and perspective on the subject of innovative thinking.

First, when it comes to shaping a product or service geared towards a customer perspective, some really great advice that I took from this book:
  • Customers “hire” products to do specific “jobs.” Translation: A new product will succeed if it helps customers accomplish something more effectively and conveniently than what they are already trying to do. You should not force customers to “change jobs” just because your new product is available. If they weren’t trying to solve that problem before, they won’t change to solve that problem now.
  • Consider and target the circumstances that customers find themselves in, rather the targeting the customers themselves. This reinforces the point made above, but also speaks to another point about market research: Market research typically determines the size of opportunities, but does not understand the customer’s underlying circumstances, and it is the circumstances that a customer is in that are of vital importance.
An example that reinforced the notion of customers “hiring” a product for a specific purpose was a quick-service restaurant that wanted to improve its milkshake. An initial attempt was made to improve the milkshake by structuring everything around product and customer characteristics – traditional product and market research. However, this did nothing to improve sales or profits.

Using a circumstance-based approach, it was observed that there were morning and afternoon purchasers, and each was “hiring” the milkshake for very different jobs. The morning drinkers were commuters looking for a filling, easy breakfast. The afternoon consumers were parents with kids who needed a smaller shake, small because the parents wanted the kids to still be hungry at dinner. They also didn't want the kids to take too long drinking the shake.

Getting the Juices Flowing
Each book has a lot more to offer than the snippets that I’ve provided here, and these are definitely on my recommended reading list. I took the advice of these books, considered what our company was really all about, the circumstances that our customers were in, discussed this with a variety of people – and in the end was able to craft a five year vision that everyone in our company and customer base completely agreed with.

The beauty of this approach was that I shared the notions put forth in this post with others who helped to drive our product vision. The end result is one where I cannot take credit for all of the ideas in our vision, and I'm good with that. The participation resulted in a stronger vision and greater buy-in all the way around.

Of course, now everyone wants it yesterday!

How Managers Can Help: Championing Process Improvements

April 3, 2009

There is always room for improvement. I live in New England and I am a Patriots football fan. During their undefeated 2008 regular season (I won’t discuss the one loss), head coach Bill Belichick always had a stern look on his face. Why? Because he was always concerned that the team could be doing a better job. If the Patriots football team has this standard for themselves during a record-breaking year, than those of us in the corporate world can certainly aspire to higher standards as well.

As a manager, you can get in tune (or keep up) with development processes and engage in discussions that geared at helping teams become more productive. I've noticed that truly empowered teams can distrust management, particularly when conversations are geared towards measurements; Any metrics discussed must be in context of implementing measurements to help teams improve, and the rule must be that these measurements will not used as ammunition in a performance review.

My goal is to collaborate with the teams in the same way that I expect those on the team to collaborate with each other. I find that working with them to determine what process improvements will and won’t work helps to fine-tune things.

My blog post Six Keys to Successful and Productive Software Delivery discussed what I feel are vitally important areas when it comes to achieving total results. Those specifically related to core software development:
  • Customer involvement
  • Design reviews
  • Automated and manual code inspections
  • Testing – early and often
I feel that anything that can be done to avoid costly re-work or prevent defects will provide substantial velocity and savings. However, when teams start managing and monitoring their own work, I've seen what you might consider to be "basic blocking and tackling" get overlooked, and when people skip the basics, bad things happen!

Talking with teams – and working with the teams – will help build commitment and trust. The goal must be clear: you are working with teams to help produce better software, faster; to improve internal efficiencies by doing things right.

In terms of teams that aren’t meeting their commitments, I feel that it is certainly fair to have process improvement conversations. It is not OK to have an empowered team that is “managing” its own work and failing to deliver. Clearly, changes need to be made, and open, candid conversations are a must in these situations.