Some Background

I work for Market Technologies Inc. (MTI) which writes custom software and web aplications for companies all the way from Fortune 50 companies to startup companies like MTI’s sister company Optic Edge Corporation. We’re a small company doing big things, which seems to involve growth every year for the past five years. Not only do we write the software and web applications for our customers, we also offer support packages for hosting them. At the company I am the System Administrator, a People Manager, a Project Manager and a Software Developer.

Chaos: Where It Begins

Each year as the company has grown we have always focused on a key group of people to make sure things happen. MTI was and still is a fairly small company. We don’t have the disposal of 50 people to throw at a task or to delegate tasks to. Switching between sysadmin to people manager to project manager to software developer and then back again does quite a toll on your brain. That is alot of different roles and responsibility to switch to and from. Some would argue that it is too many roles for a person to be responsibile for. And it may be, but as any small company or startup knows, you can’t hire hundreds of people upfront to get the ball rolling, instead you get a key group of people who carry the load until the company figures out how it will run itself and then hire pepole to fill those roles (remembering to take into consideration the whole cashflow perspective as well). And it appears that I am one of those key people at MTI to help carry the load as we grow until we reach that next horizon of success at MTI to bring in another wave of employees to help push us forward. This is where where the chaos begins… for me at least. </div>

Reflection: Knowing When To Change

About 21 months ago we started an extremely large software project. The timeline was insane. We first met with the customer in September, but didn’t get any requirements until November and they wanted it released on the first of January. What followed was a few months of working the longest hour shifts I have ever worked and about 100 thousand lines of code in Java from our development team. After it was released, we followed an Agile development style on our team to kick out new releases and updates every few weeks.

Things were going well except for everyone’s personal life had became non-existant. What was a one-time thing to get the project out on time became expected behavior from the customer. If something took 12 hours to complete and it was 4pm, they were still expecting an 8am completion of the task the next day. We hired two additional developers in February of 2005 to help offset the load. After a short while of training and the developers getting more familiar with our software we were able to maintain most of the workload the customer was pushing on us. However system administration time became non-existant for me, and we still lacked what I felt was a good process for managing projects internally and externally.

We weren’t failing at managing things completely because we kept kicking out updated software for the client, but we weren’t managing things in what I felt was the optimal way.

Each day just seemed disorganized for the most part to me, and it felt that we were just doing immediate tasks each and every day, never focusing on how-to improve or where we were headed. In the spring of 2005 I started reflecting on what was working and wasn’t working for us.

I have realized that knowing when to change is an extremely valuable asset and important quality. Without change you will never improve upon anything, and if you’re not improving you’re most likely going to become dissatified with what you are doing and where you are headed, and so will the people on your team.

Discovery: How To Change

In the Spring of 2005 I started investigating the different trends of software development and engineering. I ended up finding books on XP and Agile development methods by Kent Beck and Alistair Cockburn. I also ended up reading books which were to help make you as a developer more productive, from the Dave Thomas and Andy Hunt. I then went back and started reading again books by Tom DeMarco and Timothy Lister (like Peopleware and Waltzing With Bears) and I started reading The Mythical Man Month by Frederick Brooks.

I started evangelizing to coworkers and my boss about some of the techniques and methods that I felt would our company and development team would really benefit from. Everyone seemed to be on board, but nothing happened. The more I tried to have a sane-work-week the more behind I felt I was getting, but nonetheless updates to our software were getting kicked out.

A coworker in late 2005 purchased the book Time Management by Timothy Limoncelli. I have been reading, rereading and studying that book ever since. In early 2006 I finally had gained the confidence to start implementing the changes I felt our company, our development team and myself needed. Becoming equipped with knowledge, and experiences is a very powerful thing, however if you don’t know when to use them you’re no better off then not knowing them to begin with.

Knowing what changes to make is the prerequisite to making change, but unlike so many meetings you have probably been apart of, the action plan needs to be implemented. That is the only way it isn’t a total waste of time for you, and the rest of the people sitting in any meeting.</div>

AAA: Act Act Act, Part 1

Follow-through is the key to making change. In fall of 2005 I was evangelizing to my team, my coworkers and my boss. Everyone was on board with the thoughts on where we could make improvements and on what improvements to make, however nothing continued to happen. My job-satisfaction plummetted. It had been about a year and nothing had changed. We seemed to be at a plateau, and I felt like I was not only wasting my time by not using it efficiently but I was wasting other people’s time as well. We had the formula to make things better we just weren’t putting it to use.

I met with my boss on a few occasions to discuss my frustation, not only for my sake at work (I was also a newlywed just a few months before the first huge project took over my life), but for my marriage, and he gave it to me straight. He agreed on what I wanted to and he was behind me doing it. After that meeting I realized that someone had to start making the changes. So in the winter of 2005 I started implementing changes for me personally. In the beginning of 2006 I continued to make changes and adjustments for myself. Things were going better, however so much of what I did involved the other members of my development team and how we managed projects as a group, and that really hadn’t changed all that much.

AAA: Act Act Act, Part 2

I have the pleasure of knowing Craig Demyanovich (a software developer who applies agile software development practices at his workplace) from the grandrapids.rb, and on several occasions I have been able to discuss with him how his team works, and what he finds works well or doesn’t work. This led to the first change that was implemented at MTI on the development team at a team level.

We implemented a very basic scheduling system with a dry-erase board, markers, post-it notes and colored electrical tape. The board represents a two-week iteration divided up into 1 hour blocks per day. Each post-it note represents a one hour block.

At the beginning of each week we get together as a group and plan out workload for the next two weeks. We mounted this to a wall in our office so it is in visual view for our developers.

Each developer is a different color post-it note, and each developer takes up a single column. As phone calls, emails, instant messages, etc… come in we are able to look at the board and quickly see where we can schedule the workload. If it is important enough to knock something else out of the way, we simply remove the post-it note and reschedule it for later in the two week iteration or remove it from the board completely, and then put a replacement post-it note up.

We made it a point to only involve seven 1 hour blocks for each day. We assume there will be around 1 hour of non-constructive work each day. Whether it’s phone calls, emails, a short break, etc, we want to make sure people don’t schedule themselves into jamming every hour of every day into doing actual work work. Communication has to exist, and communication itself takes time. I haven’t met anyone yet who can talk on the phone and fluently write software while staying focused on both tasks at the same time.

There is also a bonus to scheduling only seven hours of a day. Since tasks can sometimes take longer then expected it gives people a little leeway room that day, and if people get things done early it allows them to do something else with their time. We aren’t expecting anymore work that day to be complete, so if a developer jumps on tomorrow’s tasks that is a bonus. Perhaps they want to read up on slashdot, or work on a fun side-project. It keeps the workplace a more enjoyable environment to work in, and it is a win-win situation. The project continues to meet expectations and the developer gets to do something fun with his time.

Forward Thinking: Continuing Change

The scheduling board has been in existance now for a shortwhile. For me personally it has made things one hundred times better. It is easy to tell not only how busy I am, but how busy the other developers are. An engineer came into our office one day and asked about the board and then said, “It’s kind of different thinking that the IT Dept. isn’t using something high-tech…”. He’s right, it is different. Tom Limoncelli found his favorite form of a PDA is a PAA (personal analog assistant) which is essentially a planner that he writes in with a pencial or pen. No electronics required. </div>

So far our analog-based scheduling system is working wonders for our team. The next step towards better time management for us will be communicating that effectively with the rest of our company and with our customers. We have a summer-assistant who starts work tomorrow to help us do just that. We aren’t going to automate anything, we are going to take the long way around, and do it manually. It is hard to automate a process that doesn’t yet exist, and it’s a waste of time to try to automate something and make it up as you go.

We have scheduled a meeting with our customers to take in their feedback on where things can improve. We want to continue to provide the best software and service around. Forward thinking tells me that this is the right way to go. Experience is starting to tell me that to successfully manage and deliver a project is not to be the one with the shortest timeframe to completion, it’s rather the one that can successfully manage the expectations of both the customer and the development team (including developers and managers). Providing clear-cut communication and the right data to the people involved seems to be the vessel that is best suited for that job.

I know I can write great software. I know everyone on my development team can write great software. My fear doesn’t come with what I know we are capable of. My fear is that we won’t manage expectations in a way that allows us to do what we are capable of. And that is why I am making change and involving every single person I can in our company to help make that change with me. I don’t want to only make myself better at what I do. I want to make my development team and every person at MTI better in what they do. I want to change how our company operates, I want to change our culture.

Passionate People: Find Them Or Wake Them Up

It is very easy for people to fall into a slum to where they just expect to roll out of bed, show up at work, and somehow make it through each day, and then leave at 5pm. I am not one of those people, and no one on my development team foots that bill either. To me these are people without passion. Not everyone is passionate in what they do, but you can create passionate people where there seems to be none.</div>

People need to be able to see why change is needed, and to see a glimpse (if not the whole picture) of where change will lead them. Most people can’t visualize their way out of a paper bag. Sharing a glimpse of where change will take them and getting them to see it has the ability to heat up the passion inside of a person who has fallen into a lethargic routine of showing up, surviving the day and going home.

I consider myself a lucky person. The immediate people who surround me at work; my development team and my boss, are all passionate about what they do. It certainly helps feed my own self-motivation to make and embrace change. Not every environment is like this.

I had a previous boss who focused merely on the daily todo’s. Every day was just work-work-work. It felt like we were running on a treadmill, doing lots of work, but not going anywhere in the longrun. There was no way to see what was in ahead of us, or where we were headed outside of just today’s work. Every now and then he seemed like he had a glimpse of how to improve, but then it would disappear by the next day.

Being stuck in that type of situation is not fun, enjoyable or satisfying. Most people I have encountered are passionate about something. Sometimes they need someone to help them see things in a new light.

Passionate people aren’t perfect, they are merely passionate. They have a drive to do something and to do it well. Utilizing a person in an area where they are passionate will help keep them passionate and it will give the development team, the employer and the customer better results. People can’t always be utilized in what they are passionate in 100% of the time, but even giving them a percentage of time to focus on that task is enough to keep them fired up.

Tying It All Together

I am finding that better time management leads to higher rates of productivity and a less stressful environment for me and the people around me. I am also finding that passionate people are key to making, embracing, and accepting change at the office. A year ago i was surrounded in what my mind felt was chaos. Six months ago I felt I had the tools to start making change and I evangelized to the people around, but I failed to make change. Now I am making change and involving the people around me. Not every piece of change will work, but that’s ok, we can always change it again.

Next Article

This article was very lengthy. I probably could have released this as the mini-series. I feel this is a good platform to start the mini-series. It is from the viewpoint of a System Administrating Project Manager People Managing Software Developer(s).

The next article will be much shorter (i hope!) and will focus on some of the new techniques we are implementing at our office with how they are surviving so far, and the results of meeting with some of our customers and their take on the whole process of change.