An Open Letter to the Software Managers of the World

Dear Software Managers of the World:

We, the Software Developers of the World, realize that our two factions have had many disagreements over the years. Through this letter we would like to extend our hand in a gesture of reconciliation.

This letter contains two lists: the first list describes responsibilities we are willing to accept wholeheartedly, assuming you are willing to accept the second list with an equal amount of zeal and commitment. These lists are not intended as indictments of either side, rather glimpses of an ideal world where developers and managers work together in harmony.

We, the Software Developers of the World, agree to the following:

  1. We will do what it takes to get the job done without being asked, including working extra hours (as long as it does not violate clause 1 in the section below).
  2. We will not complain when we are assigned boring tasks, bad problems, or have to maintain someone else’s code (as long as it does not violate clauses 4 or 5 in the section below).
  3. We will bring issues to your attention constructively and with proposed solutions.
  4. We will seek to understand a decision before questioning it.
  5. We will build the best software we are able to.
  6. We will be loyal to the company and our team.
  7. We will be passionate about the software we build.
  8. We will be available when you really need us.
  9. We will fully document our code and designs.
  10. We will happily coach and mentor new developers.
  11. We will tell our friends how cool it is to work at our company.

In turn we ask that you, the Software Managers of the World, agree to the following:

  1. You understand that “crunch time” is an unexpected part of software development. Unless we have substantial equity in the company, crunch time will not exceed 3 weeks during any 6 month period.
  2. You will give us powerful, best-of-breed PCs, huge hard drives, large monitors, and the latest development software.
  3. You will listen and take action when we constructively bring a problem to your attention.
  4. You will ensure that at least 80% of our time is spent on good problems.
  5. If you plan to call us when software breaks, we will be given time to refactor and stabilize it as needed.
  6. You will not ask us to serve as technical guides for highly paid contractors only to be held responsible when their code single-handedly brings our operations to a grinding halt.
  7. If marketing is allowed to set our deadlines based on their knowledge of software projects, we will be allowed to set their budget and/or revenue expectations based on our knowledge of marketing.
  8. You will not ask us to compromise a solid, stable, and maintainable design in order to meet an unrealistic deadline.
  9. You will communicate expectations to to the stakeholders. You will ensure that before we begin building an application, all stakeholders spend ample time reviewing and understanding the specification.
  10. You will ensure that as new requirements arise we will be given the corresponding amount of additional development time.
  11. You will pay attention to your people more than your bottom line.
  12. You will make our company a cool company to work at so we’re not lying to our friends.

We hope you take these items under consideration and we look forward to how these changes will positively affect our relationship as we continue to work together to build software for many years to come.


The Software Developers of the World

Digg thisDigg this

If you liked this post you’ll also like Nine Things Developers Want More Than Money.

Thanks to Mike Taber, Andrew Black, Jeremy Lukensmeyer, Dave Standring, and Adnan Masood for their input. Special thanks to Mike Taber and Dave Standring for reading drafts of this post.

Start Small, Get Big
Growth Secrets for Self-Funded Startups. It'll Change Your Life.
What you get for signing up:
  • A 170-page ebook collecting my best startup articles from the past 5 years
  • Previously unpublished startup-related screencasts
  • Exclusive revenue-growing techniques I don't publish on this blog
"The ideas and information Rob provides should be required reading for anyone that wants to create a successful business on the web." ~ Jeff Lewis
Startups for the Rest of Us...
If you're trying to grow your startup you've come to the right place. I'm a serial web entrepreneur here to share what I've learned in my 11 years as a self-funded startup founder. Luckily several thousand people have decided to stick around and join the conversation.

For more on why you should read this blog, go here.


#1 Dewayne Mikkelson on 12.06.06 at 6:45 pm

This is an awesome letter, if only we could get some buy in on this. I would really like to set marketings budget too!

#2 http:// on 12.06.06 at 8:28 pm


#3 Richard Banks on 12.06.06 at 9:44 pm

Pretty amusing. How about a couple of extra ones: Devs: – We will take a pragmatic approach to problem solving and not over engineer our solutions. (might be contrary to point 5 though) – We will take the time to explain technical problems in a non-condescending manner as required Managers: – You will not go all glassy eyed when we discuss technical issues with you – You will give us time to keep up with technology and time to learn “new stuff”

#4 http:// on 12.07.06 at 3:20 pm

Great. How about? Devs – We will do our best to estimate effort accurately; we will not overpad estimates for things we are not eager to do; we will not lowball estimates for things we want to do so you will buy into them Managers – You will let us estimate the effort and duration for the work to be done – You will never give us false, accelerated deadlines to make us work faster

#5 matt v. on 12.16.06 at 2:39 pm

Great letter! I’ve thought about crafting something like this for a while now (tech support vs. CIO).

#6 http:// on 12.18.06 at 6:08 am

Wow. I think you broke just about every agile rule in the book with this one. Starting with the “we vs. they” attitude… Saying “my manager stinks” is just an excuse for not having the guts to take responsiblity for your own career. What are YOU doing to better the situation? What are YOU doing to communicate to stakeholders? What are YOU doing to explain to marketing why the deadline can’t happen without scope changes? If you just want to bang out code while whining about how unfair the dev world is, be my guest. I’d rather hire someone who’s seeking solutions to these communications issues through active participation.

#7 rwalling on 12.18.06 at 6:52 pm

Patrick – I think some clarification is in order. I hope this post has not been interpreted by most readers as “my manager stinks.” If you’ve read my past writings you’ll know I’ve not only been a manager, but I have the utmost respect for anyone who manages developers; it’s a very difficult job (see The reason the post takes a “we vs. they” attitude is because that’s one of the big problems in our industry. I could have written a letter to “everyone who has something to do with developing software” and sort of rambled on about things that are wrong with our industry, but that’s like sending an email to 10 recipients and calling for action; no one will step up because they think the other guy is going to take care of it (psychologists call it “diffusion of responsibility”). I’ve chosen to focus on a single issue; the very real rift between managers and developers. And I’ve asked two well-defined parties to take action on fixing things from their end. If Agile does not address this as a real issue in their methodology then they are living in a dream world. In answer to your specific questions: What I’m doing to better the situation is bringing up issues on both sides of the table – this post doesn’t only ask for sacrifices from managers, it also asks them from developers. The bottom line message to developers: stop complaining and get the job done. Regarding what I am doing (or what are we as developers doing) to communicate to stakeholders or explain to marketing why the deadline will be missed: developers out there please correct me if I’m wrong, but every company I’ve ever worked at, with one exception, did not allow developers to speak directly with stakeholders or marketing. Most of the developers I know would like the chance to speak directly with these groups…perhaps that’s a better solution to the communication problem than the one I posed in the letter. And I’m all for the better solution. If you’ve read my blog you know I’m not just here to bang out code and whine…I’m genuinely trying to find ways to make things better for all parties involved. And I’m always looking for constructive ways to make this happen in our industry.

#8 http:// on 12.20.06 at 6:09 pm

Hey Rob, First of all, I apologize if I was a little edgy in my post. It was 2 a.m. and my Xbox 360 is now giving me the dreaded “3 Red Lights of Death”. Not happy about that 🙂 I like your response here, because I think it drives to the heart of what I was trying to say – the best solutions involve open communication amongst all stakeholders, including executives, developers, and everyone in-between. I’ve never worked in a company larger than my 100 person shop, so I’ve never had to be in the unfortunate situation of not having communication with the executive level. If you are stuck in that position as a manager, I’d say your primary job is to do as much as possible to bridge that gap. “Executive Support” is on top of the software critical success factors for a reason 😉 Our biggest problem has been encouraging developers to use the fact that execs are so close to them…most seem to assume they are not *allowed* to communicate. I always feel that just having a role called “manager” implies that developers have to succumb to that person’s will – and that’s where Agile methodologies can shine. It will always be the case that “two heads are better than one”, and the draconian decisions of a single manager will never be better than what the team could come up with together. The tough part is creating that situation where developers are no longer restrained by management but actually ARE mini-managers themselves. We’re finally accomplishing that here, but it takes time. I would suggest Alistair Cockburn’s book “Crystal Clear: A Human Powered Methodology for Small Teams” to anyone looking to break the vicegrip of top-down management. Even if you are on a larger team, the ideas that Cockburn presents in this book lay the foundation for empowering teams to reach their full potential.

#9 admin on 12.20.06 at 6:52 pm

Thanks for your input, Patrick. Your points are valid and it sounds like your company is on the right track trying to bridge the gap between developers and executives. One of the most common reasons I’ve seen for project failure is miscommunication between executives, managers, and developers. The more layers there are, the higher the chance for miscommunication. The value of a small company such as yours is that you are able to eliminate the layers between developers and executives. I have a firm belief that small teams are exponentially more productive than large teams, and I think the same goes for small companies vs. large ones. Also, excellent book recommendation. I plan to pick it up in the next few weeks.

#10 SKumar on 12.29.06 at 2:19 pm

Good one. Thanks for the comments.