Peter Drucker declared, in one of the most important chapters of his landmark volume The Effective Executive:

Effective executives know that time is the limiting factor. The output limits of any process are set by the scarcest resource. In the process we call “accomplishment,” this is time.

Time is also a unique resource. Of the other major resources, money is actually quite plentiful. We long ago should have learned that it is the demand for capital, rather than the supply thereof, which sets the limit to economic growth and activity. People–the third limiting resource–one can hire, though one can rarely hire enough good people. But one cannot rent, hire, buy, or otherwise obtain more time.

The supply of time is totally inelastic. No matter how high the demand, the supply will not go up. There is no price for it and no marginal utility curve for it. Moreover, time is totally perishable and cannot be stored. Yesterday’s time is gone forever and will never come back. Time is, therefore, always in exceedingly short supply.

This fact of more demand for time than the limited supply available, it’s a fact of life for us small businessmen. There’s always too much to do and too little time. Maybe you too have said, as I often do: “I wish there were some way I could find more time!”

But now we have the answer to Peter Drucker! Yes, an ingenious manager has now figured out the secret to overcoming our limited supply of time. And you’ll never believe it. It’s so simple. When you hear what the answer is, you’re going to freak, it’s just so simple!

To find out what it’s about, just click here to read all about this exciting new technique, on Star C’s blog, Wednesday’s Off.

-TimK

P.S. Yes, this is a joke.

P.P.S. If you want the real secret of how to overcome the fact of limited time, see Peter Drucker’s timeless classic The Effective Executive.

You might think it’s strange for me to call a failure a good thing. But I count it solidly a good thing. Because it means I was stretching myself, doing something I had not already mastered. And the fact that I recognize that there was some part that I can improve, some part I would do differently, means that I’m using the opportunity to grow. That’s the most important thing you can get out of a failure, and that’s why we need to fail. Actually, we shouldn’t even call them failures. Like Phil McKinney did recently on the Killer Innovations podcast, we should call them opportunities to learn.

So, how did I encounter this opportunity to learn? First you have to understand something about our system. It’s a legacy enterprise web-app written mostly in C++. Numerous consultants wrote much of it back in the 20′th century. Money was tight, and the most important goal was getting new features delivered. So a consultant would be hired to add features as fast as he could and pad his resume at the same time. For example, one of these consultants apparently wanted to be able to say that he developed a web server. So he did. And we’re still saddled with it.

Yes, our enterprise web-app uses a web server that isn’t a real web server. But that’s only the beginning. It also uses an app server that isn’t recognizable as an app server. And interwoven with these are the application model and domain model. And I do mean interwoven. There is duplicated code everywhere, and each piece of code has at least five different responsibilities. Before working on this system, I thought I had seen unmaintainable legacy code. Ha! If you’ve ever read Working Effectively With Legacy Code, I routinely face real-life problems as bad as the most terrifying stories Michael Feathers recounts. Whatever code you’re wrestling with, take heart that it probably isn’t as bad as this. The basic rules every first-year comp-sci student learns: high cohesion and loose coupling— Remember those? Well, our system has no trace of them anywhere.

A good design is like an egg. If you crack an egg into a bowl, you’ll see the yolk in the middle and the white around it. Each of these parts has its own form and function within the egg. Each is highly cohesive. The two parts have a well-defined relationship with each other. Each never intrudes on the other’s space, but they work together to form the whole egg. They are loosely coupled.

Take a fork and whip it through the egg over and over again. Now you have a scrambled egg. That’s our system. My job is to unscramble the egg.

I wanted this responsibility. I’ve been pushing for it. You might think this is an instance of be careful what you wish for. But I’m not afraid, and I’m not overwhelmed. Because I know the secret to unscrambling an egg. The secret is to do it with tweezers, one pinch at a time. Pick up a tiny bit of egg. Is it yolk or white? Yolk? Okay, put it over here. Next tiny bit. Yolk or white? White? Okay, put it over there. The secret to refactoring code is to do it bit by bit.

So the way it worked out, I was in charge. No, it wasn’t on a grand scale. It was just a mini sub-project. I didn’t make a Gantt chart. I did end up posting a burn chart, which I’ll get to in a moment. I was not officially a manager. But I was, for a few weeks anyhow, in charge. And I discovered something fantastic: I liked it.

The first thing I did was to prepare a small presentation for the rest of the team. I went over how the bits of our system fit into a proper enterprise architecture. And I identified a first step: Refactor our response code to use an IHttpResponse interface, instead of typing in HTTP response text and pushing it at the open TCP socket. Yes, that’s really what the old code did. I boiled this down to a set of refactoring techniques we could use. I pulled the general process from Working Effectively With Legacy Code. But then I applied it to the specific problem we were facing at that moment. I provided refactoring templates that applied to most of the code that we needed to refactor. Yes, there were special cases. But we could handle them as they arose.

When I gave the presentation, a junior engineer was already working with me. He was refactoring the parts of the system he was intimate with. Afterward, another senior engineer was asked to help out. She picked a module with some pretty hairy refactorings that were all interrelated and had been bugging her. I worked on the rest. I picked a module to refactor and went at it. Then I picked another module.

But how did we know what code we needed to refactor? We searched through the code for a particular function call: the Send() function. Send() was the function that pushed response data up the open TCP socket. We could just search for instances of Send(). Then instead of generating HTTP and calling Send(), now we wanted to generate HTML and use IHttpResponse.

This also made it very easy to chart our progress. Just search for instances of Send(), and find out how many instances we’ve eliminated. I threw together a semi-automated process and did this every day. Then I updated a burn chart, which I posted in our shared hallway. Everybody appreciated seeing the progress, especially my manager.

Can you imagine my elation the day I actually deleted the definition of Send() and rebuilt the project? I told everyone what I’d just done. How cool is that? All that excitement over one little function that had its tentacles woven throughout the whole system. And now it is gone, hopefully forever.

There’s one big thing I would do differently. I would only take on personally those parts that required my insight into the big picture. As soon as other developers were on-board, I would start asking them to work on any part of the project they could. In other words, I would delegate more. As it was, I spent a lot of time doing by-the-numbers refactorings. Then at the end, there was one more function, which has a couple unique twists. To refactor this monster, I first had to change the inheritance hierarchy and add additional features to the supporting classes. It took me days. If I had been thinking more effectively, I would have avoided all the by-the-numbers work. A junior engineer could have done that, and at much less cost to the company. I would have been working on this code much earlier, and we probably would have finished sooner.

And that’s what I plan to do with the next phase. Right now I’m implementing IHttpRequest. We finished the response side of things; now we’ll do the request side. Of course, the function that needs to instantiate the request object currently does things from all layers of the system, including the domain model. It’s 465 lines long. And it’s full of bugs and, er, undocumented features. So I need to deal with that, again using the techniques Michael Feathers talks about.

But once that’s taken care of, we can start refactoring the application-model code to use IHttpRequest instead of the global variables and duplicated logic it uses now. Most of this code will follow straightforward patterns. But some of it will hold unexpected surprises. I plan to look for the unexpected surprises first and save the rote stuff for later. We’ll see how that works out.

-TimK

Leadership is like Ronny Cammareri’s love, from Moonstruck:

Love don’t make things nice, it ruins everything! It breaks your heart, it makes things a mess. We’re not here to make things perfect. Snowflakes are perfect, stars are perfect. Not us! Not us! We are here to ruin ourselves and— and to break our hearts and love the wrong people and— and die! I mean, the storybooks are bullshit!

Similarly, great leaders make as many enemies as friends, and most of what they do goes unnoticed for a long, long time. Leadership is about taking the initiative, about challenging the status quo. Leadership is about vision and perseverance. It’s about listening and humility and letting others take the credit and pleasure in the little gains that other people accomplish. Leadership is about setting an example and letting someone else run with it. This is the kind of leadership that may earn you no accolades, no awards. In fact, people may criticize you at first, because they don’t see the difference it makes. Even worse, they may ignore you. But it does make a difference. Or rather, a bunch of little differences.

Occasionally, you’ll make a big difference, but never by yourself. My last performance review was a shock to me, and it was because I was not talking enough with my manager or with his boss. Now, I could have just let it slide, which is one’s natural instinct. Why rock the boat? After all, you can’t force someone else to talk to you or to listen to you. And with your manager, if things don’t work out, you can’t fire him.

But I knew there was only one professional course I could take. And I also knew that others had been saying the same things I have, that we don’t know how our efforts fit into the team’s long-term goal or into the corporate vision. I went further: I don’t know what management expects of me. And I went further even than that: Management doesn’t know what I expect of the company.

Then I committed to meeting with my manager each week to discuss these issues. I didn’t know how that was going to go over, because you can’t force someone to talk to you or to listen to you. But the option with the greatest risk also has the greatest reward. And there was only one professional course I could take.

Now, my manager’s boss goes over my performance review, as a matter of policy. And he had a meeting with me to hear my thoughts. And I told him exactly what I thought. I told him that I disagreed with parts of the evaluation. And I told him that I thought I needed to talk more with my manager, because I didn’t know what he expected of me, and he didn’t know what I expected of the job. And I told him that I didn’t understand how my work fits into the team goals or the corporate vision.

And he was on the same page. He has now started having regular lunches with the software department. He’s already explained to us his vision for the future and opened a dialogue. And when I went to talk to my manager for my first weekly chat, he was open and receptive. He listened, and I listened. And I ended up thinking, This could work.

The honeymoon isn’t over yet. Wait another few months, and then we’ll see how permanent or effective these changes are. It somehow feels like too big a step to make all at once.

What does any of this have to do with moving chairs? Well, in my team, moving chairs was a little step, one of those things most people don’t even notice as significant. But it excites me. It excites me as much as the corporate-and-team-vision thing.

A few months ago, we moved to a new office space. In our previous space, the four of us shared two offices, two developers per office. A short hallway joined the two offices. You’d think we’d have pretty good teamwork, sharing space and being relatively close together. But the opposite happened. We felt closed in upon and cramped, which does not foster openness. And the hallway between the two offices meant that those of us in one office rarely talked to the people in the other office.

Our new space affords us each a normal-size work-area. But we don’t have cubicles. Instead we have alcoves, three walls and a missing fourth side. This was not our choice. I myself would have rather had a fourth wall. But at least we all sit together. And one of the side-effects is that I can look out from my desk and see two of my colleagues. And if I can see them, I can talk to them, too. Each of us can do this. It’s as if we each had our own area in a big, common office.

Here’s where the moving chairs come in. Shortly after we moved into the new space, one of my colleagues asked me to help him with something. We have no guest chairs, so I grabbed my chair from my desk and wheeled it across into his space. The practice caught on. I remember the way I felt when one of the other engineers wheeled his chair into my space. It’s such a little thing, but it represents something to me. It represents camaraderie. It represents that the four of us are not living in isolation, but that we’re part of the same team.

Recently, we had a design meeting in my manager’s alcove. One by one, we brought our chairs over to sit as we worked on his white board. Someone walked down the hallway that divides our space, and we joked that they were walking through our conference room.

This, all because we were moving our chairs. And I did it first.

-TimK

In our company, I as an employee am expected to fill out a self-evaluation, my manager is also to fill out an evaluation, and then we discuss the differences and file the forms with HR. The first thing I noticed is that I didn’t know how to fill out my copy of the form. Each line item I could rate as “strong point,” “satisfactory,” or “needs improvement.” I knew what each line item meant, but I didn’t know what my manager actually expected of me, so I didn’t know how well or how poorly I had achieved it.

Now, I could have just evaluated myself against my own personal yardstick, in which case I would have had a dozen strong points. Isn’t that a little disingenuous? Well, no, actually. Because I achieved measurable progress in all areas I had set goals for, and I was happy with my performance in all the other areas.

But it would impact my manager more if I were to drive home that he and I need to talk more. So, for all line items, I marked down “satisfactory,” neither good nor bad. The only further comment I left was that I thought better communication with management would make my job easier.

But then came the meeting with my manager and his evaluation. In almost 20 years as a software developer, I have never had less than a stellar performance review. Now, one year with one manager, and I finally understand. Well, I understood before, but I had not internalized it. Now I can internalize it: Performance evaluations are not about actual performance. They are about the relationship with the guy filling out the evaluation form.

I don’t want to make it sound as though the evaluation was all bad. For example, my manager thought I had strong organization skills. He particularly like my “system of breaking down a project and organizing the individual tasks.” Ah yes, I am proud of my system. It’s a system I began using years ago in a prior job, to track features and tasks and to estimate how long new features would take to develop. As a result of this system, I actually know how much I can safely commit to, and I actually deliver when I say I will. It’s a marvellous system, one we should all try. Those of us in the know call them story cards.

Then there was the fact that my code has fewer bugs than anyone else’s. I produce high-quality code. I was actually surprised to hear this, because I didn’t think we counted bugs. Well, as it turns out, we don’t. I still believe I probably introduce fewer bugs, because I’m the only one of our little team that uses unit tests, at least on new code. I hate bugs, both the software kind and the multi-legged kind. And as far as I know, the few I have introduced into our system have all been in non-unit-tested code.

(As you can probably see, I’ve been reading Extreme Programming Explained and Crystal Clear. Actually, I read them both long ago. But I also have them both on my shelf at work, and they are my plumb line.)

So I do deliver quality code on-time, but my productivity “needs improvement.” Apparently, I often require “more than [the] ‘normal’ amount of time.” Is that true? How do we know? What’s the “normal” amount of time? We don’t actually have a way to measure feature size or velocity. I’m the only one of the team who measures his velocity. (Remember the story cards?) But how do you compare that to other members of the team? And why would you want to?! Gack! Talk about sabotaging teamwork!

Fortunately, no one’s talking about sabotaging teamwork. But I have a sneaking suspicion that because my code actually works the first time (usually), and because I don’t have to spend endless hours after-hours tracking down yet another defect in our legacy system, it looks like I’m getting less work done. I’m not speaking ill of my teammates, mind you, because they really are doing the best they can with a system and process that fights against them at every turn. They are good programmers, each according to his experience level, and I truly vouch for each of them. And if any of them were to ask for a job reference, I’d give it in a heartbeat. This includes my manager, who is also the team-lead. (If a job reference from a wash-out like me is worth anything.)

But I’m a toxic employee. So my “attitude… needs improvement.” Seriously. I “often look distressed and disgruntled.” This in addition to some not-so-stellar properties of my communication and teamwork skills. According to the report, I’m always arguing everything, and this puts off the other team members.

This confused me greatly. Yes, I am always ready to point out alternatives, especially the challenging ones that require us to think outside the box. This could come off as argumentative, but I consider a good thing. It’s called collaboration. Just this past week, one of the other engineers came to me for advice. She wanted to talk to me. I did not ask her. Together, we delved into the engineering problem she was working on.

My manager from his desk he had heard everything we said, and he cited it in my performance review. He noted how I had picked over everything, always giving a contrary viewpoint. Well, yeah. That’s what she had wanted. I had asked her what kind of input she wanted from me, and she had said she just wanted my thoughts on this design problem. So that’s what she got, my thoughts, no matter how challenging they were. I also told her I might be talking out of the back of my head and that I wouldn’t be offended if she ignored everything I said. They were just ideas, and she was doing the actual work.

The next day, she came to me again and discussed the same engineering problem some more. I did not bring up the subject; she did. If I had made her feel so bad, why did she keep coming back for more? I asked her an open ended question: “What did you think of our meeting yesterday?” She said that she thought it was constructive and useful and that she appreciated my spending my time to hash through her design problem. (I later gave her feedback on how constructive it was for her to give me feedback on our interactions, but that’s another story.)

This all actually did tell me something useful. It told me that I have not been smiling enough at my boss.

It also reaffirmed something else I already knew. My manager and I do not talk enough. We talk about my tasks and my status, but about personal and social issues we are in two seperate worlds. I don’t really know what he expects of me, much less whether I can deliver it. I’ve never really asked. I do not know how what I do fits into the broader corporate vision, or how it fits with what my teammates are working on. I’ve never really asked. And he does not know what excites me about my job, what gets me down, or what my aspirations are.

I asked him if we could have a short, weekly meeting to discuss these issues on an ongoing basis. Or at least every other week. He’s very informal and doesn’t need a set time, but I told him it would help me remember. Otherwise, I might forget and put it off, and it would slip through the cracks. And I didn’t want that to happen, because once a year is not frequent enough for a performance review. So I asked him for a weekly meeting.

I had no real choice. The performance review was a disaster, because once a year is not frequent enough for a performance review. (I know I’m repeating myself, but that bears repeating.) In order to be effective, performance reviews must happen every month, every week, and even every day. It’s that darned feedback cycle again. Agile management, anyone? I need feedback frequently and quickly in order to address workplace issues.

So I plan to discuss these things with him, for better or for worse. I’m taking the first step, which may help. Or it may bring to the surface those issues that are more comfortably left submerged.

Hmm. I see here under the “Leadership/Initiative” line item — “Able to take charge and direct and coordinate activities; able to work independently; seeks increased responsibilities” — he marked, simply, “satisfactory,” no specific comments.

Oops. I think I mentioned unit tests to one of the other developers today.

-TimK

(UPDATE: The series I later changed to “Tales of a Wanna-Be Software Entrepreneur,” because entrepreneurship makes it possible not only to manage, but also to do it the way I think best.)

I never thought I’d want to be a manager. In fact, I don’t want to be a “manager.” I don’t want to spend all of my time administering the people who do all the interesting, creative work. But I’ve been filling more leadership roles in my life: where I work, where I worship, even in my family. And I want to do more of that. I want to be a team lead.

So what does that mean? It does not mean being in charge. And this fact is actually what makes me long to fill that position.

Being in charge does not make you a leader. I started learning this as soon as I became a father. Being able to set the rules and enforce them didn’t make anyone actually listen to me. I found that parental discipline isn’t about the ability to administer punishment so much as it is about teaching and respect. So in my studies to become a manager, I’ve been practicing effective management techniques on my kids.

Being in charge does not make you a leader. This is even more true in a church. I am a musician and worship leader at my church. Churches are non-profit organizations staffed largely by volunteers. They can’t be fired, because they’re not being paid. As a church leader, if you try to push them, they’re more likely to disappear than to do what you want. If you want them to go all out, you have to engage them, involve them, and get them excited. Over the years, I’ve seen both happen, and I’ve done both.

Then there’s my employ. As a senior software engineer, there are plenty of opportunities for me to take a leadership role. In a small company—the only kind I love—there’s always more work to do than there is time in which to do it. And there is always a leadership vacuum, no matter how great the managers of the company are. So there are opportunities to engage the other engineers, to prompt innovative solutions, to take the team culture in a new direction, to mentor more junior engineers. I get little credit for any of this, but I don’t care. I’m making a difference.

That’s really what it boils down to: making a difference. The more I think about it, the more I conclude, it really doesn’t matter whether I’m officially a “team lead.” Because a leader is something you are, not something your company calls you.

-TimK