Tag: management

Team work and communications workshop

Just over a week ago, I spent a couple of days in Forest Park Hotel in Platres, as part of the Team work and communications workshop.  The company I work for – Easy Forex – organized it for about 20 people.  We had a good mix of people who work together on a daily basis, across several teams, from both Cyprus and Israel.  There were a few issues to sort out, a few things to improve, a bit to learn, and also some fun to have.

I’ve been to a few similar events before, but none of them even comes close to how useful and interesting this one was.  It wasn’t boring, it wasn’t “motivational” as in “look within to find yourself and your path to success”.  It was practical, to the point, and as much individual as it was team-oriented.  Two people who were hosting, organizing, and managing the event were Paris and Deano from Open Box Communication.  And I have to say that they really know what they are doing.  Most people went in skeptical, closed, and maybe even slightly aggressive.  The change in attitudes was obvious even a couple of hours in.  Two days later we left as rather different people altogether.  At least, the way I saw it.

Here is a little YouTube video they composed with a few highlights.  I know it’s probably irrelevant to most who weren’t there, but for me it will be a nice reminder to go back to once in a while.

[youtube=http://www.youtube.com/watch?v=gKfRtlYYpu0&feature=youtu.be]

If your team has any issues you should definitely consider these guys.  If you think you don’t have any issues, I strongly recommend to consider them anyway, as they will bring out a lot of things that you’ve probably never thought about.

Coding, Fast and Slow: Developers and the Psychology of Overconfidence

Coding, Fast and Slow: Developers and the Psychology of Overconfidence

This is an excellent take on why (we the) developers suck at time estimations.   Basically, it boils down to two reasons: unknown details of the project and overconfendence.

First off, there are, I believe, really two reasons why we’re so bad at making estimates. The first is the sort of irreducible one: writing software involves figuring out something in such incredibly precise detail that you can tell a computer how to do it. And the problem is that, hidden in the parts you don’t fully understand when you start, there are often these problems that will explode and just utterly screw you.

And this is genuinely irreducible. If you do “fully understand” something, you’ve got a library or existing piece of software that does that thing, and you’re not writing anything. Otherwise, there is uncertainty, and it will often blow up. And those blow ups can take anywhere from one day to one year to beyond the heat death of the universe to resolve.

Read the whole thing, it’s worth it.

Scaling Teams and the Fight Against Human Nature

Scaling Teams and the Fight Against Human Nature

Human nature dictates that we:

  • Form tribes to build identity and camraderie – yet in a scaling startup, this causes untenable, painful, progress-stopping inter-team rivalries.
  • Invent a common enemy upon which we can heap blame and against which we can fight – sadly, inside the tribes that naturally form, there’s often a tendency to create that common enemy internally (it could be marketing vs. engineering or testing vs. production or sales vs. execs, or any number of others).
  • Minimize the positives and focus on the negatives – that could be feedback from customers, internal critiques, manager reviews, product imperfections, or weaknesses in process. It’s so easy to forget that we somehow beat the formidable odds against building something that worked, something that attracted customers, something that scaled, and a company where hundreds of people really do want to work.
  • Resist change at all costs – yet in a scaling startup, change is the only constant, and processes, procedures, formats, teams, and everything else has to change to be successful.
  • Act emotionally, yet believe our decisions to be driven solely by logic – we tell ourselves we act rationally, but can easily prove that irrational biases rule our minds. This wouldn’t be nearly as dangerous if we could recognize these biases, but in another failing of human nature, we cannot – we cling to the notion that our decisions, unlike the rest of our species, are uniquely logical.
  • Lose empathy as our numbers grow – tragically, when we need empathy the most (as an organization gets bigger and there are more people to consider and more complexities between them), our nature is to rescind it. It’s easy to empathize with a small group you see everyday, but much harder to extend that empathy to everyone in a larger group (especially those you may not know well).
  • Create rules and process to prevent against repeats of singular abuses – the old adage of one bad apple ruining the whole bunch becomes more and more likely the larger a startup grows. Process can be wonderful, but sometimes we create a process just to ward against some bad behavior from a former employeee and, by doing so, ruin the company a little more for everyone. Use process to free and enable, not to punish and restrict.
  • Irrationally romanticize the past – “Remember how things used to be? It was so much better three years ago when I first started here and…” -everyone at any organization, ever. But I remember three years ago. It sucked compared to today. Our ability to delight customers paled in comparison. Our ability to attract talent was in the toilet. Fear about our budget and our bottom line was a daily occurrence. 2013 is superior in so many ways and I know it, but even still find myself fondly remembering (or, rather, misremembering) back in 2010 when (in my human-addled mind) it all seemed so much easier.

The notion that you’re trying to control the proce…

The notion that you’re trying to control the process and prevent error screws things up. We all know the saying “it’s better to ask for forgiveness than permission”. And everyone knows that, but I think there is a corollary: if everyone is trying to prevent error, it screws things up. It’s better to fix problems than to prevent them. And the natural tendency for managers is to try and prevent error and over plan things.

Ed Catmull