I came across two articles over the past few days, both of which resonated with me, but neither of which filled me with much hope for a resolution to the problem they addressed.
Ron Jeffries‘ article, Estimation is Evil: Overcoming the Estimation Obsession, enumerates some well-known issues with how software estimates are interpreted and the problems they cause. His suggestion is to forego estimation, start building software, and come to a go/no-go decision after a couple of iteration cycles.
When I was first asked to manage a project at Art & Logic, I had my reservations. Did I really want to start down a career path that led to less development? Would my skills as a developer go stale? My first few projects as a manager were solo projects so I still had plenty of development work and fortunately, I found myself to be a pretty easy person to manage. As time went on I started managing larger projects and with them came the responsibility to manage other developers. To my surprise I found project management to be rewarding and dare I say, even fun. It’s very satisfying to work with clients, helping them define their visions and seeing those visions come to life.
It’s in this context that I was very interested to read the article Engineering Management is Dying and the subsequent discussion on Hacker News. The author seems to define Engineering Management at a step above project management, those managers responsible for teams at a human resources level. However, some of his thoughts still ring true at the project manager level, especially that “…the hackers themselves tend to the business of building things.”
When I first started out as a project manager, I struggled with how best to provide value to the team. Yes, keeping track of task lists and budgets are important tasks that need to be done. But they don’t require any special skill. Like the author, I find that staying “hands-on” is critical, both for understanding the problems your teams face and feeling like you’re an active part of the building process. I try to work on smaller items around the edges of the project, avoiding critical paths in case my management duties need to take priority. I also find that bug fixing is a good way to stay active in the building process as it gives me a chance to review code and perform some ad-hoc testing in the project.
But while it is important to remain “hands-on,” I think there is a function of project management that provides essential value to a project and will never become irrelevant, especially in the context of consulting. That function is communication with the client and maintaining a positive client relationship. More often than not, problems that come up in projects are due to lack of communication and have little to do with technical limitations. You thought the client’s main priority was feature X, but they really think feature Y is critical to their application’s success. The client heard you say feature Z was possible in a short amount of time, but didn’t understand the caveats you laid down. The “boss-less” companies such as GitHub and Valve have the luxury of defining their own visions, but good communication is still essential to a successful project and a great personal asset to have no matter what role you fill.
Whether you seek to stay down in the trenches of code or work your way up to pointy-haired status, you can only benefit from learning to be a better communicator. Two resources I find valuable that discuss these topics are the randsinrepose blog and the Manager Tools podcasts.
(image by DailyPic)