I originally posted this on my blog about a year ago. If it's interesting to you, I post new content on daedtech.com roughly weekly.
It's been a while since I've posted a hot take. And, to be fair, this is probably a lukewarm take, at best. I'm taking a slightly aged tweet, and I'm going to react to it in a slightly oblique way.
Here's the tweet.
Unpopular career advice: speaking at conferences is a massive waste of time
Seems cool when you’re young But creating a new deck takes time Talks have low recall & rarely lead to followers, subscribers, etc. Better to focus on compounding activities: write, build something — Brianne Kimmel (@briannekimmel) March 26, 2019
I do have opinions on this tweet, and I'll get to those momentarily. But, as I go through this post, I'm actually going to relate it more to a different facet of the programming world. Specifically, I think this has an tangential-but-important tie-in with how we tend to fetishize skill in the tech world, in spite of it being not that important in the scheme of things.
But let's put a pin in that.
Conference Speaking is a Content Marketing Activity
If you've followed this blog for a while, you might have seen me write about this exact topic. I titled the post, "Conference Speaking Isn't Good for Your Career Until You Make it Good," and that title serves nicely as a spoiler for the content.
My premise is somewhat softer than Brianne's, in that I neither discount speaking outright, nor do I make an ad hominem implication that youth and naivete govern speakers' decision-making. My take is less that conference speaking is pointless and more that people tend to do it quite inefficiently.
In a professional context, conference speaking is a marketing activity and, more specifically, a content marketing activity. You deliver value for free (in most cases) with the idea that investing your time and effort this way will pay off later. Other activities, including ones that Brianne mention also fall into this bucket.
- Writing blog posts
- Building FOSS utilities
- Starting a Youtube channel
- Building a social media following
And Conference Speaking is Uniquely Prone to Content Marketing Inefficiency
Now, as someone who spent years creating content inefficiently, I have plenty of perspective here. I wrote a blog like a journal, instead of an asset, and it led to all kinds of opportunities and new careers. So, I did it, and it worked, albeit less efficiently than it could have.
So against this backdrop, I'll offer my own spin on Brianne's comments, which I think make sense. When you miss the point with blog posts, software, social media, videos, etc, you can always rework that content into more efficient forms. You can't do that with speaking, which is ephemeral.
In other words, while all forms of content marketing activities are prone to these inefficiencies, conference speaking makes it uniquely hard to course correct later.
Probably the biggest source of inefficiency for us in the software world is the preoccupation with impressing our peers instead of speaking to our buyers. In the throes of this preoccupation, we generate all sorts of content aimed at a sub-optimal audience and delivered in a sub-optimal way. To efficiently help our careers, we'd measure our content not in terms of software developers following us on Twitter, but in terms of dollars of salary offered to us by dev managers and VPs.
And, when we eventually discover this truth, we have a much easier time re-tuning old blog posts and videos than we do going back in time and speaking to different audiences.
The Reactions to Brianne's Tweet Tell an Interesting Story
So far, I think you'd find yourself hard pressed to argue with my point, since I present it in something of a mercenary way. I'm ultimately measuring everything (as is Brianne, I think) in dollars and cents and eliding the personal development benefits.
In fact, let's now look at some of those. Here are some (paraphrased) counter points in the Twitter thread.
- It's rewarding to advocate for something you're passionate about and to give something to the community.
- You can build confidence by speaking to large groups of people.
- Speaking helps you cultivate and improve a variety of non-technical skills, such as teaching, organization and, well, speaking.
- You learn a great deal about the subject matter of your talk.
- With the other speakers and the audience, you network, make friends, and form human connections.
These cover a bit of ground, but there is a fairly heavy emphasis on personal development. You reap a lot of intangible benefits from giving talks, many of which have to do with making you a better person in some capacity.
Career Development by Coincidence
And now we get into the meat of what's troubling me and why I started writing this post. Brianne made a pragmatic, efficiency-driven argument. And the lion's share of the response wasn't to refute her point, per se, but rather to come back with "efficiency isn't everything."
As I mentioned earlier, we in the programming world seem to assume that if we just sharpen miscellaneous skills that we have, the corporate world will take care of us. "I'll get better at mentoring, asynchronous programming, and public speaking, and that'll pay off for me professionally... somehow... eventually."
This sort of attitude reminds me of an iconic concept in the programming world: programming by coincidence. Programming by coincidence happens when we get in the habit of saying, "I don't really know why that works, but I'm glad it does, so let's move on."
Career development happens in a similar way. You plug along, improving whatever skills you feel like improving in a given month or year, and trust that fate will take care of you.
Not All Skills Help Your Career Equally, or Even at All
I saw Brianne's tweet and the responses last week, and it wasn't until today that I understood what about the debate had bothered me. And, truly, it's this concept of career development by coincidence. Viewed through that lens, here's how I see the discussion.
Brianne: If you take a data-driven, business-like look at your own career, you'll see that speaking isn't a very efficient strategy.
Popular Response: I disagree. I speak and I like my career, so my strategy must be working.
Is public speaking a valuable skill for a programmer? Is mentoring? How about power point? The answer to all of these is "probably, to some degree."
But is a mastery of any of them going to make a difference to your salary and org chart position? That gets a lot harder to say.
The most direct counter-examples in the discussion thread are ones of immediate opportunities. People talk about getting a "break" as a result of a talk: landing a new client or job. And, while those are clearly wins, what's less clear is:
- Does, say, landing a client, actually move your career needle?
- And does it even bring ROI from the time spent prepping the talk?
Now, to be clear, I'm not saying the the answer to any of this is "no."
I'm just saying that, absent specific metrics, we can't really say "yes," either. And, if you're going to be engaging in marketing activity for the sake of improving your situation, you should want a path to "yes" as surely as a SaaS company measuring conversions from a landing page.
De-emphasize Building Skills and Emphasize Driving Outcomes
"Skills" are largely internal concerns, personal to the individual. They scratch our itch for mastery and allow us to mark developmental progress through life.
But they don't matter all that much to clients or even employers. Oh, sure those entities will ask about or demand skills, but in the same way you 'demand' skill from your tax prep company or accountant.
You don't really care about their skills. You care about your outcomes that you perceive to depend on those skills.
And you certainly don't care about how well your tax preparer crochets or how accomplished a pool player your mechanic is. Some skills are totally irrelevant to outcomes you're supposed to provide, meaning developing them has legitimately zero commercial interest. Commerce isn't an RPG where any marginal skill development makes your overall character stronger.
Skill development requires two things to benefit your career:
- Relevance to the outcomes you deliver.
- Consistent, measurable ability to improve those same outcomes as you develop it.
But since these things are both outcome-focused, why not just cut out the middle man and focus on outcomes?
If you want to write/blog/speak/whatever as a hobby because you enjoy the feeling of improvement and creation, then, by all means, do that. I have for years on this blog. But if you want those same activities to be demonstrably good for your career, you need to have a plan beyond the universe rewarding you for leveling up.
So start with outcomes, work your way back to the activities, and make sure you can measure your progress. Anything else is career development by coincidence.
If you'd like to ask a reader question, you can do so at the "ask me" page.
Top comments (4)
I really think you've hit home with this post. Personally, I tend to get stuck doing some course or other in order to try and improve my skills, but at the end I don't really have much to show, and even if I do (if you actually build something in the course), all I have to show is that I've done the course really since everybody else would have the same thing.
One thing I've learned in my career so far is the power of incentives and how bad things can go when you incentivize the wrong thing. I worked for a call center for a while, and instead of looking at the amount of successful sales, the manager started looking at the amount of time the agents were on the phone for. This lead to people drawing out the phone calls, making calls to themselves and then going on lunch etc. All because this was an adjustable value that was more a side effect of what was actually needed - the desired result. He eventually realized that there was just no way of fooling desired result, whereas the peripheral numbers can be manipulated.
I guess as developers, there's no getting around actually making products. At least it's an indication of what you can do and the fact that you actually can deliver something of value. What would your suggestions be for this though? Should people be more focused on delivering products to show people? Building up their GitHub profile etc?
Creating incentive structures with perverse incentives is one of the most common organizational problems out there. I logged ~5 years as an IT management consultant, and this (anti) pattern occurred over and over. There's a great saying, though I'm not sure of its attribution: "if you give your staff a metric, they will achieve that metric, even if they have to burn the company to the ground to do it."
The most common instantiation of this object, so to speak, in software was always unit test coverage. I can't tell you how many codebases I've seen with 75+ percent code coverage, achieved with "unit tests" that contain no asserts and such. Asked about, devs would say, "we've got delivery pressure, and we can't commit if we don't make Sonar happy... so we make it happy."
Anyway, I think my advice about measuring success and choosing skills would depend heavily on whether the developer is a current/aspiring freelancer or an employee. For an employee, it'd really be about finding job description/requirements for desired job(s) and working backward toward being well suited for that. For the freelancer... it's more of a heavy mindset shift to thinking about how to deliver holistic outcomes for clients. And the reason I make this distinction is that employers tend to view developers as tuples of (skill, experience years), whereas clients are more interested in outcomes (unless they're just mining Upwork for staff aug/pseudo-employee contractors)
Thanks for the kind words! I'm glad you like the posts.
One of the simplest ways I can think of to decide what's worth learning would be to talk to one's line manager and just explicitly ask. Like, if you're a Software Engineer III, you can ask if there are any additional skills you could develop that would help build the case for Software Engineer IV or something. The answer to that might often be "no, nothing specific, just more time/experience," but you might get something useful out of that conversation.
If not that, maybe looking for higher pay/title positions at other companies, and seeing if there's some skill they're consistently looking for that you lack.
As always, thanks for your well expressed thoughts!
As I see it, the higher you go on the company ladder of software developers, it's less and less about daily development. Mentoring, making other devs and management accpeting best practices, solutions becomes more important.
And that point you need the mentioned skills. It's arguable how to get them. Probably actively working at your local toastmasters club is quite a good option, though it will offer you less credibility in the eyes of your colleagues.
Does that matter? If you want to show that you can lead technical changes, I think so. Blogging, presenting helps establishing that credibility, authority, but you have to choose your topics well.