You are currently browsing the monthly archive for October 2008.

I created a demo video of the application I helped build for my last company, which I no longer work for. They have a live version that can be accessed online, but since it’s a sophisticated tool that requires some prior knowledge, it’s easier for me to give people a general overview of the look and feel by using this kind of video.

I don’t show all of the application, just a couple main pages. At this time, some pages are old versions that aren’t of the latest internal version from when I left, and some pages are updated with new stuff that I had nothing to do with, but the video shows pages that haven’t really changed since I left. Since I can’t vouch for the quality or state of the application now that I’m gone, this video gives some general sense of the product.

Quality is pretty crappy being a Youtube video. I have a .mov file, but I can’t upload that here, so if anyone is interested in a higher quality, then let me know (~30MB file).

Overall, I’m happy with the product. I feel like I did a hell of a lot of work on it doing everything from UI Design, client-side coding to server-side and business logic coding to some database work as well. There’s plenty of points that could be improved, things I’d do differently if I did them again now, but such is the way with small companies and tight deadlines. The demo had been tested against IE5.5-7, FF2 (Mac and Windows), and Safari (Mac). I believe Opera worked fine as well. FF3 has a couple minor visual glitches, but probably not noticeable by someone not familiar with the product. FF3 came out after the initial design, and client work (and my boss’ priorities) kept me from fixing the issues before I left (UI Design was the least important thing to pretty much everyone, but me). C’est la vie.


I recently posted some thoughts about P&L and my own version of P&L, productivity and learning. I’ve been asked to shed some more light on the subject of productivity, so I’m delving into the topics of capability and capacity. In my previous piece, I argue that productivity is made up of a few components, and capability and capacity are two of the tangible elements at play (other intangible elements would include level of challenge of assignments and happiness with work). I also note quality as a key component in the piece, but more as a component of learning, and less as a direct component, although still influential, with productivity.

Estimating capability and capacity judges readiness and ability to adapt. This allows you to highlight potential problem areas. The method won’t give you a number. It defines the boundaries of your team.

With this understanding, you can then see how your team’s characteristics match your overall functional priorities, and from that point, you can develop plans for getting or keeping your team aligned with your overall goals. In terms of measuring results, you want to measure based on primary goals, and not based on lower level components such as capability or capacity, or you greatly risk managing by misdirection (for instance, increasing productivity may have in impact on revenue, but could instruct people to push out crap instead of better satisfying the real goal). If you do develop a means of measuring sub-components of your team (for the purpose of reviews, and ultimately, effecting compensation), then it should always be understood in relation to the overall impact on the overall goals.

Understanding Capability

Capability is another way of saying, what does your team know? In understanding your team, you’ll want to map out the Domain of Knowledge that your interested in. You first break it down into a set of business or functional categories. Such as software engineers obviously need to know about writing code, but also potentially about the subject matter of the business itself like advertising, or farming, or insurance. You may think of 3 or 4 different areas of interest even if the primary area, engineering, is the main area of concern as understanding finance or marketing or design may play a smaller, but still consequential role in the team makeup.

Once you have broad categories listed, you then want to break each area down into 3 or 4 levels of understanding like beginner, intermediate, and expert. Software engineers under the engineering category would look something like: (Beginner) basic coding skill, maybe some specifics like JSP, HTML, CSS, Javascript, (Intermediate) Object oriented programming, data structures, security, database, (Expert) design patterns, high performance applications, specific app server experience like with JBoss, specific experience with a particular tool of interest. You can get more or less specific, but do the same for each of the other areas.

Then see how your team stacks up against that breakdown showing you obvious holes. Both specific expertise and broad knowledge individuals are useful. Typically people with a broader knowledge base will be less of an expert in any one area, but could be just what you need. You have to understand the daily and weekly demands, and make sure that you team can meet those needs, but also the growing needs of an evolving business. People who are experts in a small area provide a lot of value immediately, but lose a lot of value if you go away from that area giving you potential incentive to not chance when you might need to.

Nothing mind blowing there, but if you don’t take the time to think about what you need and what you have, and how that aligns with your overall goals, it’s impossible to fix a problem when it arrives. And, if you’re lucky, you might be able to cut off some problem areas before they become a problem, or at least plan for a known gap.

Understanding Capacity

Capacity can be variable based on your own ability, not experienced or skilled enough, but also extremely open to external pressure such as being set up with inappropriately short deadlines or simply too much work no matter how good you are. For a normal week, though, no work should require overtime*. If the normal operating procedure includes overtime like normally working 12 hours a day or working 6 days a week, then there’s probably something wrong with the system, and it should be investigated, and plans should be developed to fix that problem. Otherwise, the cost of abnormal pressure will become too much, and you’re out of room to be agile or adapt to changing situations, nor will you likely have time to innovate.

*I understand that some people will be exempt salaried and therefore not receive overtime, but I’m using overtime to mean anyone working more than 8 hours a day regardless of whether they explicitly get paid for it or not.

Grade A

You’re able to handle a week’s worth of work, 40 hours, in less than a week’s time, something like 30 hours or less. You have time to optimize what you do, and research better ways of doing what you do, which would bring you up to 40 hours of work a week. If there’s a sudden increase in critical, time restricted work, then you probably won’t have to do any overtime to absorb the increase. This should be the standard for any given work week.

Grade B

You’re able to handle a week’s worth of work, 40 hours, in a week’s time, 40 hours or less time. If you have a sudden increase in critical, time restricted work, you can still make a weekly deliverable with some minimal overtime, less than a total of 48 hours. Essentially, you can handle the work you’re given, and don’t have to push yourself to get it done in time. You can stay ahead of the curve.

Grade C

You have to push to keep up, or barely keeping up with current workloads. Getting head of the curve is a problem. Probably have to work overtime more regularly to keep up with everything. You’re probably in over your head either because there’s just too much to do, or you’re not experienced/skilled enough to do the required work in the required time. Anything over 48 hours instantly puts you in this spot if not verging on an F.

Grade F

There is no D. You’re either barely keeping up, or you’re behind and failing. This doesn’t mean you’ve missed deadlines, but it means you’re probably in risk of missing deadlines, if you have already.


Bringing these two components together, you can get a sense of how productive your team can be. Improving productivity would then generally be matter of realigning your team’s knowledge around the domain of knowledge, or fixing capacity problems that are causing even your best employees to have productivity pains.

I don’t like thinking of number of widgets produced as productivity, but instead as a combination of factors including capability and capacity. You can increase the number of widget your team produces without really improving the status of your team. And as a member of the team yourself, there are some good selfish reasons to keep your team running smoothly.

By mapping out the domain of knowledge, and having a standard metric for measuring capacity, you can approach someone with the power to fix the problem, if that not be yourself. Increasing hours is always a very short term solution that has major long term impacts on the intangible attributes of productivity if not kept to the short term. Rapid increases in productivity general come in the form of re-engineered processes, and not re-engineered people. People take time to improve either through on the job experience, or in the class education. If you’re not fundamentally addressing capability or capacity, then you’re not really dealing with productivity.