A day in the life of a Technical Account Manager

Basefarm is of course constantly on the look out for new talents to join our company, both technical and non-technical.
I’m personally working as a Technical Account Manager (TAM) for Linux customers in Sweden, and thought some of you might find it interesting to read about what it is we do. First of all, let me explain a little bit about what a TAM is.

The role

On our website, you can find the following information:

“As a systems consultant at Basefarm you will be responsible for application management on the Linux platforms for our customers. That means handling monitoring, maintenance, optimization and troubleshooting of applications and OS. The focus is often on the Java-based solutions. We work with open source products, including JBoss, Resin, Tomcat, and php applications sush as wordpress, joomla and drupal. As a systems consultant, you can become a Technical Account Manager for some of the largest and most complex internet sites in Sweden. This means very varied assignments and a fast pace. You will naturally have a close, regular contact with your customers and you are responsible for both further development and maintenance of your customers technology platforms. This requires proactivity and that you and your customers is at the forefront of technology. In your role as a Technical Account Manager you are a key for business success!”

That text, albeit very true, does in my personal opinion boil down to two specific things; that a TAM is someone who is very customer oriented and has a deep wish to constantly evolve and learn new things. These two traits are the key to your success as a TAM. Basically, your days will more than often revolve around these two, because you have a very deep level of cooperation with your customers, and often they will come with a new application or system that you might not have heard about in the past. In our field, personally having previous knowledge is most often not the most important thing, as there will always be applications that almost nobody has heard of. What’s important is that you are able to learn the new things being tossed at you!

The challenge

I work a lot with media companies, who are always on the bleeding edge when it comes to software and technology they use. The applications they want to run are vast, and constantly changing. What you learned today might not be used tomorrow. Due to this, it’s impossible to know everything beforehand. Nobody can know everything, but what’s important is being able to quickly learn as well as adapt to this new technology which they present to you. The same goes with setting up new customers, and this is also one of the tasks I enjoy the most as it offers such a diversity. No new customer is the same, which means there’s always something new to learn!

That said, we do have a very diverse and large team at Basefarm, and there will without doubt be a few people who has worked with the new application your customer has provided you with. This means what the knowledge you’ll need is always around the corner or at most a phone call away (if the knowledge resides in our Norwegian office), and everyone is always more than happy to take a moment to assist you. It is however important to keep in mind that it will be your task to quickly learn this new application, as you will be responsible over it in your customer’s environment.

Can’t be prepared for what’s going to come your way

Customer contact is, as I said, just as important. Each day, you will be speaking with different people at the customer’s which you are TAM for. These conversations can range from anything from presenting ideas on how to improve their current platform, having customer meetings, hosting workshops or discussing issues with developers. I find this very interesting, and also extremely important in order to keep the platform well managed for monitoring and similar tasks.

The job as a Technical Account Manager can be both very challenging and rewarding, mainly because your scope is so big. You will for example work with pre-sale customer meetings, designing customer platforms, be part of implementing that platform, and then also have the on-going responsibility of making sure that the technical platform works as great as it can be. You will also take part of on-going meetings with your customers regarding the technical platform and your suggestions for the future.

In the end, what I like most about the position is that you can’t always be prepared for what’s going to come your way. There are usually no guide lines for how to solve something beforehand, and you have a very close connection to the customer on a day to day basis. Being able to take on new platforms and applications that you have not worked with in the past is a big requirement, as this happens very often. If you feel this challange sounds fun and interesting, send us a mail at !

For more information about positions available in Sweden, please visit

Year 2011

Now it’s just some few days left of this year and if we look back, it’s really been an eventful year. Here are some highlights from 2011:

  • 2011 was the year of expansion

Today we are approximately 260 employees and we’re still recruiting. Want to work with us?

  • 2011 was the year of acquisitions

This year we acquired Webdeal in Norway and Bluedome in Holland. This will strengthen our position in Northern Europe and has increased our Basefarm family with almost 40 new employees (only the acquisitions included).

  • 2011 was the year of new products

We launched hybrid hosting to our service offering. Hybrid hosting makes it possible to combine a traditional operating platform with modern public cloud services. Learn more about our service hybrid hosting.

  • 2011 was the year of exploring new market segments

We’ve had a breakthrough in the bank and finance market in Norway and within public sector in Sweden.

  • 2011 was the year of investing for the future

We are building a new colocation center in Norway

  • 2011 was the year of certifications

Basefarm was the first hosting provider in Norway and Sweden to be PCI DSS certificated. In Holland we have also been certificated according to ISO 27001.

  • 2011 was the year of customer satisfaction

We’ve got several new customers in 2011. To mention some of them: Avito (Europe’s largest website), Schipol, Viasat and Kirkerådet (a council for the Norwegian Church). In addition, we have renewed confidence to several customers.

We look forward to a new exciting year in 2012. This year’s christmas present goes to unicef (see christmas card below). We want to thank all our friends for a great year in 2011 by wishing Merry christmas and happy new year!


Thoughts on interviewing technical candidates and running technical tests

(We’re hiring – Drop us a line if you’d like to come and try our technical test!)

We’ve been expanding quite a lot recently, which is a good thing of course, but also means that you often need to spend a fair amount of time doing recruitment and interviews. I find this side of the business extremely interesting, and it’s something I’ve always enjoyed being involved in throughout my career. There are many schools of thought surrounding this topic, but here are some points which I like to cover when I recruit technical people for support and operational roles.

I always try to do a technical test. This may sound like a given, but in my experience it’s not always the case. Technical tests mean different things to different people, but I like to do technical tests where candidates get the opportunity to demonstrate in a real situation that they know how to troubleshoot things. I’m only in the business of recruiting operational and support staff and I think that this is a very specific field but one that is hard to test people on specific skills for. Therefore I like to watch someone fix something that is broken. I have all my candidates for the role to do the same technical test as well, so that I can compare and contrast.

Normally I tend to do my interviews like this:

1. CV reading – if it’s more than 2 pages I get bored and you’re unlikely to get through. This is a huge topic all of its own, but I’ll just say this: listing out every programming language, tool, script engine and piece of software you have ever been in the same room as does not impress me.

2. first interview – 1 hour usually and can be done by phone if appropriate. Are you generally appropriate for the role?

3. second interview – technical test (see more below)

4. third interview – meet managers and other team members (this could actually be more than one meeting)

5. make an offer

I am extremely passionate about recruiting the right people first time, and there are really no short cuts in this process. You need to be prepared to invest the time up front or you’ll be paying it back for years with the wrong candidate on board. (I learnt this the painful way when having candidates imposed on me much earlier in my career in the early 90’s, and I resolved to do all I could to avoid this situation as soon as I reached a level of seniority where I was allowed to recruit for myself.)

There’s enough literature out there about the interviewing process as a whole, but here are some more thoughts on the technical test side of things.

I like my technical tests to follow this theme:

a) simple theory closed questions about the main technical topics – these questions should have fixed answers. I think of these as textbook questions. (which to me means that you can parrot learn them so I don’t actually hold the results in that high a regard) A typical example might be:

What does ACID mean in terms of RDBMS?

b) more complex open questions about techniques or principals involved in the job. This should give the candidate the opportunity to give a lengthy full answer demonstrating their full knowledge of the topic. For example I usually ask about 10 questions of the following nature:

A customer complains that their website is running slow. Explain how you would go about troubleshooting this problem.

c) a practical test  – sit the candidate down in front of a computer and get them to attempt to do something which replicates what their day to day job might be. This can be painful at first as you need to spend time on creating a reproducible scenario that you want repeated candidates to test on, but it tends to be time extremely well spent.

I was challenged this week by the thought of writing a new technical test for candidates to our windows team. The stuff I wrote is certainly not going to win any design awards as the web pages it’s based upon look like this




(don’t you wish all webpages were this clean Smile – all my web development looks like this by the way)



anyway I’m not interviewing for people writing HTML, CSS or equivalents, I’m looking for operational people who can sort out why when I click the above button my website doesn’t work (amongst many other things)

The roles we are looking to fill here currently require quite broad experience and you need be a “jack of all trades” within the windows world. At any time you might be asked to troubleshoot Windows OS, SQL Server, IIS, BizTalk or innumerable other components. We have deep specialists in all these areas of course who can help with the most serious escalated problems , but the TAM roles we are looking to fill at the moment are much broader and you often need a working knowledge of all the components your customers are running.

My point being that this was a slightly more difficult test to write than some I’d done before, as just how do you cover all of these areas? The answer is that you can’t really, so in the end I just tried to cover the basics and allow the candidate to prove that she knew her way around windows troubleshooting generally across some of the major components. I covered such topics as troubleshooting an IIS server which wouldn’t serve a page correctly in a .NET application, simple SQL Server administrative tasks, windows ACLs and so forth.

After all I’m looking for a candidate who displays the correct attitude to troubleshooting a problem, and who displays a logical and methodical approach to problems presented to them. Solving the actual problem within a short interview timescale is actually irrelevant (although obviously it doesn’t do any harm). The other good thing is that you get to watch people do the test and I find you can often infer a lot about someone’s overall approach to this situation, especially if get them to talk you through what they are thinking. It’s worth remembering that the test is a means to an end, and as such you could test someone on a completely separate piece of technology, just to see how they handle the troubleshooting process and being put on the spot as well.

So don’t be surprised if you come and interview for us and get given something to fix.