Entries Tagged 'Managing Software Developers' ↓

The Fallacy of Management

In case you missed Gates VP’s comment about The Fallacy of Management on my recent post Q & A on Leaving Management for Development, I’ve re-printed it below:


I have a working theory that I’ve titled The Fallacy of Management.

The basic definition is that current managers would have us believe that the work they do is the very reason for project success and therefore they believe (and have convinced others) that their’s is the most important role.

The real truth is that most managers are just overhead, projects would likely self-assemble without them, especially with good devs on the job. However, companies do things like targeting management for bonuses and taking other steps to make management a “position of privilege.” The truth is, good managers don’t deliver projects on time, good programmers deliver projects on time and managers just guide the process.

Continue reading →

Q & A on Leaving Management for Development

I’ve received several emails about my post Why Good Developers are Promoted Into Unhappiness. One reader asked some interesting questions on his quest to decide between development and management.

Here are some excerpts from our conversation:

Q: Does leaving management for coding greatly cut your salary?
Going back to coding may cut your salary, but it’s quite possible it will not. In my case, the first time I went from management to coding I was fortunate enough to move into a higher paying development position. The second time I didn’t receive additional money for my “promotion” into running a development team, so going back required no monetary sacrifice.

Continue reading →

A Conversation with Joel Spolsky

I relocated from Los Angeles to Connecticut a few months ago, and a few of my geekier friends joked that I had to meet Joel Spolsky and Paul Graham before I came back to California.

Joel is in the midst of his 21-city FogBugz World Tour and one of his first stops was in New York City, where I saw him demo FogBugz 6.0 two weeks ago. In fact, in the picture at the top of Joel’s post about the session, you can barely see my head peeping out over the guy with the black shirt and white stripes on the left side. Those stinking paparazzi never leave me alone.

FogBugz 6.0
The demo went well; it wasn’t spectacular, but it was a good 40-minute overview of FogBugz’s main components: a wiki, forums, bug tracking, and scheduling. But it didn’t need a big flashy presentation – the application itself is seriously impressive.

Continue reading →

New Article: Computer Science Enrollment is Going Down, and Taking Software Jobs With It

From my new article Computer Science Enrollment is Going Down, and Taking Software Jobs With It:

“How many of us would kill to work with ultra-qualified, talented developers instead of whoever we can find that has a pulse and once wrote an Excel macro for a junior high class project? If Computer Science enrollment continues to drop people will eventually get hired, with or without degrees and regardless of how qualified they are, because companies will be desperate. And then we’ll be stuck working with folks who can’t find their text editor with two hands and an issue of Dr. Dobb’s Journal.”

Read the complete article here.

Why Good Developers are Promoted into Unhappiness

I once thought I had traveled a unique career path. Graduating from college with a degree in computer engineering and electrical engineering I was on fire to be a manager. My dad had worked for the same electrical contractor for 30-something years and I knew everyone from the Chairman of the Board down to the woman who worked the front desk. I had a major “in” and was quickly shuffled into a management training program, with my sights set on one day becoming CEO of the $600 million firm.

18 months later I left for a job writing software for a dot com in Sacramento, and within 3 months I was running multiple project teams (albeit, small ones). I was young, it was fast paced, and I loved it.

When that company experienced difficult times in 2001, I transitioned into contracting, which I did for about three years before taking a position as the Application Development and Database Supervisor at the City of Pasadena, directly responsible for the management and supervision of 10 developers and DBAs. The prestige? High. The paycheck? Fat. The job? Hated it.

Continue reading →

How to Attract Software Developers That Fit Your Company

I’ve worked for startups and stalwarts, small shops and large corporations, firms where software is the means to an end, and firms where it was an end in itself. After years of exploring what I love about building software I’ve realized that coding for a 17-person dot com is a far cry from building enterprise software for a 300-person credit card company. It only took me eight years to figure out why.

There are a myriad of articles on interviewing, evaluating, and hiring software developers, but a topic that’s rarely discussed is how to attract software developers that fit your company’s environment. With the current state of the software job market, it’s critical as a hirer that you determine not only what type of developers will be happy in your environment (your “developer demographic”), but how you can become more attractive to that particular slice of the market.

Your Developer Demographic
As an example, IndyMac and Countrywide are large financial institutions with development offices in Los Angeles. They attract people looking for stable jobs with good benefits where they can code 9 to 5 and then go home and not think about it from 5 to 9. I envy people who do not grow bored with this environment; I really do. Life would be much, much simpler if I could handle it.

There are also tech startups that attract caffeine-junkies. Long hours with potentially large reward, and the prospect of building something really cool in a short amount of time that could make a difference in peoples’ lives. Or, more likely, be relegated to the failed startup scrap heap. These companies should be looking for people who love using new technology, are typically younger, willing to take risks, and willing to shoot from the hip.

These may be extreme cases, but they illustrate the point: certain attitudes and personality traits play nicely with certain environments. Often, a developer who thrives in one environment will find that she slowly withers away in others.

The Three Dimensions
To get more specific, there are three dimensions to a company that most affect the internal environment for a software developer. It’s critical that you know which of these your company falls into, and not only market to, but ensure you can retain developers who fit that demographic. The descriptions of the software developers who like to work at each corporate classification are generalized, but they serve as a guide to get you thinking about the personality of your ideal candidate.

Your company may not match exactly with one of the choices below each dimension, but do your best to categorize it. Many companies start off as one thing and transition to something very different in the first year or two.


  1. Size
    • Small – Some small companies are startups, and some are 10-year old, profitable, mature businesses that make money hand over fist with 9 employees. Software developers who like small companies are typically social, they like the vibe of knowing everyone, going to lunch with the same people, and knowing that they contribute a great deal to the success or failure of the enterprise.
    • Large – The bulk of corporate development is for larger companies. They tend to have big teams, lots of process, and decent-sized QA and Change Management teams. Software developers who like large companies tend to enjoy more process, like working on larger teams where they can either lead or be led, and enjoy the possibility for growth that comes with a large organization.
  2. Chaos Level
    • Stable – Stable companies tend to be, um…stable. They have good benefits, and employees can often get away with working 8 or 9 hour days. Developers who prefer stable companies are likely a little further along in their career, may have a family, like the consistency of coming in to the same office each day, and enjoy their time out of the office when they don’t have to think about software.
    • Startup – Startups tend to be more risky with the possibility of more reward. The salary may not be as high as that of a stable company, but the stock options will be worth six-figures if you can get your bleeding-edge online calendar out the door before Google’s. Benefits tend to be spotty. The hours are long, but it’s more than worth it for developers who are passionate about technology (read: bring books about ASP.NET to the beach), love building software that matters, and enjoy the camaraderie of working on a team of people who share their interests.
  3. Focus
    • Software (or a technology that relies on software) – These companies rely on software for their main source of revenue, whether they sell it (Microsoft, Intuit), give it away (Google, Craigslist), or offer it on some type of “pay to play” basis (eBay, salesforce.com). Technology firms that rely on software are companies like Palm, Apple, or the guys who make the fingerprint readers I keep seeing at data centers. Software may not be their main source of income, but they are technology companies and software is critical to their product. Software developers who prefer these types of companies enjoy being around other software people; they like the idea that technology is at the core of their company, and they love that they work on real products that people use. In addition, they relish the fact that software firms tend to live towards the cutting edge and are able to constantly upgrade their skills to the latest and greatest.
    • Everything Else – These companies make up the majority of companies in the world; their main source of revenue is something other than software – credit cards, lawn furniture – you name it. “Everything else” companies use software to support their business: to track widgets, support their call center, and balance their books. The majority of corporate software jobs are working for companies under this umbrella. Software developers who enjoy this type of company like building applications to support accounting, management, and the people who produce or sell the company’s main product, and they are either very content to know they can go home at night and not think about developing software, or they go home at night and all they think about is they day they can leave the company and work for someone like Google.

Your Company, Your Developer Demographic, Your Job Description
Before writing your job description think hard about where you fall in each of the dimensions. Then think twice as hard about the kind of developer who will be happy at your company. Don’t kid yourself; you can convince the 24 year-old tech hot-shot to work for your financial services company by offering him a huge salary, but he’ll be gone in 9 months because you’re using three-year old technology and developing boring (from his perspective), back-office software.

Once you’ve determined who will be happy at your company, write your job description with that person in mind.

You’re a large company with great benefits? Spell it out in bullet points: plain, simple, and official. Play up your stability.

You’re a small startup with no benefits? Use a casual tone and create excitement. Make that 24-year old hot-shot be dying to work for you.

Even if he has to pay for his own health care

Deadlines: On Being a Professional Software Developer

When I was in college I was a professional comic book writer. After numerous submissions I had several stories accepted by three independent comic book companies, all slated for publication.

I even received a $100 advance for one of the stories, with all of them paying royalties on the “back end,” meaning I’d probably wind up making $100 per story if I was lucky. And back then $100 was a lot of…no, let’s face it, even back then $100 was nothing. But I could call myself a professional comic book writer.

On Being a Professional
Which is a joke, of course, because I wasn’t a professional. I was writing in a tiny bedroom, typically from 10 at night until 2 in the morning, cranking out a short script every week or two. Sure, I had honed my skills as a writer enough to match the myriad of others trying to make it, but I was not a professional writer. And I’ve had a hard time puting my finger on what it was that distinguished me from those whom I considered “legitimate” comic book writers. It wasn’t the fact that I worked out of a small apartment. Or that I wrote at night.

It was the fact that I didn’t consistently deliver under the pressure of deadlines.

I’m sure I’ll receive a few comments saying that a professional is someone who gets paid for what they do, or someone who does something as their main source of income, or someone who’s easy to work with, or someone who comments their code. Those are some of the components of being a professional, but one of the most important and often overlooked pieces of being a professional is consistently delivering a usable product in the face of deadlines.

How Many Deadlines Must a Man Walk Down…
I knew at least two guys who were amazing comic book artists. Both drew as well as the books on the shelves, but neither could draw an entire 22-page comic in a month…and that’s what it takes to be a professional in that game.

I’m not saying if you miss a deadline you’re suddenly an amateur – the continuum is much less binary than it is fuzzy. But during your career, your present job, or the past 6 months, how many deadlines have you hit? How many have you missed?

There are going to be extenuating circumstances. There are going to be times when a third party vendor flops and the project falls apart at the last minute. And there are going to be times when the deadline is set externally and you know from the outset you’ll never hit it. But if you find that there’s always a reason you aren’t hitting deadlines you have to start asking yourself: Is it you?

I know that somewhere between 55 and 90 percent of software projects fail. Missing deadlines is easy; I could get my mom, who knows nothing about software development, to come in and miss project deadlines. Does the fact that she showed up and collected a check make her a professional developer? She’s easy to work with and comments her code.

So here is my question: during your career, your present job, or the past 6 months, how many deadlines have you hit and how many have you missed?

This isn’t a show of hands, just a gut check.

[My Reply] You Be the Manager: A Case Study of Unmotivated Developers

On Tuesday I posted a You Be The Manager scenario about a real group of unmotivated software developers. My reply to the original author was sent several weeks ago, and in retrospect I wish I had included some of the creative thinking many of you offered in the comments. If you haven’t read them I suggest you do; there are some exceptional insights into how to improve (or abandon) the situation.

I took a straight-on approach and offered suggestions for determining why these software developers are unmotivated, and how to start returning motivation to their dismal existence (I say dismal because spending 5 years on an ERP project sounds like the worst thing since hitting yourself in the head with a hammer).

If you’ve been a reader for any length of time you know I don’t condone working overtime as a general practice, but I’ve found that a couple times a year it’s necessary to work extra hours to hit a crucial deadline, and this is the approach I took in my response: that this project is in the final stretch and needs one last “push” for completion.

Here were the thoughts I offered the consultant faced with the scenario of the unmotivated software developers:

“No one wants to fail. If the developers sensed the project would not be completed on time they may have begun to mentally distance themselves from it. Even if they supplied the deadline, did they really believe they would hit it, or did they just spit out a date because they were forced to?

  • If they believed in the deadline at the beginning and started feeling behind, it surprises me that at least one of them did not start working extra hours. If this is the case, the the company/department might be an “8 to 5” culture. My immediate thought is that there are 1 or 2 leaders who set that pace and, if they were not present, the others may be willing to work extra hours to hit that deadline (assuming it was reasonable in the first place).
  • If they never believed the deadline, that’s a major problem. Why would they supply a deadline where they had no buy in? This rings of a lack of faith in their management, or their team’s ability to actually complete the work. After 5 years a lack of faith is not surprising, and it’s not out of the question that they simply made up a deadline to satisfy you.
  • If they feel like they aren’t able to move forward because of political or “people” issues, someone has to clear them out of the way, and fast.
  • Does the project sponsor have the respect of the developers? At a company I used to work for the CEO would stop in on a meeting every once in a while during a hard project, and explain why the project was so important to the success of the company. Having a high-level manager who the team respects stop by shows the team that this project has major visibility, and that failure will be noticed. Now, I am vehemently against motivating people through the promise of punishment, but if the team has no accountability and seems to be running on their own schedule then it’s quite possible they could use a little something to get them back on track. BTW – if there is no project sponsor that’s a major red flag and unmotivated developers are the least of your worries.”

You Be the Manager: A Case Study of Unmotivated Developers

An SbR reader contacted me looking for guidance on how to work with a group of un-motivated developers; his email is below (posted with permission).

I will post my reply next Monday, after giving you a chance to weigh in on the situation.

Q: “In the course of providing Change Management consulting services to an owner operated company, I got involved in trying to find out what was happening in their IT department (4 Software Engineers). They are all on salary with full benefits.

The IT Departments absolute priority is to insure the company’s current software and network system is operational. In general the current company system only requires minimal daily maintenance with periodic planned upgrades. Accordingly the Software Developers are able to focus the majority of their time on development of a new ERP software system.

They have been at the project for approximately 5 years. Design is complete and development is underway. After much discussion and prodding I managed to get them to produce a timeline to deployment versus completion. Deployment defined as being able to switch from using the current system to the new system with a minimum of equal functionality to the current system. The timeline is to a specific date versus effort in months. They arrived at the deployment via sophisticated process versus an educated guess so I believe it is realistic.

In my view stakeholders must have a deployment date and developers need a realistic deadline. We have our deployment date (set by the developers, not stakeholders) but I suspect they are not committed to it. They start at 8:00 am on the dot and are out the door at 5:00 pm. Lunch and coffee breaks are never missed. My concern is that they have been spoiled by not previously having a definitive deployment date so it is expected to balk at accountability.

My instinct is to shut the project down but I also do not like to give up.

[I’m looking for] direction on how to motivate this group to want to take ownership and to rise to the challenge of meeting the deployment date.”

If you were in his shoes, how would you handle this situation?

A Survey to Determine if Your Developers Are Happy

After publishing Nine Things Developers Want More Than Money late last year, I received several requests for something that could provide more specific information than the 1-9 score on Rob’s Criteria for Keeping Your Developers Happy. In other words, managers want to know which of the nine areas to focus on, and most who wrote suggested I create a survey they could give anonymously to their developers.

In response, I’ve created a 29-question survey that covers all nine of Rob’s Criteria. I built it in HTML so you can print it out and distribute paper copies, or write code to place the responses in a database for easier analysis. If you wind up using a database I’d appreciate if you would send me a copy of your code so I can post it here.

The survey does not have a norm since it has not been administered to anyone. As a result, determining the results will be up to your interpretation. Hopefully that’s not too difficult given the nature of the questions.

If you have other questions you’d like included, or stories to share about survey results, please post them in the comments.