Secret weapons

Dusty Candland | | strategy, team, process, communication, languages

Startups need secret weapons. Any advantage that a startup can leverage is important. My secret weapons might not be yours, but you'll have your own.

For software startups, the team, process, communication, and languages have the ability to accelerate the business and to be treated as secret weapons.


Hire smart capable people and let them do their thing. Let them make mistakes. Let them be responsible for their decisions. I'm not talking about smart in that they know all kinds of things. I'm talking about people that are humble, want to learn, and are problem solvers.

Set clear OKRs to align the team. People want, maybe need, to know what they're working toward. Besides it helps them make decisions and keep moving forward with whatever they're working on, on their own.

Fire people who bring the team down. Negativity is contagious and will effect the rest of the team. Probably quicker than you'd think.


I like the least amount of process that works for the team. Some teams require more, some less. The process is for the team, no one else.

I think there are a few key things that a process should address.

First, objectives. Objectives align the team and keep everyone moving the same direction. They should be clear and reviewed pretty often, at least monthly. I find even for my personal objectives I need to review them at least monthly.

Closely related are some type of scheduled check-ins. These check-ins should review how thing have gone and any changes that should be made going forward. Also a good point to review or update the objectives for the team.

Communication. Some way to keep everyone updated on what's being worked on, what's coming up next, and what's been done. This usually ends up being a backlog and a kanban board for me. I like wikis for the 'what's been done' aspect.

Lastly, automation. Or maybe better thought of as helping people choose the right thing by making that thing easier. Automated builds and deploys when the code passes it's tests and quality metrics for example.

I wrote more about my process here.


The specifics here don't matter too much as long as the team can communicate. I like to have group chat, a simple task tracker, a wiki, and a shared calendar.

A chat app like Slack or Keybase is really important. I like the integration Slack provides. But really the point is so that conversations can take place in a way that other people can catch up on them. I try to encourage using groups over one to one chats.

Some type of task manager. My default is Trello because it's simple and flexible allowing it match your process and not the other way around. I keep the backlog here and a view of what people are working on currently.

I haven't found something I like for a wiki or something for central documentation. This is for internal documentation about how things are setup. Both code and infrastructure wise.

With any amount of remote work, communication becomes more and more important. I like to work remotely and like to make that an easy option for anyone on the team.


I'm mostly talking about software development here and languages matter a lot. They allow things to be built quicker or better in some way.

Ruby & Ruby on Rails is the go to for a lot of startups. It has strong opinions on how things should be done. While I don't always agree with them, those opinions have allowed a huge ecosystem of code and developers emerge because once you know the opinions you build toward them and know how to jump into an existing codebase. Scale is usually the reason people shy away from RoR and in rare cases, it's warranted, but not often.

Clojure is less popular and requires a big shift in thinking about the code. It's less opinionated and can be harder to get started in. That said I feel you can create very reliable code quickly and with less of it. I was heavily influenced by Paul Grahams: Beating the Averages, as you see from the title of this post.

Most recently, Elixir is on my list. It combines a Ruby like Syntax with a lisp like feel on the Erlang VM. I don't yet have enough experience using it yet to really know it's strengths and weaknesses.

I think there is a lot of leverage to be gained by stepping out of the most popular/safe languages and making something less popular a secret weapon for your team.

What are your secret weapons?


These are webmentions via the IndieWeb and Mention this post from your site: