On (not) Being Post-Technical

In ThoughtWorks, one of the most poignant insults one can throw at you is “so-and-so has gone post-technical”. This usually means one has entered the land of management, that place where you give back your brain in exchange for money (or prestige.. or nothing, as it turns out).

Lately, as I have taken on additional roles at ThoughtWorks, the temptation to go “post technical” has put itself forward. Imagine not having to think anymore. Imagine being able to just focus on “strategy” and “people issues”, without all that hard technology stuff.

I could take that path, but I’d rather not…

I remain technical. My day-to-day job may involve things like Statements of Work and such, and I do not write code 100% of the time, but I am making a decision to at least remain somewhat involved in the technical communities in which I have interest.

Of course, my time is more limited, given I have taken on some management responsibility lately. So I can’t pursue everything. And I do have to admit that with my reduced time, I am likely never to be the most “technical person” in any given group of TWers. In fact, given that TWers are all generally really good at their jobs, it would be utter arrogance for me to assume I could keep up with them when I only act in a technical role for 40% of my time. So my bar isn’t TWers – they will most likely all be more technical than I am. But it is remaining competent enough to understand at least 40% of what they talk about, and more importantly, remain excited about technology.

So what am I excited about these days, here is my own, personal, “tech radar” (no fancy graphics required):

  • Functional Languages and Big Data

Someday, the world will catch up to where the F#/Clojure people are now. I think the tie between FP and Big Data is strong, and given that is where much of the value will be created in the next 5 years with corporate IT spend, the use of FP will only increase.

  • IaaS (note, I don’t say cloud… too overloaded)

I got the cloud bug this year, and I will admit, I am a terminal case. I saw an app where someone deployed a load balancer with an http request. And not an http request that converts into an email that goes to a tech that puts a physical one on a rack. Infrastructure as code is changing this business. Imagine the ability to specify, in human readable code, an organization’s entire server configuration. And realize that configuration by executing the DSL it is written in. That day is approaching, fast. Imagine the possibilities – from everything to devops to disaster recovery.

Why don’t I say cloud? The term is so overloaded that it is meaningless. Anything that runs on the internet is putting “cloud” in front of it’s name, which is why I have stopped using the term and do everything I can to use more descriptive terms.

  • Lean Startup

Though not a technology, it is the first thing from a project management standpoint I have been truly excited about in years. At least since Agile, maybe more so. Why? It finally closes the loop, bringing in the entire scientific method into the business of software development. It seems so obvious now, it never ceases to surprise me that it took our industry 50 years to adopt it. Lean Startup, to me, is the application of the scientific method to how you run business. I recently did a webinar that nicely encapsulates how I feel about it in much more detail, but my general sense is that this builds on CD and gives organizations that embrace it a much more repeatable, sustainable path to successfully delivering business results with software.

The three things above are the tools I believe will create most of the value in corporate software over the next 5 years. And I fully intend to remain competent enough to discuss these topics with both technical and business audiences, even if I don’t write code every single day anymore. The trick, not being a full time software developer anymore, will be to:

  • Make sure I don’t stop doing some technical work – I still intend to pair program with the team when I can, as well as keep up with a selection of OSS projects I am involved with.
  • Continue to read new technical material – I am on planes a lot, should not be too hard. For example, I am learning Python now, despite that I don’t have a good reason to personally code in python.
  • Be aware – ultra-aware – that I am not the most technical person in the room. My team-mates will likely know more than me, and I will defer to them on technical arguments more often than not, especially if they have decent data on why a given technical decision needs to be one way or another.

Will this work? We will see. I am only in the starting stages of this journey – will be interesting to see the degree to which my technical skills atrophy from not being a full time developer anymore!

On (not) Being Post-Technical

2 thoughts on “On (not) Being Post-Technical

  1. Jon Kruger says:

    There is plenty of room in the world for good software developers with a lot of experience (e.g. Uncle Bob). Why do you feel the need to move into management? I hear so many former technical people talk about how they miss the days when they got to write code. Management does appear to be the next rung on the proverbial ladder in many places, but I’d rather maximize my value doing what I’m best at, which is staying in the technical world. Just because you’re good at many different things doesn’t necessarily make them the best use of your time, do the thing that you can be great at.

Leave a comment