In 2009 Paul Graham posted on his blog about Makers and Managers. I don’t know if he was the first to blog about it but this was the first time I read about it. When I ran across that article in 2010/2011 I really didn’t understand it. I was a full time developer and wantrepreneur so I really didn’t ‘get it’. Fast forward a few years and with a partner Jason Jarrett we launched Resgrid and my perspective changed.
The Maker/Manager issue is about context. A Maker (Developer/Programmer) has a different context then a Manager (Supervisor/Owner/Executive). Context switching is a well known issue for developers, every time you need to thing about something other then what you’re currently working on there is a cost, your brain needs time to adjust, so if you’re constantly switching contexts you will never get in a flow.
In either context (Maker/Manager) you can get into a flow, which is important. Based on our history/skills we will gravitate to one or the other naturally as it’s more comfortable for us. However, this can cause huge issues for startup founders.
When your in Maker mode your looking at features, bugs or whatever and trying to figure out how to do them, which patterns do you use? What architecture would you implement? How is the UI going to look, etc. Your then going to go ahead and implement it.
In the Maker mindset your going to just create and find reasons create. Don’t like that pattern/code refactor it. Oh that feature may be good for 1% of my customers, spend a week implementing it. A Maker’s context is creation and implementation.
In Manager mode, your looking at direction and hopefully utilizing analytics and real paying customers to drive your decisions. You will plan out features, set schedules, work on a budget and gather/document requirements. At the manager level your doing business work, working with customers and growing your business.
In my mind the Manager has much more to juggle, but it’s because I’m far more comfortable being a Maker. Managers don’t handle implementation and will tend to get themselves into analysis paralysis if they aren’t careful. A Managers context is business oriented and the ‘30,000 foot/high level picture view’.
Why set a Schedule?
The issue is that we will all lean toward more one then the other. In my own experience with Resgrid I’ve spent far more time developing then growing the business. Everything I do somehow leads back to more development and more code. As a startup founder you can’t just write code and actually this could be the least valuable thing you do.
So setting a schedule where you will dedicate days to being one or the other will help force yourself to do something your probably not comfortable with. This will help you get into flows and ensure your not letting part of your business stagnate. If your naturally a Manager, maybe your not going to write code on the Maker days, but getting more involved with your product’s guts is important.
Setting the Maker/Manager day doesn’t mean to totally neglect the other. For example of your on a Manager day and the production system has a critical bug you should fix it. But don’t work on feature development don’t develop or write code unless it’s fixing a problem. The same goes for when your in a Maker day, don’t neglect your customers support emails and calls, but don’t work on marketing strategy or budgets.
What am I doing
One of my goals for this year is to get into a Maker/Manager schedule. Monday, Wednesday and Fridays are my Manager day, Tuesday, Thursday and Saturdays are my Maker days. Resgrid deploys every Friday, so part of that day I’ll be in ‘Maker’ mode. Sundays will also be my light/off day I’ll only be working on major issues.
My goal is by Q2 2015 I’ll be fully on this schedule, I’m going to ease into it, due to the amount of work I need to get done on the Maker side.