2018-01-05

LinkedIn, Titles, Roles, and the nature of work.

Titles are like animals that we keep around because we are amused by them. You never quite know what they're going to do, or how they're going to effect your life, but a lot of people really seem to like them, and pay a whole lot more attention to them than they're actually worth.

Recently I've spent a lot of time at a company that barely recognizes that titles exist, internally. Everyone can chime in about anything. People may look at you a little odd, but it's true, and certainly interesting to have that level of exposure. Sure, there's some churn due to information flows, but people tend to self organize by interest, rather than specific role or title.

This has made me reconsider how I think about titles, and in particular what I should put on LinkedIn. I try to keep my resume as up to date as I can, but when you work at a company that is a Holacracy, you can't quite pigeon hole yourself with one particular role/title. I've gone through a bunch of iterations on what I think I am, as a software developer...
  • Junior
  • Mid-level
  • Senior
  • Architect
  • Principle
But what do any of these really mean? They're supposed to indicate a level of capability within your given field. They might just do that if you're an Accountant, or perhaps in certain lines of business. They simply don't map very well on to the abilities of a programmer. For example, I've met people that call themselves Principle Software Architects. What does that mean? That they're really good at making flow charts? Do they even code? As another example, I've met Junior Developers that are far more capable than your average Senior Developer. These dichotomies exist all over the place, of course, but it's quite stark in software. It's far more important how your thought process works, than how long you've been able to call yourself a developer.

So I've decided to take a new track for LinkedIn. My primary title is now 'Thinker, Problem Solver, and Writer of Code'. I think that best describes what I do, in respect of how important they are. Without considering problem spaces, you can't even come up with problems to solve, and when you're solving problems, sometimes it'll involve code. Occasionally. Too often people rush to write code without considering whether or not they really need to, and that's one of the things I like to think hard about. 

The only code you don't have to support is code not written.

That doesn't mean I'll remove all my titles from individual positions, but I do think it's far more important than all those position names, combined.