"What should I do?" is another question I hear a lot, especially from the people I manage. It gets phrased differently sometimes:
What would you like me to do?
How would you like this done?
How should this be done?
How should it work?
Etc.
This may be the most value-robbing question ever. It essentially turns an opportunity to show who you are and what you can do into nothing more than a task to be completed. Asking what should be done is, essentially, asking someone to design the solution to the problem that you've been assigned. When I run a team, I want my team members to design (and implement) the solution. One of my management mantras is, "Bring me options and ask for a decision".
I can hear the naysayers now: "But Jay, not everyone who reports to me can design the solutions to the problems we have."
Oy.
I'm not suggesting that your only options are what your team brings you, I'm suggesting that before they ask for help they demonstrate an attempt at solving the problem. This is how you build design skills: You practice and you find out where you're wrong. Eventually you get to the point that your designs are accepted by your manager consistently and you get to move up a notch. Without that practice, though, you'll remain stuck where you are.
So instead of finding out (and doing) what you should do, do what you can. Present options to whoever needs to make the decision and if the options are unacceptable, then ask for help. Look for the growth opportunity in everything you do and you'll be amazed at how quickly you grow.
I read a lot about successful people. I also think a lot about people who aren't as successful as they could be. My theory is that if I can determine what makes or breaks success then I can either emulate or eliminate as the case may be. Recently I've become convinced that I've found at least one piece of the puzzle and it has survived back-testing against both the success stories and the group who falls short. The entire concept can be boiled down to 3 words:
Commit and deliver
I originally spent some time thinking that it could be boiled down to 2 words "commit" and "deliver", but it turns out that the "and" is critical. I've worked with lots of people who commit, but then fall short on delivery. These are usually excuse artists who are more adept at explaining away success than they are at pursuing it. The excuse artist won't see non-delivery as failure, they'll just explain how they could never have been expected to deliver . . . despite having committed.
I've also worked with people who deliver, but never commit. I'm sure everyone has worked with folks like this. They're the wafflers, the ones who caveat everything to the point that they cannot be held accountable, they're the ones we often call "slippery". They will, however, sometimes deliver something of value and then never let anyone forget it. These people have entire catalogs of accomplishments in their head, but have never failed and never been wrong. If you think that they have, they'll be quick to point out that in the particular case that you mention they never said they'd deliver, they said they'd try or they'd see what they can do or that it might be possible.
I'm pretty fortunate to have worked with a few people from the final category. The ones who commit and deliver. These folks are great to work with. They say, "I'll do X" and X gets done. Not always as smoothly as originally thought, not always as quickly as originally thought, but it gets done. It gets done without fail. No excuse, no ambiguity about whether or not they're on the hook for delivery, just straightforward "it will be done".
There may be other factors that shape and size your success, but I guarantee that if you simply commit to doing things and then deliver relentlessly that you'll succeed.
This post will probably strike you as either common sense or absolute crazy talk. It is especially written for those in the latter group.
I write a lot about working safely. After lots of posts on branching, test environments, kitchen analogies, etc. I'm here to recommend some behaviors for those times when you totally screw up. After all, you may very likely find yourself in an environment without all of the safety nets you want because you were specifically brought in to build the safety nets. I'm going to assume that you messed up while doing the right thing in the wrong way rather than something criminally stupid like, say, encoding your DVD collection to Divx on the production database server because "it has those really fast drives and all that RAM".
First, and foremost, as soon as you realize that you've screwed up, let someone know. Do not be tempted to keep things quiet and fix it before anyone notices. I have yet to see a production issue that didn't get worse with time (and quickly). Keeping things quiet is outright selfish because you're putting your own comfort ahead of the good of the group.
Secondly, fixing your mistake needs to become your top priority. Fixing means not only getting things working again, but getting them back to the way they would have been. Does data need to be re-keyed? It's now your job to re-key it. Do numbers need to be verified? If you're not the one who can do it, be prepared to generate special reports or data dumps to make the job as easy as possible.
Next, take responsibility for your mistakes. Full responsibility. You don't get to say, "I deleted the production website, but the slow restore process is what caused the outage to be so long." Being up the creek without a paddle means that you own the upstream and downstream problems as well.
After things are back to normal, do your own private After Action Review (note: there's a good chance you'll be asked for either a public one or one with your manager). Take this opportunity to learn from what just happened while it's still fresh. For a big enough mistake, you'll probably also reflect on it for a day or two. Having said that, hear me now and believe me later: do not utter the words, "Well it's kind of lucky it happened because…". Even if there's some fantastically beneficial outcome, you don't get to celebrate the effect, you are still responsible for the action.
Lastly, get over it. If you've made the kind of mistake that I'm writing about, it will almost certainly affect you emotionally, mentally, and physically. That's to be understood and will actually help with internalizing the "Don't do that again" lesson. But don't let it affect you too much for too long or you'll kill your productivity. If making a huge mistake makes you skittish to the point that you are no longer a high performing contributor, then things aren't back to normal are they?
As a final thought, while things are at their worst you may start wondering, "Are they going to fire me for this?" I can't answer for certain, but I can tell you this: When I had headcount, I never fired someone for making a mistake . . . and they pulled some doozies. If you do get fired for a blunder that you feel comfortable defending (i.e. Doing the right thing the wrong way), then chances are it wasn't the place for you anyway. The only way you can do truly incredible work is by being willing to take some risks and if your employer squashes any chance of that happening by firing people for mistakes, then you're better off elsewhere. Just don't make a habit of it: it's easy to explain a one-off, but the second time you get fired for f'ing up big time it starts to look like a trend.
I got stuck several weeks ago. I was working on a fascinating, but difficult, post and had all kinds of other interesting things going on. Somewhere along the way, on thing after another got a little bigger, a little harder, a little more intertwined than I had planned. As I started to work on all of these tasks, I got lost without even realizing it. I was pushing forward and making progress, but in a really inefficient manner. In short I was thrashing.
Thrashing is a form of getting stuck in that you aren't going where you want to. It's worse than getting traditionally stuck because all of the activity has the illusion of progress. As a Big Swinging Developer (or Big Swinging Anything), the ability to self-manage is critical. Self-management isn't just about knowing what to do, however. It's also about recognizing that you're doing the wrong thing and that comes only through continuously monitoring both your activities *and* your progress. This is really easy to do for others — how many times have you looked at what someone else is doing and asked, "Why are you doing that?" just to have them give you a long-winded explanation that they slowly realize makes no sense? The whole reason that they were doing the "wrong thing" in the first place is that it looked like the "right thing" at the time.
It's easy to get stuck a little at a time. Actually, I'd argue that it's easiest to get stuck a little at a time by compromising a bit or not course-correcting often enough. Then you face two challenges: recognizing you're stuck and then getting unstuck. Here are my suggestions for both.
To recognize that you're stuck (or off course) compare where you are with where you thought you'd be on a periodic basis. If you're off by more than you can fix before your next measurement then it's a warning sign. If you miss by that amount twice in a row, then it's a problem. Notice that the shorter your measurement cycle, the easier it is to get back on track.
To get unstuck, there are 3 important steps. The first step is to stop. Once you recognize that you're stuck or thrashing, just stop whatever you're doing so you don't end up even further off course. Step 2 is to reevaluate where you want to end up. From the time you originally planned a goal until the time you got stuck things may have changed. Instead of blindly reorienting and pressing forward, make sure you know where you want to go. The final step is to work backwards from your newly established goal and take the smallest step in that direction that you can.
In my case, it was brought to my attention that I had neither cooked nor written anything that interested me in a long time. These are two of my favorite activities and looking back on the number of days that I postponed doing either, I realize that I was going off course. Last night I cooked Moorish pork kabobs that had a non-trivial amount of saffron, and today I'm getting back into my writing routine.
If you have other suggestions on either tracking your progress or course correcting, just leave a comment below!