Steven,

We have a serious problem in our development process that needs -- for everyone's sake -- to be addressed here and now as a topic requiring immediate resolution. I took a step back this weekend to look at Irrive from a different vantage point, and the reality is clearer to me than ever:

The bottom line is that we are always setting unrealistic, demotivating deadlines, which are resulting in a stressed-out, exhausted team and increasingly inferior product -- both of which are only going to get worse unless great changes are made, with great haste. Unfortunately, this situation was left unchecked for far too long, and my letter comes at a time when everyone is already at an exceedingly low point, making sacrifices to both their work and their lives that they are not proud of. No one is given a chance to legitimately feel like a 'winner', as most of what on the surface level appears to be successful 'cranking' is just an aesthetic cover-up of a very bad solution.

Let me be straightforward with you: The developers are writing bad hacks -- substantially worse code -- for the sake of 'meeting' deadlines that are largely arbitrary. Yes, we all know that we need to move fast. However, despite pop-culture yarns of motivated young hacker teams building product prototypes in a weekend, good work is not usually manifested in this way. By sacrificing the possibility of letting our developers do their work in the right way, we are actually losing rather than gaining time... That is, in the future, via unnecessary bug hunting and fixes, easily avoidable rewrites, etc. Did I mention that we also risk sacrificing internal and external credibility when this happens? We really do, and that kind of damage is a MUCH harder fix.

Steven, our development team is tired, stressed to the max. Every single person. Do you realize that Noah has not had a day off since he started working with us, or that some of us feel physically ill when we're in the office, due to the palpable tension in the air? What we're doing simply isn't sustainable, but luckily there are some basic steps that we can take towards massively improving the situation.

Here is what we need:

-- REALISTIC DEADLINES, COLLABORATIVELY MEASURED

As stated above, our deadlines are always off, and we have not yet hit a single one -- even with our killer team! This says that deadlines are simply not being calculated appropriately. We need to fix this in the following ways:

#1: ALL developers involved in a given project should be involved in the planning of deadlines. Every single one, without exception. All inputs are valid here.

#2: We need to take -as much time as is needed- to plan them. The decision will not be made in a flash decision after 2 minutes of talking with people who haven't researched the requirements.

#3: Steven, you are not to be included in the initial conversation; we need to let the devs have an open, honest discussion of TECHNICAL FEASIBILITY, uncolored by your desires for more, faster -- and their desire to please you. This will result in something more like accuracy, and your milestone requirements can then be mapped into our plans realistically.

-- TEAMS

The approach of everyone being able to jump into anything, anytime, is, in my view, inappropriate -- and not just from a technical perspective!

I know that this expectation of flexibility is again partially a result of the pop-culture stories of young hacker teams... But let me say this: We don't have such a team. We have highly experienced people who know what they're doing, some of whom have come to specialize in one thing or another. That means, despite having the technical chops to be able to 'figure it out', huge time and productivity is wasted to put someone on a task that they are not comfortable with.

The solution to this problem is having teams, possibly more specific than "frontend", "backend", etc. Let people hone their skills and build their toolkits. That is what will end up producing work faster. Camaraderie will also be built in this way, rather than antagonism, which will soon be the result in Irrive if the madness is not curtailed.

-- PROPER WORKING HOURS

Almost everyone on this team is hovering at around 30 years old. We are not teenagers. We have lives outside of work. Some have families of their own to take care of. Expectations should be "9-5". Working a team every day of the week is unproductive and demoralizing, producing sloppy work and disillusionment.

This does not mean the total absence of overtime hours in some circumstances, but for example, failure to meet a deadline on a Friday should not automatically imply work over the weekend. What that implies, instead, is a failure of planning that needs to be addressed in the next cycle.

Many sites that you know were built in this way, rather than a manic, non-stop code frenzy. LinkedIn is one prominent example.

-- YOU, STEVEN OUT OF DEV CHAT

You cannot be in the development chat room anymore. CANNOT. The team needs to be able to talk about things openly, utilizing the tools and resources needed to accomplish the tasks that they need to accomplish. Right now there is this sense of: "Is steven going to like this, how is this going to make steven feel?" -- which is completely non-productive. We need transparency and honesty in there, above all.

A perfect example of this problem is the other day, when Anthony was having problems with his environment and made it a public event to figure out. You made a comment about having your whole team helping him and how you wanted it out of dev chat. My thought was, why don't YOU get out of dev chat? Because the direct result of this is that people are going to ask less questions publicly, for fear of worrying or disappointing you, which leads to FURTHER productivity problems. It's shitty, and isn't going to work anymore.

Secondary to this is your direct probing and questioning. No one likes it when you are on their cases; it does nothing to improve the delivery of quality code -- it just does the opposite. With your pressure, the developers rush to get 'something' done, which is usually of a worse quality.

My summary is: Trust your team or get a new one that you CAN trust. Everyone is working to get something done to meet the expectations and needs of both the product and company. You can either believe it or not.

-- A SCRUMMASTER

I've been talking with my friend Lars, a young but surprisingly experienced German developer, about scrum. It turns out that what scrum is, is really about figuring out a team's capacity -- what they can actually DO under typical circumstances -- so that an appropriate amount of work is expected, and the appropriate features prioritized, within the understanding of about how long it will take. That is the PRIMARY use case.

We need an experienced ScrumMaster, immediately. I could potentially be trained to be, but right now I am not that person. I have asked Lars to come in on Monday and show us how it should work, and he kindly agreed to do so without compensation. Lars will show us what to do, what tools to use, etc. I would like us, as a team, to spend at least half of Monday working on that.

-- A PROPER PRODUCT MANAGER [TRADITIONAL] / PRODUCT OWNER [SCRUM]

Have you made Ryan Brown an offer yet?

I'm sorry to harp on it, but we need someone to manage the product -- someone who has deep, loving care for the kind of work that we are doing, but who isn't you or Stanton. I wish that person were me, but you know my feelings about all things social media: I am not an appropriate hire for that role, because I will never actively use the product.

And PS, your Product Manager will be needed in the Scrum world ('product owner'): the keeper of an intimate understanding of why every single piece of the product works the way it does, and a vision for how it will change. This is crucial.