Posts tagged Startup
I’ve been in technology on both the IT side of the house and the Development side of the house now for over 15 years. I’ve seen projects, transitions, major efforts, etc fail gloriously, succeed spectacularly, clutch success from certain defat and everything in between.
I’ve heard a lot about “Failing Fast”. It’s a lean startup principal and is the foundation for a lot of how bootstrappers work. But I’ve seen it more and more in the agile community as well. Companies pick up the “Fail Fast” mantra and repeat it.
Out of all the companies I’ve seen that say they practice “Failing Fast” very few actually do, why because failing fast is hard, very hard. In the world of startup success is only possible because of failure and lots of failure. Slowly people are realizing that for all the Google’s and Facebook’s success stories there are thousands of failures that they stood upon. But for all the good that can come out of failure (I’ve always said I learn far more from my failures then my successes) there are some very real bad parts to it.
First off there is a very real emotional consequence to failure, it sucks, it hurts and it makes you feel like crap. Your ego get’s bruised and you start to question a lot of things, a deep level of critical introspection is never fun. Secondly there is the expenditure of capital (it can be money, reputation, favors or even political capital) that was expended on the failed endeavor that may never be recovered. Next you have the wasted time, resources, brain power and goodwill that all take a hit. If you’ve had 5 people working full time on a project for 6 months, that is a lot of time and effort that they pumped into something that nothing may be salvageable.
Nobody wants to back a failure, especially when they were responsible for pitching or proposing it in the first place. Their ego is on the line when that happens, and it obviously will have an impact on decisions and ongoing evaluation. Finally we all believe at our core that we can accomplish anything, meet any goal or be the single person that can save a project. We all want to be the hero, and how better to be one then to save that ailing project single handily.
Failure can come in many forms, it could be a failure to deliver, failure to deliver on time and on budget or that success just cost too much in the way of relationships, lost personnel, feelings and other items that are hidden from the balance sheet. So yes, even your success could be a failure if you look a little deeper.
So with everything stacked against failure is it any wonder we rarely see a fast failure, especially one with any magnitude? We’ve all done spikes, tested a market and decided “Nah, not going to work” but those are easy and cheep failures. What about a system re-write, where it requires a team months to just get the ball rolling? Do you just call it quits at the first obstacle?
It’s easy when a project fails due to one big cut. The problem that just take the head clean off. You can look at it and say “We failed because of this one big thing and maybe a bunch of smaller ones”. But what about the failure due to a thousand paper cuts? Our tendency is to find a solution, put a band aid on the cut, and keep moving, we end up doing that so much and so often that we forget about all the cuts until it’s too late. This is where “Failing Fast” comes into play, stopping the endeavor before you’ve bleed out.
But it’s hard, you feel like you can’t go to your boss or stakeholders and say “This project is failing because of these little issue”. Their response will be “well those are minor and we can work around them, a new design, reduced requirements, more resources, etc”. But resist the urge to throw ‘more’ at it and analyze why and how it’s starting to fail. It’s easier to do 3 months into a large project, then a year in.
I always have a bottle of Macallan 10 on standby for my big failures, it helps with the emotional aspect.
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.
Every day I get exposed to different architectures and designs for systems. It’s a great contrast to see how a large company tends to have pretty complex software architectures compared to software I’ve designed outside the large company environment. There are many reasons for this, some of it is developers trying to show off, justifying their jobs, create job security, trying to be too clever or trying to be too helpful. Maybe the use cases or requirements were over engineered planning for every “What if” scenario under the sun.
The vast majority of the time it’s not malicious or has even a hint of bad intent. But most of the time on the developer side it’s science experiments that turned into production code or developers trying to make something too “pit of success’ie” without contemplating the drawbacks.
Complexity carries a heavy burden that most developers don’t want to think about and instead look at architecture as the solution to every problem. But too often when simple problems are over engineered it causes more problems down the line. For a large company, this is ok, they can take the extra time, throw the extra money at it or add manpower. For a startup, especially a bootstrapped startup our best feature is agility, and if our software is too complex to be agile we are trying to win a marathon with our legs tied together.
What are some problems that arise from the dark art of architecture and complex system design and why are they bad for startups?
1. Complexity make debugging more difficult and tracing issues more problematic. The more complicated your system is, the more layers it has is more you will have to debug at 3:42 AM on a Tuesday morning when the production system seizes up. When you’re in a startup environment there usually isn’t a DevOps team to deal with those issues for you at odd hours.
2. Complexity creates friction to change. The more complexity the more you need to refactor or recode when you change directions. It’s also more time, and effort you loose when you throw away that system. You will be throwing away code, and lots of it over the life of your startup. When you go in add a new feature or recode something you can then go in and refactor.
3. Complexity systems take more time to code. In a startup environment the easiest, quickest, hacky, ugliest solution is almost always the right choice. The less time you spend on things the quicker you get stuff done and to your customers getting feedback propecia finasteride. Delivering is the most important thing. This isn’t to say you should push out totally buggy unusable systems, they need to work.
4. Architecture is not a deliverable. In the vast majority of cases this is true, but there are cases where this may be false. If your designing a system to say show people how to cook, your users don’t care how may layers you have, how you got CQRS and async full stack with DI and 100% coverage. Are those cool things? Yea, but they aren’t as important as us developers like to think they are.
5. It’s hard to bring new developers into complex system. In a startup environment development is probably one of the least valuable things you can do. As a founder you probably need to spend more time on business development, customer acquisition, planning features, marketing, etc. So you’ve reached that point and you want to bring in a technical founder, consultant or employee, the more complex your architecture the harder it will be for the new people to learn and longer it will be before they are up and running efficiently.
I’m not ‘anti-architecture’ or ‘anti-patterns’, instead I’m of the mindset that there is a time and a place for science experiments, architecture and complexity but rarely are those good for your early stage startup. I’m still trying to fight my inner architect when I develop for my startup, it’s difficult, but next time I’m up at 3:42 AM debugging an issue I’ll be a little more happy.