Posts

This post is the first in a series as discussed here: Developer Happiness at OSU

Most times here at OSU, being in a team is like being born; you don’t get to choose your family. Having said that, let’s talk in bullet points about development teams at OSU.

• Managers are the ones who are most responsible for their team’s composition. Firing is a non-option, so let us talk about the process you have the most control over: hiring. How do I make this absolutely clear? Hire well and hire the people who can work well with your existing team. Our team’s philosophy has been “Hire for mindset, not for skillset.” We define mindset as having an open and honest attitude, questioning-to-understand (as opposed to questioning to demean,) and always, always, always willing to learn. Warning signs are there in almost every interview; make sure that some members of your team (if not all of them) are along in the interview.
• Hiring for longevity: I have been in hiring committees at OSU where the committee members were leery of hiring someone (who would have been great for the team) because “they won’t stay long at this job.” Well, personally I might be more interested in people who have an ambitious mindset and are entrepreneurial in their outlook. If they do jump for a more interesting opportunity (as opposed to OSU driving them away,) at least we had them for the time we did. Sustainability of an app or piece of software should not be related to the longevity of the people that work on it.
• How about developers who are a team of one?: I worked in a position like this for a number of years at OSU. The main takeaway I had from my experience is this: You might be the only developer, but you are still part of a team that should necessarily exist. That team is the person that you report to, the people that bring work to you (business analysts, researchers, etc.) and the people that host/support the software that you have developed. Every person interacts differently with the members of this “team,” so I can’t presume to tell you how to change. However, the realization that a team still exists was one that changed my sullen woe-is-me-I-am-alone attitude to one of hey-I-can-talk-to-these-people.
• Teams that are just so, and there seems to be no relief on the horizon: You know these teams.
  • The vibe is all messed up.
  • It seems like everyone hates their jobs (not necessarily hating everyone else.)
  • The intertubes from everyone’s laptops are jammed with resumes flying to job applications at other places.
  • The manager rules the team with an iron fist of authority.
  • Legacy applications (what we call toxic assets) are overflowing from the portfolio.
  • People are overruling the prioritization process to get in their own pet development projects.
  • Development seems like an afterthought in the overall IT structure.
• Oof, I am getting the hives just writing all of the above. What does one do in such situations?   The developers will probably follow some variation of exit or voice [1] (sometimes both.) But it is the manager of the team who has the most latitude to do anything, so this is directed to the manager: You may think that there is not much you can do about the portfolio or the fact that your team seems like the step-child of IT upper management. But you cannot make excuses that no ideas exist. There are literally books written on the subject about how you can make life for your team better. Do your homework and see where you can make difference, however small.
• Side rant: What is up with OSU developers reinventing the wheel? Who decides that rewriting your own database connection libraries in PHP is a fine way to pass time? We have encountered applications where budding geniuses decided to toss aside (or were plain ignorant of) years of open-source, time-tested libraries to connect to MySQL, in order to roll their own. Have fun supporting that after said genius leaves!
• Shenanigans: Well, allow them, I suppose. 8 hours of productive work per day is an unsustainable target; make sure it is appropriately interspersed with whatever the heck the team wants to do.

1. Exit, Voice and Loyalty is an awesome book written by Albert Hirschmann. Here is a post about him and his life’s work: Exit, Voice and Albert O Hirschmann.