Skill – The ability to execute a practice, process, or procedure successfully; the ability to accomplish.
Competence – The ability to increase or acquire skill over time; the ability to grow in capacity.
Talent – The ability to decide which skill is best to apply, and/or invent and execute practice, process, or procedure, where no skill exist with reasonable success, and/or the propensity to gain competence in acquired skills.
If you take the definitions above from my prior post, you will start to recognize that much of what IT does requires talent. That skill and competence deal primarily with repetitive activities, that support an essential certainty about their execution. While these activities require decision making, the decisions and the decision criteria are constrained, they follow patterns.
Those of you who have spent their careers in IT will recognize that many of the activities that IT professionals do are not repetitive. They require invention, hypothesis, or discovery. These activities present new and unconstrained decisions. In short, they require talent.Continue Reading
In this post Glen Alleman retorts the commonly lauded platitude that:
“There is no way to prove that the requirements we have are complete and correct until we have working code.”
And as Glen is a very smart guy, from the perspective of the domains within which Glen most frequently works and thinks, his perspective that this is wrong, is essentially on target.
In those domains, requirements are imposed by the overall design of the program (not the software) with tremendous specificity:
The emergency shutdown system shall stop the turbine driving the compressor in 1.3 seconds or less to prevent overspeed of the RB-211
But in the domain of service business operations (investment management), a requirement for the program might look much less specific:
The investment platform shall allow portfolio managers to rebalance open architecture portfolios without requiring any non-trade transaction instructions implemented outside the investment platform. This operation shall take no more than 2 minutes from initiation to completion for portfolios with up to 500 positions.
These requirements sound similarly specific. The thing is they are not. What is missing in the service business case is how many steps in the process require human interaction. When the human interaction is taken into account, human variance and experience is important.Continue Reading
What are the elements of a staffing strategy? What are the the things to consider when developing a staffing strategy? These are the questions I want to address in this post.
Division of work: What is that taxonomy into which you divide the work into that helps you decide how to staff?
Often IT organizations divide along lines of administration and delivery. Sometimes delivery is divided between support and development. For product organizations that don’t support installed customer platform, administration includes platform or infrastructure. For enterprise IT delivery includes platform or infrastructure. For product companies that also host their product on shared infrastructure, platform may be divided between administration and delivery.
Occasionally, IT organizations will have a sales or relationship function, separate from administration and delivery. Sometimes an R&D function will included, separate from administration and delivery. Sometimes both of these are included in the delivery organization.Continue Reading
One thing that IT managers – and many managers whose work consists of projects struggle with is staff forecasting. Project work can often require elastic staff scalability. I have more projects, or bigger projects, or tighter deadlines therefore I need to increase staff (elasticity) to a larger size to complete them on schedule. As a leader, I need to have practices in place that work equally well with larger organizations as with smaller organizations (scalability).
In observing how the construction industry scales to do projects there are lessons IT can learn, but they don’t apply directly.Continue Reading
This is a collection of observations about things that managers and leaders of software teams encounter or trip over. This post comes out of a series I am doing about IT Staffing Strategy, but these are localized to the software team, not the larger strategy picture. These are very similar to Johanna Rothman’s excellent Management Myths series. If you are any kind of a leader in a software team, some of these will resonate with you:Continue Reading