Saturday, May 04, 2013

What’s Your Culture?

In this post I want to talk about company culture. Every company has a culture. Some are outstanding, perhaps some are close to criminal, but I guess most are just mediocre.

How do you know where in this spectrum between star and rubbish your company’s culture is located?

I think a good way of telling is whether you were given the opportunity and the freedom to improve the way you work. Are you working on new projects that lead to a significant improvement of the processes you use and as a result significantly improved benefits for your customers?

Let’s look at a randomly made up example. A team is working on a product that is a combination of hardware, firmware, software and services. The product has not been introduced to the market yet. However you know that you need to finish the project by the end of the month. “Finish” does not mean that you have all features complete that you thought you must have. Instead it means a cross-functional effort between product management, hardware engineers, software developers, marketing, sales and probably a whole raft of others.

In that collaboration the team will understand that it may not be able to ship every single feature, but it will also understand the priority of each feature as each feature has a different business value to the company and to the customer. Let’s assume that in this given example a demo in the first week of the next month is highly likely to lead to receiving a significant order.

With the wrong culture the team would do it’s 8 to 5 job and then go home. No creativity would be invested and you may even see the occasional finger-pointing. Progress would be slow.

With a different culture the team would band together working towards that objective. A sense of excitement would be visible within the team. The team would collaborate, think beyond the boundaries of their “official” role (e.g. developer) and they would be very creative to find even simpler and faster solutions that would allow to stitch together a product that would be good enough for the purpose. They would throw in as many extra hours without the need to be asked or be instructed. The team would do whatever it takes to achieve the objective. They would know that they can make decisions and they would get the tools and the support to get the job done.

The leadership in both of these cases is quite different. It is very likely that the former breathes of micromanagement and bureaucracy. Maybe getting new hardware and software is close to impossible and always requires a lengthy process for ordering and procurement.

The leadership in the latter is most likely more hands-off. It’s management by exception or management by objective. If the team needs a new tool, hardware or software, the decision can be made within hours if not minutes rather than weeks or months. The leadership would embody trust towards the individuals in the team, willing to take the risk that things can go wrong when you push the envelope.

How do you know that you are in the right culture? First of all you need to decide for yourself what company culture you want to work in. Then ask yourself a few very simple questions that I believe are indicative of what the actual culture is in your company. Questions include:

  • Am I working on a project that challenges me, the team and the approach we take>
  • Is the project leading to improvements of the product, the processes you use, learning for yourself?
  • How do you interact with customers? Do you have direct interaction or do you have ‘men in the middle’?
  • How long does it take to get new tools like hardware or software? Is the duration measured in hours and days rather weeks or months? Do you see new tools arriving in your team on a regular basis, e.g. at least once per month?
  • What is the attrition rate in your team? Are people replaced immediately? How easy is it to replace people?

I’m sure there are plenty of other indications that help. The important thing is that you do not judge your leadership by what they say but by what they do. Once you know what culture you are looking for and what culture your present company has, it’s easy to come to the right conclusion. Perhaps you like it. Perhaps the time has come to move on.

What if there was a significant change in culture? My recommendation in that case would be: Don’t make any quick decisions. I that case hang in there for a few more weeks or months. Sometimes things don’t turn out as bad as they might appear initially. You can still make a different decision once the new culture becomes clearer to you.

Here is a link with yet another set of aspects regarding a company’s culture. It’s a post by Grant Cardone.

Saturday, April 06, 2013

Yammer Losing Posts…

I just entered a new post on an internal Yammer network. Writing the post took some time as it was one of the longer ones. When I tried to post it, Yammer told me that it (Yammer) had been update and needs to reload.

Result: The post was gone.

It appears as if Yammer is somewhat behind technologically. It should not lose content. GMail saves regularly and I have never lost an email that I hadn’t sent yet.

Recommendation: Use a text editor to create the post. Once you are good to go, reload Yammer, then copy the text into the browser window, and then post. This should avoid the duplicated effort of writing the post.

Sunday, February 03, 2013

Initial Business Model Canvas

Last week I wrote about “Eating Your Own Dog Food” as a mentor at an incubator. We have taken the next step and created an initial business model.

There are different options for creating and representing business models. At the eCentre we use business model canvases. This idea originates from an initiative that resulted in a book titled “Business Model Generation”. Alexander Osterwalder and Yves Pigneur wrote it with hundreds of contributors. Online tools are available from several places but a good source is the site for the book.

In the meantime some variations exist. As with other topics there are defenders of the “only truth” who believe that changing the original idea destroys it. To me that type discussion reminds me a little bit of the discussion which programming language is the best. I think it is important that a tool works for you. And if it doesn’t try something else.

In our case we decided to try out a variation called Lean Canvas. Some of the elements are changed over the one created by Osterwalder et al. I want to mention only the differences that are most interesting for our case: Problem, Existing Alternatives and Solution.

As recommended we created the initial canvas in just about 20 minutes. In the past week we then had a more detailed discussion about the canvas and refined a few items.

The basic idea is that everything that you put into the canvas is basically a hypothesis about some aspect of your business model. You then validate each of the hypothesis. The outcome can be either that a hypothesis is upheld or it is wrong. How do we find out?

Steve Blank suggests as part of the customer discovery activity: None of the facts you need exist within the building (see “Four Steps to the Epiphany”). You have to get out of the office and talk to people. Who would you talk to? Your canvas helps you as you will have identified target “Customer Segments”. That’s who you talk to.

So, in our case we have an initial business model canvas. Now we need to validate each hypothesis in it. We are prepared to revisit the canvas as often as needed based on the feedback we get. We have started to generate a list of people who we want to speak with. This will take a few weeks.

Books mentioned in this post:

Friday, February 01, 2013

Example of Expensive Software Project Gone Wrong

Novopay is a payroll system for school and school support staff in New Zealand. It’s development started in 2005, was planned to cost 30 million NZ dollar and take 2 years to develop. As of 01 February 2013 staff are owed an estimated 12 million NZ dollar due to errors in the software. As of writing it is still possible that it may be switched off.

While I can’t speak as an expert for this particular project, the newspaper articles reveal some interesting facts. For example the first emergency meeting apparently was conducted only after 5 years. Note this project was planned to take 2 years. The system was signed off based on the recommendations of four advisers, one of them PWC. Then it went life despite almost 6,000 payslip errors.

One actual result of the live system was a payslip sent to a caretaker who was awarded a 102 million dollar holiday pay packet. Unfortunately for him, he won’t be able to keep the overpayment.

The deputy education secretary reportedly said in April 2012 that “there was a need to run a total of 270 test scripts”. Frankly, I’m hoping that they had more than 270 test scripts and I hope they were all automated.

More details can be found in articles here and here. I’m mentioning this project here as quite obviously something went terribly wrong. Is there something that can we learn from this? Can we do better? Are we doing better?

Saturday, January 26, 2013

Eating Your Own Dog Food

I’m a mentor at the eCentre in Auckland, New Zealand. The eCentre is an incubator that follows the concepts of the “Lean Startup” as described by Eric Ries who in turn was a student of Steve Blank, author of “The Four Steps to the Epiphany”.

For this blog I am going to describe the journey of one of the startups. The intention is to demonstrate agile principles are at work.

The startup’s name is AgileCore. As of writing it doesn’t even have a proper web site, just the domain has been reserved. AgileCore’s idea is to provide technologies for cloud-based, scalable web applications that can be developed very quickly and then release many times each day.

Where does the idea come from? There were two independent events that coincided a couple of months ago.

One event was that while mentoring startups I discovered that their minimum viable product (MVP) – some call it a prototype – had certainly functionality that wasn’t core to their idea. Instead quite a few of those startups had similar requirements. Examples include sign-up, profile management, social network integration, support for mobile devices and similar more. At some point I started to assemble the same off-the-shelf technologies for some of them and I felt as if I was doing duplicating work instead of having something that they could share.

At around the same time a group of entrepreneurs had a discussion between themselves about how they would be building their first prototype (MVP). They found that they had certain requirements in common and came up with a list similar to the above.

So there was a problem and there was a solution, two important ingredients for a new business idea. As a consequence we started an initiative which we called AgileCore.

Of course we are at the very beginning of our journey and the path forward will be long and tough. It is possible that AgileCore joins all the other failed startups. That would be a success, too, as a failure is nothing else than the discovery of a path that didn’t work (see also Thomas A. Edison and is over thousand attempts to create a working light bulb).

On the other hand for AgileCore we intend to follow the principles we teach in our Sprint program. So we will be eating out own dog food if you like. And that is what I want to blog about once in a while.

Books that I mentioned in this post:

Hostgator promo code