A new workplace Q/A site needs you!

I'm a big fan of the StackExchange network - it's QA done intelligently, and applied to an ever-growing range of topics.

A few days ago a new StackExchange site entered public beta called "The Workplace." It's all about work, jobs, workplace issues (from HR, to client relations, to productivity, to politics and more).

Come join the community; if you've got a question that hasn't already been answered, ask it! You're likely to get a fairly quick response (in fact, you'll probably get multiple responses, and most within 24 hours) with numerous perspectives, cultures, workplace types, and nationalities represented.

What we're missing is you! We need more representation in a broader range of professions. The site has started out with a heavy contingent of IT and software folks, and I would love to see people from all sorts of professions join up so that the tech folk (like me) aren't hogging the conversations. I would also love to see more questions asked and answered from the perspective of upper management, executives, and folks in HR roles - perspectives that are often not shared beyond the bounds of their own membership.

Task flow

One of the most valuable lessons I learned when working in IT was the idea of task flow. It's what you do to manage long lists of unrelated tasks, while not losing track of where you are. At ProNet we called it "managing your queue," and it's a skill I've taken with me to all assignments ever since.

The list

It doesn't matter what form the list is in - even paper will technically work - but you need a list ot keep track of what's on your plate. Once you've got the list, you need to make it habit to add things to the list that are important. I tend to have a relatively low threshold for the meaning of "important." I just put everything on the list that I need to remember, and if later it turns out not to be important, I just cross it off and move along.

Estimating, scheduling, and prioritizing

Do you have a list of 30+ items, each of which is for a different client, and you're not sure which should be done first? Been there. If you don't schedule and prioritize these things, the inevitable outcome is that you'll have conflicts, and things start to fall through the cracks. Sometimes you'd have nothing pressing to do for the next hour, but after that you had seven things to do all at once. Scheduling and prioritizing will help even out the waves of work into something closer to a steady flow.

Estimating is a matter of experience

What you want is basically this: after you've been in a job for six months or so, the ability to pretty accurately estimate how long something is going to take to accomplish. When you know that, you can put it on your calendar, set a reminder, and get back to crossing things off the list. Depending on how fragmented your typical day is (some people can schedule entire half days toward something, while others can barely schedule 15 minutes reliaby), you need to scope your items to match your level of fragmentation. If the thing you're trying to schedule is more than 2x the amount of time you can reliably schedule, then you should try to break it into sub-tasks that do fit on your schedule. When you can get items on the list pared down to easily digestable chunks, conflicts in scheduling become much less of a problem.

If your main issue is that your day is highly fragmented, and it's very difficult to schedule anything (many people in a customer service role feel this way), then much of this will still help you. This process is about taking control of the amount of crazy in your work, making  it easier to manage and plan, and getting more things done.

Scheduling is a matter of habit

So, when you're adding something new to your list, whenever possible, you should schedule it right then and there. When I worked in IT and managed a service ticket queue, my habit was to create a new ticket for incoming requests immediately. Not writing it down inevitably leads to forgetting things.

In addition to always making the note, the ideal scheduling scheme is portable. If you go to a meeting, it would be preferable that you bring your calendar with you, so when you're asked to take on that new volunteer project, and you estimate it will take two weeks, you have some idea when you can start, how it will fit in with everything else, and most importantly, when it will be finished. If it's not possible to have your schedule with you at all times, say in a meeting, then make 15 minutes immediately after the meeting to figure where new items fit in, follow up on pending commitments you put off for the meeting, and then get back to working on the list.

Prioritizing

The world is a place constantly asking for your attention. If you say yes to everything, you're going to over commit yourself. If you think volunteering for every project under the sun will make you look like a go-getter, you're not thinking about what happens when you have more to do than you can possibly manage, you start failing, and then everything in the schedule starts to slip by hours, days, or weeks. At that point your willingness to jump in winds up looking like naivety, and the result is people won't trust that you can get something done when you say you will. Being able to make a commitment, and sticking to it >95% of the time, will earn you boat loads of trust in any role, regardless of whether or not you're slower than the next person. In the 5% of cases where something might slip, immediately letting the client know that there's been an issue, and given them an updated timeline, helps you maintain that trust. 

Crossing things off the list

I've mentioned it a couple of times already, but this is about getting into a flow, and knocking things off the list. If you spend too much time simply managing the list (and not getting things off the list) it will simply get longer. You should absolutely be spending the majority of your time getting things done. Many people are willing to jump head-long into something and work hard, but if there's one thing I see the holds people back over and over, it is this:

Don't wait on other people - always being thinking about what's next, and what you can do to get something closer to finished

One of the most important things that people don't realize about lists, especially if it's a list of things you're doing for a client, is that you're putting it your list so it doesn't have to be on their list. Take charge, and set the pace. Every day, when I look at my list of things to do, I think, "Which of these can I work on or follow up on right now in order to push it closer to being done?" Tasks often spend a lot of time sitting around waiting for something to be done. Second only to getting things done, your job should be to minimize the time that things spend waiting for action.

For example (I see this all the time), let's say you're waiting on a client to make a decision on something before you can proceed. You absolutely need to make sure you know what the next step is, when it's supposed to happen, and what to do if it doesn't happen when you expect it to. If you leave a client meeting, and the client says, "I'll let you know when we decide what to do, and get back to you," but they don't say when they will get back to you, then suggest a time. What time you should suggest really depends on what the task at hand is, but if you say something as simple as, "Sounds good. Should I check in with you next week just to see how things are going?" you'll often find that they will say that you should, and having a definite date/time to follow up is how you keep things from sitting around. If, no matter how many ways you suggest a follow up, the client doesn't say when you should check in, then you're just going to have to pick a time and do it anyway. Trust me on this - it's critical.

Clients pretty much never feel bothered by you checking in. if they don't have a schedule in mind, suggest one, and make sure you follow up when you say you will. Just keep pushing forward, and don't ever leave a task sitting out there with no action plan. Tasks that fall into this category will never get done, and at some point the client will follow up with you. If it's been months since you've done anything on that task you will inevitably convey the message that you don't care, regardless of the circumstances. Even if it's 100% the client's doing, you're going to be the one looking like you didn't take appropriate steps.

As my last point on the "don't wait on other people" topic, sometimes you work with a client that is just indecisive. Be brave, and suggest solutions to questions and problems. Don't wait on the client to make all the decisions; help them make those decisions. They've hired you because you're an expert in your field, and they are looking to you not just to provide a service, but to be a leader and keep the project or task moving. The fewer things the client needs to balance, and the fewer decisions they have to make, the more quickly work will proceed.

Troubleshooting

Sometimes things don't always go as planned. Here are a few ways to avoid some of the most common issues that come along with these techniques:

Dealing with commitment conflicts

Often you won't have a choice what to commit to, and conflicts in your schedule will inevtiably arise. You need a simple way to decide, among the various things you have on your plate, which ones should take priority. Stephen Covey's Four Quandrants is one of the simplest, and most effective ways to do it. It basically comes down to giving everything a "priority" so that when scheduling conflicts occur, it's clear (and already decided) what should come first. You shouldn't have to spend a lot of time thinking about what to do next. Your schedule, and the priorities assigned to the items, should make it clear at a glance what to do.

When estimation goes wrong

The vast majority of people don't estimate tasks 100% accurately. Most of use are either overly pessimistic, or overly optimistic. I tend to be on the optimistic side, always thinking something will take less time than it actually will. As part of your estimating practice what you'll need to do is track not only how long your original estimate was, but an approximation of how long it took you in reality. What you'll usually find is that you're off by roughly the same amount every time (you might always underestimate by about one-third, for example). Knowing this about yourself can help you take your gut feeling on how long something will take, and then add or remove a certain amount of buffer time depending on past experience.

What you wind up with after you make this estimate is a time frame you give others that is pretty reliable, which builds trust.

Task flow

When you've mastered this, you've got task flow. You know what you're doing, when it's happening, and you're always pushing tasks forward toward completion without waiting on other people to move things forward.

Sharpening and skill building

From Mark Twain's "A Tramp Abroad". This illustration shows a man who was so good at sharpening swords, a person could use them to shave. That's a good analogy for what I try to acheive in my own work.I work hard to be as good at what I do as I can. Recently I decided to explicitly build some new habits in order to increase my acquisition of new skills. The primary one comes down to what I'm calling sharpening.

In the past I would gain skill primarily through painful mistakes (the kind of mistakes that you never repeat), and over time I became very proficient. However, I found that this pain-driven approach was lacking for a number of reasons. First of all, it makes you look like you don't know what you're doing. If you're in a fast-paced, high-stress environment, you're probably having information thrown at you more quickly than you could reasonably absorb it. The natural reaction is to simply go home after work, relieve some stress, and not think about it again until the following day. After being in just that sort of environment and after multiple painful mistakes, I just got tired of letting the pain be the motivator for change.

Now I take a more proactice approach. Anytime I learn something new, or even see a piece of information I know I'll want to remember later, rather than just hoping I'll remember it, I write it down. Then, every morning I review the list of things I've written down, reading each of them again, carefully. When I've reviewed a particular item enough times (when I can basically recite it from memory), then I know I can safely take it off the list. This has been especially great for me, because it gives me a practice environment where I can make mistakes when it doesn't matter. That means I make many fewer mistakes for an actual client, resulting in much happer clients, and ultimately less stress for me. The list I keep and review each day isn't very long either, maybe a dozen items. I don't review large swaths of text or go through an entire practice of something long and complex. I only write down and practice the things that I need to improve on. On a typical day, this practice takes only 10-15 minutes at the most.

In my line of work, this is especially helpful when it comes to writing code and remembering obscure and helpful syntax tricks, or the steps for something I only do once a month. It's also very helpful as I've recently changed industries from banking to medicine, and I'm awash in new terminology and people. In my new job I review not just new coding tricks, all the new vocabulary so I can come up to speed as quickly as possible. If I still worked in IT, I would be using these tricks to more quickly learn the names of new clients, the structure of rarely-used infrastructure in a network, or anything that was important but not necessarily obvious or easy to recall due to how seldomly it comes up. In some ways, you could say that this is something we all did in school: it's basically running yourself through drills, except the test you need to pass isn't on paper, it's something in the real world.

They call it "pivoting"

In the startup world, there's this concept known as a "pivot." Depending on who you ask, you'll get various definitions, but basically it means this: you're hitting a wall that you either can't, or shouldn't try to climb, it's time to make a change, and you've decided to take a new direction in order to keep your venture going, and to hopefully be successful.

I'm in the middle of a big pivot in my life right now, at nearly every level: personal, professionally, and privately. Chalk it up to me being in my 30's if you wish (I hear things start to happen for you in your 30's), but whatever the reaons, I'm pivoting.

The big pivot

The pivot in the professional end of my life took about two years from concept to reality, and much of the payoff has come in the last six months. About a month ago, after getting my first paying job as a developer, I chose to move on to take another opportunity, also in software development. What follows is an overview of just what's happened in the last six months, and what I hope will happen in the next six.

Six months ago I was prepping to leave my position at a hard-core IT consultancy company based in the Phoenix area. During my time there I went from the entry-level position, to being a leader, manager (and counselor at times), and finally to building a new support team in Chicago. Joined by some existing engineering staff in the Chicago area, I set out with a bold goal: to make a career of this, to leave software behind, and to make a life in IT operations and magement. The long and short of it is that it didn't work out for a number of reasons. While I was reasonably successful at some aspects of the job, and while I garnered enough respect to be a voice in the Midwest region, I reached a point where I knew that my grand plans to make a life out here with that company weren't going to pan out. A lot of the reasons it wasn't going to work had a lot to do with me. As much as I poured my energy and life into it, I was never truly satisfied, and though I believed I had left my software days behind me, I continued to try to accomplish many of the larger projects with software solutions. On a deep level I was still trying to follow software, but in a role where that's just not what people needed from me. It took me a few years to understand just how fundamentally flawed this approach was, and in the mean time I picked up a lot of business knowledge, and networking skills (things that would serve me well regardless of what happened next).

Finally deciding to put my money where my mouth was: I started a small company called KarmaNebula where I would build my own software solutions to the world's problems, not needing to wait for buy-in, and not needing to ask permission. For 18 months I worked on a project called FeelGoodTrader.com, and used it as a springboard to launch my software career. From the beginning I saw three possible outcomes. (1) it's a fabulous success, I make lots of money, and it becomes by full-time job (highly unlikely), (2) it's a reasonable success, and I sell it off to someone for a nominal fee, using the money to seed my next project, or (3) I use it to prove that I have the programming chops to be a pro, and I land myself a job.

Well, #3 turned out to be what happened. I still own KarmaNebula, and while the first project (FeelGoodTrader) wasn't a success, I continue to work on side projects under the KarmaNebula name.

To get back to the story, about six months ago was when I saw that FeelGoodTrader wan't going to take off enough to be a full time job, so I applied to work in a software group connected with a local university. I wanted the job, badly, but things didn't pan out right away. When it appeared that nothing was going to happen at any predictable point in the future, I continued my search. I quickly landed a job with a great bunch of people, on a small software team where I could make real impact, where the work schedule was flexible, and the only thing that mattered was you delivering on your promises. This was an arrangement that worked well for me, being a self-starter, and burned out from more structured corporate environments.

The freedom in this new job was amazing. It was a tele-work position where I wrote software from my home office, full-time, meeting with my supervisor via a VOIP call a couple times a day, and I was given the trust to interact with customers directly whenever necessary. The ten years I'd spent in IT, and customer facing roles, would pay dividends in trust and responsibility awarded to me right out of the gate. On top of all of that, my supervisor was a great mentor, and treated me more like a peer, as we argued over points of code style, the best way to do something, and what mattered to us personally about working in an environment that trusted us, first and foremost, to be professionals.. Though it turned out that working relationship would end in just a few months, I maintain contact with my now previous supervisor, and continue to enjoy meeting up for a beer occasionally, and talking shop.

So what happened at the end of that first development gig? Well, it turned out that the other job I'd applied for back in March at the university, the job that I wanted even more, called me back in July and asked if I was still interested. The story of what happened between March and July is an interesting one, but one I'll save for another time. Suffice to say, the job at the university was one that had the right combination of just about everything I was looking for in environment, culture, and long-term alignment with my own goals. In other words, it was one of those opportunities that I couldn't turn down. So, I began the process of notifying my then current supervisor that I would be departing, and working out all the details around that shift.

I've now been working for the university for about a month, and so far I've been loving every second of it. Looking back at the previous six months and the road to get here, I feel that it's a direct result of the effort I put in to get here. With little-to-no previous pro programming experience (though I've been writing code since I was 13), I was tough, tenacious, and more than anything I didn't stop believing that I was good enough to pull it off. As I look forward, the next six months show a lot of promise. I hope they're as exciting and filled with success as the previous six months.

A final word, and a reality check

People say that getting the right opportunity only happens if you are ready for it when it arrives. Work hard, and make the sacrifices to put yourself in the right place: in my case, it was creating KarmaNebula and FeelGoodTrader.com. Follow you passion: you're guaranteed to fail when you give up. Eventually, maybe even after 15-20 years, you just might get what you want. When it comes, you'll finally get a greater degree of choice in life, and for me, that's what it's all about.

When hearing about my new, new job at the university, a friend of mine joked, "You know there's a recession going on, right? It's really not fair for you to take two jobs in three months when so many people have none." It was his humorous way congratulate me, but I was humbled by his message regardless. In response, I could only feel deeply appreciative of what's happened to me in these last six months, for the journey, and for everything I've learned along the way. My friend is right after all: the world is falling down around a lot of people, and here I am writing a blog post about how I landed two great gigs in quick succession. I'm in awe, and to whatever series of events conspired to bring this to me, I extend my deepest gratitude.

Motivation through shame

We've probably all worked at places where shame was used as a tactic to theoretically elicit higher quality. This kind of tactic has always struck me as childish, but don't take my word for it.

The link below is to a Q/A site for professional programmers, but you don't have to be a programmer to understand the tactic. The #1 voted answer takes into account the various concerns around someone making a mistake, including quality control, team morale, and the fact that the person making the most mistakes is often the person doing the most work. I love the method proposed for dealing with it in the top-voted question, especially because it addresses all of these concerns without needless shaming. For those intersted, in programming terms "breaking the build" is what happens when a programmer writes in new changes that introduce bugs into the system - a somewhat minor incident that, when correctly quickly, is simply another small, rather insignificant daily event. But just replace "breaking the build" with whatever common mistake happens at your workplace, and see if you don't feel the same way.

Appropriate punishment for breaking the build

Having worked for more than one place that tries to "motivate" through shame, I simply won't work at another place like it. If you read through several of the other answers, you'll see that the various punishments suggested run the range from silly, to funny, to reasoned, to down right ridiculous and counter productive.

Do you work at a place that employs shame, either publicly or privately, in a supposed effort to created higher quality and fewer mistakes? If so, I'd love to hear your story. Write to me: jeff@karmanebula.com