How Managers Can Help: Removing Impediments

March 31, 2009

Our use of Agile development involves the usual short, daily standup meeting where team members answer three questions:

1. What did I do yesterday?

2. What am I working on today?

3. What is getting in my way?

The last question is about obstacles, and anything that blocks progress for an individual or a team will drag the overall performance of an organization down. As a manager, I find that I am in an excellent position to help remove many obstacles faced by teams.

Physical Obstacles
Early on, teams may face basic challenges like having a meeting place for their daily standup or having enough white boards available. These problems are easily correctable and something that a manager can take on to help the teams establish themselves. This will also be motivational for the teams, as you will be seen as supporting the team through direct action.

Other problems can surface, like the desire for team co-location or the need for test machines (virtualization makes this easier), but again, as a manager I find that I can help support teams by taking on certain tasks to facilitate whatever cross-organizational approvals are required to make things happen.

Resources & Training Obstacles
The technology world is not standing still! There will be a need for training in specific areas in order for teams to be successful. This may involve formal class training or bringing in a consultant with specialized knowledge. If you are new to Agile, an Agile coach is highly recommended! In any case, managers can help get the approvals in place to make things happen.

In some cases, there will be a need to reach out across your own internal organization for specialized knowledge. Approvals for someone’s time may be difficult to obtain, leading me to my next point.

Organizational Obstacles
Overcoming organizational inertia (red tape) can be a drain, such as getting tools and equipment ordered and approved or resolving conflicting goals between departments in terms of priorities. Managers can work these issues on behalf of teams so that the teams can remain focused on what they are doing, which is building quality, working software.

Teamwork and Personnel Obstacles
Not all teams will fire on all cylinders automatically. Managers will need to help guide teams and their direct reports so that expectations are consistent and clear. As I mentioned in my post Assessing, Coaching, and Developing Your Staff, I noted that not everyone is prepared to be part of an empowered team, nor are teams of people fully prepared to work as a self-directed team, particularly if this is new to them.

What else can a manager do? Anticipate.

Empowered teams are typically focused on the here-and-now. A useful management technique is to look ahead, determine what the team will be facing in the near future and be at the ready with options. General George Patton, famous for his ability to move an entire army quickly and efficiently did this very thing.

The Most Distasteful Management Task: Firing

March 28, 2009

Firing takes two main forms:

1. Termination due to an economic “position elimination.”

2. Termination due to poor job performance.

Unfortunately, the net result is the same. Someone looses their job.

There is little that can be done when economic forces are at work. If the business doesn't support the current head count, trimming is better than trying to make a go of it and potentially putting even more jobs at risk. Not that I think all the trimming that goes on in the world is truly valid – but those decisions are typically made at high levels of the organization, and out of the control of lower-level managers.

Personally, I feel that laying someone off due to "position elimination" is more distasteful than firing someone for poor job performance. Eliminating a position – and a person – because you have a gun to your head and you need to make cuts versus dealing with poor job performance is just that much harder for me to do. I’ve had this duty – knowing that those who are being laid off have families to support – and it really tears me up.

When it comes to poor job performance, I never take terminating someone lightly, either. I make every effort to provide all the feedback, coaching and time to improve before making this call. I provide essential feedback and room for people to correct and improve. I also recognize that people may have things going on in their personal lives that can affect short-term performance.

My personal philosophy is to exercise as much due-diligence as possible. As a manager, I feel personally responsible for the performance – and non-performance – of those who report to me.

I’ve heard that some managers out there don’t provide much in the way of straight and candid feedback. This goes back to my prior post, Assessing, Coaching and Developing Your Staff, where I noted that some people don’t handle conflict well. Managers can be guilty of this as well.

My experience is that you must fully prepare for the conversation, have your notes and thoughts in order, and then have the conversation. In general, people will respond reasonably (initial reactions aside) to feedback that is related to their job performance, as long as you are objective and constructive about what they need to do.

If someone needs improvement, my first move is a conversation, usually in a regular a one-on-one session. If the conversation does not help improve the situation, I start documenting the problem in the semi-formal quarterly review, and if necessary I progress up to the formal annual review with full documentation. (Unless the issue is pressing enough that something needs to be done much sooner.)

I find that most adjustments can be made through coaching conversations. Some people get blinders on, though, and you may need to continually move up the formality chain to get the message across. It takes time, but if I’m faced with firing someone, I want to be able to look myself in the mirror and feel that I did all that I could in fairness to that person.

I'm sure that you would agree that if you are spending repeated effort over time on the same issue(s), the old saying holds true: “It’s not the people that you fire that make you miserable, it’s the people that you don’t.” 

No matter what the circumstances – an economic position elimination or termination due to poor performance – I terminate people in a face to face conversation. HR is always part of the final process, but I don’t hide behind HR and let them do my dirty work. In cases where I’ve had remote employees I’ve done this over the phone, but our working relationship was always on a telecommuting basis anyway.

Assessing, Coaching and Developing Your Staff

March 25, 2009

As I have mentioned, we have adopted Agile development at my company. One concept that directly impacts my management role is the empowered team. Does this mean that I’m easy street?

Far from it! Just because people are managing and monitoring their own work doesn’t mean they should be cast adrift. In fact, our full adoption of Agile was not a slam-dunk, hands-off exercise by any means!

For some people, transitioning from the old command-and-control environment where tasks were assigned and even worked on independently – with little to no interaction with others – to the more interactive, collaborative Agile team was a major shift.

Some people struggle with taking initiative and action. To this day, I get the “What should I work on next?” question (although less frequently these days). Some people are so used to having work assigned to them that they are uncomfortable with taking on work independently.

Honestly, sometimes this is a play to work on something other than what has been defined as a priority for the team. Early on, I tripped up and collaborated with the ScrumMaster (project manager) and assigned work. It took some extra effort and time out of my management day, but I found that there was a need to coach individuals on what it takes to be a team player, and what their responsibilities were – including picking up work that was defined for the team.

Communication and collaboration skills were a weakness for some individuals as we moved to interactive teams. Others needed help with the dynamics of being a teammate who focused on team results over individual accomplishments.

I’ve also found that as a manager, coaching isn’t always confined strictly to your staff, either. For example, early on in our adoption of Agile, I detected certain disconnects in expectations between the development staff and the management team as a whole.

We had some people on the development side who wanted Agile to be “whatever the team makes of it” – along with zero transparency into what the team was doing. I could also tell by comments made during management meetings that members of the management team did not fully understand key concepts of Agile.

I took up the charge of working with my peers at the management level to craft an “Agile Expectations” document to level-set our entire organization on what Agile was and what we should expect work to look like moving forward. This was distributed to the entire development organization for comment and feedback, and in the end everyone had a deeper understanding of just we had embraced.

This is one example of how a manager must be in tune with changes affecting the organization so that he/she can help to head off difficulties and challenges.

As a manager of people on empowered teams, one other area that can I find myself in an excellent position to contribute is with career planning and advancement. People on empowered teams will still have career goals, and they will need to articulate those goals to someone in order to ensure that the appropriate training and opportunities are made available.

I mentor employees to prepare for a new position, targeting training and work in areas that will help make them stronger candidates when the opportunity arises. I also find that I am in an excellent position to be in tune with upcoming projects that are aligned with an individual’s career goals, and can allocate people to those projects that meet their interests and goals.

As a manager in the Agile world, assessing performance of individuals who are part of empowered teams is a change. I don’t assign people work, but I have to pay attention to what they are working on, and how they are going about it. This isn’t all that difficult.

Regular one-on-ones and a little walking, talking, and observing go a long way towards providing a manager with the essential information needed to have effective coaching conversations. Getting some feedback directly from teammates is also essential, so it pays to have a good rapport with everyone.

The big change in our moving to Agile was the nature of the coaching dialog, migrating away from being task-specific in nature to more of “Here’s how you can become a better player, helping the team to win,” conversation.

Another big area that requires managerial assistance is in coaching at the team level. For people who have never self-managed, you will see sub-optimal decision-making at first. It will take time and coaching for teams to learn how to organize their efforts effectively. I’ve also seen problems where some individuals sit back and allow others to take a larger share of the burden, which leads me to my next point.

Not everyone is prepared for – and can easily transition to – empowered teams where team members actually hold one another accountable. I’ve found that teams in general need help in raising issues and managing conflict constructively. There can be an unhealthy absence of any conflict within teams, which means that frustrations are being surfaced elsewhere or manifested in other, counterproductive ways. There is a need to surface and address core issues that affect teamwork and productivity.

My final point: Make sure that you are spending time with those you deem to be your best. If these people start feeling underappreciated, they may look for employment elsewhere. Paying attention to your high-contributors and ensuring that they are genuinely appreciated is a significant retention tool. These people tend to get leaned on when the going gets tough, and it is in your best interest to not take these people for granted.

Interviewing and Hiring Stories

March 22, 2009

Since I’ve spent the last couple of posts on the hiring process, I thought I would share a couple of personal experiences.

If you were presented with a resume of someone who had a great deal of technical experience – using all of the technologies where you needed to add expertise and depth – and the resume even called out something like: “so-and-so evaluated all of the compilers on the market, and was so dissatisfied with their offerings that he wrote his own for project XYZ,” what would you think?

I interviewed this person at the request of the hiring manager – I wasn’t the one hiring – and did so over the phone because I was travelling and the hiring manager really wanted to move quickly. The phone interview started slow, and it was difficult to establish a rapport early on, and I even found myself asking this person, “Do you really want this position?”

When he responded “Yes,” I kept poking, and after one technically-oriented question, the floodgates opened! I found this person to be very knowledgeable and technically savvy. I relayed this back to the hiring manager, and by the time I returned to the office, an offer had been made to this individual and accepted. We had a new hire, someone who appeared to have all the knowledge and abilities that we needed.

Except…

You aren’t paid for what you know. You are paid for what you know and what you do. That bit about this individual writing his own compiler? That should have been something that I explored a little deeper. It turns out that it would have provided me with some very useful insight – before we made the decision to hire him. But I was younger and less experienced in those days.

This person was highly intelligent and had all the knowledge, capability, and confidence to be a strong, “A” player in the organization. But we didn’t get much out of him. Worse than that, this individual was highly disruptive to the entire team that he was assigned to. He derailed entire meetings, often quoting from his technical repertoire and providing enough information to confuse and cast doubt about the direction his team was taking. The problem was that he also failed to recommend anything to guide them.

He single-handily froze work, routinely complained about his manager, and made enough noise that senior management put him in a room to talk with him about what he needed, an open offer that included getting rid of his boss if that was required – so that he would have” room to run.” His technical knowledge was respected enough that they were willing to do this.

Despite all the complaining, this individual did not want the responsibility of making the call to get rid of his manager. He put that back on senior management. In fact, the reality of the situation was that this person had more fun tying an organization in knots rather than focusing on producing results. That was his idea of job satisfaction!

This experience is one major example of why I look for what you can do and what your accomplishments are when I conduct interviews. Being knowledgeable is great, but I look for the total value that you bring to the table, and whether you can – and will – produce results.

That person made it through the door based on deep technical knowledge. Here’s another war story of mine with someone that didn’t make it past the interview process. This case illustrates why you want to make sure that you are contributing and providing value at all times.

Several years ago, I was grabbed by our QA manager who had brought someone in for an interview that she was struggling with. She thought that a particular individual looked qualified on paper, but she was having some real trouble getting at just what this person did, and she was thinking that it was her interview technique that was a problem.

A quick scan of the resume confirmed that the individual appeared to be qualified, and there were recognition awards noted for participating in highly successful projects. I ended up sitting with her during the interview, and as the interview unfolded, I realized why my QA counterpart was struggling. She was in a state of disbelief. Here’s a slightly modified version of what transpired:

“I see that you played a major role in the ABC project,” the QA Manager said.

“Yes, I did. In fact, my manager told me that without my presence on this project, the project would have been an absolute failure.”

“Great! Tell me more about that.”

“Well, there was a problem with performance, and we tracked it back to the database layer…”

“— and you found this through testing?” the QA Manager interjected.

“Well, I didn’t actually conduct the tests, someone else on the team was testing,” the candidate responded. His high degree of confidence was also very evident.

“But you became involved when the problem surfaced?” the QA Manager asked, clearly trying to work towards what this person’s role was. Given the confidence, we both were expecting that THIS would be the where we learned what this person did on the ABC project.

“Right,” he said.

“So others approached you with the data,” the QA manager said, probing, since information wasn’t being offered. “And what did you do?”

“I didn’t do anything,” the interviewee said, with pride and self-confidence. “I called someone and told them that they needed to correct this problem.”

The rest of the interview as essentially a replay of the above, at every turn this person was “vital” to the success of various projects – and recognized as such – but this person never actually contributed by taking on any task (that we could determine) in any way! Every time we probed at something, this person always seemed to be the person contacting someone else to take action, but was never the person on the hook to do anything…

Don’t be this person! Your employment options will be extremely limited once you change bosses.

Interviewing: A Development Manager’s Perspective

March 19, 2009

This blog is about Software Results, and I’m currently exploring my role as a development manager in delivering results. As a manager, I’m NOT directly part of the teams that are delivering software (well, I am also a Product Manager, but I’ll cover that in a future post), so what is my role?

For a start, what I need are people who do code – and code well. In the spirit of the book Good to Great by Jim Collins, one of my keys to high productivity is having “the right people on the bus,” and this means hiring right. I covered the resume process in my last post: What a Manager Looks for in a Resume, this post is about the interview process.

Once I’ve screened the resumes and narrowed the list of candidates down, I will typically conduct phone screens as my first interview. These are always short, as my objective is to ask pointed questions geared at confirming that your experience on the resume is accurate.

One of the first things that go wrong for people is when I determine that the technology “experience” on a resume is there because an individual worked on a project that involved that technology, but they didn’t have any actual experience with this technology themselves. Believe me, there are times when resumes have been chock-full of implied experience, and it didn’t take me long to determine that the resume was severely over-stated. 

One suggestion that I have is to choose your words carefully. The purpose of the resume is to talk about you and what you can do, not to describe the projects that you were a part of. Instead of mentioning technology – and creating an impression that you may have worked on something that you haven’t – cite the experience that you have, and take pains to accurately represent any other involvement.

For example, don’t state that you worked on the “universal translator project written in C# and storing data in a SQLServer 2005 database designed from scratch.” This describes the project, but what did you do?

I’d prefer to see something like: “Collaborated on the design of the universal translator, personally developing 80% of the C# code that was used in the final product and was recognized having virtually defect-free by our QA department. I also worked closely with the database architect who designed the database schema for the SQLServer 2005 database. “

Now we have some things to talk about! During the phone screen we can have a quick conversation about the challenges and work that you did perform, and how you collaborated with the database architect. These would be areas that I would be sure to explore in greater detail in a personal interview; but you’ve satisfied me that your resume reflects your actual experience.

Once I’ve decided to bring someone in for an in-person interview, the field has been narrowed significantly because we want to spend much greater time with those that we’ve determined to be solid prospects. In addition to interviewing with me, I’ll arrange for interviews with other developers, particularly those who you will be potentially working with.

We don’t deliberately orchestrate high-pressure interviews, but we do conduct team interviews – and some people find this to be intimidating. I will admit that teams of people can add to the stress, partly because a group will toss out questions that take you all over the board, forcing you to mentally switch gears. Seeing how you respond does help us to understand how you will operate under those times of pressure.

At some point in the team interview, the interviewee will end up on a white board talking through some problem. It’s all about understanding your thought process and how you go about problem-solving, along with interacting with those that are your potential peers.

When deciding on a candidate, I’ll defer to the team’s assessment of your specific technical skills, but as a development manager – and someone who did a fair amount of coding in the past – I will probe into how you approach your job. I’ll ask you how you go about writing high-quality code, from design to actual coding and unit testing. I’ll also explore the types of interactions that you have with the QA department, what you do when a requirement is not clear, or how you deal with someone who is not holding up their end.

I’ll ask questions to gain an understanding of both your knowledge and preferences; I’ll ask about what is causing you to leave your current position (assuming that you haven’t been laid off due to a poor economy – something that is very prevalent these days, unfortunately), and how you like to take direction.

I’ll ask for your opinion about who the best manager that you have ever worked for was, and why. Part of this is to understand what management style will make you feel truly comfortable and productive, and part of this is to uncover anything that I can do to improve myself. Interviewing is a time-consuming process, and I try to get a little pay-back out of the process while I’m at it.

As part of the interview process I will want to determine if you are the type of person who will continue to learn and grow. Do you read any particular blogs, or even blog yourself? Do you read trade journals? Do you participate in any open source projects? Anything that indicates that you take initiative to keep yourself current in the technology arena certainly reflects well on you.

Ultimately, I want to understand what makes you most productive, what management style works best for you, any work preferences that you have, and whether you will an asset today and tomorrow. It’s hard to find perfect matches, but I do try to cover the bases.

If you want to stand out from your competition, do a little homework first. Visit our web site, find out about our company. I’ve been impressed by what some candidates have been able to learn prior to an interview. Others come in without knowing a thing about us, despite this information being readily available.

Ultimately, we make hiring decisions that examine a candidate from a variety of perspectives, and involving multiple people. After an interview, we discuss the candidate and weigh what we have learned against our needs. And if there is any uncertainty, we’ll bring you back for another round. And our standard HR process is to check references and conduct background checks.

Overall, I consider due-diligence in the hiring process as very important to the business. Hiring wrong at the least will not be of true benefit to us or the new hire, and at worst will make things miserable for all concerned. If we don’t find a match, we pass.

What a Manager Looks for in a Resume

March 16, 2009

A good many organizations are fond of saying: “People are our greatest asset.”

I won’t get into whether many companies really believe this, but having good people who are true assets begins with the hiring process, and the first meaningful step (once you've advertised for the position) starts with reviewing the resumes.

Unless we have an immediate need for a very specific skill (and despite pressures we have from time to time, this is in fact very rare), as a software development manager I look to hire good programmers, period. I don’t worry about prior experience with a particular language or platform, but I will use experience that is directly related to our needs as a tie-breaker, all other things being equal.

When it comes to the resume, I’m sure that I’ve overlooked some good candidates in the past because their resumes didn’t differentiate them from the pack. A fair amount of developer resumes read like a shopping list, providing a dry list of tools and technologies, but little in the way of what you can really do.

What I really want to know is that you are able to think through difficult problems, prioritize tasks, that you take personal responsibility for your work, that you have some initiative. I want to understand your accomplishments and what your capabilities are.

To succeed in today’s world you need a range of skills and abilities that I as a manager find important, including technical knowledge, communication skills, collaboration skills, and regular showers. However, I won’t notice your hygiene until your resume gets you through the door…

And that means that your resume should highlight more than the technology that you have touched! Being qualified for a position in this field requires more than just having technical knowledge; you need to be able to produce results. Make your resume speak to whoever is going to read it, compel them to at least pick up the phone to have a conversation!

For my money, I prefer it if you provide me with your real qualifications up front. Don’t provide a bland list of compilers, database platforms, and communication protocols that you’ve played with. Tell me about what makes you a good candidate. You can write short paragraph or provide bullet-lists, but tell me what you can do – at a high level. For example:
  • Demonstrated ability to deliver quality results, on time and on budget, as part of an Agile team.

  • Proven track record of designing and implementing highly scalable, enterprise systems.

  • Accomplished presenter and author with 5 published articles and the writer of a weekly blog.

  • Recognized for building collaborative, committed, high-performance teams.
These are just examples, but you should get the idea. You don’t need to give the details of your experience, keep it short and highlight what makes you valuable.

Get me interested to read on and find out more. I’ll learn more about the specific technologies that you have worked with as I review your employment history. You want your resume to get me intrigued enough to pick up the phone and schedule an interview to discuss your experience in person.

Personally, I don’t find an “objective” statement all that useful. You want a job, right? You know what position I’ve posted, so presumably you know what you are applying for, correct? I always assume people have career objectives, and I am more than happy to explore these during the interview process, provided you reach that point.

What I really look for are individuals who have a track record of learning and growing, who can work through difficult problems and deliver, and who will be a good fit for our company and the team that they will be assigned to.

Once you’ve provided me a short outline of your capabilities, the rest of your resume can be divided up with your actual employment experience, education and anything else (do you blog?) that you think that I should know about.

If you want to list the technical tools and platforms, put them in a Technical Skills section. And with so many candidates on the market today, it's a good idea to tailor your resume by putting the skills and knowledge that we've advertised for up front. Don't let me overlook you!

When describing your actual experience, include your job title and list your key accomplishments and the benefit(s) provided along with the technologies and platforms that you had experience with in that position. Seek to provide more than just a list of facts about your prior employment. For example:

2007-Present XYZ Corporation
Development Lead
Key Accomplishments:
  • Led a high-performance team of 5 developers that replaced an entire suite of mission-critical mainframe products, re-designing and re-writing them using Microsoft C#, SQLServer 2005, and Microsoft Office SharePoint Services (MOSS). The new applications took 50% of the time required to develop the original suite and added new workflow automation, enabling the XYZ Corporation to lay off 10,000 employees, achieving significant long-terms savings realized through greater productivity.
2005-2007 XYZ Corporation
Developer
Key Accomplishments:
  • Designed and developed an “implement” add-on for Microsoft PowerPoint entirely in VB.NET in 45 days. This add-on enables business users to generate small-scale, working software products directly from PowerPoint slides with a push of a button, eliminating the need for costly software development projects. Received a chairman’s award and gift certificate in recognition for generating hundreds of millions of dollars in new revenue.

  • And so on…
Notice how these items are not just descriptions of projects, nor are they a list of "responsibilities." They provide information about what you contributed and how the company benefited from your efforts.

Another nice touch that adds to your being noticed: A cover letter. If you’ve paid attention to the job posting, you can call out specifics about your experience listed on your resume that make you qualified for the position.

If I receive a cover letter along with a resume, I always read it. It allows me to understand the person behind the resume a little more, and this is a great place to provide a little information about your career goals and aspirations. A good cover letter can make the difference between your being a "maybe" on a pile of other resumes to getting a phone screen at the very least.

If you are interested in more resume-writing tips, I suggest the following links:

http://www.resume-resource.com/resume-tips.html

http://www.free-resume-tips.com/10tips.html

http://www.damngood.com/jobseekers/tips.html

The Software Manager’s Role

March 13, 2009

Since I’m a software manager, I thought I would examine my own role in terms of contributing to the successful delivery of software. Interestingly enough, my company has made the switch to Agile development, and according to some people this makes me obsolete.

Why? Because Agile development supports the notion of empowered teams, meaning that the team manages and monitors its own work. This can even go so far as self-selection of team members and even helping to set product direction, but my impression is that operating at this level will vary based on the company and circumstances.

Personally, I haven’t found this difficult to accept. But for some managers who are used to regularly assigning and monitoring work, teams that manage and monitor their own work is a significant change, prompting questions such as:
  • If a team is managing its own work, what is my role?
  • How do I accomplish performance reviews?
  • What can I – or should I – do if an empowered team is failing to deliver?
Well, well. The classic definition of management is getting things done through others, and I see nothing in conflict with teams managing and monitoring their own work. In fact, software teams are comprised of professionals who are supposed to be capable of prioritizing and organizing their tasks in the first place.

What they need is context.

Context that is provided in the form of clearly articulated long-term business goals and objectives, more often than not coupled with tactical targets that are balanced against those inevitable short-term issues that need to be addressed while taking smaller, intermediate steps towards the long-term goals and objectives.

OK, that was a mouthful, but the concept is that management, particularly mid-level management, is well-suited to the planning and communicating required in balancing long-term and short-term needs of the organization. Mid-level managers are close enough to the action to understand the daily challenges of those in the trenches as well as being positioned to ensure that the long-term vision doesn’t get lost or pushed aside.

My short list of management activities that I’ll explore in upcoming posts:

  1. Hiring
  2. Assessing, Coaching, and Developing
  3. Firing
  4. Removing Impediments
  5. Championing Process Improvements (internal efficiencies)
  6. Improving the Business (external opportunities)
I’ll post follow-ups every few days or so to explore each topic.

Should You Manage by Metrics?

March 7, 2009

Metrics are a source of debate among many in the software development world. Personally, I feel that metrics are useful, but they need to be used properly.

An inappropriate use would be to measure a programmer’s job performance. For example, if you use lines of code as a primary measure a programmer’s job performance, you’ll get lines of code, in spades. I wrote about this problem in my blog post: Does a Software Productivity Metric Exist?

Plenty of others have written about this and and other common metrics as being a lousy measures of productivity as well. Here’s a couple of links if you are interested:

CannotMeasureProdctivity by Martin Fowler.

The Productivity Metric by James Shore.

What should metrics be used for? They should be used for comparison purposes to help teams and individuals improve, comparing yourself against the industry norm. For example, if your defect rates per thousand lines of code are above the norm, it may suggest that you need to spend more time on analysis and design before coding.

They are also helpful for planning purposes. A very useful blog post on this topic is one of Jeff Atwood’s Coding Horror posts, Diseconomies of Scale and Lines of Code. In it, Jeff notes that the lines of code metric is useful for determining a project size.

Jeff also cites my favorite software development author Steve McConnell, who points out that there is a non-linear relationship between a project size and overall productivity, something to be considered when planning projects and comparing yourself to others in the industry. To quote directly: “[Using software industry productivity averages], the 10,000 LOC system would require 13.5 staff months. If effort increased linearly, a 100,000 LOC system would require 135 staff months. But it actually requires 170 staff months.”

Simply stated, a metric is a gauge, measuring some key aspect that is important to your overall understanding of a larger picture that you are managing. If you want to improve the reading of the gauge, don't starting asking people to deliver more of what is displayed on the gauge! Examine what drives the reading and turn those knobs instead. This is why demanding “more lines of code” from programmers does not actually increase productivity.

Furthermore, metrics should be confined to measures that help you understand and to improve your results. Don't get metric-happy and measure everything that you can think of. Focus on the areas of critical importance and the key measurements that you need to understand how you are doing.

In the end, measuring informs you, but managing is all about understanding what the work is and why certain practices will increase your odds of success. The real need is to manage the business, to manage people, and to manage projects. Reducing management to any one metric is an oversimplification that will only create Dilbert-like scenarios.

My post Six Keys to Successful and Productive Software Delivery discusses the areas that I consider important to measure and manage.

Since I've touched on management in this post, I'll commit to examining my own role as a manager in my next post. As I’ve mentioned, we’ve adopted Agile development at my company, so I’ll examine my role with respect to Agile. Fair warning: I’ll work at refuting the notion that there isn’t a need for managers with empowered, self-directed teams!