I recently decided to change jobs. For many other people in software development, this is a more frequent occurrence than it has been for me. It was my fourth job in 20+ years (man, have I been working that long?). It’s my third in my my software career. Change can be good… and bad.

I started this blog as things were winding down at my old job. The period of time immediately following turning in the resignation letter brings highly mixed feelings.

Leaving one job...

The job I left was a middle management/senior tech lead position. There were great things about the job. The overall quality of the people I worked with there was top notch, with a few exceptions. I truly enjoyed working with a highly talented and capable team of engineers. During the 2 1/2 years working there, I learned a great deal. My position provided a great deal of autonomy working on interesting projects the way I felt they needed to be worked on. I was free to try out new technologies, new ways of approaching software development, and new approaches to scalable web applications.

Of course, you don’t make a decision to leave a job without reasons. The company is a large corporation with an IT department of around 1200 people. I have a number of observations about working in this large an organization, but I plan to write about them later. Suffice it to say, everything is a big thing and big things move slow. This drove me nuts. I, in turn, drove those around me nuts, so it was time to bring some balance back to my life and move on.

I turned in my resignation. I felt bad about leaving my teammates and those I reported to holding the bag. These guys were great to work with. While I feel I accomplished a ton while there, I still left them with a pile of unfinished work they would have to deal with in a slow, agonizing way. But… I was relieved I no longer had to deal with it. It liberated me.

My notice period quickly ran out. I started my new job. It’s been 3 weeks.

Starting another...

My new company is vastly different. The whole company has 20 people. They grew their technology quickly and somewhat haphazardly. Everyone there wants to fix this and it’s part of the reason I was hired. This has to be balanced with the culture developed while creating the technology. When the CEO or one of the salesmen want something in order to sign a client or increase cash flow, it gets built in.

My previous position focused solely on software development. There were other departments responsible for support, network infrastructure, server hosting, etc. The technology arm of my company, 8 of the 20 people, report to me and fill those roles. Now I have more things to worry about.

In 2 1/2 years, you get comfortable with people, processes, routines, business domains, just about everything. When you are the new guy, you know none of this. When you are the new guy and the one with leadership responsibility, you need to learn all of this fast. I spent the past 3 weeks trying to get my head around all these things and more.

A small company has a much different pace than a large corporation. Regardless the role you fill, you are much closer to the pressures of running the business. The people at my new job feel this pressure and have worked for a long time under the gun. Just the other day, one of these guys asked if I regretted my decision. My answer was, “I do not. I prefer a huge amount of work coupled with the pressure to get it done yesterday to a huge amount of work coupled with the apathy to slow moving projects of the larger organization.”

How did I ever accomplish anything without some of my tools?

I went into this opportunity with eyes wide open. I knew I would encounter challenges when I got there. For one thing, the large corporation provides an almost unlimited budget. The small company does not. In my last job, we had a number of things important to running an organization. I need to introduce and set these things up.

• Source control -- Over the course of my career, I have worked at one other small company. They did not have source control. That’s no different here. Frankly, it’s difficult for me to understand with all the benefits of source control. As Jeff Atwood says, "source control is the very bedrock of software development". I need to get this setup.
• Open collaboration tools (Wiki) -- Email is evil. Email is the primary source of collaboration in my new company. This needs to change. I need a living breathing place to document a number of things where everyone in the organization has access. Projects, priority lists, step-by-step instructions for repetitive, unautomatable tasks, etc, etc.
• Issue Management -- Issue management intake processes, especially in an environment where information comes fast, need a repository for capturing issues and managing priorities. There is a home-grown issue management tool in the new company. If I want to change the piece of software, I need to give up valuable software engineering resources to accomplish it. Why keep that up when there is a plethora of tools out there that accomplish what I need it to do? I also want something that integrates with my Wiki. Another thing to change.

I know some companies get things done without these tools. Some of these tools were not in place when I arrived at my last job. I asked questions about introducing something, not knowing someone was already working on something. When the wiki and issue management tools were put in place, I helped drive adoption within my team. I wish I had the budget to bring those tools in, but I don’t. I have to identify something that works almost as well, but requires no cash outlay to obtain it. I plan to write more about these decisions in future posts, but open source here I come.

Technology

I took a slight step back deciding to go to my current company. After spending a large portion of my career focusing on working on the latest Microsoft platform technologies, I now work where the majority of the systems were built in ASP/VB Script and C++ client programs. These programs are solid. They support the business well and run with very few flaws. When it comes to building on top of them, however, there are issues. I mentioned the software was built somewhat haphazardly, so they expressed interest in fixing this.

I spent a large portion of my career working on Microsoft development technologies from ASP/VB Script with VB COM components to .NET 1.1/2.0/3.0. Working on interesting leading edge technologies is important to me. I dabbled in non-Microsoft technologies over the course of my career with a heightened focus over the past 2 years. I think Open Source software is a viable alternative to Microsoft, when it makes sense for the solution.

I have decisions to make about how to proceed with development. I need to balance my comfort zone with the Microsoft technologies with ideas about potentially better ways of doing it with open source software. This opportunity was one of the top “pros” I considered when deciding to take this position. I will write about this more in the future.

Introducing Balance?

So I have a huge amount of work. I expected this would be the case, because I asked questions to discover the state of things during the interview process. It’s not surprising, since they were looking for someone to lead the technology side of the company. They wouldn’t need my help if there weren’t issues to resolve.

In addition to the things I mentioned above, I spent time in the last 3 weeks putting together a list of backlogged projects. The fact a backlog existed surprised no one. The length of the backlog surprised everyone. Putting my wiki and issue management tools in place should help make sure everyone in the company knows what the backlog looks like from here on out. This will help keep things in perspective, give some people hope, and when the answers on when things will get done become unacceptable, will help justify getting extra help.

There are a lot more things I need to do, but this post is becoming long. Look for more posts as I move through this process.