On this page, I've tried to pull together some information about myself, so that I can send people to just one place to find out about me. I do a lot of stuff online and offline, so this may seem a bit messy. So be it - such is life!
Some things I do
I run a (relatively) successful startup blog, swombat.com. Before that, I blogged right here, on danieltenner.com, though it looked different, and on inter-sections.net. My articles have made regular featured appearances on Hacker Monthly, as well as being published or republished on TechCrunch, LifeHacker, SitePoint, OnStartups, and in a number of other places.
I'm also the tech cofounder of Woobius, a collaboration tool for architects, and Vocalix, a now-defunct startup whose goal was to help small businesses put voice on their websites. I am also an advisor of rLocums, which helps GPs find locum work.
I also speak and teach at a variety of events. I have done speed-mentoring at Ignite 100, Lean Startup and Business Model Canvas workshops at Business Bootcamp, guest lectures in Oxford, and of course lots of talks at events from HNLondon to Alpha Version.
What I care about
I believe that entrepreneurship is primarily a matter of drive, insight and skills. The first cannot be taught, but the second can be communicated and the third can be taught. Most startups fail in a boring way - by which I mean a way that could easily have been avoided with the benefit of experience which was available to people other than the founder who failed. While many writers or speakers focus on how to inspire entrepreneurs, I believe that our responsibility as experienced entrepreneurs is to convey valuable insights and teach valuable skills.
Despite this, most first-time founders will probably still fail. Starting a new business is a very steep learning curve. But I hope that with the right kind of assistance, they can get further, fail less often, and fail in less obvious ways.
Where I can be found
Almost everywhere! On twitter, facebook, app.net, github, linkedin, and many, many other places on the net. Feel free to tweet me on twitter or app.net, send me a mail to firstname.lastname@example.org, or otherwise ping me! I'll do my best to respond, though I can be slow at times...
I worked in Accenture for 4 years. For almost 2 of those years, my role was to be the QPI lead on my project. That stands for “Quality Process Improvement” lead. No, I’m not kidding you.
In that role, I was essentially meant to take the “best practices” from the Accenture methodology and ensure the project followed them. Yet even a relatively rigid company like Accenture understood that not all “best practices” applied to every project. Project managers were not told to take everything from the book and apply it to their projects. Instead, the very purpose of the QPI lead was to work with the project manager to figure out which of the Accenture methods were suited to the project at hand.
Circumstances vary, and with the circumstances, the “best practices” change. A competent project manager must be able to pick and choose the techniques that work best for his team, his project, his objectives, his budget, etc.
Even Accenture, with all its big-corporation mentality, had this figured out. And yet when I look at the world of start-ups and agile projects, I see a much more religious fervour. People seem to believe that the only way to apply an agile methodology properly is to apply the whole of it, without exception. When someone picks out the bits that might work for a specific project but doesn’t succeed, the blame that they receive is “you didn’t follow the whole methodology”.
The truth is, the methodology is rarely to blame for a failed project. Ultimately, blame rests with the people: the project manager, the product lead, the developers, and so on. Blaming anything else (from “the requirements gathering” to “the methodology” or “the programming language”) is just pointless blame-shifting. If your project failed, it’s most likely because of you failed to adapt to your project’s circumstances, rather than because you didn’t follow your methodology to the letter.
As a start-up project manager (and every start-up founder is a project manager, whether they know it or not) your job is to pick out the best practices for your start-up, apply those to help the project, and terminate, adapt or replace them when they’re no longer the best practices for your start-up’s stage.
Every start-up is different, and calls for a unique mix of techniques. Blind obedience just doesn’t cut it.