Posts Tagged ‘management’
Visit Calgary: You’re Very Welcome!
When we returned from Costa Rica, our plans had been pretty simple: take off the month of December to get settled, and then head back to work in January. Plans changed shortly after arriving back home, and suddenly I found myself without a job. Bills still had to be paid, food purchased, and because we live in a city that is far too unfriendly to public transit, we also had to buy a car.
A few years ago, this probably would have put me into a panic. And a few years ago, it would have been just me to worry about. Now I have a wife and two kids (well, one at the time, and one on the way) to support. Really, that should have put me off the deep end. Having lived through a significant amount of adversity over the last couple of years, though, I found myself not even concerned about the prospect of unemployment.
I attribute that to having kept contact with just the right people.
Mentorship is a must
No-one is ever born knowing everything. Like all animal life, we enter the world devoid of knowledge, having only the instincts innate to our species after countless eons of evolution, adaptation, and survival of the fittest. But those instincts can only grant us so much in the act of survival — they do very little for us as higher-intelligence beings. Instincts can only assist survival, in near-epic troglodytic proportions.
We need teachers to help us move past mere instinct towards self-sufficiency, and self-learning. They teach us mathematics, communication, sciences, and art. As intelligence grows, we shift away from teachers, and look more towards peers — people who are similar, but have more experience. They are our mentors, ones who offer their abilities as examples for us to learn from, and models upon which we can hope to improve ourselves.
And anyone who thinks they can survive without a mentor has truly never had one.
What makes a Senior Developer
Every so often, someone asks me what I need to see in a senior developer. Why people ask me this is a mystery. I mean, besides the fact that I’m a Know-It-All, could it really be that several years of being a manager have really allowed me to delve into the core of the human psyche, separate the hard skills from the soft, and know what it really means to be “that” person?
Yeah, I’m having a good laugh at this one, too! But since I am a Know-It-All, and someone asks, it’s really hard for me to say “I don’t know”. I mean, it’s not like I don’t have an opinion on it or something…
Overtime is not a solution
Every project is defined by a schedule. That schedule determines when certain tasks start and stop, when people enter and leave a project, and ultimately how much that project will cost (because, after all, time is money). But as we all know, the schedule you start with is almost never the one you end with.
Schedules change. No-one can predict the future. No-one can see the out-of-left-field problems, the people unable to work due to sudden illness (or worse), or the sudden changes in project direction. When a project’s schedule starts to go sour, time management rapidly becomes extremely important. In a world where deadlines are fixed and resources are limited, one of the most common solutions is to work overtime.
However, overtime is not a solution. Overtime is a problem.
A good programmer is lazy, not stupid
I say this, in one form or another, to developers I manage. I’ve said it for years, and I’ll continue to say it until I’m proven horribly, horribly wrong. Which, until I leave this industry, is not likely to happen. My belief is simple: when you work in a time and materials-based industry, such as marketing, you’re not being paid to do everything new. You’re being paid to deliver a solid solution as quickly and effectively as possible.
The problem, however, is that programmers like to create. It’s what makes a programmer a programmer — I know, because I used to be one. (Then I turned to the Dark Side, but that’s another story.) Programmers like to do things themselves.
But good programmers — at least in this business — try to as little work as possible.
I wouldn’t have done it that way
I’ve recently run into a common programming problem. While turning a development project over to another development agency, we heard that worst of comments:
Why did you build it that way?
It seems like a simple question. But it belies it’s true meaning. What they’re really saying is:
We wouldn’t have done that. This design is bad.
It’s a completely valid point. And you know what? I probably already thought that same thing.
Failure is an option
One afternoon, a few years ago now, the head of my department uttered something completely heretical while we were in a fairly high-stressed meeting about some technical difficulties we were having on a project. It was one of those utterances that made everyone take pause, look at him, and wonder if he was off his rocker.
He wasn’t, for the record. In fact, he was striving for us to not view impending doom as a bad thing. While his two words were at first shocking (especially to the Account Managers present, who’d ultimately have to deal with the client), it was also one of those moments you sat back and actually thought about what you were doing.
So what did he say?
Embrace failure.
- Allard Losier
How to handle a problem
Problems fill our daily lives. Sometimes they’re trivial (“where are my keys?”), sometimes they’re pretty significant (“how do I hide this dead body?”); sometimes you can solve them on your own (“they were in my jacket pocket”), and sometimes you need help (“Mr. Wolf”).
How you approach a given problem shows not just your critical thinking process, but also a lot about your character. People will react in different ways to the same problems, even seemingly trivial ones. Some people try to solve problems on their own, while others will look to others to solve the problems.
In a busy work environment, problems are frequent. And I’ll argue that putting the solutions in the hands of a few people is a recipe for disaster.
The power of responsibility
With great power comes great responsibility.
- Various sources
I’m sure you’ve heard this quote before. It’s a good one, often used to reinforce the need for people to not slough off their priorities. Don’t get me wrong, it’s all fine and dandy, but I don’t really like it. It works for superhero movies and parental figures. It fails in my mind because it puts more of a burden on responsibility, rather than the sense of freedom one gets from being responsible.
Instead, I prefer this variation:
With responsibility comes a sense of great empowerment.
- Me. ‘Cuz I just said it.
I know what you’re going to say…
The blinding effect of an ego
One of the most dangerous things for anyone to have is an unchecked ego. I say “dangerous” because egos lead to a significant number of problems between team members, and can even lead to teams being pitted against other teams for no good reason.
I’ve seen ego problems not only as a manager, but also in myself — so I know what I’m talking about. I’ve seen all sides of egos, from the underappreciated, to the benign and humble, to the offensive. And yes, dear readers, all of them require some form of attention. Not because they’re all necessarily bad — some of them can be considered good traits — but because all of them need some form of nurturing.
All developers have an ego. (I’m focusing on developers because that’s who I manage. Egos exist in other disciplines, too, but my ego isn’t so big to think I can lump everyone into the same bucket.) Those egos express themselves in different ways. Some can produce outstanding work, but downplay their involvement. Others use their experience to educate. And there are those who choose to oppress.
Archives by Month:
- August 2010
- July 2010
- June 2010
- May 2010
- April 2010
- March 2010
- February 2010
- January 2010
- December 2009
- November 2009
- October 2009
- September 2009
- August 2009
- July 2009
- June 2009
- May 2009
- April 2009
- March 2009
- February 2009
- January 2009
- December 2008
- November 2008
- October 2008
- September 2008
- August 2008
- July 2008
- June 2008
- May 2008
- April 2008
- March 2008
- February 2008
- January 2008
- December 2007
- November 2007
- October 2007
- September 2007
- August 2007
- July 2007
- June 2007
- May 2007
- April 2007
- March 2007
- February 2007
- January 2007
- December 2006
- November 2006
- October 2006
- September 2006
- August 2006
- July 2006
- June 2006
- May 2006
- April 2006
- March 2006
- February 2006
- January 2006
- December 2005
- November 2005
- July 2005
- June 2005
- May 2005
- April 2005
- March 2005
- February 2005
- January 2005
- December 2004
- November 2004
- October 2004
- September 2004
- August 2004
- July 2004
- June 2004
- May 2004
- April 2004
- March 2004
- February 2004
- January 2004
- December 2003
- November 2003
- October 2003
- September 2003
- August 2003
- July 2003
- June 2003
- May 2003
- April 2003
- March 2003
- February 2003
- January 2003
- December 2002
- November 2002
- October 2002
- September 2002
- August 2002
- July 2002
- June 2002
- May 2002
- April 2002
- March 2002
- February 2002
- January 2002
- December 2001
- November 2001
- October 2001
- September 2001
- August 2001
- July 2001
- June 2001
- May 2001
- April 2001
- March 2001
- February 2001
- January 2001
- December 2000
- November 2000
- October 2000
- September 2000
- August 2000
- July 2000
- June 2000
- May 2000
- April 2000
- March 2000
- February 2000
- January 2000
- December 1999
- November 1999
- October 1999
- September 1999
- August 1999
- July 1999
- June 1999
- May 1999
- April 1999
- March 1999
- February 1999
- January 1999
- October 1998
- September 1998
- August 1998
- July 1998
- June 1998
- May 1998
- April 1998
- March 1998
- February 1998
- January 1998
- May 1996
- April 1996
- April 1991
- July 1989
- June 1989









