A Developer’s Primer on Being a CEO (Lessons Learned, Part Two)


I’ve been a software developer all my life, but one day around three years ago I traded places with our CEO and traded Xcode and vim for Google Spreadsheets and Apple Mail. More than a year ago I shared with you my thoughts on that switch. Since I’ve received some questions and comments on my piece, I decided to share the update on my experience and solutions I employ to stay productive.

People vs. Code

Contrary to popular belief, a lot of things related to interactions with people can and should be automated. This is where having a history as a developer comes in handy when you’re switching to more of an executive role.

Let me just state, for the sake of clarity, that I’m not implying people should be treated like code or machines. I might be nerdy, but not that much. There is a multitude of soft skills that many talented engineers have trouble grasping and thriving at, skills which are, in essence, related to human interaction, empathy, and communication. But people also have a systematic aspect to them and we can really make a great use of it using software. Here are a couple of pointers that will help you with that.

First up, accountability – set up a system or a tool that reminds you of delegated tasks and results you expect from people right when the time comes. Delegating without keeping people accountable is a waste of time. You need to remember who you hold accountable for something and when that something is due. Creating a simple list of “delegated” things should do fine, as long as you remember to review it every once in a while (daily or weekly works best for me).

Second up, open loops – keep a list of discussions you have with people that should lead to a decision, some other action or a more tangible outcome. Don’t rely on someone else’s memory to respond to your e-mail or call you back to keep the ball rolling. Remember, use your software of choice to remind others when a certain loop wasn’t closed, e.g. a discussion wasn’t finished, thus making sure nothing falls through the cracks.

Setting up processes comes relatively easy to developers. After all, among other things, development is imagining how to design a flow of individual actions for the computer to execute. Coming up with the right workflows in your organization shouldn’t be that hard. Just remember not to overdo it with too rigid structures. Design a process and solicit opinions on it from others (preferably not developers) before you implement it.

Write things down. When you have a process or a set of rules, write them down and encourage others to do so, too. Keep it as informal as possible and adjust the amount of formality to fit the size and the culture of your organization, but do it. It will make things easier and ensure everyone’s on the same page. Also, the sheer act of writing – just like with programming – will help you understand the rules and processes better and find ambiguities much more quickly. Valve’s “Handbook for new employees” sets a great example and is actually being used in a real-world organization.

Stop, Reflect, and Improve

Plan a weekly review meeting with yourself to look back at the things you’ve done over the course of the past week. Identify what went great and why, and try to keep it up. See what you could have done better, investigate the things at which you have failed miserably. Be frank with yourself and don’t seek excuses. Jot these thoughts down and draw conclusions on how to improve your ways so that next week will be more successful.

Being a developer taught me that such an outlook has tremendous value. At Macoscope, we are pretty religious about Scrum and the iterative, Agile approach in general. One of the key elements of our process are “retrospectives” – structured meetings where we try to look back on the things we’ve done as a team and improve them. It turns out that the same technique can be fairly easily applied to your work as an individual. Things to google: “scrum retrospective.”

I’ve been a software developer all my life, but one day around three years ago I switched places with our CEO and traded Xcode and vim for Google Spreadsheets and Apple Mail.

21 Books On Business, Design and Development Every Entrepreneur Should Read
I Hate Time Tracking