Archive for the 'Team Building' Category

Do the Simplest Thing You Possibly Can

This post borrows ideas from TPS and metacool but hopes to bring ideas to these ideas to life with a concrete example.

Right now at work, we have a project that seeks to get a better understanding of how small businesses could use voice technology to organize workers and streamline process.  Very cool, cutting edge stuff and quite complicated.  In fact, in order to work with businesses, I’m going to have to set up a VOIP line for each…


Wait just one minute here.  Whats the goal? To understand how small businesses can use voice technology (VOIP, transcription, recognition, etc).  Okay, but is it possible to achieve the goal without actually bothering with the technology?  Seems silly, but in this case it actually is.

In fact, I can provide any one person with a state-of-the-art voice recognition system lightyears beyond what’s on the market today with just 5 minutes of work.  All I need is a home telephone line, an answering machine, and my brain (which happens to be able to process audio files, extract semantic meaning, and transcribe to text).  See, in this case, voice technology has actually nothing to do with the problem you are solving.  It has everything to do with scale.  But when you are just trying to prove that there is a business case, the technology really doesn’t matter.

Now before someone thinks I’m advocating for the proliferation of vaporware, I’m not.  You’ve gotta love the technology too.  Before you get all excited that you’ve just invented the next gazillion dollar industry just because you know how to use an answering machine and can speak english, you need to know that you can get the technology to work.

But my suggestion is this: first, do the simplest thing you possibly can.  prototype your solution.  Then, with all the time you have leftover (because how hard is it to answer phones?) get a real grip on the technology.  Once you have a good understanding of both the customer problem and the technical solution, then you are free to get excited.

Deadlines need a bite

Now i don’t mean this quite as literally as pictured here, and this may seem obvious after I say it, but recently I asked myself the question:

“Why do deadlines work?”

It’s pretty common knowledge that in order to make progress on any project a team needs deadlines to more forward, but why?  Why are people so bad getting work done in the absence of a deadline?

My answer came to me in a bit of a round about way.  Our team had a deadline that we did not hit.  Everyone knew what what had to be done, they even had enough time to do it, but when the day came and went, the work was not done.  Clearly, there could be 100s of reasons for this, but after i reflected on it for a while one in particular stands out for me.

We did not set up a face to face review.

My thesis is the following: knowing a deadline just isn’t enough.  Deadlines are just dates on a calendar unless people feel social pressure to get something done.  No one likes disappointing their team, and they especially don’t like looking teammates in the eye when they disappoint.  So when we talk about deadlines, perhaps it would be best to frame them in the form of a review meeting.  “Are we going to hit our report out to the boss?”  To me, that is the real bite behind a deadline: social pressure.

It doesn’t have to be a negative thing of course.  I would never want a team where there was unrealistic or antagonistic social pressure.  However, I think a recognition that a little social pressure in a team setting is the real magic behind deadlines will help me to craft more effective ones.

Be Specific!

I think i’m developing a bit of a split personality.  Before jumping to conclusions, let me tell you what I mean.  In one part of my life, abstraction is king.  As a programmer, your ability to recognize, comprehend, and apply abstraction is a fundamental tool in your toolkit.  Without abstraction – and proper application of it – large programs would be utterly incomprehensible.  They would be just a mix of random words and numbers without any means of interpretation.

But on the other hand, in the realm of business, I’m finding that abstraction can be quite dangerous.  Abstraction – and it’s evil cousin, vagueness – lead to all to many long meetings, or worse, miscommunication.

When communicating – with words, not code – I try my best to support everything with specific examples.  This can be hard to do sometimes, and i certainly don’t always succeed, but specificity in language is – i think – a good goal to strive for.

So in the interest of following my own advice, here’s an example of what I mean (it would be a pretty ironic post if i ended with the last paragraph, huh :) ):

This evening I sent out an email to our RIA meetup group.  I was asking for input on our next topic.  Specifically, I need two people to prepare some examples of UI design patterns they have followed when using RIAs.  Rather than just leaving the request at that, I provided an example about how my team used a JS call to caution the user away from hitting the back button and therefore losing all their work.

I hope that this specific example helped to clarify my request and hopefully made the task seem easier than it would have been if i had just left my request in a general form.

You have examples of how clarity in communication has helped you?

ps. the picture is totally random

Who, not just What

It never ceases to amaze me how easily teams can get distracted by what they are doing and never really stop to ask who is doing it and why.  This really should go without saying, but different individuals on every team have very different skills.  For simple things this is obvious: you generally don’t want to have programmer writing help documentation.

But there is another level to this axiom that I think goes unnoticed too often: What you do, must be informed by Who is doing it.  It is flat out wrong to decide what your team should be doing without taking into consideration who will be doing the work.

I have seen this play out countless times before.  Someone decides that we need to accomplish some goal.  Let’s say it is writing an app extension.  So we decide to write an app extension and then we turn around to our app team.  Oops! we don’t have any time on this team.  Okay, no problem we’ll just give it to this team over here.  Nevermind that this team has 0 experience with any of the tools or technology or process for writing an app extension.  We decided that this needs to be done, so lets get it done.

This just makes no sense.  What if that other team happens to be really good at building engineering tools?  Because an app extension was your first choice you’d rather have an extension that takes 2x as long to build and has 1/2 the quality over a great set of developer tools that boost the productivity of all the other teams in the organization?

Of course this is a contrived example, but I’m sure you can think of many situations like this.  When designing and prioritizing you should do at least one of these two things: Either you should know your team well enough that you can envision who will be doing the work before you decide to do it, or you should give your team members the freedom to push forward the ‘Whats’ that they are most passionate (and skilled) at solving.  If you miss these things, then you might be setting yourself up for some serious disappointment.

Collaborate Through the UI

Over the last weeks and months I have started to develop a theory of team collaboration. I have watched my team struggle with 1) internal team communication 2) external communication, and 3) motivation. I have heard over and over again “we’re not making any progress.” “What have we been doing for all this time?” At first, I was wondering the same thing: where did the time go? After reflection, I believe that my team IS in fact making progress, it is just that we have 1) made progress on intangibles and 2) allowed ourselves to drift a bit more than we should.

I believe that a major cause for this is our selection of tasks over the past few months. We have chosen ‘explore’ type tasks. Or design tasks. or infrastructure tasks. All of these are important and eventually need to get done; however, focusing on them in isolation has caused some serious problems. Although we are all in software and all of us know and understand that there is a whole more more to software than UI, the reality is that people, human beings, react to what they can see, touch and feel. I believe that if we had allotted just 20% of the infrastructure time toward UI, those “what are we doing” questions would dissolve. The reason: we can point and say: “that. that is what we have been doing”

I believe that ability to point and say ‘that’ has the potential to solve the three problems my team is having. First, a UI (even a nascent one) causes the whole team to get involved. When there is an interface to see, Designers want to contribute, PM’s want to argue over features, and project managers can explicitly see the holes that need to be filled. Second, where there is a UI, it is much easier for managers to communicate with executives outside the team. Third, when progress is visible, the team is motivated to continue to make progress. It is extremely easy to get stuck in a design, research loop. Working on the UI helps to break this loop by making it more clear exactly what is necessary and unnecessary at lower levels of the application.

What I describe above is not dissimilar to the XP concept of flow. All i’m saying is that for many teams, motivation hinges in the ability to see the fruits of their labor. I think many teams would benefit from investing a little bit more in the UI sooner than what would seem natural.