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:
1) Mature process is not a replacement for talent.
We may follow a process, that process may be well documented, but it is not the steps that create value, it is the decisions that are made at each steps which represent the work. Just like a thousand monkeys in a room with a thousand typewriters will never produce Shakespeare, a dozen average coders following a good process will not produce great software. Process is there to make sure that all the right and necessary decisions are made, talent is what makes the decisions well.
2) Staff onboarding is way more than an HR checklist and a development environment.
In order for developers to be fully productive they need subject matter knowledge, practice familiarity and competence, and a small organizational network of go to people to keep them from getting stuck. In my experience it really takes 4-6 weeks minimum, before most new developers can independently work up to their capacity. Comprehensive developer documentation for software design, developer practices and environment configuration can make this better, but I’d wager that if you only think it takes a week or two to onboard a developer, you haven’t invested in this yet.
3) Team formation is always more difficult that you think it will be.
Different opinions, strong convictions, diverse experience, varying levels of familiarity with the problem or the tool set or the practices, and overly optimistic self-evaluations make for tremendous challenges in bringing a team to consensus. New leaders eager to prove themselves, or too reliant on prior leaders introduce too much or too little change. Getting a new team through four phases of team formation – forming, storming, norming, performing – requires more attention and more intentionality than many managers can provide. Serially adding members to a team or having a “replaceable man-widget” staffing philosophy can prevent teams from ever reaching the norming phase, let alone the performing phase.
4) Leadership capacity is the #1 driver of scale.
If your team has capable leaders, who can direct the work of others and maintain control over process, then you can have a big team. As a manager of application delivery teams, you need to focus on your leadership roles first. If you don’t have the right leadership team, the rest is moot. Leadership in software development is not hiring authority, it is decision rights. Who gets to decide what, how, why and who? If those rights are not clearly defined, or given to individuals who are not capable enough, chaos will ensue.
5) Leadership development is difficult because the capacity of a leader has three dimensions:
– scope – how many competent people can he supervise? This is like juggling – how many balls can he keep in the air until they start falling.
How do we provide our leaders with experience that challenges them to develop their capacity? Do we understand their capacity? are we thinking about it, or are we just expecting them to exercise their skill? How do we let them fail, so that they can resurrect themselves as a stronger, harder, tougher (battle tested) leader? If they never lose, they never learn. Capacity is increased by exercise; practice. To grow they must do more than they think they can, enabled by a coach, who encourages them, but does not rescue them until they go under for the third time.
6) Incompetence is a drag on leadership and a significant driver of risk.
I want to make a difference between incompetence and non-competence. Non-competent people realize that they don’t have the capacity to do what you are asking. They will ask for help, phone a friend, read a book or take a class until they can figure it out. They may not know how today, but as soon as they realize they need to know how, they start learning. Incompetence is different. Leaders spend an inordinate amount of time cleaning up after incompetent people. Incompetent is different from unskilled – If you are incompetent, you are unable to exercise any skill that you have in a consistently successful way. Leading a team with incompetent people is like driving a car with bad tires. When they lose pressure, you have to stop the whole car to pump them back up. Even one bad tire makes the trip a lot slower and more frustrating. Incompetence doesn’t have five years of experience, it has one year five times.
Why are these ideas important to your forecast? Because each of them influence your staffing model. If you are like most IT managers, like I was when I started, I thought that skill was the most important driver of my staffing strategy. If I could simply hire the team with the right skills, my team would be effective.
No Comments