Hi all,

Just wanted to refresh with everybody principles of Money Management from the book “One minute manager meets the monkey” by Kenneth H. Blanchard, William Oncken), Hal Burrows that we’re applying in our company combined with Scrum methodology for IT development.

So, crystal clear and simple, four principles:

1) who owns the monkey
2) what is the next step
3) secure risks (2 types here: recommend, then act; or act, then advise)
4) when is the next step due

That’s it and good luck with managing your monkeys!

While doing some browsing before bed last night, I came across an interesting article on Mashable.com called, “New Study Shows the Mobile Web Will Rule by 2015“.  While it’s clear from recent product launches (iPad anyone?) that the way people consume web based content is changing, what is truly astounding is the rate at which mainstream adoption of new technologies is happening. A few years ago, most people thought of the “mobile web” as looking up stock quotes or sports scores on your cell phone. Now, your device can be anything from a gaming console to a GPS in your vehicle that allows you to access the Internet.

Take a look at the article and the report for yourself here: http://hu.la/9I17lN

At Flatsourcing, our focus is still on creating robust, scalable web applications, but more and more we are engaging in work that crosses over to the mobile space as well. If you want to find out more about our capabilities and take advantage of our free test task offer, just give us a shout.

Hi everybody!

Just wanted to announce that we’ve released Rpm package for CentOS nginx+passanger for sliceconfig.

More Flatsourcing open-source stuff by our developers is in our github account http://github.com/fs.

Thanks,

Oleg

One thing we’ve been talking about lately within our organization is how to apologize.  We’re all huge fans of 37Signals, and when Rework came out two weeks ago, we all tore through the book.

One of the chapters that most resonated with me is titled “How to Say You’re Sorry.” A snippet from the essay.

Here’s another bad one: “We apologize for any inconvenience this may have caused.” Oh, please. Let’s break down why that’s bad:

“We apologize … “ If you spilled coffee on someone while riding the subway, would you say, “I apologize”? No, you’d say, “I’m so, so sorry!” Well, if your service is critical to your customers, an interruption to that service is like spilling hot coffee all over them. So use the appropriate tone and language to show that you understand the severity of what happened. Also, the person in charge should take personal responsibility. An “I” apology is a lot stronger than a “we” apology.
” … any inconvenience … “ If customers depend on your service and can’t get to it, it’s not merely an inconvenience. It’s a crisis. An inconvenience is a long line at the grocery store. This ain’t that.
” … this may have caused” The “may” here implies there might not be anything wrong at all. That’s a classic non-apology apology move. It slights the very real problem(s) that customers are experiencing. If this didn’t affect them, you don’t really need to say anything. If it did affect them, then there’s no need for “may” here. Stop wavering.

Now, we’ve been taking steps from top to bottom in our company to make sure everyone involved with a client understands the business impact of mistakes/bugs/issues/snafus when they happen.  Connecting with our clients when we apologize stems from understanding that the work we do for clients is not an exercise, its not a project, its a real and they are depending on us.  We always are striving for a deeper connection with our clients, and we know when things go wrong, its a BIG DEAL to them, and therefore its a BIG DEAL to us.  They count on us. Let’s say we’re sorry in a way that is honest, direct, accepting of responsibility and not defensive.  And most importantly, let’s fix it and learn from it.

Now, a ironic note.

When we started this discussion internally over Basecamp (a 37signals product), Oleg reminded me of error message when something goes wrong in Basecamp.  It’s actually a Ruby on Rails (the web framework which co-author of Rework, David Heinemeier Hansson created) error message, and I’ve attached a shot of it below.  Maybe he’s just really sick of seeing that message pop up in Basecamp.