The Outbox – efficient collaboration without interruption

There are lots of ways to get team communication wrong, and I have been guilty of at least several of them!

Email too long. I’m reasonably good at thinking, I think, and reasonably good at writing, and thanks to dictation software, very efficient at turning thinking and writing into a torrent of words. Unfortunately, in a team, there is a considerable cost to creating words and consuming them. I’ve written too many words, too often.

Email too often. Some people are pretty good at juggling a long inbox where each message represents a separate chain of discussion. Many more people are not. I’ve often written many short emails which ignore the truth that humans mostly work in terms of a mostly-single conversation context with each correspondent.

Chat too often. Communicating via a chat tool avoids the many-simultaneous threads-problem, but it bumps into another rough edge of human communication. Even as we use tools which are technically asynchronous, we create distraction (or depending on the hour of the day annoyance). I have both witnessed and been the perpetrator of too-many-chats-too-often.

Long-term / short-term. Some of us have a knack toward thinking at both short-term and long-term levels concurrently all the time. Sometimes this pays off, but more often it is yet another anti-pattern in team communication. A team needs to mostly collaborate and coordinate to get done whatever is on the plate right now.

The Outbox

A few years ago, I stumbled upon a better communication pattern that avoids most of this. I’ve sometimes called it the outbox. An outbox is a place to keep short notes about things you need to communicate to various people; one note/page/file/whatever per person or group. It can be implemented as paper notes, a text file, in Apple Notes or Google Keep, whatever is most convenient. Each person’s output is independent and simple. Whenever some thought comes up, rather than immediately emailing or messaging the person it pertains to, jot a few notes in the outbox.

Then at some reasonable cadence (daily, twice a day, weekly, monthly, etc) discuss it all of it at once.

To keep these discussions sessions maximally helpful, divvy up your outbox between immediate/tactical and strategic ideas. This makes it easy to frequently collaborate on short-term matters, and then less often talk about strategic matters.

This pattern works well with both one-to-one and group communications. You’ll have something useful and planned to say if your team has a regular “stand-up” meeting. You’ll have something useful to talk about next time you have the opportunity to have a discussion with someone. You might even have something great in hand next time you bump into the CEO in an elevator (“great to see you, I’ve been meaning to talk to you about…”).

Even better, a bit of time to percolate in the outbox sometimes gives an idea the chance to go obsolete and be deleted. Maybe you wake up in the morning thinking, “I should talk with Anne about redesigning the company logo”. Should you email about it right now? Well, maybe, but this might be a distraction to Anne who is working on something much more relevant for today. Should you send a chat message to Anne right now? That’s even worse. Instead, jot it in the outbox… perhaps when you meet with Anne at the next interval, you may have realized in between that the logo redesign doesn’t make any sense to pursue tactically. So you discard the idea, never having created a distraction in the first place.

(I’m certainly not claiming this is a new invention. Thinking before you speak is a valuable idea going back forever!)

“Personal News”

Do we still call it “personal news”?

After ~22 years, I’ve left the company I founded in 2001, and the other I cofounded more recently. I’m briefly retired (!), but likely back in the game in 2023.

My contact information at my old work… no longer works. Personal email shown in the ridiculous image below, to foil spammer-scrapers in text.

Tremendous thanks to everyone I’ve worked with in the last couple decades!

Maximum productivity when you are the bottleneck

Scenarios that make you scarce

Software development productivity is the ratio of desirable high-quality software to money spent. With this meaning, productivity is aligned with quality and effectiveness: it only counts creating “the right software” and encompasses creating “the software right”. Productivity is more important than efficiency (the lack of waste), as occasionally a bit of inefficiency pays off.

In the quest for some combination of these values, project management methodologies or practitioners generally assume that members of a team have approximately similar scarcity/availability/cost. But sometimes, you may find yourself more scarce than a group you are working with:

  • You are leading at a high “fan-out” – one person leading a team of many.
  • You are leading a team expected (for good reasons or bad) to expand or turn over significantly.
  • You are much more senior than the rest of your team.
  • You are in an expensive city or country, other team members are in a less expensive locale.
  • You are a “hired gun” consultant, brought in at great cost, expected to “move the needle”.
  • You are a professional developer responsible for mentoring, teaching, and getting results from a group of interns.
  • You have a communication advantage with the customers of a product or project; perhaps you speak the customer’s language more fluently than others on your team.
  • You are the only team member with extensive and relevant experience to the problem at hand.
Continue reading “Maximum productivity when you are the bottleneck”

Populate your issue tracker at scale

Sometimes when working on a project at work, we find out about a pile of features or changes needed. This can happen at the beginning of a project, at the start of the major initiative, after deploying a project (which triggers much user feedback), etc. Sometimes we have so much to absorb and divvy up into issue tracker items, that the logistics of doing so are painful.

Just thinking through and writing down 50-100 issues (or more!) is too tedious for one person to get through quickly. To divide up this work (of describing a bunch of issues in enough depth someone could work on them), I’ve come up with the following approach.

First, I jot down a list of all the areas of the system where there are new issues to enter. This forms an outline of areas that have issues, I don’t even attempt to make an entry for every likely issue.

Second, I record one or more videos, showing the screen of the system I want to add issues for, alternating back and forth with code. As I go, I describe each problem/opportunity/fix, that should become an issue. Depending on whether the new issues are closely related to existing ones, sometimes this includes bringing up the issue tracker (Jira, etc) also, talking through existing items about work remaining on them.  Sometimes something that first seems like a new issue, is really just a refinement of the success criteria of an already known issue.

Having spent potentially quite a while just describing issues (there have been times when this goes on for over an hour), I hand over the recording(s) to a relatively new person on the team, who will go through and translate this rapid-fire description into a set of items. Typically it’s fastest for the person to do that not by directly entering the items, but by just typing the candidate issues into a document. (If the list is big enough, it can pay off to have a transcriber handle the first pass – turn the words from the video/audio, into text.)

Finally, that initial rough list of candidate issue, goes to the project leader(s) of the project in question, to clean up, refine, review, approve. Then someone copies the approved text into the issue tracker.

Admittedly this is not a complex process, hardly worthy of a blog post. But someone once asked me how we successfully enter so much detail into so many items on complex projects – and here is the answer. Entering all that really does pay off. It is much more plausible to delegate work if you have described it as thoroughly as you can.

Apply Enough Force

I have written and spoken many times about the importance of getting started. This is a key idea in agile software development (or for that matter, to many other kinds of work). If you refuse to start projects until you fully understand how they can be completed, you will miss many valuable opportunities.

When in doubt, start. But start with a modest budget, because there is an opposite and equally unavoidable fact of life. To complete a project of any size (one person-hour, or 1000 person-years), a sufficient effort must be mustered. Sometimes some of my fellow agile lists talk about working on a huge project one bite at a time, planning just the next few iterations, just the next scrum, whatever. This is all good, this is all agile. But it is important not to ignore the size of the thing you’re trying to accomplish.

To accomplish something of size (fast enough for it to be valuable) requires an approximate overall understanding of its size, then committing sufficient “resources” of all kinds:

  • Money
  • Time
  • Developers
  • Project managers
  • Marketers
  • Salespeople
  • Physical facilities
  • Lawyers
  • The list goes on

If it is not possible to commit enough firepower to the job at hand, then the right time to cancel or rescope an effort is at the beginning, not halfway through (the infamous point at which you are 90% of the way done but have 90% of the work still remaining). Keep that in mind next time a project is proposed. Understand the resources that can be committed, the overall scope of the project, and if they don’t fit, pick a different project.

 

Martin Fowler defines Software Architecture

Yesterday I saw the following video of a brief talk by Martin Fowler, in which he defines software architecture. I have grumbled about that term myself, in that firstly it is often ill-defined, and secondly it can be pretentious. I have sometimes defined software architecture as “high level design”, or as the design of systems complex enough to warrant substantial input from someone who is been around the block many times.

Fowler’s definition is crisp: Software architecture is those decisions which are both important and hard to change. This means it includes things like the choice of programming language, something architects sometimes gloss over or dismiss. Both aspects land squarely on the economics of software development. Said another way, software architecture is those decisions which, if made poorly, will make a project either succeed or fail, in a needlessly expensive way.

This connection resonates deeply with me. I have often talked about the economics of software development, the economic impacts of tool choices, the economic impacts of process selection, platform selection, etc. But Fowler’s talk made a connection I had never set out loud at least: the economic concerns, not only the technical ones, are software architecture.