Skip to main content

About the Author

What happens when a 10x developer becomes an IT manager?

Great things, I promise you!

From <html></html> to SELECT userID FROM users

Yep, that's me. I worked in the web development industry for two decades, starting with good ol' Notepad on a Win95 machine, writing HTML by hand, and testing on the latest version of Netscape (Gold!) From simple HTML assembly I moved on to dynamic web pages and database integration, with most of my work focused on content management systems, the precursors to today's blogging systems like Wordpress, Drupal, and Ghost.

The Wonderful World of java.lang.StackOverflowError

I also worked on an awful lot of legacy systems over the years, pieced together by both junior and senior developers alike. These apps touched a lot of verticals: healthcare, education & learning systems, automotive sales, maintenance ticketing systems, computer & video games, the restaurant industry, the bagel industry, and real estate & property management. I even got to break bread with the big shots in the National Football League, working on websites for teams that called the rocky mountains their home.

The chaotic rush of agency work abruptly came to a halt with the slow-as-molasses pace of corporate America, and each environment had its own set of...shall we say...challenges. Yet whatever the cadence, I pursued these never-ending problems relentlessly. Band-aids were not my thing; when I fixed something, it was imperative we weren't papering over the cracks. It affected me so deeply, I couldn't sleep until I sussed out a root cause in each and every troubleshooting operation. It pained me not knowing the answer.

"Yeah...you didn't put a cover sheet on your TPS report..."

Finally, after twenty years of development, I got my shot at management. I took everything I'd learned as a 10x developer and was certain I could do the same from the top down. And while it didn't quite send me screaming to the asylum, I will say there were plenty of things I wasn't prepared for: Waste. Bureaucracy. Poor communication. "Winging it." And smart people constantly forced to do the same things over and over and over.

So how did I tackle this challenge? Well, it can't be summed up in a paragraph or a blog post, but the mentality shift can be:
The most powerful tool a programmer has to fix code...is the 'Save As...' dialog in your editor; the ability to actually rewrite something. Fixing a people problem is far more difficult, not because you can't find the problem...but because people don't want to be fixed.

Dunning-Kruger Eats Agile For Breakfast

Code has no agency; it isn't self aware (yet!) It doesn't care if you write it, break it, compile it, launch it, publish it on GitHub, or delete it forever. So the biggest obstacles programmers have...is already handled for them. When code breaks, they simply leap in and begin troubleshooting.

No so with people. It's easy to spot people problems; it's quite a differently entirely to solve them, especially when cognitive biases and logical fallacies trick humans into thinking everything is fine.

I enjoyed success as a professional developer because of my hyper-vigilance towards constant improvement. After I wrote code to execute tasks, I wrote more code to repeat those tasks. After "fixed" applications continued to crash, I built debugging infrastructure to capture, track & document errors thereby improving the accessibility of the code to more junior maintainers. I freed my time for more thorough investigations and empowered those around me to do better work.

So when I became the boss, constant improvement meant thinking bigger. Instead of code to repeat tasks, we were automating entire deployment processes. And when the same people made the same mistakes, I didn't yell, bang desks, or call my team to work late into the weekend. I relentlessly pursued knowledge around why humans behave the way they do...and what were the most effective guardrails to put in place.

The result? A style of high efficiency management that keeps:

  • teams excited and productive without working them to the bone, and
  • the companies that employ us profitable and successful without resorting to downsizing or "calling in the Bob's"


Isn't it time for you to enjoy that success as well?

Popular posts from this blog

Sad Stories

How are you measuring the quality of your product management? Is it: How accurately you adhere to Scrum?  How close your velocity matches your SLO?  The number of bugs fixed in this sprint? None. of. this. matters. A surface level review of these metrics would seem to matter to folks desperate to boast about their Agile compliance, while failing to remember the first edict of the manifesto : Individuals and interactions over processes and tools A recent tweet reminded of this: Wow! I reported a unicode issue affecting URLs to 2 different commercial software companies. One responded in 4 days indicating it'll be fixed in a yet-to-be released new version (which requires more $$$); the other provided a working patch in less than 3 hours. — James Moberg (@gamesover) June 18, 2019 While I can't comment on what specific bottleneck is separating these two companies, I understand (all too well) the side-effect of throwing everything into a Scrum bucket. Af...
Read more

Tired: 10x Developers. Wired: 10x ENVIRONMENTS.

image: the mythological 10x developer, caught in its natural habitat. A 10x developer thread blew up on Twitter over the weekend. A startup/disrupter posted their tips on how to find the mythological 10x engineer and what massive rewards your organization will reap by having one. Unfortunately, their "tips" only amounted to the perpetuation of a very different type of engineer: one who can't mentor, can't be bothered to attend a meeting, knows only code (to the detriment of all other soft skills), and will insist on doing things the right way...aka their way. In short, it was a list of attributes that described a toxic developer. After having slung code for two decades...and am now charged with leading my own team of developers...here is the harsh truth of the matter: If you want to build a team of highly productive developers, focus on building a 10x environment . Build knowledge sharing into your process, so your team is actively invested in educa...
Read more

How Do I Use Myers-Briggs To Assess My Team?

Question: How do I use Myers-Briggs to Assess My Team? Answer: You don't. Seriously. That's my answer.  Don't do it. Still reading? (sigh) Alright, if we're going to do this dance, let's get it over with. Myers-Briggs is Junk Science When a hypothesis is tested in a controlled experiment, proven, and those results are vetted by independent peers, you have yourself a little thing we like to call scientific evidence. Leave any of these on the table (eg. you make a hypothesis but don't run an experiment), all you have is opinion . The missing piece in Myers-Briggs (or MBTI) is that last part: independent verification by peers . Scientists uninvolved in the hypothesis need to be able to reproduce the experiments and put their career on the line by saying, "Yeah, this other scientist I don't know anything about...they're 100% correct." The only "verification" that Myers-Briggs has is via the Center for the Application...
Read more