I originally posted this on my blog a little under two years ago. If it's interesting to you, I post new content on daedtech.com roughly weekly.
Last night (this morning), I clicked "publish" at about 3 AM and went to bed. Now, those of you who follow this blog probably assume that I clicked "publish" in Wordpress, firing off a 3 AM blog post.
Not so.
I did this in Visual Studio, where I published a little web app called El Dorado to Azure. I source control the thing in Github and I publish to Azure, where it serves as a little line of business application for me and some of the staff at Hit Subscribe. And, while a Visual Studio publish isn't exactly state of the DevOps art, it gets the job done.
The significant thing here isn't any of the techs that I'm using. It's also not the fact that I was up late coding, nor is it the purpose of the app.
What matters here is that I own a non-trivial and growing business and that I'm also writing code.
The Classic Management Track vs Technical Track Conundrum
Years ago, I wrote a blog post in which I told a story of something most enterprise-y/corporate programmers encounter sooner or later. It's the "where do you see your career going, management or technical" question.
Choose wisely, young programmer. Down one path, expense accounts and Gantt charts await. Down the other, UML diagrams, and... well, probably also Gantt charts.
I could never really wrap my head around this dichotomy. I mean, I get that furiously banging out code and leading departments are somewhat divergent activities.
But I never understood why the line blurred so little and so infrequently.
I poked around the internet a little to see if this was still true, and I think it mostly is. I found some posts like this one, talking about the coding dev manager.
But this has always seemed like just taking the role that most companies call "architect" or "tech lead" and having people actually report to it. That just kind of kicks the can down the road slightly.
If you're a "coding manager," you're probably in a fairly vertical, tech-focused organization where line managers still don't really think about "the business."
Are Technical and Business Savvy Mutually Exclusive?
So this begs an interesting question. Are technical savvy and business savvy mutually exclusive?
Oh, I mean, don't get me wrong. I'm not honestly asking whether techies can become startup CEOs or whether leaders with f-you money couldn't learn to code. Of course those talents can both exist in the same human being.
What I'm asking is whether or not someone can do both of these things meaningfully, at the same time. Can someone run a department (beyond a "tech-lead-y" line management role) and also have legitimate business reasons to bang out code, and do it halfway decently?
I have a hypothesis that the answer is yes.
Yes, people can run non-trivial organizations while having good reason to code. And no, applied, simultaneous technical and business savvy are not mutually exclusive.
Developer Hegemony, Revisited
If you're new here or coming in through share or some kind of Google search, I wrote a book about a year and a half ago. I could explain it inline here, but it's probably easier to link to a post that I wrote, which has the subtitle "the crazy idea that software developers should run software development."
That book has been a lot of things to a lot of people, and it's earned me a lot of support, emails, readers, and general engagement. It continues to sell at a nice clip without any real promotion from me outside of this website.
And I think that's because it resonates.
Doctors are knowledge workers, and they partner up to form firms, delegate non-doctor tasks, and run the show while still spending most of their time doctoring. Lawyers are knowledge workers, and they partner up to form firms, delegate non-lawyer tasks, and run the show while still spending most of their time lawyering.
Software developers are knowledge workers and they.... well, they exist below 8 layers of line management, as well as product management, project management, program management, and probably 6 other p's of management that I'm forgetting.
Why is this?
Well, the book has its take, and I'm not going to re-litigate it here. But I will tell you that my hypothesis was and remains that it needn't be so.
Developer hegemony is the idea that we, too, can ply our skills in a way where we run the show.
Developer Hegemony, In Search of Real World Examples
In the last part of my book, I interview a series of folks that seemed to me to be living the Developer Hegemony dream, or at least getting there. But this is a new and fragile beast.
The standard software development situation these days is some kind of Scrum team. You have 7+/-2 developers, working mostly collaboratively and full time, executing "the business's" vision.
These software developers are either:
- Salaried members of "the business" or
- Salaried members of a software pro/app dev shop taking direction from "the business."
Rarely, if ever, are the software developers also "the business."
In the wake of writing the book, I hoped to serve as a living example or else a pied piper, leading the charge toward something better via info products or an example "efficiencer" team.
But then, life got weird, and the content agency that my wife and I thought would be a nice side-hustle revenue stabilizer for us blew up into a runaway bull in a rodeo, with both of us just trying to stay seated and not get trampled.
So, until recently, I thought that I made for a poor example, but would fix that later.
And now, later has arrived. Just not how I thought.
And so, I'd like to finish my story. And I'd also like to invite any of you with similar stories to weigh in for the readership (comments, or I'll happily feature them in subsequent posts, as I entertain the idea of throwing DaedTech open to like-minded contributors).
I am a Partner in a Non-Trivial Company, and I Still Write Code that Matters
That 3 AM commit felt good.
It felt good because I'd made the software better, gotten the better of some Entity Framework weirdness, and could go to bed victorious. But it felt good in a much deeper way, too, as I channeled Emma from the intro of my book, staying up late and fixing something in spite of a 10 AM meeting the next day.
It felt like true autonomy.
My wife and I founded Hit Subscribe as partners a little over a year ago, each with our "side" of the business (mine being sales/account management/finance and hers being operations/service delivery). Since then, the business has grown to encompass 4 people working full time and more than 30 people contracting in various capacities.
Amanda and I run this business, presiding over a new 401K one day and an onsite client visit the next.
And I still write code -- code that is important to the business.
I'm not writing this to navel-gaze, but rather to put out a signal flare of "coder as 'the business.'" It's a novel concept, and you see it only in fits and starts.
But it's out there. Keep your eyes open, and keep striving for it. And please weigh in with your own experiences, direct or indirect.
It's only a matter of time until software developers are knowledge workers, and they partner up to form firms, delegate non-automation tasks, and run the show while still spending most of their time automating.
If you'd like to ask a reader question, you can do so at the "ask me" page.
Top comments (3)
Really awesome it's hard that there is someone that writes about the blending of tech and business with partners to build the products. I would love to read that you wrote on it.
Thanks for the kind words. I do write about the topic a good bit at my site, daedtech.com, if that helps.
I would posit that a manager should not touch the code because of conflict of interest, but the team could manage itself.