You're a loser. Get a job! (Part 1 of 3)

I am a loser, a good for nothing jobless scum.

Not really, but that’s how I sometimes felt when I was looking for a job.  Are you looking for work?  Are you good at it?  How long will it take for you to find a job?

I left a job I loved to join a small promising start-up.  It turned out much less promising than I hoped, and a month later I was out, looking for a new job.

Some of my friends had been looking for work, too.  I seemed headed for success, but my friends seemed like they didn't get it, they didn't know how to go about finding a new job.  They spent way too much time browsing jobs web sites like Monster instead of being invited into companies through their professional network.  

I landed my next job.  I think I know a few things that work.  I want to share what I know with you so you can get your next job, too.

Be prepared
There are three fundamentals to landing your next job.  First, be prepared.  In part one of this three part series, I’ll discuss what it takes to be ready to find a job before you need a job.  Next, finding a job is your job.  You have a job: finding your next job.  You're just not getting paid for it.  Finally, you're a wonderful person--don't change a thing!  I’ll cover the latter two topics in parts two and three.

Already have a job
They say luck is a combination of preparation and opportunity.  You can't control opportunity, but preparation is all yours.  The most important part of being prepared to find a job is to already have a job, and to use it as the springboard toward your next job.  

Looking for work is stressful, and running out of money more so.  If you already have a job, you won't view every job opportunity as the pot of gold that can't live without, and you'll perform better at your interviews without the added financial pressure to win the job or lose your home.  

Make sure you have adequate savings.  If you got fired tomorrow, how long would it take you to find another paying job?  A week, a month, three months?  Do you have enough savings to cover your expenses for that long?  If you already have a job, you can take your time and pick a company that has a business model with which you are comfortable, whether it is an investor funded venture with a fast burn rate or a more stable company with a sustainable business model.  Already having a job puts you in the driver's seat.

Build your reputation
People in your industry should know who you are.  Make yourself well known and credible in your field: write a blog, speak at conferences and industry events, and get published in magazines and conference proceedings.  It is surprisingly easy to submit a presentation proposal, get it accepted, and speak at a conference.  With just a little effort, you will stand out from the crowd of job seekers, and people will be eager to meet you and invite you in for interviews.  

Build and reinforce your professional network before you need to use it.  LinkedIn is a useful tool for managing your network, but the only thing that counts is face to face contact.  As part of building your network, don't be an asshole.  Be helpful--do selfless things for people that help them succeed.  

Exercise: Stop reading for a few minutes.  Write down three things that you can do to build your reputation.

Don’t suck
The third part of preparation is not sucking.  At your current job, kick ass!  Be valuable.  Help the company win.  Be highly competent in your role, in your field, and in your industry.  Read, read, and read some more.  Take classes.  Attend conferences and industry events.  Don't ever stop learning.

Coming up
Stay tuned for parts two and three of this three part series:
Part 1: Be prepared
Part 3: Don’t change


Eat at Pasha

Pasha is a great new Turkish restaurant in Arlington Center. Stop by for the warm decor, the relaxing atmosphere, and the rich food. Finish it off with a Turkish coffee. They are at 669 Massachusetts Avenue, Arlington, MA 02476.

Here is a scan of their menu. Call them at 781-648-5888, order a skewered chicken sandwich to go, and enjoy!

(It appears you don't have a PDF plugin for this browser. No biggie... you can click here to download the PDF file.)


Use Agile for mobile, and be awesome

Your dev team sucks.  Use Agile software development for mobile, and be awesome.
That was my pitch Saturday morning at MobileCampBoston3.  I led a session later that day, titled "Agile for Mobile."  I introduced Agile, explained some of its rationale, and identified some of the Agile frameworks.  I talked a lot about Scrum and a little about XP.  I had a blast, and I hope you did, too.  Here are my notes from the talk.

Why you need Agile
I contrasted traditional software development with Agile, and I offered reasons you should go Agile.  Some of the reasons are:
  • So you don't suck
  • So your group or company doesn't get shut down and you have to look for a new job
  • To build what your customers want, efficiently
  • To build what your customers really want, so they can change their mind and get something better quickly

I mentioned the Agile Manifesto, and I compared it to a businessy view of Agile.  The Agile Manifesto says fluffy things like, "Individuals and interactions over processes and tools."  Fluffy doesn't resonate with business people.  A businessy rationale for Agile is:
  • Customers get what they want, so
  • We make money faster, and
  • Our workers are happier, and
  • Our costs are lower, and
  • Our customers are happier, so
  • We get more repeat business

Which Agile framework should you use?
There are many flavors of Agile.  They all have the same overall goal, but they use different means to achieve it.  This chart from Mads Buus Westmark and Jesper Ronn-Jensen places a few of the Agile frameworks on a scale of prescriptiveness.  How many rules do you have to follow to be able to say you are using a particular framework?


Scrum will help you identify many impediments, some of which are business issues, and some of which deal with technical practices.  XP is a set of practices that address many of your technical problems.  Use XP in conjunction with Scrum.


How to be a great tech leader

Anyone can write code, but how do you effectively lead a team building an excellent software product?  To guide your team to greatness, you have to be a great technical leader.  A great tech leader does three things: know what to build, help the team build it, and help the team continuously improve.

Know what to build
Being a great leader is all about enabling a great team.  That starts with helping the team know what to build.  What does your customer want?  What does he really want?  Why?  Your team needs a deep understanding of your customer's needs.  They need more than a formal list of requirements--they need to understand the rationale and intent behind the requirements.  If your team doesn't know what to build, they simply can't build it, and your customers and managers will be disappointed.  If the team doesn't understand what to build, they will build something technically great, but that isn't what the customer wants.  They will hyperfocus on some requirement that's not important to the customer.  They will build something that is interesting to them, but not to the customer.  They will build exactly what is listed in the formal requirements document, and nothing else, missing the customer's target because they didn't understand the customer's goals.

Scrum and Agile make it easy to know what to build.  Instead of a big formal requirements document, use a product backlog.  Fill the backlog with user stories.  Each user story communicates both the What and the Why--what the customer wants, and the intent behind it, so even if the What statements are incomplete, the team understands the intent and can fill in the blanks.  Prioritize the backlog by your customer's business value.  Always honor your customer's prioritization; always build the most important stuff next, build the less important stuff later, and postpone the least important stuff, maybe forever.  Add good acceptance criteria to each story, so your customer can better articulate his desires, and so the team better understands what to build.  Estimate the complexity of each story as a team, so everyone understands the What and the Why, and so the team can preview upcoming stories and put some context around the current sprint's stories.  During the sprint planning meeting, decompose stories into tasks and estimate the effort for each task, so the team gets an even deeper understanding of the What and the Why.

Build it, and deliver
Now that the team knows what to build and why, they have to build it. More importantly, they have to deliver it--building it doesn't count if they can't deliver.  Software is intangible, and building it is an intellectual exercise.  But delivering it makes it a tangible, demonstrable thing: you either delivered it to your customer, or you didn't, and your customer either accepts the delivery, or he doesn't. Your customer doesn't care how hard you worked or what hurdles you encountered along the way--he just wants you to solve his problems. When you deliver something, your customer feels less anxious and less stressed--you have proven that you made progress, instead of just making a claim of progress.  For your team, build-and-deliver needs to be the norm, not the exception.  If you plan to deliver exactly one time at the end of a long project, without having had any practice at production deployment, then you are planning to fail.  So instead of building it and delivering once, your team needs to make delivery a regular activity, repeated every two weeks.

Scrum and Agile help here, as well.  Make sure your user stories are small enough that the team can get any story done within half a sprint.  At the sprint planning meeting, the team makes a commitment to itself, to you, and to your customer, to build and deliver some stuff.  When there is a problem that impedes getting the stuff done and delivered, the daily scrum and the sprint burndown chart alert you to the impediments early, so you can fix the problems early, before they torpedo the sprint.  Break the user stories down into small tasks, each no more than eight man-hours of effort, so you can gauge daily progress--if you started a story yesterday, but it's not done today, there's probably something wrong. Display your impediments on an impediments tracking board so you don't lose sight of them and so there's pressure on you and the team to remove them.  The sprint demo focuses the team on getting stuff done--when you demo i in front of an audience, the stuff better work! But don't just demonstrate what you got done--deliver it in production.  Focus the team on Really Really getting things Done Done: if it can't be deployed as a production service at the end of the sprint, then it's not Really Really Done Done.  Guide the team's definition of done to include "it was deployed in production." With the sprint rhythm, the team gets into the habit of delivering to the customer every two weeks.  Build-and-deliver becomes a normal behavior, not an exception.

So you built and delivered some stuff.  Did you meet your commitment?  Were you Really Really Done Done?  How much stuff did you get done?  Do your customers and managers expect more out of the team?  They are paying a lot of money, and they expect more stuff done, faster, at a higher quality level.  Can you do that?

Once again, Scrum and Agile make this easy.  Help your team know its velocity by estimating user stories in story points.  Use a product burndown chart, and gauge the team's likely, best, and worst velocity.  Inspire the team to increase its velocity, and help remove the impediments on their velocity.  Keep in mind that velocity is a vector--not just a magnitude, but also a direction--and that you can't just get more stuff done, you have to get more stuff done toward your customer's goal.  Keep using the daily scrum and the impediments board to achieve sprint commitments, and use the sprint retrospective to find and fix larger impediments.  Don't just react to the impediments you know today, because you're already too late; instead, anticipate upcoming impediments, and eliminate them before they slow down the team.  Do third party dependencies slow you down?  Crappy tools and hardware?  Lack of XP practices, such as continuous build or automated testing?  Help the team identify its problems, help the team get them out of its way, and they'll help your customer and management team kick ass.

So there you have it, the three fundamental abilities of a great leader: know what to build, help your team build it and deliver it, and help your team get better at it.  Scrum and Agile are the leader's toolkit to make it easy.

(Boston Celtics photo credit: http://www.lebasketbawl.com/why-will-the-celtics-win-it-all-next-june-this-team-has-depth/)


Related Posts with Thumbnails