Read this great line from Johanna Rothman’s Hiring Technical People blog:
When you are unemployed, your job is to get a job. If you do other work, you better have a great reason.
It so correlates with the book I just finished on Friday “The War of Art” by Steven Pressfield which completely expands the topic to how we tend to find ways to not do what we are really called to do.Continue Reading
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
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
I am thinking about IT staffing strategy. In order to share my thoughts, I need to define some aspects of that strategy, and perhaps explain why I think they are important. I am not an OD guy, nor do I play one on TV. I have, however, observed and participated in management and leadership in information technology for over twenty years.
Earlier posts on IT Strategy including Goal Strategy Policy and Vision, Strategy, Policy are the beginnings of where these thoughts come from.
In my prior post ( ITStrategyInternals ) I explained a little about patterns and practices. Patterns and Practices within IT go hand in hand, in that we have an established solution, and a body of knowledge and expertise around that solution.
I think that we sometimes think that by selecting a tool, we have defined a pattern. So let me say, that patterns are at a higher level of abstraction than a tool. A pattern may require some tooling, but it should not be specific to a tool. The body of expertise around implementing a pattern with/through a specific tool is a practice. So ORACLE DBMS is not a pattern, but a data warehouse may be. Likewise, MQ Series is not a pattern, but a message bus may be. We may have a practice around implementing a message bus using MQ Series, or TIBCO, or Tellurian sockets or Oracle SOA Suite.
Tools are really only valuable, in that they enable the delivery of patterns. Tools can be anything from an integrated development environment (IDE) to a component library to an operating system. Programming languages are not tools, but editors and compilers are. Programming languages are patterns. SQL is not a tool, but MySQL is. SQL is a programming language that is a common part of a relational database pattern. We have come to expect that any tool that enables a relational database pattern implements some version of the SQL programming language.
Those of us who have been in this industry for a few years, realize that the players (tools) change pretty frequently. As a new pattern emerges and is perceived as valuable, it disrupts the market for a while, then the tools supporting the new pattern prosper, and the others diminish and sputter towards irrelevancy.Continue Reading
Hiring is a tricky business. We screen for experience. We screen for skill. How do you screen for talent? We should recognize that talent and skill are not the same thing. Skill is the ability to apply technique correctly. Talent goes beyond that. Talent includes the ability to know which technique will produce the right result. Talent is the ability to know when none of the techniques I know are a sure winner. Talent is the ability to quickly learn and assimilate new technique.
Talent != skill and experience – five years of c# programming experience does not equal talent.Continue Reading
Technique without talent is inefficient.
Some folks are just born with certain gifts and talents. They are smart in the right way to “just get it”. Whether it is music or leadership, or basketball, it doesn’t matter – some people are a “natural”. The rest of us have to learn the techniques and practice, practice, practice. While technique will get us pretty far, it will never catapult us into the same league as the natural talent. Our practice does not accomplish as much as the practice of the person with talent.
Perhaps you have experienced the struggles of on-boarding new developers into an already large team in the middle of a project. Everybody who comes wants to have a say in how things are done, no matter how late in the process they get involved. Here is a litany of the types of commentary that I hear in this situation:
- On my last project we used <insert product, pattern, or practice> and it worked great. We should certainly use that here.
- We don’t need <insert pattern, product, or practice> its too <insert adjective>.
- Why don’t you just <insert suggestion>.
- The code-base is in a bad state because <cite example>.
Each of these commentaries were delivered, without necessarily an understanding of the choices that were made by the team to get to this point, nor with a full understanding of the work remaining. I sincerely believe that each developer made the comments in a spirit of trying to help the team. I also believe that each of these comments reflects the developer trying to construct a “familiar” environment where he knows how to deliver value.
Here are the problems with this:
- Commentary rarely reflects a problem statement before offering a solution.
- Commentary rarely exposes the cost (in effort and risk) of adopting the solution.
- Commentator may or may not have the experience or skill to lead the team through the adoption of the solution.
- Commentator may or may not have thought through the solution to the ultimate conclusion – to determine whether it is feasible, valuable, or reasonable within the context of the project.
I attribute these commentaries to each developer’s on-boarding process, and their process of “mourning” the familiarity of their last engagement, while also trying to understand the current environment.Continue Reading
Hiring has some words that we use to describe what we are looking for:
1) Been There, Done That – you want someone who can do this job with their eyes closed.
2) New Blood – you want someone who will never say, “that is not the way we do it here”.
3) Fresh Meat – you want someone who isn’t already burned out.
4) Youthful Optimism – you want someone who will not stop trying when things get ugly.
5) Hands – you want someone who cranks out work.
6) Brains – you want someone who can show us how to do it better.
7) Potential – you want someone who can become a star.
Hiring is difficult, because you don’t always know what you are getting. But it helps to know what you want. I like these words, because they informally signal what that I am seeking.