I’m a proud member of the Density Lobby — I believe that having dense cities surrounded by farms and undeveloped forests is the best urban structure. Density enables more services and lowers transportation energy use; the surrounding land easily accessible and connects us to the world.
I’m not sure what’s going on out there in other companies, but I keep having this same conversation with promising software engineer candidates where they say “I want to move into product management”. What? Huh? Here we are, talking about a development position, and they start talking about how they don’t want to do that, they want to be in product management.
What is it about product management that is so attractive to these excellent developers? Do they know what product managers spend their time doing? They go to a lot of meetings (developers hate meetings); they talk to a lot of people (developers are mostly introverts); they don’t “do” anything (developers check-in code and push it live to the servers); … do these people really want to be product managers?
Eventually I figured out that what they were really saying was “I want to be in control of what I do”. They’ve noticed that at their current company, the product managers are in control and so they want that job: product manager… Ah, now I can explain how at New Relic we don’t have a product management group and that those kinds of decisions are made by developers.
The good candidates eyes light up because they realize that we’ve got the best of all worlds: passionate developers who write code and make decisions without excess layers of management. Maybe someday when we grow to be a big company we’ll have to reorganize and add product managers, but not yet: today, our developers are directly talking to our customers and so our developers are our product managers.
(If this sounds great to you, take a look at our jobs page.)
One of my tasks at New Relic is growing the development organization. I’ve more than doubled it in the last year, and we’re going to double it again in the next couple of years. And of course, like everyone else, we only want to hire the best people. So I spend a lot of time on hiring.
It would be wonderful if I could find those “best people” directly, without a search, but that’s unrealistic, so I spend a lot of time screening candidates, both at the resume level and at pubs (I prefer “pub screens” to “phone screens” because I’ve never gotten good at the phone screen). We advertise for Ruby on Rails developers, but while our performance monitoring tool is written in Rails, it’s really a fairly complex application with all kinds of interesting engineering challenges, so what we’re looking for is hard-core engineers rather than website developers: people who love the challenges of the whole stack, especially making the bottom half go fast.
I point this out because most of the resumes I receive are for web developers who know Rails. The problem is that they’ve spent too much time being just a web developer – they’ve trained themselves into the narrow specialty of building nice looking, but boring, websites. They’ve over-strengthened the “building a website” brain cells and let the “building a complex application” brain cells atrophy.
That’s the real problem: they’ve practiced themselves to perfection, but a perfection of doing something we don’t need and, for many of them, a perfection doing something that they don’t want to do. Even worse, many of them work as independent contractors or in unsupervised teams, so they never get feedback about their career until it’s too late: until they apply for jobs like ours and don’t get past the screening.
So what can you do to avoid becoming perfect at the wrong thing? You can make a conscious effort to stretch your expertise: perhaps joining and seriously contributing to an open source project. Maybe finding some mentors who will help you grow as an engineer. Possibly you could find a new job, one your current perfection qualifies you for, but with a good manager who will broaden your experience.
Whatever you do, take an active role in your career: don’t just keep building the same websites or programs over and over again and hope that, somehow, this will lead to something better. It won’t [1]. You are what you’ve been doing; to change, you need to do something different.
When I left the Eclipse Foundation, I had intended to stop writing on my eclipse blog and begin writing here. However I turned out to have more to say about the Foundation and so I continued writing over there. After I finished writing over there, I thought for a while about what I wanted to say over here.
But the things I wanted to write about are already well covered by other, very erudite, writers. For example, there are many well-written blogs on software engineering and startups including those by Mik Kersten, Kent Beck, Scott Swigart & Sean Campbell, Peter G. Neumann, Jason Cohen, Johanna Rothman, Eris Ries, Steve Blank, Eric Sink, and more.
Similarly, there are already a number of excellent blogs about flying, including Cockpit Conversation and Flight Level 390.
Finally I realized that there was something I could write about: software psychology – the art and science of listening to the software and the team. I’ll be writing a bit about managing software (but I’ll try not to repeat what’s already out there) and I’ll be writing a bit about learning from great engineering of the past. I’ll probably also write about how much fun I’m having working at New Relic.
There’s a lot to talk about and I hope you’ll stick around as a reader.
I’ve been writing a private personal blog for ten years and a public Eclipse-Foundation-work-related blog for four years, but now that I’ve left for the Foundation for something different, I thought I’d start this public, yet personal-opinion, blog. I will also be writing on work-related things on the New Relic blog.