Category Archives: Improving

So, You Wrote a Document

Improving, Interpersonal,

A great document won’t breathe life into an idea, but salesmanship will.

So, you wrote a document. That’s a great start, but it’s only a start. Whatever is in there – an argument, an idea, a plan, a process – may be fantastic, but it’s not going to succeed because of the document. The document was mainly for you – a way to organize your thoughts. Its mere existence will lend some credibility to whatever it is that you’re pushing, but few people are going to really read it, and next to nobody will read it more than once.

Now that the document is done, it’s time to start working on your elevator pitch. For better or worse, the 60-second version of your position will have much more impact than the 60-page version. It’s time to start selling.

If It Were Easy, It Might Still Remain Undone

Improving, ,

Don’t underestimate the number of problems that can be solved by expending slightly more effort and attention than your predecessors did .

“If it were easy, it would be done already.”

This is something I hear frequently. On the face of things, it sounds reasonable – something a been-around-the-block veteran says to the starry-eyed newcomer who has yet to be introduced to reality. It puts the arrogant in their place, reminding them that they are not so much smarter / better / more motivated than those who came before them. It bespeaks practicality, and a certain worldly wisdom.

Often, it is just flat wrong.

Granted, one can reasonably expect that a valuable goal which has remained unattained will be attended by non-trivial obstacles. However, that is the sort of thing you bear in mind so as to temper your expectations – not the sort of thing that should slow you down in advance of locating and confronting those obstacles. The “if it were easy” refrain is more likely to be a catchphrase of complacency than a sign of sagacity. It is used as warrant for the worst kind of failure, the kind that comes from never even trying to succeed.

What suggests that you can achieve a goal that has remained unrealized, in spite of many competent predecessors?

  • Even good people tend to buy into organizational myths about how difficult things are or the reasons that such-and-such won’t work. The people before you might not have even tried to solve the problem because they were sold the same “if it were easy” notion. This dynamic becomes progressively self-reinforcing as more people come to brand a particular problem as hard, longstanding, etc. Such branding creates a kind of inertia that is difficult to overcome, and helps to explain why new faces are often able to make tremendous changes to an organization in a short amount of time – they have yet to be introduced to the contents of the “don’t bother” list.
  • Even good people get lazy sometimes – the problem you’re looking at may be one of those areas where nobody competent has ever really rolled up their sleeves yet.
  • You can’t tend to every problem – maybe nobody has quite gotten around to this one at all yet. (Don’t trust the organizational historians who say otherwise, unless they can credibly explain why your predecessors stopped short of the goal line.)
  • Achievements are incremental – the blockers that kept your target goal from being realized in the past may have been recently removed by a new information system, org structure, business rule change, etc. You might be the first one to stand on the shoulders of the giants who came before you, and do full justice to their achievements by building upon them.

Plenty of easy (or at least very manageable) things that are worth doing remain undone in every organization, and you’re not tilting at windmills just because you don’t accept the blithe alibis of those who don’t want to bother expending some uncommon effort. What’s relatively easy may very well remain undone. However, what’s already done is bound to be even easier, which is why so many people avoid the risks and uncertainties that attend meaningful progress.

Iteration Works for Everything

Improving, Process,

Everybody knows the benefits of iteration for developing software, but iteration should be practiced for developing just about everything.

If you’re working in software development, professional literacy / competence demands some acquaintace with iterative development techniques. From intern to architect, it has been drilled into us all – iterate, iterate, iterate. Most of us can and do carry the tune – we deride the linear ways of waterfall (at least explicitly), and preach the gospel of iteration.

So, why do we iterate? I think these are the best reasons:

  • People often don’t know what they want – It takes seeing some kind of semi-realistic product before people realize what they do and don’t want from a system. Iterative development gives people slices of functionality that they can test-drive, thereby enabling the feedback needed for future iterations.
  • People often miscommunicate – Even when they know what they want, people aren’t always so good at expressing it. Further, even if well-expressed, a requirement might be easily misunderstood. Iteration allows people to look at something in progress and say very simply and specifically what is right or wrong about it.
  • Requirements change  – Targets have a way of moving, even the ones that have already been hit. Iteration gives you a way to continually re-validate requirements and to keep pace with fluid demands.

So, we all know the above, and countenance these truths in our development practices. Yet, for some odd reason, most of us reserve the valuable practice of iteration for creating code. When we need to produce user guides, proposals, standards, COTS evaluations, slide decks, and any other non-software deliverables, we revert to the dark ages of engineering, hoarding our labors and polishing them at length, waiting for the right moment at which to unleash them upon the world.

Your non-software deliverables are just as susceptible to miscommunication, moving targets, and imperfect requirements as your code is. As such, you should iterate over those as well. Don’t wait until you have a complete and thorough document / presentation / proposal before throwing your cards on the table. Instead, get something (e.g., a table of contents, outline, or synopsis) out to other stakeholders as soon as you can, and let the magic of iteration help you to make these products as good as they can be.

Iteration works for everything.

Rules for Meeting on the Maker’s Schedule

Improving, Management, Tips,

Schedule your meetings in a way that is cognizant of the significant difference between the maker’s schedule and the manager’s schedule.

If you manage people who are building software or otherwise doing something that requires sustained, intensive concentration, then this is something you need to read:

http://www.paulgraham.com/makersschedule.html

The basic gist of the essay is that the “tax” of holding a meeting is many times worse for a maker (people who build things, and require sustained concentration to do so) than for a manager. The manager tends to view the day as a series of hour-long slots into which obligations, especially meetings, must be fit. The maker, however, tries to get large blocks of uninterrupted time, because of the effort required to get back into the creative “zone” after an interruption. For a maker, three contiguous hours are much more valuable than three isolated hours. A typical software developer will get twice as much coding done from 1:00 to 4:00 as she would from 9:00 to 10:00, 11:00 to 12:00, and 2:00 to 3:00, even though the total time spent seems to be the same in both scenarios.

After reading this article, I now try to schedule meetings using the following rules, which assume that I can see the daily calendars of the makers with whom I’d like to meet:

1) If a maker already has an uninterrupted morning or afternoon, don’t touch it. That’s golden time, and biting into it is like cutting open the golden goose. Find another time. (This rule decreases greatly in importance if the maker appears to have lots of unscheduled time, but most engineers / developers have a decent number of meetings that they need to attend.)

2) Try to schedule the meeting adjacent to existing meetings, preferably on the side that allows the block of time on the opposite side to be as large as possible.

3) If the above don’t work out, schedule the meeting immediately before or after lunch.

4) As a corollary consideration, schedule your meetings with other managers at times like 10:00 AM and 2:00 PM, so that you will be free to meet with makers (as needed) on a schedule that is more congenial to their interests.

I’ve been trying to follow these rules for a month or so, and my folks think they make a difference. They report a little more time to tackle hard problems, and they appreciate the fact that I am cognizant of their scheduling needs . Of course, there are times when I have to violate the rules, particularly when the meeting is large (making it much harder to find common free time) or when it involves somebody who is chronically over-scheduled. For example, my boss has an amazingly small amount of uncalendared time in any given week, and so if I need to get him in a meeting with my folks, I’m pretty much bound to pick whatever free time he might have.

My scheduling concerns are relatively complicated because I have a geographically distributed team, part of which is on eastern time (Philadelphia) and part of which is on mountain time (Denver). So, for team meetings, it’s harder to get a time that works for everybody. 11:00 AM eastern works pretty well because the Philly folks will go to lunch right after and the Denver folks (2 hours behind) are just starting their day. 1:00 PM eastern is also good for similar reasons (Philly folks have lunch before, and Denver folks go to lunch after).

The difference between maker’s time and manager’s time is pretty obvious in retrospect, but most managers are surprisingly oblivious to it until it is pointed out to them. (I was.) Accounting for the difference is relatively simple, and likely to pay big dividends. So, I’d recommend coming up with your own set of rules for meeting on the maker’s schedule, and sharing them with the other managers in your organization. You’ll make your makers happy if you do.

Do What Hurts. Now.

Improving, , , ,

Figure out what’s painful for you, and then go do that.

You’re a distance running coach. You need to figure out what one of your athletes needs to improve. There are many different kinds of workouts you could use, but these all boil down into roughly three flavors:

  • long, slow runs
  • shorter, faster tempo runs
  • the high intensity bursts of an interval workout

So, how do you know which to emphasize for a particular runner? It’s actually fairly simple – you ask the runner what kind of workout they hate the most. Their answer is your answer. In my case, I love long, slow runs, and hate interval workouts. Not surprisingly, I can run for a fairly long time, but I’m not very fast. I need to do more interval workouts.

People gravitate toward their comfort zones, and avoid their pain points. The pain points are typically the areas in which they are weakest and least comfortable. Like many pains, pains born of weakness are cyclical and self-reinforcing. As people avoid their pain points, they become even worse at doing the thing that brings the pain, thereby making it all the more painful, and increasingly less likely to be something that they’ll want to tackle.

Your pain points are probably the things making you the weakest – the things that are holding you back. If you want to be stronger, one of the best things you can do is to break the cycle of pain. You need to go do the thing that you fear the most, which is likely the thing that hobbles your performance the most. Your dread is your compass for success.

I sought out a difficult conversation today. I was afraid of it, and could have avoided it. The weekend was coming up, and I knew I could have run out the clock on the afternoon without confronting it. Yet, I also knew that it was the thing I needed – my workplace interval workout. If I had hidden from it, I would have felt weaker, and the underlying problem would have grown for lack of tending, making it much harder to tackle on Monday / Tuesday / whenever I couldn’t avoid it any longer. So, I made the conversation happen. It hurt some, and I got a little bruised, but I made my lot better by confronting it, and built my confidence that I could handle the thing of which I was (and still am, but less) afraid.

Know what scares you? Then go.