Podcast: And Jeff ep 1 – Cause, Discipline and Self-Improvement


Kalle and Matte simply add Jeff to the mix with a glorious inaugural podcast where the guys each bring one topic for the group to discuss on air.

If you are not Kalle, Matte or Jeff and is still reading this, we’d appreciate any feedback you have on this experiment. Thank you!

1:10 Cause (Kalle’s topic)
(The Bret Victor talk: http://vimeo.com/36579366)

16:24 Discipline (Matte’s topic)

31:59 Self-Improvement (Jeff’s topic)

Our best akward silence: 19:58 – 20:14 (out of a couple of strong contenders)


Do I need my own desk? – Tieto Sweden HQ

Hi Kalle (and Jeff),

Time to talk some more about Do I need my own desk?, this time with real life examples from the company I work at! (Oooh, exciting!)

I had an example of a web agency I read about that had no set work stations for their employees and lockers for personal belongings.

Turns out that I didn’t need to go far to find this thinking in action – the Tieto Sweden HQ in Stockholm is using this concept live!

Here are two clips explaining the concept from Struktur, the company that helped Tieto with this. Yes, there is some marketing happytalk in there, but try looking past that. ūüôā

I will visit the HQ in September and will make sure to talk to some people about how this REALLY works in practice, will keep you posted. By the way, the Luleå office is not using this in any shape or form Рhere we are talking standard offices, fixed desks and sitting 2-3 in each room with standard telephone rooms and conference room. However, it would be interesting to find the lowest hanging fruit from activity-based workspaces, and try bringing that into the Luleå office as well.

House of Win-Win in Gothenburg seems like another example, care to fill in the details there Kalle?

This all feels very Peopleware, time to go back and reread that book methinks.

Miss you guys, take care!



Attempted poetry on user feedback


To Kalle and Jeff,

I just read a most excellent post from a poster whose posts are excellent most.

It spoke of why user testing comes hard, and why good user feedback is hard to come by.

If you get no feedback on bugs in your system, assume your system for feedback has bugs.

If you get feedback on a certain feature, certainly look at the feature but not to the feedback.

If you get feedback on smaller deal issues, you might have to with larger issues deal.

If you wish for user feedback on a wish application, apply yourself to get the feedback you wish to use.



No bosses, no juniors – working at Valve

Hi Kalle,

if you haven’t already, it’s now time for you to go and read what might be the most interesting publication in company and workplace culture this year:

The “leaked” Valve handbook for new employees.

There is just too much interesting stuff in here to discuss in one blog post so I’ll probably break this down to a few posts (or we discuss it on the podcast), but here are some highlights:

  • No management – people work on the projects where they feel they can be of most use and move their desks to form groups accordingly.
  • No juniors – only hire extremely competent and driven people at the height of their careers. No costly bringing up of juniors, they have enough attraction as an employer that they don’t need to “grow their own” – they can attract the best within the business.
  • Compensation based on peer review¬†– salaries are based on stack ranking by your co-workers. You make what the guy sitting next to you think you should make based on your contributions.
  • “T-shaped” employees – hire people with a broad range of skills that are also one of the best in their field within a narrow discipline (sounds a bit like The “Jack of all trades” department put into practice!).

Valve also lists what they think they could improve on (mentoring, predicting more than a few months away etc) which is very self-aware of them, could be interesting to discuss as well.

But what are you waiting for –¬†let me know when you read it, can’t wait to discuss it with you (and Jeff)!

And may all your TF2 hats be awesome,


Day 1 checklist – Make the new guy the hero

Hi Kalle,

since I just started at a new company and am in the first few weeks in the “getting-up-to-speed” phase where you go around feeling kinda useless and stupid, I have two good, solid tips for how to make sure to get your new employee a flying start.

So when you have to hire a guy three years from now to your gloriously successful start-up, whip out this post and make sure to:

1) Have everything ready for them.

Computer, chair, phone, keycard, whatever system access they need (especially to SVN/TFS/etc – for some reason version handling always gets forgotten by HR, I wonder why…).

Everything you need to do good work should be there ready to use at day 1 – no exceptions. If the hire has a choice of computer or phone, make sure to sort this during the time between the signing and the first day so everything is ready to go.

If you have this all sorted and stars align on that first day, you have a chance to…

2) Have the new guy/girl make an impact in the company on day 1.

First day at Lavasoft, I got to fix a bug for customer support that caused their support form to give the customer the impression that their ticket failed submitting, causing the customer to type in the same request over and over again in an increasingly agitated tone, producing a nice mess for the support department to deal with.

I wrote a single line of code, managed to publish the change and voila! – instant gratitude by the support department and saved money for the company on day 1. Couldn’t have asked for a better start.

This was by pure chance in my case but in future hires, I will try to make this part of the introduction plan – to have a task that needs doing that day that is important for the company, so they get to be the hero on the first day of work. I forgot this at my last company, so this is as much a reminder to you as it is to me.

Some ideas for suitable tasks might be:

  • Fix a bug that can be published the same day.
  • Improve the language of a particularly nastily written public webpage / wiki.
  • Answer customer questions on the company forum.
  • Fixing the resolution of the projector in the conference room so that it actually fits the canvas. (We might have this problem at work…)

Can you think of other useful tasks in the same spirit?

Take care,



Creating an API to a team – a system developer’s take at company communication

Hey Kalle!

Been a while since I posted here (we should really publish the podcast too btw, need to speak to Jeff about that).

As you know, I’m now working for a really big company (about 18000 employees) and as such I’m but a grain of sand on a large beach of company culture.

However, the part of the company I’m working for used to be a smaller company that was bought and incorporated into the bigger company in a single-brand strategy (i.e. the old company’s name is not used any more etc). It¬†is still a fairly self-contained branch with stable customer relations that was established before the merger and has the application management of a product that has been around since the early 90’s.

So our department is both a part of the rest of the organization, as well as our own ship, and this reflects in our methodology. In some parts we are running some SCRUM, we are looking at Kanban for some of our stuff and we also have a lot of waterfall in a lot of parts as well as some ITIL-inspired roles for application management. On top of this, we also have a delivery excellence process that is instituted by the company as a whole. In short, it’s all a bit of a mixed sallad (one that has both tomatoes and tuna as well as steak and kumquats – yummy!) with each bite tasting slightly different (not very agile-sashimi at all).

Here is our dilemma:

We need to work out a way of working that works for our independent unit given our customers, our products and our staff – while at the same time working together with the large organization we are also a part of in a way that they can understand and appreciate.

The good news is that I feel that it would be accepted to run any kind of methodology internally in our branch as long as it meshed well with the rest of the company and it yielded great results (i.e. we were efficient and very profitable), so it is a great situation for improving our process. However, the key here is how to work together with everyone else in the company in a manner that is efficient for them and for us.

So I thought:

Why not approach this as a system developer and picture our part of the company as a module in a large piece of software?

If we could just provide an API to the exterior world (the rest of the company and our customers) with metrics and ways of communication that is useful and efficient for them, we could pretty much run any kind of internal process as long as it was CPU-efficient (i.e. cost-effective).

This is obviously the opposite of transparency, and it would be interesting to hear your thoughts on the subject. Maybe transparency should be a topic for a future podcast, sometimes I feel that people just don’t want to know and too much transparency might just create confusion as to what they are looking at.

I’ll keep you posted on how this develops – I think my next step will be to map our “interface” in a way¬†similar¬†to how I would map the interface of a module and see if that yields any interesting results.

Thanks for reading all of this (I think I just scored 0/3 on my own scale…), let’s talk soon.

Take care,



Change for the sake of change

Dear Kalle,

this has long been a pet peeve of mine:

I hate when people (usually managers) want to change the look of the corporate website just to “keep it fresh”. Not better, not improved, just fresh. Without measuring, the best efforts can actually make the website worse than before.

On the other hand, there are arguments that change or attention in itself creates positive results:


This can be seen in almost any team implementing agile for the first time – regardless of how bad your early implementation is, the team will become entusiastic enough that it shows in the quality of work produced. However, when this effect dies out eventually as things becomes more settled, the true colors of the quality of your agile implementation will start to show.

Agile methodologies usually combat this effect by embracing constant change and refinement within the methodolgy itself.

However, it would be interesting to switch the entire methodology every three months or so between SCRUM, Kanban, Crystal etc, just to “keep things fresh” and keep the entusiasm going. Food for thought (might be more interesting than practical though).

Until then – keep it fresh,