“Every problem has a gift for you in its hands.” ~ Richard Bach

If you’re in the business of technology please speak to me but, in the meantime, here are some recommended starting points:

The Fundamentals

Negotiation is important. Getting to Yes is a good book on the subject. I’m taking an online course that seems promising also.

As is presenting. Speak to Annette. When building presentation I’ve found Beyond Bullet Points a valuable reference (ignore “with PowerPoint” it’s the story building methodology that’s important).

Not to mention being able to sell. Solution Selling has taught me much.

This all builds on strategy. Good starting points are Strategy and Planning by Hussy and The Strategy Book by McKeown.

Which leads to a business model. I recommend Business Model Generation and its Business Model Canvas.

And Oblique Strategies of course.

You may need to simplify your life so try The Power of Less. Also Things and OmniFocus are great for staying focused.

If life is stressful (and if it is not) I recommend mindfulness meditation. Try Headspace.

Creating a technology stack

When it comes to where to host, if you have a sysadmin on hand then AWS (with Chef) can be a sound choice (pricing is an issue and AWS really is a Platform As a Service provider so you need to think reliability through from day 1). Otherwise look into Heroku for a PAYG, turnkey, option or EngineYard for a fully managed solution (I hear good things about Vorboss also).

After language, database is often the next most important choice. For most applications a relational database, such as MySQL or Postgres, is still a sound choice. Although MySQL has its detractors a lot of people run a lot of software on it. If you don’t need a relational database Redis is a fantastic key-store (on its own, or as an application cache), and then there are document databases. These can be a bit of a minefield and the right choice is very application specific so I can offer no general advice beyond read, read, read, and read again about their advantages and disadvantages.

Then there’s a host of other concerns such as search, payment, data processing, and virtualisation. But they’re beyond the scope of a general walk through like this.

Oh and don’t get talked into building your own CMS. This is a solved problem.

Choosing a language

Objective-C is pretty much the de-facto choice when building desktop software for OS X or iOS however if you’re interested in productivity look into using AppCode rather XCode. If you have Ruby experience on tap RubyMotion is niche but well worth a look.

For web development Ruby & Ruby on Rails have become a solid choice especially as Ruby performance has improved over the years. However Rails is not the lightweight framework it once was and good Ruby developers are still hard to find so you still need to step carefully.

For more experienced teams I recommend looking into Clojure and ClojureScript. In some ways Clojure is in a similar position to where Ruby was in 2005, as Rails was being born. A lot of smart developers are adopting it and finding it a great language to work with. However it has the advantage (as a mature Lisp dialect) of being better positioned as a language, with a great concurrency story, and superb performance via the JVM. The Clojure web ecosystem is evolving rapidly but Ring, lib-noir, and Compojure are still sound choices. For something more cutting edge look into Hoplon or Om.

If your team is Lisp averse look into Elixir which is a Ruby/Erlang hybrid and runs on the Erlang VM. Although I’m not keen on the language itself (although many great Ruby developers are adopting it) you can’t argue with Erlangs concurrency story. If you need concurrency over raw performance you could do worse than look into it.

I do not recommend using Javascript if you don’t have to. ClojureScript (a dialect of Clojure that compiles down to Javascript) offers greater language power, with few downsides.

While I am aware of Python (and Django), C#, and Go I don’t work with them but I understand them to be sound choices. I recommend against using Java, PHP, or Perl as there are comprehensively better alternatives.

Working together in teams

Make sure you own your own software. This is especially important for teams that are outsourcing any work. git has pretty much won the battle to become the version control system so use it, get your own Github account, and save yourselves a bunch of headaches.

Good communication is vital. Yammer is good, asynchronous, tool for teams to keep up to speed. For most uses it’s free. If your team involves remote working Campfire offers a simple web chat interface although Slack has the edge for me lately. Skype is go-to for voice and video. If you’re pairing or helping someone out Screenhero is all kinds of awesome.

Learn to coach. You’ve made an investment in people so help them achieve all that they can.

It’s best to have a process. As light as possible but no lighter. The key to all process is the release, scheduling work into releases and having a solid delivery date. Everything else flows from this. For simple task management (particularly repetitive tasks with little hierarchy and few dependencies) Trello is hard to beat. For development task management (or, heaven help us, “agile”) Pivotal Tracker and Wrike offer more functionality while remaining pretty simple to use.

When it comes to mocking up designs I’d recommend sharing a large sheet of paper. But if your UX guy is external then please skip Photoshop and either work directly in HTML or use something like Balsamiq. The advantage to working in HTML is that it’s so easy to tinker with a, more or less, working mockup. Using Bootstrap or Foundation means mockups look and feel real from day 1.