11 Ways to Mismanage a Dev Team

Turnover kills – it should be on a bumper sticker. I should actually qualify that a little and say, "turnover can kill." I had the opportunity to ask Tom Peters about turnover a number of years ago since it's a pretty typical scenario that plagues many companies. There's certainly an upside to turnover (as Tom told me) – it can be an opportunity to bring in fresh blood and a new energy, and maybe even weed out dead weight. Often the case, though, it's the wrong people who are leaving.

In a feature team at Microsoft, it's no secret that when a new developer joins a team, the productivity takes a dive for a short time. It almost seems counterintuitive – adding, say, 20% to the resource pool causes a 20% drop in group productivity. But it's true, since resources are spent bringing someone new up to speed.

Microsoft highly encourages internal movement – this is fantastic, because it helps keep talent in-house and limits the productivity hit if the new team member is already a Microsoft veteran. When talent leaves any company, it's painful because filling a position is expensive – financially with the expense in recruiting, but also time in reviewing and potentially relocating a candidate. My move to Microsoft took about 4 months from beginning (an initial e-mail) to end (my first day). And when someone leaves a company, think of all the business knowledge that leaves with them.

I've worked at a number of companies of all sizes, and collected some ideas of what works and what doesn't from developers at PDC and thought about them quite a bit while driving the long, deserted highways in California on my way back to Redmond.

Before I enumerate my list, I want to clarify that I'm referring to full time employees here, not contractors or consultants (because the rules and expectations, from both sides, are simply different for contractors), and even though I'll use the word employee, I'm referring specifically to developers. Although some of these may apply in either whole or in part to contractors or non-developers, this is geared for developers and FTEs. And of course, like everything else in this blog, these are my own opinions and thoughts, and not representative of any view from Microsoft or other company.

So here's my list of 11 things I've seen that destroy development teams. Perhaps I'll follow up on this list with a list of the best and most innovative ways to manage a dev team.

1. Not having an SDLC.
The number one problem in a development team is not adopting an SDLC. Any development team (i.e. more than one person) needs to have a development lifecycle. There needs to be process, including analysis, design, development, testing, scheduling, etc. The type of process (waterfall, agile, etc.) isn't as important as having a process – without one, there will be missed expectations, missed features, schedule misunderstandings, higher defect rates, and generally more chaos.

Implementing a process helps to deliver a better quality product in a realistic time frame. It allows developers to know what to expect, and to know who to go to.

2. Non-technical people making technical decisions.
Especially architectural decisions. Steve Ballmer recently said in a keynote, "Every company is a software company."

I admit it: developers aren't usually the best salesmen, and marketing (while brilliant with marketing aspects) is unqualified to make implementation decisions. This often happens, though. Your car mechanic tells you, "Well, I can fix it by cleaning it out, adjusting x, y, and z, and get you another 3,000 miles. Or, I can reorder all the parts, spend ten times as much, and fix it correctly." Most people take the 3,000 mile cheap solution – at least, they often do in software if led by non-software people.

You can't always engineer an end to end solution for everything, of course, but if things are engineered correctly from the beginning with extensible solutions, projects should get easier. Platforms are quickly evolving every year – strictly speaking on the Microsoft platform, how do you know when to move from ASP 2.0 to ASP 3.0 to ASP.NET to ASP.NET 2.0? What language do you use? Do you still use IIS5, or upgrade to Windows Server 2003, or wait for Longhorn/IIS7? Do you develop with Avalon?

Developers, admittedly, often want to use cutting-edge products because it keeps the skills up, it's fun to learn, and it's a challenge. But you can't do technology for technology's sake unless you're solving a business need, and the right leadership can provide this.

That leads into the next:

3. Always taking the path of least resistance on development efforts.
Public companies, of course, have to think about the quarterly results and it is usually necessary to have tight deadlines (which is why I'm a huge fan of agile development and XP in particular – it focuses on delivering a prioritized list of features to the deadlines). A good leader can plan for this and make correct architectural decisions for the company and the team. While I strongly feel that overengineering solutions is just as bad as underengineer, the latter digs you into technical debt (the former is the land of never-deliver). So the next project (or project after that) suffers as a result of this near-sighted decision.

Seldom will you find architects or technical management always looking for the hack solution – usually decisions in these cases are driven by non-technical management. This drives developers mad, because they see the solutions they're developing as less than ideal, and can't feel proud of their work. They also have less faith in management because -- assuming their ideas are being vocalized -- they see mistakes being made.

4. Not giving responsibility or accountability.
Most developers are quite willing to accept responsibility and take ownership of features, projects, technologies, etc. In fact, having that responsibility is often a reason to get out of bed in the morning. Now, with the accountability comes authority, too: it helps make technical areas very clear and helps to foster a "pride with ownership" mentality.

But above this, I've seen cases where managers defer to their manager in making decisions (who sometimes defer to their manager). Clearly, this is appropriate in some extreme cases that affect the business or productivity, but most of the time, why? Is it not the role of the manager to manage? If developers feel that their manager is incapable of authorizing or making decisions, it undermines their authority and in turn the confidence the developers have in management and the structure of the group as a whole. If the manager has no authority to make decisions, then how can responsibilities and accountability be bestowed?

Indeed, often times managers are actually supervisors: doing the "dirty" work of day-to-day "management" of people and activities but not making any key decisions and not having any real authority. Before joining Microsoft, I worked at a small company and thought this bureaucracy would be non-existent, but it turned out to be the worst of all! So it's not always "large corporate red tape" that causes this, which is often a complaint of people working in large companies.

5. Act as if developers owe loyalty and should be thankful for having a job.
Trust and respect is earned, not bestowed. And so is loyalty. There's a few of my old managers I would do almost anything for (I think many of them read this blog at least from time to time, so I won't embarrass you by name). They earned my loyalty through their commitment to me, and they have my respect and loyalty – even now, in some cases years later.

If a company (well, management, anyways) thinks loyalty is owed, odds are they aren't doing anything to earn it to begin with.

As for being thankful for having a job: employment is a mutual commitment. It's not as simple as: "we pay you, you work for us." (See "pluggable units" below.) Especially for mid-level or senior developers, often the developer expects at least as much from the company as the company expects from the developer – and it goes beyond the paycheck.

While it's certainly true the job market will ebb and flow, hopefully a candidate will always seek the right company, and companies will only seek the right candidate, regardless of the market conditions. The best situation is when employees feel fortunate for working for a certain company, and the company in turn feels lucky to have the candidate.

6. Have strong recruitment, but little (or no) investment on retention.
Here's a hint: calculate the yearly and 5-year turnover rate. If the company's yearly turnover rate is less than 15%, congrats! That's pretty good, statistically (around 14% per year, on average, depending on the source). If it's around 20%, that's getting kind of high – that's like losing one out of 5 developers every year. Since it takes months to replace an individual, and months to get a new candidate productive, this is horrific. Worse yet, I've seen the turnover rate go much higher (in the 70% range!).

If recruitment is spending a significant amount of time filling non-growth positions, there's a retention problem. Turnover is expensive – productivity takes a huge hit, and the sheer cost of bringing in new candidates is very high. If the company is located in a remote location and frequently needs to fly in and relocate individuals, the cost goes even higher.

And, it's not always financial incentives that keep people. In fact, most people surveyed aren't looking for more money … they're looking for other kinds of rewards. Full time employees assume they'll have access to training resources, and hopefully have the opportunity to explore their career and take advantage of opportunities within the company. They're looking for recognition – any company should have clear ways to acknowledge a job well done. Morale represents the general health of the team – and it's critical for management to recognize and handle morale issues.

7. Employ pluggable units with no focus on employee development, career advancement, or structure.
Often this yields too many chiefs, not enough Indians – or vice-versa. If a company isn't committed to having a formalized structure of roles, responsibilities, and career paths (assuming the team has more 4 or 5 people) then maybe outsourcing the development to another company is the right solution, or simply hiring a handful of consultants is the right solution.

Very rarely will you see developers who have no career aspirations and are content just heads down coding all the time; often, people are extremely skilled and looking to lead, or lack experience and hoping to learn. The environment needs to support that – if it doesn't, companies should make that crystal clear before hiring.

8. Lie or over-exaggerate when recruiting.
It's not uncommon for some individuals to exaggerate a little on their resume. Any technical interview should be able to find that out straight away based on a few questions. (If the exaggeration is flagrant enough, it usually enough to dismiss the candidate from consideration altogether.)

But let's not forget that developers are often interviewing the company, too. I've experienced the good, bad, and neutral sides of this in my own career. It's not uncommon for candidates (assuming they are far enough along in the process) to ask about bonuses, average pay increases, and how to move up the corporate ladder or seek other opportunities in the organization.

What makes this so nebulous is that it's an intangible based on a future possibility. Perhaps you expected a 4-6% salary increase but only got a 1% increase – with no reasonable explanation (review was good, sales were good, etc.).

I had a positive experience when interviewing last year for another opportunity (not Microsoft). The hiring manager was very upfront about salary increases and bonuses; it wasn't a pretty picture, but at least I knew that upfront. I appreciated the honesty.

In the end, if a company needs to lie or exaggerate to bring good people on board, it's a dirty tactic they often can get away with but it will burn them in the long run.

9. Limit or block employee movement.
I've said it before, and I'll say it again: Microsoft does an amazing job at encouraging internal movement. I've had frank conversations with my managers about other teams, I've met and had "informals" (informal interviews) with other teams – it's fantastic. The bottom line: Microsoft gets that finding a good fit is difficult, and even then only temporary as employees grow, and the environment changes.

While not every company has 7,000 developers to create such an environment, about the worst thing a company can do is stifle this movement. Companies should encourage it. It's a win-win situation – the company retains business knowledge and a good hire (presumably), while the employee is happy with the move.

While you'd think this is contrived, I've seen this now in two organizations. In one case, turnover was so high they needed to block movement to stabilize the team – wonderful logic there: a sure way to encourage people to exit; and in the other, the logic was, "if we move the candidate over, we need to train and get that individual up to speed in the new job, and then we still have to hire a replacement for the old position. It's more expensive than if we just hired outside for the position." Again, faulty logic that will, in the long run, just get the company burned.

10. Not hiring the right people to begin with.
Companies can often make bad hiring decisions; and it's not always their fault. Despite great interview processes, sometimes the wrong person still gets through the cracks.

Often, though, it is the company's fault. Especially when good candidates are hard to find (such as now), a company will often settle for less than ideal. Sometimes, there are flaws in the hiring process (such as the wrong people doing the interviews or lack of depth in the interview process).

Even in the hardest of market conditions in finding qualified people, good candidates are out there. Sometimes the job isn't in a location the candidate is willing to work, but often there's just not enough of an incentive.

The bottom line is, if a company is willing to settle when making hiring decisions, they're taking a gamble and it's likely to cause problems down the road and it's not fair to the company or the candidate. If a company isn't attracting the right people, I can assure you there's a reason (or reasons): location, incentive, reputation, and job requirements/responsibilities to name a few.

11. Poor communication.
Communication needs to be timely and clear. As I learned in a communications seminar, what people do not know gets filled in with worst-case scenarios.

There's plenty of scenarios where communication, unfortunately, must be "blacked-out." For example, perhaps a candidate didn't receive a job offer and would like detailed feedback on why, to improve themselves. While I personally would love to provide that feedback, and while a candidate may very well grow and be better prepared next time, there are legal issues preventing it and too many things can go wrong. Similarly, it's common place to not explain to other employees why individuals were let go.

There's plenty of room for clear and precise communication. How many times have priorities not been communicated (or there have been multiple #1 priorities)? Have you discussed your career with your manager in the past week or two? Did you have an employee orientation, or just expected to "start working"? Do you know where to go to get questions answered? Is there clear methods of knowledge transfer on the team (design meetings, code reviews, etc.)?

Often times, an intent or idea is positive, but the communication is botched. I recently blogged about Jim Allchin's i-Mate "fiasco" (a bit exaggerated) at PDC. The device was offered at an amazing price -- fantastic move, well appreciated for some, and his heart was in the right place. But because of the way this was communicated and implemented, it left some people angered and upset -- and this could've been avoided.

Communication breakdown can and will lead to poor morale and ultimately, poor solutions. 1:1 meetings with management are often weekly at Microsoft, as well as skip-level meetings on a less frequent basis. This is crucial to aligning viewpoints and perspectives. Microsoft also fosters mentorship -- a great way to get career guidance and peer into the lives of another team.

One effective way to communicate is to say what you mean, and mean what you say. It's okay for priorities to change -- most developers expect that.
Comments are closed

My Apps

Dark Skies Astrophotography Journal Vol 1 Explore The Moon
Mars Explorer Moons of Jupiter Messier Object Explorer
Brew Finder Earthquake Explorer Venus Explorer  

My Worldmap

Month List