Let’s talk about the elephant in the room. Technology teams aren’t terribly effective communicators. We like shiny things and touch screens and communication protocols. We like colors, we like monochrome, we like wit, we like irony, we value the occasionally vague. We dabble in hyperbole. Most of all, we can’t stand being managed by people who can’t speak our language.
Why do software development teams have so much trouble building teams that can work together? Agile teams are an interesting case model – you would think that of all the team models out there, the most flexible model would win, yes? Agile being one of the most flexible methodologies to create, test, and ship product under, it amazingly suffers a similar fate.
Kevin Breidenbach blogs about a perspective from the Agile consulting group Thoughtworks: Most technology teams are crap, spoonfeeding the answer to companies doesn’t fix the problem, and sooner or later something has to give. Agreed or disagreed, the real question remains unanswered: what is the most flexible option to choose given that most team members are FTEs and most contractors have worked their way tightly into the organization?
The answer is to neither blame nor complain; both put shame in your game. Thoughtworks may insist that “Businesses won’t keep paying for crap, and poor technologists can’t expect to be gainfully employed”, but history says otherwise. There are plenty of people employed as technologists who not only lack a technical degree from an engineering school, but flat out can’t perform the work. Any QA analyst has seen their fair share of subject matter experts pawned off as QA staff members simply because there was no better title for them, and they were too valuable to lose. This is ultimately a disservice to the person, because they have little interest in formal QA or coding automated scripts, and a disservice to the team because they are not getting a standard set of consistent services from the person that they could expect from a person hired for a technical QA role.
Giles Bowkett blogs about the state of technology jobs beautifully (the below diagram is his:)
Being bountifully and indiscreetly ineffective at your job is not generally punished, and certainly not by being fired. There are surprisingly few consequences of job termination as a result of failure to meet goals in today’s technology employment horizon.
For a variety of reasons, it is cheaper and emotionally easier to simply move people around in an organization rather than fire them outright. There are political pressures to keep unemployment claims down, and a large firm that cuts too many headcount risks a reporter throwing their brand into an article describing yet another victim of the bad economy.
Anne Mulcahy of MIT Sloan School of Management maintains that a company should “hire with the intent to keep people and build careers.” Carly Fiorina speaks of her time managing people as CEO of HP, “For all you –sorry– quantitative types who think values and organizational behavior is soft stuff — it is the hardest stuff.”
Simply put, nobody wants bad press, and moving people around and offering “second chance number six” to people year after year is a price many firms are willing to pay. Complaining and whining about it does occasionally land you some consulting work if you’re in the business of fixing software development gone wild, but it’s not a scalable technical sales strategy. You can tell who has been shifted around once too many times in an organization by the meh-face they wear.
At the other end of the nature-nurture spectrum is the view that firing someone for poor performance is too kind. Director James Cameron, famous for directing such films as Avatar, The Terminator, Aliens, and Titanic enjoys testing employees endurance for long hours, hard tasks, and harsh criticism. writes in the Harvard Business Review blogs that surviving Cameron staff members, numbering in the thousands for these motion pictures, “tend to surprise themselves by turning in the best work of their careers, and signing on for Cameron’s next project.”
So can every technology manager be a Cameron? Probably not. But every manager can learn from his principles:. According to Keegan:
- Be comically hands-on
- Try every job everyone does
- Emphasize collaboration by forcing yourself as a manger to lean on others
- Set the pace
- Be the first to try a new challenge
- Be the last to quit at the end of the day
- Be the hardest to please
I see great value in effective executive coaching. If you are not being coached or coaching someone, you probably aren’t moving as quickly as you’re telling yourself you are. Being in touch with your own goals is paramount to understanding those of your team. Know thyself, no?
As a professional software QA manager and coach, I look to understand the nature of products under test and adjust my staff qualifications and technical approach after. As the team grows and adjusts to one another, we play with working hours, weekend and evening expectations, personal life balancing between everyone, and the level of service we want to provide our company (regardless of contractor or FTE role.) Everyone is treated as an individual. A novel concept for engineering, no?
If you don’t understand what your team is doing, start reading. Ask them for help, check in with them, drop the ego, and focus on the end goal. If you don’t have goals, get some.
As you work this process, the failure of your team will come to light, and you can begin strategically adjusting. This works best when you know your team and treat them as humans.
Oh, and laughing goes a long way. If you can catch yourself taking yourself too seriously, that’s the best gift you can give yourself, because you’re discovering what everybody already knows about you.
Good luck, relax, and have a little joy, people!