In the blogging meme of the day, I was tagged by my friend Tim Costello to share four things I wish I’d known back then. The only hard part was paring the list down to four items.
I think back to 15 years ago, when I was working retail and desperately seeking something else. Something I could really get into. Some kind of work I was passionate about. On a dare, I took the A+ computer certification exam and passed it, and embarked on a career that has led me to where I am today. Although I miss some of the aspects of that guy I was 15 years ago – bold, fearless, with boundless dreams and ambition – I also wish I could go back and teach my younger self a few things I’ve learned since then.
Failure is a part of growth.
I used to worry a lot more about failure. I feared that a big failure would end my career, but also worried about day-to-day failures – small mistakes that everyone makes. I worried that I’d say or do something stupid out of ignorance, and that would be the thing I would forever be remembered for. It rarely works that way. In most cases, a person’s career is not measured by their biggest misstep; rather, it is an aggregate of every success and failure – and the attitude they have about those successes and failures. Failing on the job is a part of the growth process. As Thomas Edison famously said, “I have not failed. I’ve just found 10,000 ways that won’t work.” A misstep is only a failure if you don’t learn from it.
You can’t be an expert in everything.
During my first year in IT, I was convinced that I was going to be some kind of technical demigod, and I set out to learn everything about everything – programming, databases, network administration, routing and switching, even Microsoft Access. You name the technology from the late 1990s, and I probably had a book on it – and intended to master it. There’s nothing wrong with learning, and to this day I still work regularly to learn about areas outside of my own specialization. But I wish I’d known back then that maintaining deep expertise in so many different technical topics is exceedingly difficult if not impossible. I wish I had realized that there’s far more demand for someone who does just a few things, but does them better than 98% of other practitioners of the same craft.
Don’t just have goals. Have a next set of goals.
There was a time fairly recently where I was stuck in the mud. I was still doing the work I enjoyed, but for a time I was doing it without a real purpose. Why? I had met all of the career goals I had set years ago, and I was working largely without a personal charter. While that’s a great problem to have, I really hadn’t planned for the contingency of completing those objectives. I wish I could go back and tell myself to be a bit more optimistic about my goals, and to list out another set to be met later, and another after that, and so forth. Like anything else, goals should be flexible enough to allow you to adapt to changes in the marketplace and your own desires and place in life. Those goals will be different for everyone, but whatever they are for you, those milestones are critical for measuring progress and challenging yourself to press onward.
Your technical skills don’t matter as much as you think they do.
In the late 1990s and early 2000s, there was still a great deal of truth behind the antisocial geek stereotype. One could be a reasonably successful technologist and stay hidden away from the front lines of end user interaction. And I fell into that trap for a while, spending virtually no time honing my interpersonal or speaking skills and just working to refine my technical abilities. While the ability to deliver technical solutions is important, being able to talk to people (both one on one as well as in a presentation setting) and understand their business and its pain points is critical for the success of the modern technologist. I’d love to go back and tell my younger self: Continue to work on your technical skills, but get out of the server room occasionally and talk to people. Learn about their jobs, and what causes them grief. Understand how to not just build technical components, but how to solve real business problems.
And to keep things going, I’m going to tag a few people to get their input on this. I’d like to hear what Marc Beacom, Reeves Smith, and John Sterrett have to say on this topic.
Great list, Tim. Thanks for sharing.