The way I see it, all human behaviors and interactions are motivated by raw fear.

We are forever bound to it with our lizard brains shaped by millenia of evolution. Our brains are hardwired to constantly scan our environment and seek out threats. Sometimes the threats are real (lion in the grass). Usually they are not (wind in the grass). But however false the threat turns out, we are forever scanning, forever bound by the possibility of the threat. 

This concept—once grasped—can be a useful tool to analyze our world and help us make better decisions.

Consider an artist who claims they would die were they denied their paintbrush, so strong is their need to express their feelings and ideas on the canvas with shapes, colors, and textures.

Would they literally pass away if denied a drawing instrument? Obviously not. Ask yourself then: what could possibly cause such a passion? Nothing more than hyperactive pattern-searching. The artist’s brain is particularly tuned to patterns, contrasts, variations. The artist’s control of their hands and eyes is particularly tuned and trained to produce such patterns.

Ask yourself: why do you seek work? Why do you want to keep working? Why do you try to do your best work, or (inversely) why do you want to blend in and do the bare minimum? What drives you to learn and try convince others around you to learn, or (inversely) what drives you to keep status quo?

We are all driven by whatever fears our brains detect or generate. And the fears are constantly battling each other.

  • Fear of not being recognized by our peers or superiors 
  • (Inversely) Fear of rocking the boat and upsetting our peers/superiors
  • (Alternatively) Fear of your skills stagnating and not being able to acquire employment in the future

Which cascades to:

  • Fear of losing work
  • Fear of losing money
  • Fear of losing possessions
  • Fear of losing leisure and rest
  • Fear of losing loved ones
  • Fear of perishing yourself

I’m of the opinion that we can actually capture our fears and use them to drive our work. I’ve discussed the benefits of constraints previously.

The most potent—and arguably the hardest—thing we can do with a fear is to recognize it, identify it, examine it, and respond with a better understanding.

Fear is good. Fear is right. Fear works. Fear clarifies, cuts through, and captures, the essence of the evolutionary spirit. (with apologies to Gordon Gekko)



There Is No Team

Consider ants searching for food. From the outside, it seems like a well-coordinated effort of searching, finding, signaling, and swarming. But when you dig deeper, a more boring reality becomes apparent. One of the ants wandering around finds a bit of food and its body begins emitting a chemical trail. When others stumble upon this trail, they instinctively follow it knowing that it will lead them to food.

Consider a school of fish evading a predator. From the outside, it seems like a well-coordinated effort of angling, disbursing, and re-connecting. But when you dig deep, a more boring reality becomes apparent. Fish traveling in schools instinctively prefer to swim close to other things that are roughly of their size, shape, and color. So when your neighbor moves away, you follow it.

This is a phenomenon of emergence. Simple interactions between a group of individuals, when observed, suggest a single creative force driving the group.

Consider a team of people who were persuaded to work together with money and free pizza. From the outside, it seems like this is a single well-coordinated entity, moving about, making things appear, day in and day out. We throw about phrases, such as “the team thinks, the team agreed, the team … feels.”

But when you dig deeper, a far more boring reality becomes apparent.

Can a school of fish think? Can a flock of birds feel? Can a colony of ants agree?

Can your team?

When we interact with one another, there are two things happening. When we converse, one of us is speaking, another one is listening. When we show, one is pointing, another one is looking. When we communicate with written methods, one is writing, and another is reading.

It is tempting to think that these highly complex interactions are happening simultaneously, but they do not. Each one is an observe-respond pair of actions. A action triggering a response, triggering further actions.

Combination of these individual actions combine to form an an illusion of an interaction. When we multiply these interactions by the people involved, the emergent system is your team.

You cannot change the emergent behavior of a team by trying to change the team as a whole. The team is not a thing you change, it is a thing you observe.

If you dislike what you observe and you would like your observation to change, you must aim your actions at individuals.

Yes, you must constantly scheme to force what emerges to be in the state you find pleasing.

Do you not like that your team is constantly in the dark and you would like the team to be more open? Talk about it with your team mates. Be open with them yourself. Ask them specific questions you feel they’re hiding.

Do you not like that your team does not appear to be motivated and appears to be just a bunch of slackers? Motivate them by your own example. Come up with ways to engage one person at a time with a problem. Trick them if need be.

Even by wanting to be left alone, you are in effect controlling your actions to minimize reactions, and this behavior directly leads to the kind of a team you are wanting to see.

In reality, you do this anyway, you just may not admit it to yourself.

Project Management Triangle — Redux

A co-worker recently blogged about a classic metaphor of the “iron triangle” whereby the three conflicting pressures of resources, scope, and time are interlocked. The rationale goes that only by loosening one of the pressures will you be able to affect the other two.

This metaphor is usually used by those who have the unlucky task of managing software development projects. It works wonders when presented as an inspiration to motivate the team at sprint launches.

It is when teams try to apply this metaphor in practice, they often find that the triangle is not as flexible as they were led to believe. The date is non-negotiable. Scope? No, customers expect a certain feature set. Can we get more people? The ramp-up is too time-prohibitive and besides we have tons of other projects that we need to deliver, so… no.

Despair. Death march.

Happy Happy Fun Times

The only way out of this morass is honest, deep, challenging conversations and creative thinking. More often than not, code is the least complicated part of the solution.

As I’m fond of saying, if it was easy it wouldn’t be called “work” it would be called “happy happy fun times.”

I think the iron triangle still applies, though to figure out how to move each of the corners, we need to zoom in.

Resources People

Talent – Some people are just naturally better problem-solvers. You know who they are in your company. Bring as many of them as you can find.

Experience – People have varying degrees of familiarity with the system or the business domain. They will help smooth out rough spots when first starting out. But be sure to balance this with some total n00bs to spread the good knowledge and bring in fresh perspective.

Personality – I’ll go ahead and say it even though it may be unpleasant: you want a dynamic team, not a bunch of loners forced to sit next to each other. You want people who are good at communicating both verbally and non-verbally. You want people with a generally outgoing demeanor. Cultivate these qualities, work on them, challenge your people to loosen up.


Width vs Depth – It’s understandable: customers expect certain new functionality, sales is clamoring for shine and customization. But consider how deep does each feature need to be. Is there a simpler approach you can take to satisfy end-user’s need? Ask yourself what you would do if you only had a week to implement this feature? A day? 4 hours? An hour? Take that hour and build a working prototype of your idea. Show it to your product owner. It will never be good enough to ship, but it will force the product owner to rethink whether they leaked too much instruction to the team as to what they expect to see. This will also force you to actively participate in discussions and deeply understand the user’s need.

Dependencies – If you think the user-interface card depends on the logic card which depends on the database card, stop! You’re heading into a swamp. Features depend on each other, deployment layers do not. Each card should consider the full flow of user experience: from user interface, to logic processing, to data persistence, and back. Start with minimally viable parts of the flow: instead of a fully featured form, start with a form with just one field. Follow it up with dependent cards that build on top of that form. Stay strong when cowboy engineers push back with “…but it’s just a couple of dumb fields, it’s so simple” — that’s how complexity creeps in.

Visibility – Time and time again I’ve seen engineers (myself included) grab onto the work they understand very well and burn through it, with eyes glazing over when product owner mentions areas that sound complex. It’s only human nature: we’re afraid of the unknown. Fight that ferociously. Demand that your product owner lay out the entire project in front of your team. Work towards deeper understanding of all areas. Split off into sub teams to build prototypes for each area, form intelligent questions, find conflicts, do whatever it takes to ensure that everyone can describe everything the team is working on without BSing. Having this information upfront is absolutely invaluable as milestones start approaching.


Embrace Deadlines – I love time constraints. They force everyone to cut out the crap and harness the adrenaline rush to reduce their work to bare essentials, no more no less. If you’re pissed that people keep setting dates for you, get in front of them and set even more aggressive limits for yourself.

With the time pressures as your guide, you can NOW start thinking about how to start pushing the corners of the iron triangle.

A fluidly functioning team full of outgoing people will be able to absorb additional people with little problem. These new people will be able to start becoming productive immediately because you can give them features that don’t depend on other features and because the features you give them will be well-defined and understood by the larger team.

With everyone feeling free to challenge every requirement and thinking of what is minimally viable, you will find most of the system spreading out very fast yet staying malleable because this wide set of features is still very shallow. Now you will be in an enviable position to decide more strategically which parts of the system you want to continue enhancing.

You won’t even notice that the deadlines have come, and they will be nothing more than a pleasant surprise.

On Business

It seems to me that business is today what it has always been: a cut-throat race to stay above water and keep making money for the sake of making more money. Even non-profit organizations have the same drive. Employees and customers shouldn’t expect the company (or any company) to be good to them any further than the agreed-upon contracts, any more that the company should expect the same from its employees or customers.

People don’t form bonds of attachment with the company, people form bonds of attachment to others working side-by-side with them. We all long for the good times to return, and wish for bad times to never be seen again.

Neither the company nor the people in charge of the company can control those outcomes for every single employee or customer. As more employees and customers the company keeps happy, as does the bottom line begin to suffer. As more focus shifts on improving the bottom line, some employees or customers are going to be unhappy.

It’s all a big equalizing act. It’s all about judging what is the right level of happiness for you to continue dealing with the company (any company). Once your threshold is reached, you can decide to part ways.

Task List For Programmer’s Soul

I was talking to a lawyer friend of ours last night about driving your daily work based on a strict task list. I can’t say I was surprised to hear that he also keeps a task list for the day ahead. But as the conversation went on, I realized that we need to keep track of completely different things when we keep track of tasks. A lawyer effectively “delivers” dates. Did the contract get written up by the promised date? Were the papers filed in court for that case by the required date? There’s no “next release” as such.

For a programmer, things are a bit different. The useful outcome of our labor is features in software. Software with one few feature is still working software. We enhance software one step at a time.

As a programmer, I find I’m always having to juggle many features, bugs, and nice-to-have ideas. I have to figure out what is the most important thing I should be working on at any point in time. At the same time, I have to keep an eye out on the plethora of other things that may more effectively enhance the software I’m producing.

Now, I’m not talking about the overall list of tasks, features or bugs for the product I’m working with. That is a topic far outside the scope of this conversation.

I’m talking about the list of tasks and subtasks that concern only me. The small tasks that let me achieve the bigger tasks visible to everyone else. The tasks that would be noise to my team.

The task list strategy I’ve honed over the last couple of years is mostly inspired by Joel Spolsky’s task list strategy. I mix in a bit of GTD (getting things done) to come up with something makes a lot of sense to me, and eliminates a lot of FUD (fear, uncertainty and doubt).

There are a few attributes that I hold dear in my task list:

  • Flat list. No hierarchies.
  • No priorities, ever. The first position is special in that it describes what I’m working on now. Anything below the first position is a loose attempt at deciding what I’m going to work on after finishing the almighty now-task.
  • The now-task is small and has a tangible, measurable outcome.
  • Secondary tasks can be as ambitious and unclear as you want. Everything I don’t want to forget goes here. The closer to the top I place them, the more likely they are to become the now-task.
  • Completed tasks move to the very end of the list. They are not deleted. This is simply a confidence booster. (Could be used for tracking and billing.)

I know better than anyone what I want to accomplish as part of the now-task. If the task is too ambitious, I won’t be able to mark it completed, which leads to frustration, which leads to flawed perception that the task list is not working. You know the proverb “every journey begins with a single step”? That single step is the size of my now-task.

To tell the truth, most of now-tasks start out overly ambitious. As I’m working on such a task and I realize that I over-estimated the work required, I pause, decide what small bit I think I’ll be able to achieve. That becomes the new now-task. The old task is either pushed down the list or is eliminated altogether for lack of clarity.

The final hurdle to my workflow was my failed attempt at Merlin Mann’s Inbox Zero system. I had all the Ds down, save for Do. What do you do when you want to do an email, but you just don’t have time at this moment? I tried using my inbox as the task list, but it doesn’t even come close to the desired attributes I mention above. What I finally decided to do was manifest each “do” email into a task on my task list, and immediately archive the email. This way, I don’t forget to get back to the email, and the email is not sitting there in the inbox, constantly mocking me.

I tried many tools over time to help me achieve a way to keep a list of things to do, without getting in the way. Here’s a summary of some, in order I’ve tried them:

  • Moleskine Notebook (aka Hipster PDA) Pros: stylish and portable. Cons: Can’t re-arrange ink. Also, susceptible to theft, loss, and fire.
  • Remember The Milk Pros: Relatively easy to add tasks. Sync to pretty much everything in the world. Cons: Can’t re-arrange tasks. I tried to mimic something with tags, but it felt foreign and caused a lot of friction.
  • Text file/Word document, etc. Pros: Each task is a paragraph. Easy to move tasks around via copy-paste. Easy to back up and sync. Cons: Formatting is either lacking or requires confusing conventions. Backup/sync is your responsibility.
  • (current winner) OneNote. Pros: Each task is a paragraph. Moving paragraphs up and down is a built-in functionality (a little doohiky to the left of the paragraph), which works brilliantly for my needs. I can visually decorate the paragraph with a “task” tag, which supports visual marking for completion. Automatic sync to my live account, almost as soon as I finish typing a paragraph. Automatic sync to my Windows Phone 7. Cons: Decorating a paragraph with the task tag requires a CTRL+1 keystroke, wish it was automatic.

Well, time for me get compete this task, and figure out which of my secondary tasks is getting promoted.

Now I Love Yogurt

Personal note: When I was 6, I refused to eat yogurt and continuously got in trouble with my parents and teachers in my kindergarten. One day late August, the kindergarten received a spoiled batch of yogurt. Everyone came down with severe stomach pains, requiring an armada of ambulances to take everyone to emergency rooms. Everyone, except for a very confused little me.

TechEd 2010

Wow, TechEd 2010 was so much fun. Plus, I got to visit New Orleans, where I’ve never been before. What a crazy town! It was so hot though, and I know Cleveland hot, so that’s hot.

I loved that pretty much everywhere there was food, there were bottles of hot sauce, usually Tabasco. I also believe every waitress there is required by law to call you “baby.”

I got a few chances to stroll around French Quarter. It’s such a unique neighborhood, aside from all the crazy drinkin’ and partyin’.

Got a lot of SWAG at the conference, especially at the partner expo. It was so fun to meet all the Microsoft folks and talk *deep* about what they’re working on. I must’ve spent about 30 minutes talking to Luke Hoban about F#, Clojure, and functional programming in general.

It was so great to attend both of Udi Dahan’s talks (between you and me, the only thing I was looking forward to): one on non-nonsense high-availability and one on CQRS. I’ve seen his CQRS talk before online, but he added so much fresh content, and really solidified a few points.

A few other talks stand out in my mind. Juval Lowy’s talks made me rethink the value of good architecture, plus his AppFabric Service Bus was so interesting and clear to follow. He’s such an effective speaker and definitely doesn’t baby the audience: “… and if you don’t know WCF, we have some crayons in the back for you.”

Saw Mark Russinovich’s “Case of the Unexplained” talk: the last one of the conference, and the auditorium was packed! It was so empowering… makes me feel like I could tackle any Windows problem.

It was so fun to dive deep into Windows Phone 7 development platform. Unlike what you may hear in the media about TechEd 2010, Windows Phone 7 was a first-class citizen there. Lots of developer and business talks about it. Also there were hands-on labs where you could learn about the basic and very advanced development topics with a guided tour. The coding4fun guys did a demo about how they built the t-shirt cannon/tank at scottgu’s behest. I was one of the lucky few on whose lap landed an awesome “i love windows phone” shirt. It was my favorite of all the SWAG.

While I’m still recovering from the trip, I’m already missing the incredible atmosphere. If you get a chance to go, don’t pass it up.