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

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

While this story may be a little unusual, a lot of software developers are starting their own companies or become managers of some sort down the line, which in a lot of ways is similar to what happened to me, although the shift is not always as extreme or sudden.

In this little piece I wanted to share some of the experiences I had during the transition and lessons learned looking back. I hope that it will be of value to some of you.

Usually, a software developer’s day looks something like this:

Sometimes, to our dismay, a meeting happens. Think a scrum stand-up or some other project-related discussion. It’s better if it was planned, but even if it was, already in the first part of our day we feel like “we don’t have too much time” and after that, “there’s really not enough time to start working on very complex problems.”

A day like that is far from perfect as far as efficient work goes. No developer likes to be interrupted when working on something difficult and knowing that this major interruption is going to happen anyway severely impairs our productivity – no doubt about it.

If you’re with me so far and nodding in agreement, take look at the following day plan.

It should actually look more like this…

… which is pretty much how my days look like right now.

Developer’s nightmare, right? I think it is. Because this is how different the work cycle is for cranking out code versus leading (or rather managing) an organization. I’m not saying that either is harder than the other. I’m merely stating that the two are extremely different and therefore require completely different approaches. For your sanity’s sake, at least. If utter lunacy isn’t something you’re afraid of and you enjoy whipping yourself with constant and unexpected interruptions, don’t bother to read any further.

If that’s not the case, let me point out a couple of things I learned the hard way (so you don’t have to):

Stop Writing Code. Now.

Just before I traded places with Daniel (our CEO), I was managing two teams on two projects and doing deployment support for one of our clients, all the while trying to keep up with Code Pilot maintenance. So even though the transition to the new position didn’t happen overnight and I was taking over Daniel’s responsibilities gradually, I quickly arrived at a point where I was fucking up most of my “old” duties. It was especially visible in the code I was supposed to deliver. “Oh, it’s a small fix, let me do it myself just before the call” — I’d say. In the end, most of the time either the call went bad or the code wasn’t there. Actually, both instances were getting more and more common. If I was to point out the single biggest source of frustration at that time, it would be me not quitting Xcode altogether.

So stop. Just stop. Uninstall your IDE, remove all of the documentation, hell — get rid of the compiler if it helps. No small fixes, no quick builds. Nope. Ask someone else to do it. Show them how if they don’t know. If it takes more time initially — fine. Tell people they have to wait. At least you’ll have the time to tell them something. And it will be easier the next time around. Everyone will know you can’t do it anyway. No compiler, remember?

Get Organized and Plan Ahead.

As I mentioned before, being a developer is relatively easy in terms of time management. You don’t necessarily need a sophisticated task management system. Due dates, priorities, reminders, scheduled activities, meetings, paperwork — nothing like that. All you need is a well-managed project, an issue tracker, prioritized tasks, and that’s it. It’s pretty routine stuff. You just code through the stuff, task by task, sprint by sprint. Maybe there’s even someone who watches over your time, keeping all the new stuff out until the next iteration.

It’s very different for people who run companies. You need to go out and meet people. Plan ahead. Secure the time to get there. And on your way there? — well, a million things can happen in the meantime. Someone is sick, somebody else needs a raise, a new project comes up, the call gets rescheduled, meetings shift, new paperwork comes in plowing through. And on and on and on. Then, back at the office, when you sit down at your desk thinking “Now I will finally do some real work!”, at that very moment an e-mail notification pops up and you have 200 new things to work on first. Before you even start wrapping your head around it, someone knocks on your door and wants to discuss something or “just ask a quick question.” And you have to be nice to people, remember? Caring, passionate, and always with a smile on your face. Even when all you want at that very moment is to go all Ballmer on them.

You have to find a way to manage that mess, even when it feels overwhelming. I tried a lot of stuff, but only a few things managed to stick. All of them really simple:

  1. Inbox Zero — do it. Just do it. Reply, delete, or convert into a task and archive. Don’t leave it to sit there. Your inbox isn’t your to-do list. Really. For me, Inbox Zero is by far the easiest way to feel more organized and in control. I also experimented with the Yesterbox technique and use it every now and then, especially when the going gets really tough.

  2. Things — I loved it and I hated it, but always ended up coming back to it after a while. Simple, iOS + OS X, sync works great, and it’s quite flexible. That’s enough for me. Lags a bit behind the competitors when it comes to features and design, but still cuts it if you know what you want. If you don’t like Things, check out OmniFocus.

  3. Calendar — definitely not an essential tool for software development, but super-important for managing your time. Not much to explain here — to know what happens when is a must. Also, share it with your co-workers to know who’s out of the office and when. Keep your Google Hangout link or address in the notes for events. And please, don’t calculate timezone differences by hand.

  4. Reminders or Due.app — let’s face it — no one stares at the calendar all day. Sooner or later something will be forgotten, alerts misconfigured, mixed up, delayed. But for very important (or repeating) things, use Due to bug you. After a while you might start hating reminders and feeling like a slave to them. Until then, learn to use them to your advantage.

  5. Actually manage your time— stop and think on your schedule. Which day of the week is best for meetings? When are you most effective at answering e-mail? When you’re still in bed in the morning? Just after arriving the office? How about the best time to do more creative stuff? Work on a contract perhaps? When do you prefer to make calls? Try to establish routines and use them to your advantage. It will make things easier, or at least less stressful. The universe will adjust.

  6. Plan and synchronize communication—rather than randomly pick people to ask them questions and check the status of things every time you feel the urge to do it, set up a short, daily or weekly meeting. Also, have the agenda ready, so you’re not wasting everybody’s time on unimportant stuff and discussing all matters at the same time.

    Experiment with your schedule. Do you really have to be at the office every day? Maybe just Tuesday and Thursday would do? Think about staying at home (or at a café) for a couple of days and doing all the things that require intense concentration in a quiet setting, leaving the rest of the week for meetings, communication, and casual chatting with your colleagues. You will feel more relaxed when you stop trying to fit these two extremely different activities in one stretch of time.

  7. Focus – if you have problems with your attention span and staying on task, there are ways to fix this, at least to some degree. Check out the Pomodoro Technique (I will write more about how I use it in my work in one of the next posts), Focusbar (Disclaimer: that’s our app), and ways to wean yourself off of Facebook, news sites, and other distractions.

There are tons of great time-management techniques available, and even more apps and books on the subject. I myself would recommend starting with the classics: Stephen Covey’s The Seven Habits of Highly Effective People and David Allen’s Getting Things Done.

Read the two and try to implement some of the things that seem to be the easiest for you.

Delegate Well

“The surest way for an executive to kill himself is to refuse to learn how, and when, and to whom to delegate work.” — James Cash Penney, founder of the J.C. Penney retail chain.

Delegation seems to be the No. 1 problem of newbie managers. Good programmers often say “I will do that better than anyone else,” and it’s probably true, because when you’re good at something, you strive for perfection, and being a developer usually leaves you somewhere at the end of task food chain. So naturally, your or one of your peers’ IDE is where stuff to do ends up.

What makes it hard to delegate tasks isn’t just that asking someone else to execute what’s on your plate seems inefficient at first, you also need to let go of the process. You can’t continue telling people how to do their job, because then it will really be nothing more than a waste of time. You need to tell them what the expected end result is, what the available resources are, and how the execution will be evaluated in the end. Then let go. Don’t micromanage.

Let it flow and if you do it right, you will feel a pleasant wave of surprise wash over you afterwards, the weight lifting off your shoulders, and sheer happiness that someone could do that as well as you, maybe even better. All the while you were accomplishing yet another task. I believe that this is the closest we can get to bilocation.

Remember to start with delegation- before you begin executing any task, think for a second if there isn’t anyone else in your organization capable of doing it better than you do. Or, at least, someone who will handle the matter properly. And think hard, because failing to recognize this is just another side of a fundamental delegation problem. It’s on your task list, so obviously you should be the one to do it, right? Wrong. Even if you can’t come up with anyone else to delegate the task to, maybe there’s a position to be filled in your company that you haven’t considered yet? Investigate it.

If you’re interested in learning more about good delegation methods, I’d like to once again recommend the good, old Seven Habits of Highly Effective People, written 25 years ago by Stephen Covey.

Or google “stewardship delegation.”

Code. But Be Careful.

When I said you should stop writing code, what I meant is that you shouldn’t do it professionally anymore. You simply can’t commit to code-based deadlines and reliably deliver on them, because of the fundamental differences between the work of a developer and the work of an executive. Just as your tools are different, so are your priorities and attention needs, even the entropy that creeps in isn’t the same.

Having said that though, you still can, and probably should, use your development skills to your advantage. Being a developer-executive gives you a tremendous lead on others. You can quickly put together a script that will help you test assumptions, automate your everyday life more, or make you more productive. Small bits of code can also stand guard over the well-being and performance of your business and/or yourself and alert you whenever it gets a little too crazy.

It’s best if you stick to one tool from your toolbox. You won’t have too much time to keep up with the technology, so just pick one. I myself found that Ruby is a perfect general-purpose language to help me with a wide variety of things, but probably any high-level language will do, as long as it has a lot of open source libraries readily available.

Let me list a couple of things I cooked up that helped me tremendously so far:

  1. Harvest reporting – since we’re doing iOS and OS X development for a living and charge by the hour, time == money, for realz. Everyone logs the time they spend working on a given thing in Harvest. I need to know how much money we “made,” how people are performing, and whether all the projects are on track in terms of development pace. I definitely could get all that info from logging into Harvest and going through a couple of reports, but we need to be up to date all the time (at least once a day). So I created a suite of scripts reporting the following parameters every morning to everyone involved in managing the projects:

    • Who spent how much time working and how much revenue has been generated?
    • How much of this time was actually billable (not internal assignments, open source, etc.)?
    • How much time overall was spent on each project and how much money did that bring in?
    • What was the “billability” that day (% of billable time)?
    • How much revenue has been generated?
    • How do all of the above compare to data from the previous 7 days as shown on charts?

    And you know what? It’s great. One of the first things I do in the morning is a quick look at the Inbox, then open our Harvest Reports (especially the charts for longer periods, documenting trends) and I already know how we are doing.

    Just recently I hooked up the script to a Google Spreadsheet file, where we try to model our needs in terms of work per person and per project. This enables us to immediately see whether someone is working too much (or not enough) and whether we’re spending the agreed amount of time on every project collectively.

    There are actually three scripts like that – a daily, a weekly, and a monthly one. Each of them shows our current performance relative to our efforts days, weeks, and months prior. And how far off the planned course each parameter is.

  2. AppFigures review report – this is something everyone on the team gets. It’s a script which uses the AppFigures API to look for new reviews and sends them over to us every day. Nicely done with stars, flags, translations, and all that. I decided to open that slap-in-the-face / fireworks-of-appreciation stream from our users to the whole team, so everyone has the chance to care.

  3. TwitterAlarm – a few years back, before social monitoring tools like mention.net came around, we wanted to know whether our little marketing tricks worked at all. Twitter was pretty important for us, so I decided to write something simple that would report on everything (by the regular expression) we wanted to know. I quickly cooked one up and when anyone mentioned something about one of our apps it immediately informed us about it.

  4. Hiring – That’s one of the most recent things I’m opening my TextMate for. We’re growing and always on the lookout for great iOS and OS X developers. I created a set of scripts that look people up on github and checks whether they fit my requirements (% of repositories starred/watched related to the technology we’re using, activity, reputation, location); if they seem to be good, I try to contact them and invite for an interview.

    The same goes for Twitter – I look up whether they’re following iOS superstars, talking or favoriting tweets about Xcode, iOS, and tweet from locations I’m interested in – and if they do, there’s a chance they’ll receive an invitation for a job interview from me sooner rather than later.

    I will probably combine the two into one and add some LinkedIn automation as well.

Just learn the following quote by heart and always repeat it three times before you start your next little side project; it will help you get through the daily grind:

“I suppose it is tempting, if the only tool you have is a hammer, to treat everything as if it were a nail.” — Abraham H. Maslow, Toward a Psychology of Being

Remember, if you were a software developer for years before becoming an executive, you will naturally gravitate towards solutions based on code rather than leading people.

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

P.S. You can read Part Two of this post here.

I Hate Time Tracking