Improving Accountability Within your Development Department

Posted by mikeberry | Leadership,Product Owner,Project Management,ScrumMaster,SDLC Management | Wednesday 31 October 2007 12:03 am

Many Software Development Managers find their way into the “coveted” position from atrition after being a development team lead, or senior architect.

Having a technical background is an obvious advantage in terms of understanding the complexity dynamics the team deals with.  One big reality, however, is that these vast technical skills are only a subset of what is required to become a great manager, and the new manager soon discovers he needs to learn much more about the role.

In Jack Welch’s book Winning, he explains that being a good leader means you shift the focus from you to them–from being the only one able to solve the latest problem, to being the proverbial “dumbest person in the room.”  Accountability should come hand in hand with empowerment.  Learning to empower your teams can be difficult, and seem like a leap of faith at first.  You soon learn, however, that letting your team originate the solution, predict the schedule, perform the work, and solve the problem builds their trust in you and in themselves.

Another effective technique is to make your team accountable to the executive staff themselves–in person–instead of you being the go-between, shielding them.   Have the team leads accompany you to the Executive Committee meeting to report their progress.  This way, they can feel a sense of accomplishment for their victories, and feel the pressure from the top, instead of from you!  Teach them to be commitment oriented.  Develop a commitment-oriented culture by keeping track of their commitments and holding them accountable for each one.    Base their bonus structure on their ability to keep their commitments.  This will teach them to be more accurate, which translates into better predictability that that is better for everyone.

Joel Spolsky has a simple solution for this.  It’s called Evidence Based Scheduling and you can read about it here.

Mike J Berry

The Role of the Development Manager

Posted by mikeberry | Agile Development,Agile Executives,Leadership,Product Owner,ScrumMaster,SDLC Management | Tuesday 30 October 2007 11:47 pm

I remember my grandmother explaining what it was like to teach grade-school.  She said to be a good teacher, you had to be part teacher, part nurse, part referee, part coach, part police officer, part mother, and part collections agent.

Fortunately, software development management requires a smaller skill-set.  Software Development Managers really have four areas of responsibility.  These four areas are:

  1. Responsibility to the corporation
  2. Responsibility to the development department
  3. Responsibility to the customer
  4. Responsibility to the product

To the corporation, the development manager owes efficient yield,  predictability of delivery dates, and transparency regarding the health and status of each project.

To the team, he owes corporate transparency (what goes on in the executive meetings), clarity of direction, priority of tasks, empowerment, and accountability.

To the customer, he owes the highest reasonable product quality, and highest reasonable product relevance.

And to the product, he owes the best tools, architectures, and programmers he can find.

Mike J Berry

Corporate Strategy Planning Simplified

Posted by mikeberry | Agile Executives,Strategy & Portfolio Management | Tuesday 30 October 2007 2:50 pm

What is Corporate Strategy and how do we deconstruct it?  Corporate Strategy can be simplified into two drivers:  Top-line and Bottom-line.  Top line is your gross revenue, and bottom line is what it costs you to obtain that gross revenue.

Think about these as numerator and denominator drivers.  Together they make a formula that looks something like:

Yield(Investment)  x Market Opportunity x Accessibility
Cost of (Development x Support x Sales & Marketing x Admin)

So, the basic idea, for a software company, is that if you have frequent software enhancements and new products that match a ripe market opportunity, and you let your customers know about it, then you can collect a lot of top-line revenue.  The trick is to do this while spending the least amount on the bottom line.

What’s interesting about this process is that bottom-line cost is somewhat predictable and standardized.  Meaning, it costs your company probably the same amount of money to hire a development manager and to get a building to put people in as it does the company across the street.  In order to shave expenses from the bottom line, you need to understand every competitive advantage your competitors have and newer industry trends in technology and implement them yourself as much as possible.

The numerator factors are really what’s unique about your products or services that set you apart from the competition.  The more relevant these are to the existing market appetite, and the more your customers know about them, the faster your top-line will grow.

Now, wasn’t that simple?

Mike J Berry

Why should Corporate Strategy be important to us in Development?

We code, right!?  We code, and play Warcraft.  Why should we know or care about corporate strategy?

Well, the answer is that most programmers probably don’t really know what their organization’s corporate strategy is.  If you do, you likely have an outstanding manager who has learned that part of their responsibility as a manager is to communicate executive directives back to Development.

A company that performs good ‘Strategy Management’ will do two things:

  1. They will broadcast their corporate strategy to all employees so that everyone can be on the same page.
  2. They will establish measurable metrics throughout the organization to determine how close everyone’s efforts are to the decided strategy.

When this happens, an effective plan is for the Development department to adopt their own ‘Department Strategy’ that supports the Corporate Strategy.  Then look for ways to measure how effective they are at pursuing that strategy.

For example, if your team has to report total hours for the week, reporting could be enhanced to include how many hours each programmer spends on each project.  Then each project can be placed into separate ‘strategy categories.’  Then, time can be measured for each project worked on during the week, and a summary comparison can be presented to upper management showing that the Development department is ‘following corporate strategic goals’ by spending a proportional amount of time on projects that are aligned with various corporate strategies.

If you are a manager and do this before you are asked to, you may even earn yourself a few stripes.  Kapish?

Mike J Berry

What is Software Portfolio Management?

What is Software Portfolio Management, or SPM?  They never taught us about this in college.  This is when you are reading your email in the morning from an unhappy customer who wants new feature X when suddenly your phone rings and the VP of Sales wants to know when you will have an install ready for a customer Y whom you never heard of before and then all of the sudden the CEO walks in and announces that your team needs to start on pet project Z.  Sound familiar?  Enter SPM…a solution to stop the madness.

Here’s how it works.  Your Executive Staff meets every two weeks.  You produce a list of all the hours available that your programmers collectively have for the upcoming two weeks (minus vacation, etc).  You produce a second list of ongoing projects, pending projects, and then you offer up the floor to whomever wants to request new feature X, Y, or Z.  They get to justify their request to the whole Executive Staff, preferrably on paper, and then the whole staff decides when to start on the new project, and how to prioritize it.

This way, project requests get presented and evaluated against the opportunity cost of the other projects, and not based on urgency or theatrics.  There’s a little more to it, but this basically describes an effective solution for an age-old problem.

Mike J Berry

Optimizing Corporate Portfolio Management

Posted by mikeberry | Agile Executives,Leadership,Product Owner,SDLC Management,Strategy & Portfolio Management | Tuesday 30 October 2007 5:25 am

I just bought a new book on Portfolio Management called Optimizing Corporate Portfolio Management: Aligning Investment Proposals with Organizational Strategy, by Anand Sanwal (Wiley Press).

To my amazement, the forward commentary is by Gary Crittenden, a long-time friend of mine.  Gary and I lived near eachother in Munich, Germany years ago.  I believe my girlfriend at the time was a nanny for his kids.  He led a group of us on a 5 day bicycle trek across Austria.  Amazing experience.  We went skiing together often in Der Schweitz.  Gary worked for Bain at the time, and later was the VP of American Express, and now has the CFO chair at CitiBank.  (If your reading this, Gary, Here’s a big ‘Hello!’)

I’m eager to read the book because it details the challenges, solutions, and results American Express faced as it went through a Portfolio Management Revolution.  Internally, they call the process Investment Optimization (IO), but it is known throughout the industry as Corporate Portfolio Management (CPM).  This process scales very well to the software industry, except that only about 50% of all software companies in America have any kind of Portfolio Management process.  Of those, few target Customer Value as the main driver for success.  So there is a lot of work to be done in the software development industry in this area.

Mike J Berry

Red Rock Research

Posted by mikeberry | Uncategorized | Monday 29 October 2007 9:15 pm

This is my first post for RRR.  I’ve started this site because I feel like it’s time to start giving back to the IT community.  Lots of the information found on these pages I wish were made available to me years ago.  Probably there are software development managers out there just starting out that are hungry for information and want to peform their jobs better.  If you are one of these brave souls then cheers…this blog’s for you.

Mike J Berry