Take Care of Your Competitive Advantage

You’re a leader of a software team. You bring on a new developer. You explain the problems that need solved, point them to your repo and project management software, and off they go. They make commits. They ship features. They close bugs. You go to work on that other project that could open up a new revenue stream. One day, you hear something curious about the product. You open it in your browser. You pop open some code. Your heart drops so fast you can almost feel it bounce on the soles of your feet. How did so much go wrong? That hire was absolutely top notch!

This is a scenario described by Michael E. Gerber in The E-Myth Revisited, with a bit of poetic license. He calls it “management by abdication”. In other words, you bring a person on to handle the tasks you don’t want to do yourself, and you simply leave them to it. Mr. Gerber is talking about a particular time in the lifecycle of a small business (the “E” in E-myth stands for “entrepreneur”), but this same scenario occurs on many a software team.

Imagine the scenario played out further. You find them the next day. You ask them how things could’ve gone so awry. They are shocked you think anything’s wrong! They worked tasks in the project management software. They even fielded bug reports themselves. They fixed those bugs as they arose. They worked hard, and did everything as they’ve often done throughout their careers. Why are you suddenly upset at them when they’ve had their nose to the grindstone? Often, the end result is one of the worst things for a software team today: the loss of an otherwise qualified, contributing, knowledgeable team member.

Let’s take a step back. Back in time, say 100 years ago or so. As Peter Drucker discusses in Management: Revised Edition, for most of capitalistic history, the business owner owned the equipment and all of the raw materials to produce the business’s product or service. The business owned what is called the means of production. Today, that is often not the case. A significant portion of the world today is made of knowledge workers, such as software developers. As software developers, we hold the means of production literally in our heads. (It’s actually super-cool, if you think about it.) There’s one effect of this that is most pertinent: every software developer takes the means of production with them wherever they go. Software developers are not just costs. They’re the business’s assets, just out there walking around, able to take themselves to a competitor over a cup of coffee. In the past, a business owner’s competitive advantage might have been in equipment, or in access to raw materials. Today, the competitive advantage is people.

If people are the competitive advantage, why is it so common to neglect them?  Have you met people? People are flighty. A century ago, no business owner ever would have neglected their equipment! At least, they would not have neglected their equipment and maintained any advantage in their industry. Unlike that equipment, people are left alone, running, for months or years, like a car that never has its oil changed, brake pads replaced or tires rotated. When the machine no longer works for us, we wonder why; or worse, we are upset, or even angry about it.

Knowledge workers do need autonomy, as Peter Drucker writes. A few sentences later, he adds to the discussion the need for knowledge workers to be “seen and treated as an asset, rather than a cost. It requires that knowledge workers want to work for the organization in preference to all other opportunities.” In other words, at least change their oil once in awhile, so they’ll stick around.

Let me tell you about my friend Alex. Alex joined Fretless a year and a couple months ago. We told him nearly a year prior to him joining that we were going to try to hire him as soon as we were able. We were all stoked to have him join the team, and I think I can say with certainty that he was stoked to join. He immediately put in some pretty rough weeks trying to help us close out a couple projects before he moved on to helping a large client of ours full-time. It was great! We asked him to help us with this task or that task, and then trusted that he would do it. He did, of course, because he’s Alex; he’s awesome. He worked with the large client for the next 9 months or so. Dave Jones was also working with that client, on the same project.

From time to time, we would hear that things were going well with the client, from one or the other of them. So we left Alex and Dave to it! No need to bother them, we’d think. They are incredibly capable developers, intrinsically motivated. Let ‘em work. In fact, I think I met with each of them one-on-one over lunch maybe twice over the course of those nine months. I had an idea that we should be talking more often, but I was slow to act on that idea.

Fast forward to March. Alex moved on to a new challenge at MOBI. We are all stoked for him, truly. We know he’ll do amazing work there! But Fretless lost some of our competitive advantage. There are many complicated reasons that led to Alex’s choice to leave Fretless. I mean it when I say I’m happy for him, and I think he made a good choice. But what if we hadn’t neglected him? Could we have helped him grow within Fretless instead? Could we have improved his satisfaction with Fretless? Could we have at least known the answers to these questions? Though the end result might have been the exact same regardless, these questions are going to haunt me.

What should we have done differently? What should you do? Have weekly one-on-ones with your employees for 30 minutes each. Yes, weekly. Seriously! Make it about them. Not a status update on their projects. Try to make it about what is on their mind, what they need, and what they want. Don’t take my word for it, though. Give this Manager Tools podcast a listen (and then part 2 and 3, as well). It’s worth 30 minutes once a week to form an actual relationship with the people you serve.

If we software developer managers, or would-be (could-be, should-be?) software developer managers continue to abdicate instead of care-take, developers will continue to stick around only until it’s convenient to leave. Instead of neglecting your competitive advantage, nurture them. Talk with them weekly. Give them feedback—positive and negative. Coach them to be even better. It’s difficult, but it’s better than losing your advantage.


Management Isn’t a Bad Word

I have worked as a software developer for different people, with different styles, and different goals. I’ve loved managers, hated managers, and everything in between. I grew to be cynical about managers and the word “management”. The idea of a person who was a “manager” of programmers-as-people became somehow a role fraught with danger, both for the people who would report to the manager, and to the person in the role – who surely was a respectable person before taking the mantle. The concept of a manager seemed one to distrust. I’d say that this feeling is prevalent among software developers.

In November and December of 2016, I had the pleasure and honor of stepping in as the Interim Director of Engineering for Springbuk. I was sending myself into danger, knowingly! I thought that my experience co-directing Fretless, and leading community groups like Indy Hackers and Indy.rb, would provide the knowledge I’d need to step up and perform the role well. After all, I had been working with the Springbuk team for 10 months in a senior developer type role. No sweat, right?

Wrong. Surprisingly wrong! Up until then, I did not appreciate the pressure of being a manager. Being the boss of a team of 10 or so at a startup that is trying to move quickly, satisfy customers, please investors, etc. involved doing much I had never done previously. In fact, they were probably two of the most stressful months of my life. I learned a ton, as well as put myself on a path to learn more. I want to share my experience, what I have learned so far, and the resources that have put me on the path to learning much more.

Keep reading »


Reasons I Like JS Again: ES6

keep-calm-and-hate-javascriptI hated JavaScript. (See my last post.) Hated it – even as my colleagues at Fretless, Davey and Dave, wrote copious amounts of the stuff using various frameworks, and then began teaching week-long JavaScript bootcamps at ElevenFifty.

Oh, I still wrote it, but I wrote it with the attitude of a king condescending to shake hands with his lowliest of subjects. Instead of donning a royal glove, I clothed myself in sneers and vitriol. When Andrew, David, and Missy at OurHealth asked that I stop adding CoffeeScript files to their project, I managed to merely frown. (And then I went to Vim and converted the piece of code I was writing to plain-ol’ JS. Hey, man. Sometimes you appease those with whom you are working on a project. It’s the right, respectful thing to do. … I do think I left one .coffee file in there for them to remember me by.)

Thankfully, JavaScript, the language, receives updates and improvements, much as any other active software project. This June we’ll see the latest release of ECMAScript, the standardized language of which JavaScript is an implementation. It is called ECMAScript 6, ES6, or ES2015. It features what I see as vast improvements to the language. Though much maligning of JavaScript is due to misunderstanding, its current standard still suffers prominent warts that make every day use of the language frustrating for many. ES6 eliminates many of those frustrations, making JS more enjoyable for every day use.

I’m excited to tell you about some of the new features.

Keep reading »


React.js and Flux Made Me Like JS (Again?)

Chimera-from-Greek-mythologyI made it known to those who work with me regularly – whether they wanted me to or not – that I hated JavaScript. Like everyone else, I had written jQuery-heavy monsters of knotted, warty code fit together like a failed experiment in creating a chimera. You know what I mean – all the horror of combining a lion, a goat, and a snake, but with obvious seams and too few legs. I had written Backbone, Knockout, and dabbled in others on the front-end – with good intentions and a positive attitude, I swear. I wrote a Node.js app in an early version of Express. All of these things piled atop one another and led me to the conclusion: I hate JavaScript.

I more or less gave up a couple years ago.

I recently began working with Kyle Shipley at Health Pro on an internal project using React.js. The framework was released well after I threw my hands in the air in disgust at the state of JavaScript and its ecosystem. It turns out a lot has happened since then, and it’s been overwhelmingly positive. Though I will always enjoy making jokes about a new JavaScript library appearing every second, I now see the quality and robustness in the community that I was missing before. React is a huge part of that – for me.

There are a few primary reasons React has me so excited to be writing JavaScript again. I am not going to talk about what React is, what it does, etc. You’re way smart, man. You can follow links, and probably search on the World Wide Web when other means fail you. I’m just going to tell you what I like about React.

Keep reading »