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.

The bottleneck of false import

I have only been at my current organization one year, but somehow I am already the definitive source for information. I am no technical expert, but find myself making technical decisions. I care so much about getting the job done (both well and on time) that I weigh in on technical decisions just to expedite.
Here’s the problem: with every new system and each project, more information is in my head and I become even more relied upon. But I am still one person with only so many waking hours, two ears, one mouth, and one tired brain. I have become a bottleneck without meaning to. No matter how much I decide or how many people rely on me to “be in charge,” projects aren’t getting done better or faster.
The solution: use all the knowledge I have of Scrum development and being an agile coach to forge a new path.
Turns out moving from the guy who knows everything to the agile coach ain’t easy. At this point, it’s equally changing my internal behavior as much as teaching others to adjust to my new external behavior.
I turned a meeting that was “standup” by name into a real scrum stand up. We answered the three questions, we tried to move conversations into follow ups; it was beautiful. Not perfect but beautiful.
Here’s how we did it: I acted as the Scrum Master. I told everyone the rules and enforced them. I tried to assist by recording the blockers so the speaker felt he could safely move on to the next person and his blocker would soon be addressed. The team did the rest. For now, I’ll setup the follow up meetings. One change at a time. Tomorrow we’ll do it again and hopefully it will be easier. By next week, I will try to have encouraged everyone enough that they setup the meetings and resolve their own blockers as a team.