The psychology of software

Organizational development—or OD for those who insist on acronyms—is a branch of psychology that studies how individuals interact within an organization and how to improve the organization's performance. Software development depends on individuals working effectively within an organization. Whether it's a small team or a large government information technology shop, the way individuals interact has a lot to do with whether the organization succeeds in its mission.

I first encountered OD many years ago, when the consulting shop I worked for conducted surveys of employee attitudes and job satisfaction. These studies often revealed why organizations seemed to be dysfunctional in certain ways and helped workers better understand one another's styles and work more effectively as a team.

I've recently been asked by a medium-sized organization to help implement a software development process. The effort will be based in large part on QuickStep, a software development methodology that I developed during the past 10 years. It seems to be a good fit, both with this organization's current practices and with its philosophy of software development.

But even when these circumstances exist, there's no guarantee that a new process grafted on from the outside will take root and flourish. A good process can fail if the organizational culture doesn't allow key practices to be performed.

For example, most development methodologies require various kinds of reviews. In a design review, a lot of emphasis may be placed on the materials that must be prepared for the participants, the process by which participants are selected and the manner in which the results are recorded.

Yet, the problem of how to actually get people to participate is often overlooked. If your staff is afraid to speak up, how can you have a meaningful review? Despite lip service that "frank input is encouraged," too often differing views are oppressed and a culture of enforcement reigns. How many times have you seen programmers trudging along, implementing a flawed design because they know it isn't safe to say the Emperor of Design has no clothes?

If you can't get authorization for an actual OD intervention, consider sponsoring interventions of your own. Ask a programmer to lunch, and see if he or she wants to talk about unacknowledged problems. Stay late to help with testing, and see what you can pick up about the health of the project.

Finally, ask yourself: "Who's complaining?" If the poor performers are complaining, perhaps they're being given tough performance standards—and that might not be a bad thing. On the other hand, if your star performers are grousing or even resigning, that should probably tell you something.

Bragg is an independent consultant and systems architect with extensive experience in the federal market. He welcomes your questions and topic suggestions at [email protected].


  • People
    2021 Federal 100 Awards

    Announcing the 2021 Federal 100 Award winners

    Meet the women and men being honored for their exceptional contributions to federal IT.

  • Comment
    Diverse Workforce (Image: Shutterstock)

    Who cares if you wear a hoodie or a suit? It’s the mission that matters most

    Responding to Steve Kelman's recent blog post, Alan Thomas shares the inside story on 18F's evolution.

Stay Connected