Part 6 in a series on managing programmers
It’s my experience that many technical managers aren’t – and don’t really want to be – managers. See, we generally start out as engineers or developers, and probably show some strong competence as individual contributors. Maybe we’re also one of those rare engineers who can keep their cool with customers and has a knack for explaining technical solutions to non-technical types. Then something happens – someone resigns, a team gets too big, a new project starts – and we’re thrust into the job of “leading a team”, perhaps “just in the interim”. And we try to continue doing things like we had been doing, but now we’ve got all these extra meetings to go to and emails to answer and we have to hang out with the guys in sales and marketing and the project manager keeps asking me questions about...
Part 5 in a series on managing programmers
Here’s a list of some of the things about management that I expect from myself, and from people I work with and for:
Communication: I believe that 95% of all problems can be solved with better communication. Good communication is appropriately clear, comprehensive, timely, and frequent. Good communication adopts the right tone and is and channelled through the right media. Communication is often more about listening and asking than talking.
Honesty: It is the responsibility of leadership to be honest and forthright in their dealings with people inside and outside of their organization. Leaders are able to share both good and bad news in constructive ways with peers, team members, and customers. Good leaders encourage people to be honest with them.
Trust: Believe in people. Actively demonstrate confidence in their abilities. Look them in the eye and openly affirm your trust,...
Part 4 in a series on managing programmers
When I was first thrust into management, I would come home at the end of almost every day frustrated at how little I had accomplished. You see, like most technical managers, I still tried to keep myself involved in the task of actually writing software. I was a “working manager”, and still a developer (“75%!”). On my daily to-do list I had code to write, diagrams to draw, and databases to query.
But I felt like I “never get anything done” because, dammit, now that I was “the boss” everyone kept interrupting me. I found that even on days when I only had two or three meetings scheduled I’d still end up spending most of my day in hallway chats, impromptu one-on-ones, emergency client meetings, and responding to about ten times as many emails and phone calls as I’d had to...
…in 5 easy steps:
Stop complaining about the client.
Stop complaining about the project.
Stop complaining about the team.
Stop complaining about the technology.
Start solving problems.
My advice on how to get an awesome grade at your next performance review is to simply follow Rands’ advice:
“Be productive, be fantastically clever when necessary, speak truth to power, hit your dates, and don’t ship crap.”
By the way, if you’re a programmer or a manager of programmers and you’re not reading everything that Michael Lopp, a.k.a. Rands in Repose has to say, you’re missing out big time.
Foraker Labs just posted this (unofficial) YouTube video of the lightning talk I had a chance to give at the Mountain.rb Ruby conference last week in downtown Boulder, Colorado:
In this brief talk I present highlights from three books on my required reading list that (I believe) will help make you a better programmer:
- The Passionate Programmer by Chad Fowler
- Clean Code by Robert C. Martin
- Refactoring by Martin Fowler
Part 3 in a series on managing programmers
The third installment in this series is about something I learned well before I got into management. In fact, it’s probably the reason why I got into management at all:
Get up out of your chair.
As geeks we’d rather just sit there. Sit in our chairs and send yet another email and hope enough folks read it. We spend a whole hour crafting a brilliant treatise on an Important Topic and assume that our written words alone are motivating enough to get people to do what we need them to do. And we hope (in vain) that people will read our words carefully, reflect deeply, and return the favor by drafting a well-written response of their own.
But when it comes to managing people email simply doesn’t work as well as we wish it did. It’s often the wrong tool...
Part 2 in a series on managing programmers
The second lesson I learned after being thrust into management was this:
Make the call.
Management didn’t confer any secret knowledge or special skills. Nothing about me had really changed from one day to the next. Except that all of a suddenly folks around me expected me to make the tough decisions.
Suddenly people would approach me with an issue. I’d listen and try to figure out what the problem was, and maybe think up a solution or two. Then I’d try to ask them what they thought about it. Hey, you’re smart. We’re paying you to know this stuff. So what do you think?
And more often than not they’d respond with something like: “Well, um, I’m not sure. That’s why I’m asking you.”
So here’s the crazy thing about being in leadership:
People expect you to lead.
Part 1 in a series on managing programmers
If I have any management secret, it’s this: Every now and then, when one of my team members asks for my opinion, I try to pause and answer with one simple question:
What do you think?
I’ve been managing programmers for over five years now. That’s a long time in internet years, and I’m to the point where I don’t think it would be too out of line for me to start sharing some of the tips, tricks, and techniques that I’ve learned about how to manage software developers and engineering types.
The first management tip I’m sharing dates back to the very first day on the job as a manager. I’d been working with my fellow web developers in a small-but-growing shop, building a couple of fairly substantial applications used by the collections and law enforcement industries. Then one day...
Foraker just posted my new blog article: “Hiring 101“. The key point:
At Foraker, we recognize that our best chance at success involves getting the right people on our bus. So we’re almost always looking for people who live and breathe the web, who are passionate about getting just a little bit better every single day, who enjoy the challenge of working closely with a team of like-minded individuals, and who are eager to produce exceptional websites and web applications for our clients.
What we look for: Passion + team fit, then general intelligence, then core skills. In that order.
A little while ago I decided I needed to get my head around this whole “Ajax” thing. From Wikipedia:
Mainly it was for a couple of issues we were having at work, but I’ve long been a fan of the “magic” behind sites like Amazon, Flickr, and 30boxes.
So, after quite a bit of searching around in books and blogs, I managed to cobble together a couple of extremely simple scripts that take most of the mystique...