Focus meetings just on decisions, wither understanding?

How Larry Page Changed Meetings At Google After Taking Over Last Spring

Every meeting must have one clear decision maker. If there’s no decision maker — or no decision to be made — the meeting shouldn’t happen.

No more than 10 people should attend.

Every person should give input, otherwise they shouldn’t be there.

No decision should ever wait for a meeting. If a meeting absolutely has to happen before a decision should be made, then the meeting should be scheduled immediately.

I really like these guidelines, and I’m tempted to adopt them whole cloth with my team.

My team meeting agenda is mostly updates on what’s happening within the teams and within the larger organization. There’s a lot of value in seeing someone’s reaction to news and having a chance to answer questions and stop misinterpretations before they start in a setting like that.

On weeks when we haven’t been able to meet, I’ve often sent out my notes of news from the organization I wanted to share. Inevitably the next week I take a few minutes to breeze through it and uncover that someone didn’t understand or made a faulty assumption about what I wrote.

(Via. Business Insider)

Posted in Management | 2 Comments

django-configurations: Sanest approach I’ve seen to having multiple DJANGO_SETTINGS_FILE setups for your various environments.

Plus it looks like it’d work really well with envdir which lets you store environment variables in files in a folder and execute programs using that folder’s files as the context. Example from the docs:

envdir envs/prod/ python runserver

(Via Glenn Siegman)

Link | Posted on by | Leave a comment

Applying “patches welcome” to management

Refactoring organizations to increase your impact: “So we changed the meetings to focus on proposals instead of problems. Stating and identifying problems is fine, and sometimes it’s all we can do when the solution eludes us. But proposals are the heavy artillery in meetings. They force us to focus on possibilities, and they force us to do our homework and weigh the alternatives.”

Things I love about this post:

  • Proposals as the management equivalent of “pull requests” or “patches welcome”
  • It’s a more sophisticated version of the old management trope “Bring me solutions, not problems”
  • It’s another post about management from folks in the technology industry, something I wish there was more of
Posted in Management | 1 Comment

Personal Kanban with Asana

I’ve found that Asana’s sections and subtasks feature makes it really convenient to set up a personal kanban system.

Here’s what my tasks screen looks like:

Asana task list

Later is the total backlog of stuff to do and it stays collapsed. I have a recurring todo to review the Later pile and pull items into Upcoming.


Upcoming is my backlog for the week. I’ve divided it into days so I can schedule out my week. I put items that need more time or analysis on days with bigger blocks of time available, and the shorter tasks fit into days with more meetings.


Meetings get todo items as well. That forces me to weigh the meetings against the other items on my list, and to think about what I need to do to prepare for the meeting.


Today gets subdivided into three sections: Meetings, WIP, and Todo. Meetings for the day go there on the day-of. Todo is a list of new tasks or sub-tasks that I haven’t started on that I’d like to accomplish today.

WIP is where any task that I’ve started, but not completed, goes. It’s my work in progress column. I review it daily, and see what next steps I need to take to complete those items. Sometimes its following up with someone whom I need input or approval from. Other times I’ve already put a next step into that item as a subtask.

With Asana, you can put subtasks into Upcoming or Todo, while the parent tasks stays in WIP. As a manager, a lot of my tasks have a “ask and wait for feedback” step. So I create a subtask for “Incorporate team’s feedback” and schedule it for the day after the feedback is due.

Finally, a word on Due Dates. I love to use the due date as a tickler function. I have a good idea. There’s no room in my current week, and the new idea isn’t important enough to bump anything off the list. I give it a due date for a week or two out and stash it in Later so it’s off my mind. Then when the due date comes up it automatically shows up in Today for me to consider scheduling it.

For items where I have a firm due date I promised someone else, I set a due date and tag it with fixed-date so I know its deadline is unmovable.

Posted in Kanban, Personal | Tagged | 2 Comments

Agility in a nutshell: Look, try, learn, repeat; favor easy change

What to do:

  1. Find out where you are
  2. Take a small step towards your goal
  3. Adjust your understanding based on what you learned
  4. Repeat

How to do it:

When faced with two of more alternatives that deliver roughly the same value, take the path that makes future change easier.

(Via Agile Is Dead (Long Live Agility) – PragDave)

I don’t necessarily care about PragDave’s  “fight” against uppercase Agile in favor of agility. I do think this is one of the best descriptions of agility and of Kanban’s principle on incremental, evolutionary change

Posted in Kanban, Management, Programming | Leave a comment

Communication is what the listener does

One of the most insightful and challenging things my boss has ever told me was: Communication is what the listener does

Think about the ramifications of that statement:

  • Another developer didn’t understand your architecture proposal – It’s on you
  • No one bothered to reply to your code review – It’s on you
  • You try to convince your team that a new library will make your jobs easier – It’s on you

Successful communication is all up to you.

Here’s the basic communications diagram they teach every journalism student, ever:

communication (2)

With the responsibility of successful communication squarely on the the stick figure to the left, what might she do to make sure the listener does what she was hoping for?

  1. Tailor the message to suit the listener. How do they like to be communicated to? The sky’s the limit when it comes to their preferences: in person, via text, audio, slidedeck, interactive game, with data, grounded in values, all of the above, and more.
  2. Account for interference. It can be technical interference like a bad video connection or too much background noise on a conference call. It could be on you.  Maybe you get really defensive about this subject so that gets bundled in along with your message. It could be on the listener’s end. They might not be in a good mood because of something at home, with a friend, or their pet. They could be
  3. Pay attention to feedback. Is the person tuning out? Are they on the edge of their seat? Are they telling you they understand what you’re trying to say, but they don’t agree and “here’s why.”
  4. Remember that feedback comes with its own interference. Pay special attention to the interference you bring to the feedback. Maybe you don’t like to be interrupted but the listener is doing it anyway, that doesn’t make their feedback any less valid. Maybe you were so excited about your idea, you weren’t at the point yet where you could take any feedback. That doesn’t make the feedback any less valid either!

How many of us when confronted with an unsuccessful communication attempt, fall into one of these or other mental traps:

  • My idea was so good, they’re clearly not smart enough to understand it
  • I told them this was a problem, they didn’t listen, so it’s on them
  • I spent 4 hours diagramming the whole thing, why couldn’t they follow my instructions!
  • It’s patently obvious why this is a good idea, why won’t my boss approve it!

If you do, and you don’t remember that communication is what the listener does, then don’t be surprised if you’re continually unhappy with the results.

Posted in Management | Leave a comment
  • Fudge – Good looking Python mocking library.
Link | Posted on by
  • If it hurts… – "If it hurts, do it more frequently, and bring the pain forward"
Link | Posted on by
  • The One Thousand Hour Rule – "You need to put in 1000-hours of hard work on a new project to begin seeing meaningful returns."
Link | Posted on by
Link | Posted on by | Leave a comment