Working at work

Getting work done at work is so hard because of all of those meetings. And so many of them don’t feel like a good use of time. So, I’m working on having fewer unproductive meetings. If you want to meet with me, you’ll have to tell me:

  • Intent of the meeting (and why it can’t be accomplish asynchronously)
  • Agenda for the meeting (showing why the length is appropriate)
  • What I need to do to prepare

If someone can’t tell me those, I’m declining the meeting. And, of course, because I wouldn’t hold anyone to a standard I don’t hold myself to, I’m not scheduling meetings without providing that information in the invite.


Time is a resource

As Project Managers we are taught to “manage resources.” Too often, however, the only resources that are managed are the people. There are others though, and I find the most important and often overlooked is time.

Time is not the enemy. We don’t fall short of the mark because time ran out on us; time is not an active participant in that way. Sure, it moves without our intervention, but the rate at which it moves shouldn’t be shocking. We fall short because we don’t manage time as the precious resource that it is.

I find that that most egregious waste of time is right in front of us: MEETINGS! I’ll take another post to address this specifically, but let me know what types of meeting you think are the most wasteful…


Care where it counts

I care a lot. I always assumed my frustration or disappointment at work was because I cared too much. Friends and family always told me that I had to learn to care less. “Leave work at work” was the sage advice I was given again and again. Since you, kind reader, may not know me, allow me to explain: I cannot leave work at work. Work is a part of my life and I can’t stop living a part of my life just because the clock has struck six. I care deeply about the people in my life and our time spent together, even if it’s at work. So, I can’t possibly care less. But I can focus on caring about the right thing.

Luck and great recruiters have allowed me to work with some of the most talented developers, business analysts, architects, and system administrators in the world. They have all proved to me that there are brilliant people who can do their jobs better than I ever could. But through their eyes, I have learned that I do what I do better than they can. In fact, they rely on me doing a great job so that they can do theirs.

Because I started as a developer and because of my management training, I’ve wasted a lot of time worried about the how. I, like many other young managers, felt as though the best way to make sure my project got done on time, on budget, and with high quality was to control all the details. As my teams grew and especially as I began to manage multiple teams, it became clear that my detail-control methodology does not scale. To make sure that I can grow as a manager and to make sure that I give my company the most value I can provide, I’ve really started to dig out of the implementation.

Here’s what I’ve learned for those we are looking to do the same: it’s hard to let go. Those who relied on you to fill in the details will take time to adjust to filling in their own blanks. Know that you will not make the switch flawlessly; you will leave things out of both the details and the greater picture. My advice to get through the setbacks: with each mistake, determine where your care and effort could have been better placed to prevent it. Continuous improvement is the name of the game. Keep the big picture in mind; the light at the end of the tunnel will slowly get bigger. Once you feel the warmth of the light, you will never look back.

There’s more…

I’ve been working on a few large projects and writing has taken a bit of a backseat. However, I do have several drafts from the past month. I have learned a lot and want to share. More importantly, I’d like to you hear your input; maybe you can help me solve some issues that keep coming up. Posts to come: The Cost of Offshoring IT, Communicating Effectively in Person, Tools – help or hurt.

Meetings don’t have to suck

I have been preaching for a long time that meetings don’t have to suck. I’ve been a part of some great meetings. All the great meetings that I have been a part of have a few things in common:

  • Short (30 minutes or under)
  • Small (There should be no more than 6 or 8 people)
  • Life Changing (Unless something is going to change, there is no reason to meet)

This is not to say that a there are not exceptions to the points above, but 99.99% of the time, they are true. Also, when leaving a good meeting, I want to work more. Good meetings inspire instead of discourage.

A few weeks ago, the San Francisco Chronicle published an article about how Larry Page mandated some changes to meetings at Google. The great thing about a CEO making changes like this is that he can follow through. Not only did he make meetings hinge on decisions, but he gave his employees the ability to decide. He went so far as to reorganize the company to make sure that each product has one person who is available to make hard decisions. One day, I hope to run a company like Mr. Page. Companies and employees should not be scared to make decisions.

The only bad decision is deciding not to make one.


Stop managing and start helping

Last week, I read an old blog post on As Chris Daily said, people need to “let go of the perception that they are in charge. In reality, you were never in charge, but you told everyone you were.” His words sat with me while I did my usual routine in trying to shepherd code from development to release. I paid attention to how much time I spent “micro-managing.” It was too much.

So, today I stepped back officially from my “managing” of the team. After only their second sprint it was obvious that they don’t need me to manage them; they manage themselves. I should be spending my time helping them get work done, not supervising or making their decisions.

Next week I’m going to be doing more of MY job (not theirs). My job is to coach. I am excited to coach with such a talented and devoted team.

Building cross functional teams

Scrum is a style of Agile software development that has become very popular. However, like its namesake in Rugby, the development methodology depends on the ideal that the team is at its greatest power when it moves ahead together as a unit: a scrum.

“Scrum relies on a self-organizing, cross-functional team. … The team is cross-functional so that everyone necessary to take a feature from idea to implementation is involved.” (Mountain Goat Software)

It’s a hard transition for some organizations to assemble a team that can operate in a scrum. If you are lucky, the management has already decided upon Scrum and is ready to assemble a cross-functional team. However, if that is not the case, it will be up to you, my fellow agilist, to advocate. The concept of Scrum is generally not enough to convince someone new to the ideals. More often than not, the first team includes only application developers. It takes time to get buy-in that the team really does need a database guy AND a solutions architect AND a QA person.

I’ve found the best way to bring everyone into alignment is to carefully warn about the possible side effects of not having a cross functional team, continue to work as hard as possible, and see how it goes. What seems to happen is that the team begins to feel the void where a function is missing. Let the team decide what it needs. I always recommend having the outcomes/goals of your retrospective posted and available for all, including the leadership of the company, to see. If one of the outcomes of the team’s discussions is the need for a more cross-functional team or an additional team member, use that information to bring it to the management’s attention.

Letting the team decide what it needs is important in all changes. Only the team knows what it needs and what it’s comfortable changing. The team will determine the right mix of functions to create the perfect cross-functional team.

Just getting it done is getting me down

I am demanding.

I want work to be done perfectly every time. I expect everyone to have the same attention to detail and follow through as me. Guess what? It’s frustrating and the frustration doesn’t yield better results. Even worse, the frustration is mine alone and doesn’t help anyone (specifically the person I’m frustrated with) improve.

Time to step back and look at the problem. As Chris Daily said, people need to “let go of the perception that they are in charge. In reality, you were never in charge, but you told everyone you were.” This is incredibly important because we were raised in a world where bosses told you what to do. It’s not unusual for people to come to me and ask questions like “How should I do this?” or “What exactly do you want?”. These questions are the root of why I’m often disappointed with the final product. If I decide the how, what stake does the person doing the task have? He won’t have any ownership and by using the prescribed solution can easily implement without much thought.  But I want him to think! I want him to come up with different solutions, talk to his peers, make decisions that the team can agree on, and own the solution.

Instead of answering with how, I am trying to enable the team to decide by itself. I am stopping myself before answering, counting to ten, collecting my thoughts, and framing my response as an agile coach. I hope to find myself answering how with a suggestion to sit and talk the problem through with the business owner and team. I hope to find myself less frustrated and more productive.