,

The 3 Types of Value

Early in my career I learned that there are 3 types of value to an employer:

  • Increase revenue (grow the top line)
  • Decrease expenses (grow the bottom line)
  • Reduce risk

In an ideal world your employer would understand and value all three equally and you'd be free to pick and choose what you work on in order to be most valuable.  Even if your employer could choose to be that balanced, the market wouldn't let them.  Instead, you have to read the tea leaves (or the corporate memos) to figure out what's what.  If you align what you're working on with what's most desired, you're in for a Big Swinging Payday.

Alright, that's the general rule.  Let's get a little more specific for the folks out there who write software for a living.  There's a development analog for each of the 3 types of value listed above.  In matching order they are:

  • Increase capabilities
  • Decrease effort
  • Improve process

You increase your capabilities (and those of your group) by learning new technologies and tools.  This increases the range of what you're capable of delivering.  There are times when providing what couldn't be done before is incredibly valuable: typically at the start of a project or during project turnaround.  At the beginning there's a much better chance that new capabilities can be incorporated into the project.  This also happens when the project hits a, "We've got to change because what we've been doing isn't working" point.  Another way to look at it is that if things are moving along, don't risk getting in the way with offering something new.

You decrease effort by bringing efficiencies to the group that either didn't exist, or were poorly exploited.  The simplest way to do this is to automate the living daylights out of everything you can.  Automated builds, testing, documentation, etc. will help developers focus on the things that only they can do: write code to solve problems.  This doesn't mean that developers will end up working less, it means that given the same amount of time/effort they will produce more.  This is easiest to do at the start of a project (before things get messy), but is actually more valuable in the middle once bad habits and thrashing have begun.

Improving the development process is almost always valuable, but becomes particularly important between the middle and the end of a project.  This is due to the fact that from the middle to the end is the time when the project needs to be set up for maintenance mode.  If you wait until the end to do that then you won't have nearly enough time to get everyone used to the process.  In addition, from the middle to the end is when people will be rolling off the project and the level of talent should be constantly increasing until right before the end.  This is not to say that process isn't important until the middle.  Chances are that when a project starts there will be a period of process development that lasts the first quarter of the overall time.  Then people settle into a groove and crank things out for a while until they hit the halfway point, when it becomes time to plan for the end of the project.  By improving the process, you make development more predictable which lets those around (and above) you plan better and control the end-of-project glide path.

Notice that I'm talking about relative value at specific points the the project's lifetime.  All of these things are valuable and you'd be well off learning how to bring any of them into your organization.  If you want to really capitalize on them, though, take a look around and align what you're doing with what's most needed.

Career
,

Why Should We Have Centralized Architecture?

I recently had a chance to discuss the role of centralized architecture with a colleague.  When I say "centralized architecture", I'm talking about a group usually found in large companies that is responsible for technology standards across the organization.  In talking with developers over the past several years, I've seen the full spectrum of opinions on central architecture groups: At one end you have the developers who are appreciative of the architects hammering things out so that the organization has a common direction.  In the middle you have the folks that have heard such a group exists, but isn't exactly sure what they do.  At the other end are the developers who see the group actively impeding their progress.

Given the wide range of opinions and reactions to the architecture function, I started thinking about what I would want such a group to do.  I finally boiled it down to this:

The role of central architecture should be to balance the desires of the organization with the desires of the developers.

There are plenty of places where the desires of the organization and the developers are aligned.  The org wants some software, the developers want to write it.  But from there, things get a little tricky.  The org prefers to standardize on certain products in order to reduce cost and simplify maintenance.  Developers want to use whatever they want to use.  Developers focus on their system, or part of the system.  The org sees their system as part of a larger system and wants to make sure it can talk to everything else when need be.  The list goes on and on, but an architecture group can resolve these differences by providing the structure with which technology gets built.  Not only that, they can help developers work outside of the general structure when it makes sense to do so and provide tools that make staying inside the structure desirable.

Process