Viking laws for tech teams, part 3: find good battle comrades

This post is part of the "Viking laws for tech teams" series.

It boils down to this: you need to join the right company.

Many of you will disagree, I'm sure: "the daily job is more important", "there are good teams in bad companies", "yes, it's a shit company, but I'm still learning a lot of stuff", etc. All very valid points, but sooner or later, reality will catch up with you. And most of all, why settle for less? Maybe there are good teams in bad companies, but there's bound to be better teams in good companies :)

What is the "right" company anyway? Everyone will have their own, personal criteria. Discussing mine in detail would be of no interest. However, having worked for (and in some cases, survived) a number of very different companies, I'm convinced that there are some mandatory questions that need to be answered before making career changes. And yes, I failed to do it on a couple of occasions, sometimes stupidly bravely ignoring some obvious red lights. Bad idea, lesson learned :)

Researching a company that you'll join for many years sounds like a necessary precaution. However, the interview process is not the place to ask tricky (and possibly nasty) questions: if you think it will make you look clever,  you're mistaken, it's actually quite likely to ruin your chances. You must do your own homework.  Most people don't: fresh meat for the grinder.

I realize that it may be difficult to know what rug to look under, especially if you have little work experience. Hopefully, my battle-tested checklist will help you out.

• Company
• How old is the company?
• Is the company the market leader? a challenger? a startup?
• Who is the competition? Smaller or bigger is not the point, maybe THEY are the right company you should join (true story).
• Does the company have any revenue (don't laugh)? If not, how long before cash runs out?
• Is it company profitable? What's the trend?
• If the company is public, read the latest annual report. You will learn A LOT, believe me. If you don't understand financials at all, find a friend who does and ask him/her to run through the numbers. If you do understand financials, would you buy this company's stock? No? Then why the hell would you join them? You are your most precious asset!
• Where are the headquarters and will you be working there? In other words, will you be close to the decision center or not?
• last but not least, is technology really the core business of the company? Or is it just a tool? The old IT vs R&D debate...

• Founders (unless you're interviewing with Boeing or General Electric...)
• Who are they?
• What's their background (technical or business)? 
• What's their track record prior to starting the company?
• What's their reputation? Ask around, the world is VERY small and bad news spread faster than good ones.
• Are still involved in the company?
• Are they still driving the company (which is a different thing)?
• Did you meet them during the interview process? 

• Governance
• Who are the shareholders: individuals? Family? VC? another company?
• CEO/CMO/CFO/Managing Directors: background, track record, reputation, etc. You might not interact with them on a daily basis, but their strategy will either drive the company through the roof or into the ground. If the company is assigning weak profiles to critical positions, what does this tell you?
• Top technical job (CTO or equivalent): dig even deeper :) This guy would be your boss. Does he have street cred or is he just a MBA graduate with fancy Powerpoint skills?
• Hiring policy: how strict is it? Does anybody get in? Hopefully not (as discussed in a previous post).

I could go on, but this should get you started. Gathering all this information is actually pretty easy: corporate website, LinkedIn, financial & industry websites, blogs and of course your own personal contacts. There's just no excuse for not doing it, except if you're not really motivated (which kind of solves the problem, doesn't it?).

Once that you have all information, assign your own weight to each item and take a long, hard look. How does this company compare to the other ones you've looked at? What are its strengths and weaknesses? How will they impact your job? If there's any red light, what's the compelling reason to ignore it?

Most important of all, trust your instinct and don't try to rationalize: if it stinks, then it's probably shit. Pass and keep looking.

Still, there is no silver bullet. Maybe you'll miss something, maybe things will change dramatically in a few months, but running your own due diligence will help you decide on facts, not on hear-say or hype. And you might avoid an awful work experience.

It's your life. Spend it well.

Please share your comments or anecdotes. See you next time.

Viking laws for tech teams, part 2: keep yourself in shape

This post is part of the "Viking laws for tech teams" series.

Skills, attitude, stamina: the iron triangle of survival in challenging environments.

No skills? You're dead weight, no one will ever want you on their team. Rusty or outdated skills? If you're lucky, you may get a job maintaining legacy systems… until they're shut down or outsourced. Bottom line: if you think you were done learning when you left school, think again. You should never stop learning: blogs, books, personal projects, conferences, anything goes. Don't let your edge grow dull, keep it razor sharp.

Example: 40-year old embedded software engineer who decides in 2001 that he doesn't like object-oriented languages and that he will keep writing assembly and C language for the rest of his life. Fast forward 5 years: ALL projects now include embedded Java applications, which junior engineers can write and debug with their eyes closed (for half the salary). Game over. The guy barely saves his ass by accepting Quality & Documentation tasks: not what he had in mind, but still useful and way better than being out of a job at 45 with two kids.

Poor attitude? You might fool the team for a while, but you'll end up being thrown overboard. You need to truly believe in what you're doing and give it your best shot. It has to be more than "just a job". No, this isn't about lapping up corporate bullshit ("work hard, have fun", you know what I mean). It's about standing your ground, soldiering on, delivering the goods, being someone that your buddies can count on in good and bad times alike. Ask yourself: when the time comes to leave, will I be able to look proudly at what I've helped build over the years? Two years later, will I be remembered as the tough-as-nails engineer who got shit done, no matter what? Will my code still run in production? Yes? Job done then, with plenty of good memories and war stories to share. Nothing else matters.

Example: that last guy who joined, left after 6 months and that no one remotely remembers. Which is the way it should be.

No stamina? You might be the sharpest, nicest guy around but you won't last. It's not about long hours, nights or weekends (yes, they're sometimes needed). It's about enduring the daily insanity of fast-paced projects: 180-degree turns, showstopping bugs 2 days before the release, supplier issues, customer whims, management stupidity… The list is endless. If you blow a fuse at every roadblock, you're bound to waste energy, grow tired and lose motivation, so whatever you need to do to vent off, do it regularly. Also, never ever lose your sense of humor: unless your code runs in nuclear plants, airplanes or hospital life-support systems,  it can't be THAT bad, so stop being a miserable bastard and just try to laugh it off (even if it's damn hard sometimes). Remember: it's not a sprint, it's a marathon, a 40-year long marathon. You won't make it without nerves of steel and a healthy dose of self-derision.

Example: the burnt-out, negative, cynical guy in your team who used to be a super achiever and a great guy. Do him a favor and let him go.

Bottom line: it all starts or ends with you. Take care of yourself, but keep pushing your own envelope. Don't pretend, do it for real: the more you sweat in training, the less you bleed in combat.

Please share your comments or anecdotes. See you next time.

Viking laws for tech teams

Viking laws... An oxymoron to most people, I'm sure. That's not surprising given that the Men from the North have long been depicted as drunken primitive barbarians, only interested in pillaging and looting (what's wrong with that anyway?). After all, History is written by the victors, in this case Christian victors who probably had no fascination for paganism and polytheism. Most of what we really know about the Vikings comes from the famous Sagas, which were only written at the very end of their civilization (12th-14th centuries).

According to these Sagas, Vikings *were* civilized and organized. Actually, the oldest parliament in the world is the Icelandic parliament founded in 930AD in Þingvellir: a stunning location with cliffs and waterfalls, straight out of Wagner's Ring (do not miss it if you ever visit Iceland). Free men met there regularly to solve disputes and take decisions according to law, which was memorized and recited by the "law speaker". And for the next three hundred years, "one man, one vote" was the rule.

Some of these laws, or at least their underlying principles, have been documented around 1250 in the "King's Mirror", an ancient Norwegian text meant for the education of the King's son on commerce, military tactics, etc. A modern, business-oriented summary of these principles appeared some years ago in a book called "The Viking's Guide to Good Business" (ISBN-10: 997985622X). It's a nice, short read and you should be able to grab a copy for $0.99 :)

Another set of Viking laws is floating around, although I can't seem to pinpoint their origin:

BE BRAVE AND AGGRESSIVE 

• Be direct 
• Seize all opportunities 
• Use varying methods of attack 
• Be versatile and agile 
• Attack one target at a time 
• Do not plan everything in detail 

BE PREPARED 

• Keep your weapons in good condition 
• Keep yourself in shape
• Find good battle comrades 
• Agree on important points 
• Choose one chief 

BE A GOOD MERCHANT 

• Find out what the market needs 
• Do not make promises you cannot keep 
• Do not demand over-payment 
• Arrange things so that you can return 

KEEP THE CAMP IN ORDER 

• Keep things tidy and organised 
• Arrange enjoyable activities which strengthen the group 
• Make sure everybody does useful work 
• Consult all members of the group for advice

And so, in my next posts, I will indeed go medieval on you and discuss how this wisdom from the past may apply to today's agile, high-performing tech warriors. I might even use some real-life examples (PH34R!), although names will be changed to protect the stupid and incompetent.

Oh, I'm afraid none it of will be remotely PMP, Prince or ITIL compliant. It will be fun, then :)