It surprised the heck out of me when my manager asked me what I thought about rewriting our software from scratch.

Apparently, he had run the idea by the CTO who was open to the idea, but wanted some convincing arguments.

I was surprised because in my experience, managers and CTOs didn’t tend to think this way. Their attitude usually fell along the lines of, “it’s done – we don’t want to spend more money on it.”

But, I could see that this company’s leadership was something special.

My team was brand new. It had been created to take responsibility for a particular part of that company’s software. We had inherited buggy and incomplete code that needed to be shippable within a very aggressive timeframe.

I.e. we had spent our first few months at this company frantically fixing bugs.

My manager came to me with the idea of rewriting our software shortly after shipping the 1.0 version.

I think he was expecting technical arguments from me, but instead, I talked about the team.

“What is our product on this team?” I rhetorically asked him.

“Obviously our product is the code we’re responsible for,” I answered myself. “But we also have another product: the team itself.”

Then I said, “I think this team is very weak.”

I continued. “We’ve all spent the last few months frantically fixing bugs. But we don’t work together. I never work with Bob, Bob never works with Dave, Dave never works with me.

“We don’t even know who’s responsible for what. Three weeks ago Bob called me to his cubicle and said to me, ‘Dan, you’re the expert for this feature, explain this block of code to me.’ To this I responded, ‘I’m not the expert on this, you’re the expert!’ This scenario should never happen again. Everybody on the team should know who’s responsible for what.

“Also, in contrast to that example, none of our code should be entirely dependent upon a single person. If Bob is away, we shouldn’t be blocked by a problem with his sub-component – anyone on this team should be able to take his place. We should mix up the job of implementing and bug-fixing to accomplish this.

“This software we have inherited contains a lot of code that we just don’t understand. Frequently, we can see what it is doing but we don’t know why it was implemented that was. By rewriting it from scratch, we’ll build an understanding for ourselves and this won’t be a problem anymore.

“Most importantly, I think people feel good about what they create. We didn’t create this code, we inherited it. I don’t feel good about it at all – do you?”

I also promised that we could do a better job on the new code. I could design it from the ground up with an eye on diagnostics and testability. I would set strict coding standards. There had also been a lot of redundant code (i.e. copy-and-pasting) that would be eliminated.

The new code would be more stable and take up less memory.

So, I promised two big things: (1) a better product and (2) a strong team.

I was betting my reputation with my new employer on this.

My arguments seemed to work because two days later I was asked to give estimates.

I went to work designing.


Don’t tell people how to do things, tell them what to do and let them surprise you with their results.

  – George S. Patton


My design was deliberately high-level. I identified the components we needed and how they were to work together, but the implementation details were left deliberately vague. It was the duty of individual developers to work out the details of these implementations. I would of course review everything, but this was how I’d planned to grow a team from a disorganized collection of software developers.

I also designed a job interview to identify and hire the right people.


I Learned Some Things

One was, experience doesn’t equate to competency. Initially, I had an experienced software developer and a junior developer working for me. Naturally, I expected that I would be able to rely upon the experienced developer and that the junior developer would need a lot more help.

Within three weeks my opinion of these two had completely inverted.

The junior developer had won my trust and respect. He executed good judgement and the quality of his work was excellent.

I didn’t trust the experienced developer. I thought that the quality of his code was awful and he was severely lacking in common sense. When he decided to leave the company, I was quietly relieved to see him go.

I also learned to listen and that sometimes I am wrong. From time-to-time, I’d assign work to someone with instructions on how it should be done. They might come back after some time thinking about the problem, and tell me that my idea wouldn’t work. They were usually right.

It made perfect sense, after all. They were the one’s spending the most time (and thought) on the problem.

This experience amplified my trust in my colleagues.

The whole operation was an enormous success.

I hired more people while the project was ongoing, and through that project I was able to train them and make them productive very quickly. So, the team I had promised was a success.

The software was a success, too. It took up less memory and was more stable than the 1.0 version.

I was ultimately given credit as the person who built that team.

That felt really good.


My Build the Team Philosophy

Sometime later, I was working as a technical lead on a new assignment.

My new manager thought very differently than me.

I think his philosophy was to get the product done as quickly as possible and fix any problems in the time remaining.

He made hiring decisions that I disagreed with.

We also disagreed on how to utilize some consultants we had contracted. These were people who had a lot of experience with the hardware our software was targeting (much more than we had).

This manager wanted the consultants writing code for us. I pointed out that we had lots of time, how about we utilize the consultants for their knowledge, but we actually write the code ourselves? My goal wasn’t just the finished product – I also wanted a knowledge transfer.

He disagreed.

He meant well, but I think my method would be better in the long run as it would build the expertise of our team.

I’ve worked my build-the-team philosophy into later jobs. On occasion (and when time permitted), I have delegated tasks to junior members of my team because I thought they would benefit from learning something new (this is good for them as well as the team).


Conclusion

Obviously the finished product is the primary goal of any company – that’s where the money comes from.

But I think it’s important to consider what’s required along the journey in order to make that goal so: one of those things is a good, strong team.

Building such a team may take more time in the beginning, but in the long run such a team is quicker, more agile, and produces a more reliable product.

And since no product is ever really done, I think it’s also important to think about what’s necessary to retain a good team.

And it is for this reason that I believe that focusing on individual teams – i.e. the team’s expertise as well as the team’s contentment – is so important for leaders to think about.