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.

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.

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:

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?

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:

Standard Agile Process

A few days ago a friend described to me how in their company they were introducing a new development process. To go with the flow they decided to introduce agile methodologies at the same time. To make sure that all worked on the same basis they are calling their new process “Standard Agile Process”.

I think that is a contradiction within itself. Either it is standard or it is agile but not both. Let me explain.

In my view at the very core of agile methodologies is the ability to adapt to the environment. Many factors can influence the decision including people, experience, customer base, technologies, product, target market, time zone differences. Since 1999 I haven’t found two teams who used the same agile approach not even within the same company.

Given sufficient autonomy and authority a team will adapt as well as they can. Is it reasonable to expect that any two teams (regardless of being in the same organization or not) start their journey at the same time, progress at the same speed, learn the same things at the same time, have the same set of experiences and end up making the same choices? Evolution is never the same if the factors influencing it are different or if the timeline is different.

It’s even more complicated - or easier depending on your viewpoint. One of the teams I’m working with is using multiple process all based on agile principles, no two are the same. Factors that have influenced their choices are type of work, product and customer. And each of the processes (at least three) is evolving at a different speed following a different set of changes. Changes are applied as the team identifies the need for them, if needed multiple times a day. Occasionally a process stays the same for a few weeks.

So when you see or hear the term “Standard Agile Process”: If you are impacted by it, keep the above in mind. Don’t switch off your brain. Think for yourself. Speak up.

Or just have a good laugh in particular if your leadership team allows you and your team to be truly agile. You may or may not believe in Darwinism. But history suggests that those who adapt faster and better not only have a better chance of survival. They also tend to have a better life, i.e. are more successful and have more fun.

Personality Tests

I just spoke to a friend who had applied a few weeks ago for a leadership role requiring experience with agile development methodologies. She submitted a resume and also spoke to the recruiter. In the next step she was then asked to do some online tests that would check for her personality and intelligence.

Based on the test results she was told that she was no longer considered included in the remaining candidates. The way I know her the results that she had delivered in her work have always been outstanding. Her experience with agile methodologies is fantastic.

After I heard this story I was wondering: If you want to fill a leadership role in software engineering which of the following criteria is a better indicator for a good fit:

1. Personality tests without even speaking to the candidate?
2. Concrete results over many years in various roles and various industries supported by data such as shipped product, improved quality, more features, shorter release cycles, increased customer base, lower development costs?

Of course, I am not an expert in personality tests, so I am probably completely ignorant of the value of such tests. In my own recruiting process I have never used personality tests other than talking to the candidate myself and having several of my team members talking to the candidate. This approach has always worked.