Martin Fowler has a good post explaining Technical Debt:

“You have a piece of functionality that you need to add to your system. You see two ways to do it, one is quick to do but is messy - you are sure that it will make further changes harder in the future. The other results in a cleaner design, but will take longer to put in place. … In this metaphor, doing things the quick and dirty way sets us up with a technical debt, which is similar to a financial debt. Like a financial debt, the technical debt incurs interest payments, which come in the form of the extra effort that we have to do in future development because of the quick and dirty design choice. We can choose to continue paying the interest, or we can pay down the principal by refactoring the quick and dirty design into the better design. Although it costs to pay down the principal, we gain by reduced interest payments in the future.”

Before you can put together any plan for managing your tech debt, you have to know where it exists.  Personally, I think Sonar is a great tool for this.  Out of the box, it will use industry standard tools to find trouble spots using static analysis (like FxCop), unit test coverage, cyclomatic complexity, etc.  But here where there's real power in this tool: it also lets users mark sections of code as problematic or in need of refactoring. It has tools for grouping problematic sections into action plans and for assigning responsibility to developers (and for developers to manage the items assigned to them).  And, it's free, and pretty easy to integrate into your existing continuous build process.

But knowing is not enough. You need to have a plan for addressing the tech debt.  There are two general groups to plan for: small, one-off items and large, architectural changes.  For the big stuff, this needs to be in your product backlog/roadmap, as changing it represents a re-architecture of the system. So have an agreement between the product owners and the developers to allocate some amount of time in each release cycle to make under-the-hood changes like this.  It's not likely something you can sell as a feature to a customer, but neither is paying down your mortgage.  It's something you do to keep your codebase maintainable over time.

For the smaller stuff, you can address it as backlog items as well, or set aside dedicated time specifically to address these.  At CSG, our releases were typically broken down into five iterations: three "development" iterations and two "hardening" iterations.  During the dev iterations, we were focused on new functionality, but the hardening iterations were primarily QA focused, so dev work was sporadic, mostly bug fixes and usability enhancements falling out of the QA efforts.  We used the spare dev cycles to address these less risky tech debt items - with the de facto tasks being filling gaps in unit tests.

At InRule, one Friday a month is set aside as "Tech Debt Paydown day", where developers pull items from the tech debt backlog and work as many as they can in the day.  There's no pre-allocation of tasks at the start of the iteration, just time reduction from the dev capacity.  We use a UserVoice.com site (Update: we now use a Trello board) to track the tech debt backlog, which allows developers and others in the company to vote on which items they'd like to see addressed, and developers try to work from the items with the highest number of votes.

Employment is a two-way relationship.  As an employee, I agree to spend the majority of my waking hours performing tasks on your behalf.  In return, my employer agrees to provide me with a steady paycheck and other benefits.

My employer keeps tabs on my performance with periodic performance reviews, production goals, etc.  So how does the employee keep tabs on the employer?  Make sure your living up to your end of the bargain - keep employees informed about the health of the company.  Obviously, this is much easier in smaller, privately held companies, as the logistics and legalities are greatly simplified, but there are many, many options available to you.

One very important note: while you shouldn’t focus on the negative, it’s important to be truthful and forward with news and events that have a negative impact on your business.

Burnout can be a pretty big problem in the tech industry.  You should have a plan in place for preventing burnout and for handling it once it occurs. On the prevention side, keep an eye on long periods of "crunch time".  If the norm for your project is 50hr or more work weeks, you've got a problem brewing. Limit the long hours to when they're actually needed (and if you think they're always actually needed, then you're understaffed).  When they do occur, show your staff their extra time is appreciated by ordering-in dinner, or having a launch party once it's done.  And put a concrete condition on when it ends: if that's "when X is done" then make sure you've clearly defined "done". Moving that condition by changing scope or adding conditions can kill moral.

Then, if an employee is showing signs of burnout, have a plan for how to handle that.  Consider this a part of your retention plan.  Consider changing something about their day-to-day job - maybe a different project, different work hours, maybe some time off. Just make sure you apply this fairly across employees when burnout occurs (where "fairly" can take tenure and seniority into consideration).

Just remember: employees want to hear that you have a burnout prevention plan that will keep them from hating their job.  They might not like hearing you have a plan for handling burnout when it occurs, because this implies it occurs with enough frequency that it needed a plan and no one wants to hear that burnout is a frequent occurrence at their job.  But the truth is that burnout is an issue in our industry and results in extended reduced productivity and in many cases the employee leaving, which is expensive for an employer, both in lost opportunity costs, as well as recruiting cost to backfill the position.  Plus, if your team as a whole is suffering from burnout, having one person leave can snowball, as other team members taking that as an example and following suit - resulting in a difficult to overcome cycle of fill-the-empty-seat.

The worst mistake good managers make, in my opinion, is treating each of their reportees in the same way.  As a manager, or someone in any kind of leadership position, you have to understand that everyone's different when it comes to how they like to be managed, how they communicate and and what motivates them.  There are, however, some general commonalities that can be applied based on a person's personality type.

For me, the Myers-Briggs Type Indicator (MBTI) works well for understanding peoples preference for communication, motivation, preferred work environments, etc.  If you lead people and don't know about MBTI, or one of it's peers, stop reading this article now and spend the next week learning about MBTI.  I suggest these workbooks to help:

Introduction to Type® in Organizations Introduction to Type® and Coaching

Understanding that an INTJ (that’s me) needs to think about a question before providing an answer can help keep a health relationship.  For instance, if you’re going to discuss a particular issue or technical challenge in a meeting, send out an agenda the day before with details about the issue being discussed.  This will allow the INTJ and other types to be thinking about the solution in the background and come prepared to share their thoughts in the meeting.  If you just ask those same people for their thoughts during the meeting, you’ll likely get dead air.  On the other hand, some other types will work best with off-the-cuff conversations and will likely just ignore the agenda email altogether.  Another example: always provide an INTJ a copy of their performance evaluations ahead of time to allow them to review it before having a meeting with their manager.

For motivation, there are many, many things that motivate different people, from monetary compensation to public praise to small gifts.  The things is, what motivates some will be a de-motivator for others.  For example, I react well to public praise, but only to a point. For instance, if you ask me to stand up in front of the whole company while you read off a letter of praise, I will not like that – but if you were to just read that same letter while allowing me to sit in my chair in the back of the room, it’d go much better for me. 

Along those same lines, understand that there isn't one career path that's appropriate for everyone, especially in the technical industry.  West Monroe had this figured out, on paper at least, and had three distinct career paths once you reached more senior levels (early in your career, you really don't have enough experience to differentiate on these paths):

Manager

This is your "people manager"/"project manager" position, and what most companies consider a "manager". They focus on client service delivery.

Principal

This is someone who has deep expertise in a field.  For technical teams, this is your expert DBA or subject matter expert on object relational mapping, etc.  In Microsoft land, this is your "technical evangelist" or MVP.

Architect

This is someone who has broad expertise across a large set of fields. For technical teams, this is your typical "architect" and they oversee the technical delivery of the product.

As an employer of software developers, not only should you not get in the way of people learning new things, you should encourage it.  This doesn't necessarily mean you have to pay to fly a developer to New York or Vegas for a week long convention - one easy, and cheap, way to do this is the Lunch-and-Learn:

At West Monroe Partners, we had a session once a month, where a team member spent about 45 mins  (allow 15 mins beforehand for people to grab food/dial-in) presenting some new (or old) technology, tool, business concept, etc., and the company paid for pizza or sandwiches for everyone.  This served many purposes, since this was a consultancy firm:

• kept technical staff aware of the industry
• provided a safe environment for people to work on their presentation skills
• served as a means for team members that did get the trip to a conference to share that knowledge with the rest of the team, thus giving the company more bang for their training buck

At InRule, three out of four Fridays in the month, we order-in lunch from a local deli (again, the company pays) and gather in the conference room with the projector to watch a recorded technical talk, typically from a tech conference like BUILD or ØREDEV, which post them online for free.  These are generally about an hour and the actual video is selected ahead of time by our department head from his own searching, or from proposals submitted by team member.

In all, each company spent about $10 person, and depending on the attendees personal lunch habits, lost 0 - 30mins of each person’s workday. A fairly small investment for the increase in knowledge and fellowship among team members.  Even if only one session per year resonates with an individual, the company has still come out ahead financially compared to sending the employee to even a half-day formal training session somewhere.  And in my experience, the "I learned something interesting" rate is closer to 40% per person, especially if the attendees have a say in the topics.

There are also may local and regional conferences which are free or cheap to attend and typically have great sessions.  May occur on weekends too.  In the Chicago/mid-west area, some great options include:

• Chicago Code Camp
• That Conference
• Codemash

Additionally, look for other ways for people to share insights internally.  Maybe that’s an internal blog (I haven't seen this have much traction), or a platform like Yammer, where team members can post links to sources they find useful, tips & tricks, etc.  West Monroe, CSG and InRule all used Yammer, but I found this was much more effective at the smaller companies.

As an employer of software developers, since your paying someone to think, make sure you provide a physical environment that promotes just that.  That means a quiet workspace for each developer.  I'm not saying you have to give everyone an office, but I am saying that you can't put your developers out on the floor of your trading firm and expect them to be their most productive. I know, because I did exactly that for two years, and couldn't concentrate during the day - so ended up working before the traders arrived in the morning, or after they left or late at night from home. And got burnt out, hard.

So, put your developers in an area where you don't have people on the phone all day, or talking loudly.  Don't have a wall of TVs with CNBC, ESPN, or anything else.  Limit distractions.

And developers: one of the best investments you can make if you work noisy area is a good pair of noise-cancelling headphones.

In addition to a quiet area, provide a place for team collaboration.  Often this is a mid-sized meeting room, where open (sometimes impassioned) discussions don't distract everyone else.  This area needs to have at least one very large whiteboard.  Personally, I think companies should have at least three square feet of whiteboard for every developer on their staff, located nearby.  Those floor-to-ceiling whiteboard panels are great.  Some of the most collaborative places I worked had the engineering meeting rooms setup with all four walls acting as whiteboards.  Wayport even covered the hallways with them in the engineering wing!

And lastly, give your developers comfortable chairs.  Think back to your days in school, sitting in those uncomfortable wooden desks.  Remember how hard it was to concentrate during tests after sitting in one of those desks for five hours.  Now, realize you're paying a developer several hundred dollars per day to think, and spend the $200 on a decent chair.  You'll recoup that money in a week, I'm sure.

Being able to bounce ideas off other team members, ask for help with a problem that's over your head without repercussion, and having open relationships between all developer groups and the business/customers.  These are all important.

When you hire a software developer, you’re paying someone to think and convert those thoughts into code.  It's really easy to box yourself mentally, restricting your ability to find optimal solutions to the challenge at hand.  So having an environment where people feel comfortable talking to each other about their plan of attack and "thinking out loud" about the problem goes a long way.  But this means developers must feel like they won't be punished for spending time talking to other developers about tasks beyond their own.  Personally, I found the easiest way to squash this collaboration is to over schedule the dev team, so that everyone feels like they have no extra time for anything - a behavior we'll talk about again, because it is good at negating several items on this list.

Beyond individuals in a team collaborating, dev teams should be able to talk to each other.  For smaller companies, this isn't as much of an issue, but for the much larger employers, the us vs. them mentality between development teams seems to be rampant.  I'm not sure how this happens in the growth of a company, but I suspect it comes down to management comparing the productivity of the groups and pitting them against each other by awarding budgets to better preforming groups (ie: raises, equipment, etc). So in the same way you wouldn't share the internals of your code with a competing company, dev groups start to become islands within the same company. This is even worse if they report under different management structures. (CIO vs CTO, etc)

And then, make sure developers have access to the people setting the system requirements, whether that be a product owner, marketing, or an end customer.  If I'm developing some code based on a set of requirements and have questions about the intent of the feature, or would like to propose an alternative solution, I should have direct and timely (within a couple hours and no more than a day) access to the person who can give me insight into the intention, or pitch my proposed alternative.  This needs to be someone with the authority to make decisions about the product.  In other words, if we agree something should be done differently than the initial requirements laid out, this person should have the authority to say "make it so" and I can go merrily on my way.  There are places where I've had this discussion, determined that a (sometime only minor) changes is in order, then been told "ok, stop all development on this while I get approval for the change.  That will take four weeks." Or worse: "implement the current requirements and we'll come back and change it once we get approvals". Waste of my time, and your money - a lot of your money.

Instant messaging is a must these days for communicating between these individuals.  At West Monroe and CSG we used Microsoft's platform (now called Lync), which integrated nicely with Exchange and Outlook so conversations could start with a IM session and transition to email, or vice versa, as well as kickoff a screen sharing session from your chat window.  At Wayport we hosted our own Jabber service (since most people ran Linux workstations) and at InRule and Incapital we used MSN/Yahoo/AIM.  Personally, I use the Trillian client, which support all of the open IM networks, and find I use it to chat with people in my larger professional network too.

In addition to IM, I’ve had mixed success with Yammer at a couple of places. I find it works better at smaller companies where people actually know each other, than at the bigger places, but this may still work if you align yammer groups with local workgroups, etc.  With Microsoft’s recent acquisition of Yammer, this may become integrated into Lync and/or Sharepoint in the future.

I've now hit that point in my career as a software developer where I have enough experience under my belt to be able to make informed commentary, but more importantly, to have a better idea of what type of work environments work well for me.  In my 12 or so years getting paid to play with computers, I've had the opportunity to observe, from the inside, an unprofitable dot-com startup turned mid-sized profit machine, an international fast food behemoth, a mega-corp tech service provider, a smaller consultancy firm, and a small ISV. I played a different role at each, learning as much about myself and about how other people work as I learned about technology.  I've been in a Linux shop and a .Net shop. I've been the youngest person on my team and the oldest. I've worked with people smarter than me, and people who really shouldn't be writing software.

This all came into focus in the last year, as I decided to leave my then employer after only a year.  I did some real soul searching to figure out what I really wanted in a job in order to find an employer I would want to stay at for years to come. (hint: salary was not my top motivators).  This was put even further into the foreground as I was asked by a couple of people I knew to mentor them on their own career paths and job changes - and for as much as I'm concerned about screwing up my own life, I'm mortified by the idea that I could screw up someone else's career, so I took this very seriously.

So based on all of this mulling around in my head for a while, I've decided to jot down some of my thoughts on what makes a good environment for a software development team.  There are plenty of people bitching about what makes a bad environment, but I wanted to put forward what I've seen work well (with a few things that didn't).

So, here we go...  Below are my thoughts on what an employer can do to provide an effective, productive and attractive work environment for highly effective software development teams:

• Foster an Environment of Collaboration
• Provide an Environment for Thinking
• Encourage Continued Learning
• Understand that People are Motivated Differently
• Burnout Prevention
• Communicate Openly About Company Health
• Have a Plan for Paying Back Technical Debt