Posts Tagged ‘leadership’

Beyond Budgeting at LESS 2011

January 20th, 2012

One of the things that attracted my interest to LESS 2011 was the Beyond Budgeting track. Having read the book a couple of years ago, it is definitely a topic that catches my interest. And it was even better that the first keynote was presented by Bjarte Bogsnes, talking about how beyond budgeting is used at StatOil

As any presentation write-up, this is just my understanding about what was presented, so please don’t hold the presenter on to what I’m writing here :)

Why ?

The first question Bjarte addressed was why the need for something different. And I believe this sentence explains it all

January-December is artificial for business and just works for accounting. But this is not accounting

He followed by explaining that StatOil is always trying to get the best performance they can (who isn’t!), and coupling everything they do to an accounting mechanism (the budget) doesn’t make sense for them. He illustrated it with a comparison between the use of traffic lights and roundabouts. While the first is easier to use and provides more control, the latter actually provides better results because it relies more in the current situation than on statistical analysis.

We need to find more self regulating ways to manage a business, and beyond budgeting is one of them.

Bjarte used Douglas McGregor’s Theories X and Y to explain how we traditional management doesn’t usually trust people and relies on a stable environment to succeed, but in a dynamic environment in which most companies are inserted today, we need to start trusting our employees much more, and that is where beyond budgeting stands.

He had a nice example to show the lack of trust some companies impose, about a friend who is a SAS pilot, and even when he is trusted to fly planes full of people around, if he wants to change his shirt more often than it’s stated in the company’s policy, he needs a written authorization for it.

How does it work ?

According to Bjartes, the problem with budget is that it’s a single tool used for three separate purposes: Setting targets, creating forecats and allocating resources. Since these results are usually different from each other (targets are what we want, forecasts are what we expect to get), we won’t get an optimal result from using it.

In StatOil they have developed an alternative format of planning called Ambition to Action. These are a few principles that are used when cdefining it:

  • Good performance is being better than those we compare ourselves with
    • It could be external companies or even ourselves, which means we are learning.
  • Do the right thing
    • Every new joiner receives a StatOil book (a thin one!) with some of the principles that guide the company, so they can all use their business judgement and make decisions when needed.
  • Resources are made available and allocated on a case by case basis
    • Bjartes compared having an yearly budget to having a bank that opens for only a month throughout the year. How can anyone make timely decisions with that ?
  • Business is forward looking and action oriented
  • Performance measurement is holistic, and composed by 50% results and 50% behaviour

These principles are used to define what to do in the company, in a process that goes like this:

1. Strategic Objectives -> 2. KPI’s -> 3. Action & Forecast -> 4.Individual goals

So the company is going to set strategic objectives which are then converted in KPI’s. These are used to define the things that need to be done (Ambition to action), which reflect on how performance is measured for everyone in the company.

Some interesting thoughts he shared when explaining the process were:

  • The perfect KPI doesn’t exist, since not everything that counts can be counted.
  • StatOil creates around 1100 Ambition to action plans, and these are not a reporting tool, but more a guidance on how you as an employee should manage him/herself. Apart from that, everything is open, so everyone can see everyone’s else goals.
  • Performance measurement is usually based on teams and, as said before, divided between results and behaviour. Assuming that the environment very often changes, how someone behaved in that occasion is as important as the results he/she delivered.

The last point that was made during the presentation is how StatOil is moving from a calendar-driven model to a business-driven one. There are no more annual versions of Ambition to Action being created, and they can be changed at any time. The performance review is still happening annually, but Bjartes mentioned they are currently revisiting it now.

Overall it was a great introduction to Beyond Budgeting and how it is applied at StatOil. If you are interested, there is more information here and here.

Bjartes is speaking in the Thoughtworks Live Australia event. If you have a chance to go, don’t miss it.

What’s the Tech Lead Doing Anyway ?

August 11th, 2009

Some days ago when having a discussion at work about the responsibility of the tech lead in an agile team, I’ve realized that this is not a so simple subject as I thought it was. Therefore, good subject for a post : )

But before being dictatorial and just writing my opinion, I ran a small twitter poll asking about this subject. Fortunately, most of the answers matched what I think in some level, so hopefully I will be able to cover it all here.

Before starting, a last note. I was reminded that the term tech lead might not be so used and known as I think it is, so if you don’t use this term at all, sorry : ). You can replace tech lead for architect, technical manager, master jedi, whatever you feel like…

Giving an introduction, the tech lead (TL)  term is defined here as a person who has the technical overview over a specific project. Some people disagree about the need for a tech lead at all, but that’s the topic for another post, and here we will assume that the tech lead exists and is a single person. Ok, that was the easy part.

Now the more subtle (and polemic) part comes here, so I will give my opinion on it (with the help from @dtsato and @flessa).

What a tech lead should be doing:

Have a technical overview over the whole project – As a developer doing everyday work, it is easy to lose the long term perspective about where the project is going and make decisions that will be better in the short term, but harm the project in the long way. It’s the job of the TL to keep that in the mind of the development team.

Make sure the project has a common faceStandards are important IMO, and making sure the project still makes sense as a whole, avoiding knowledge silos it’s the job of the TL. He shouldn’t have to enforce standards or ways to develop code, but facilitate the discussion within the team.

Remove technical impediments – As the most experienced person in the project, its natural that sometimes the TL will be the person in the best position to remove technical blockages that the team might have.

Bring people to a good technical level – If the team has different levels of experience, the TL should work to help people achieve a good work quality by sharing his knowledge and incentive others to do the same.

Write code. Write a lot of code – The TL is not a superior being that gives directions from the top of a mountain. Don’t know about your opinion, but if I can’t rely on the TL to sit down and pair with me when I have a problem I can’t solve, it’s no good to me.

I think that is enough for now. Now, for what the tech lead should not be doing:

Be the person responsible for the code – Being the tech lead doesn’t mean being the owner of the code, or the team’s boss. It’s everyone’s job to create high quality software, and the TL should only expose problems to the team and lead them in the right direction (emphasis on lead, not mandate).

Making all the difficult decisions alone - During a project, the team will be exposed to different technical decisions that will have to be made. Allowing the TL to take them alone just expose the team to more risk, since they won’t understand/care about what was decided. What we want to achieve is that Paulo exemplified here.

Impose his opinion – This is probably the most important point. Remember collective code ownership ? It is still very important. No matter how brilliant a TL can be, if he can’t share his knowledge/decisions and specially the responsability with the rest of the team, things will go bad.