25 Steps to Sustainable Freelancing

I didn’t sit down and plan my transition from permanent to freelance IT software developer, over 30 years ago, but I have successfully negotiated the freelance employment landscape in the UK, US, Europe and Australia since. Along the way I’ve developed some very useful techniques for anyone contemplating or currently enjoying a freelance career.

At first glance there appear to be significant financial advantages in moving from a permanent role to freelancing, but it’s not as simple as that. Freedom of choice (where, when and how to work) is not always possible and there are also challenges with staying current with technologies, techniques and the market. So how do you go about having a successful freelance career?

1) Make sure you have (and continue to have) marketable skills. This one may seem really obvious but there is no point in expecting to be continuously employed if you have skills that only a handful of organisations worldwide will want to utilise.
2) Invest in your skill set. I allocated a MINIMUM of 4 weeks EVERY year to my own professional training and development. This didn’t always take the form of expensive commercial training courses and with the technology available today it is even easier to achieve.
3) Develop an “Annual Goals” Plan (even better if you can make a 3 year plan). Only you know what goals you need to achieve, but you need to write them down and commit to them. I still set financial, academic, physical, social and philosophical goals every year – I don’t always achieve them all, but then some are more aspirational than practical.
4) Create an annual budget. I developed a spreadsheet (available upon request) that broke down each 12 month period into time allocated to working, training/development, holidaying/resting etc. to ensure that I achieved my annual goals.
5) Plan to work 200 days each year. For me, 200 is the magic number – it’s an easy multiplier and equates to 40 standard (5-day) weeks. This means my budget is built around 200 days of income and 365 days of expenditure! I allocate a percentage of each days’ income to a series of non-working day buckets (holidays, training/development, sickness and investment in the future). If I work more than 200 days I treat this as a financial bonus (by allocating the extra funds to wherever I need them most). I usually set aside around 40% of my daily rate for non day to day living expenses.
6) Be flexible when negotiating a contract. I never hold out for the ideal daily rate. If you create an annual budget you’ll know what your annual spend is so as long as you can service your basic requirements don’t play hardball for another $10 or $20 dollars a day. Remember, each day you’re not working is another you have to compensate by dipping into your non-working day bucket.
7) Plan your next contract as soon as practically possible. If there is a possibility to renew your current contract (assuming you want to) make sure it’s sorted at least 4 weeks before it’s due to expire. If there is no renewal in the pipeline I start checking the market about 8 weeks out from my contracted end date. This gives me the chance to have choices regarding my next contract.
8) Be prepared to travel. I regularly travel inter-state or sometimes overseas for work. If you aren’t prepared to be flexible regarding location then plan to be out of work more often. You don’t have to travel long distances but a 2-hour commute (each way) is sometimes necessary.
9) Be prepared to take on roles that aren’t necessarily your core business. I have traversed into many alternate roles. While initially being employed as a Test Manager I have morphed into Business Continuity Planning, Project & Program Management, Environment Management, Change & Release Management and many others. I have always enjoyed these excursions as they provide perspective and breadth to my main skill-set as a Test Manager / Consultant.
10) Don’t over-promise. There is a big difference between taking on a stretch role and being out of your depth. I have never taken on a role I wasn’t qualified to perform.
11) Don’t get involved in internal/company politics. It’s essential to know who the real decision makers are and those with real power, but don’t ever assume that you have a role to play in policy or strategic direction (unless that’s what you were hired to do!).
12) Build and maintain a professional network. The power of my professional network is more important today than at any time in my career. Every job that I have undertaken since 2001 has come from my professional network and not from me contacting recruitment companies.
13) Be comfortable with interviews. I have probably been interviewed more than 100 times in my career and I’ve have a success rate of around 90%. Not bad when that spans almost 40 years and includes interviews I attended “just for practice”.
14) Be resilient in the job market. Not every job opportunity will lead to a job so be prepared for rejection. I’m philosophical when it comes to job offers – if I am unsuccessful at interview I see that as a decision based upon cultural fit or technical misalignment. Given that I’ve also hired hundreds of people over my career, I know it’s not personal.
15) Don’t be desperate for work. Feeling and/or acting desperate comes across to those interviewing you. Be confident, open and honest about your capabilities. I’ve got jobs in the past even though I wasn’t necessarily the best qualified, but I did fit the culture or improve the team balance.
16) Arrive early or stay late (whichever suits your body clock). I have always been an early starter and therefore I like to be the first one in the office each day. I’m rarely the last to leave, but I always put in more time and effort than is necessary – it’s easy when you are passionate about the work you do!!
17) Learn to really listen and observe. Listening is an under-estimated skill. I have found that by listening to and observing what is really happening around me I can anticipate what is required. Be prepared to go above and beyond in terms of contributing to the goals of the project. I am far more of an observer and doer than a talker or shower.
18) Be yourself. Don’t ever try to be something you’re not, whether it be professionally or personally. You are good enough as you are and you don’t need to impress others.
19) Stay true to your ethics, morals and belief system. I never compromise my ethics, morals or beliefs either professionally or privately. I have refused to work for specific organisations or businesses because I disapprove of their ethics or business models.
20) Don’t worry, be happy. If you are unhappy, make changes or leave. Sometimes you can change a situation but be realistic when you can’t. There is no need to be a martyr, if a situation makes you unhappy, don’t tolerate it, just walk away. I have walked away from many situations that made me unhappy – it’s just not worth the aggro…
21) Only work with/for people you like. It took me many years, but I finally decided that I would only work for people I like. It’s usually pretty obvious during an interview whether you get on with those who are interviewing you. If you don’t gel with each other from the outset it’s unlikely that magic will happen!! I want to be happy at work and the people around me are the biggest obstacle to me achieving that.
22) Don’t be obsessed or a “slave” to the money. If your only reason for working freelance is the money, you’ll never be happy. Money is important, but it’s not everything. I would always take less money if it meant being happier in my surroundings.
23) Focus on your strengths but be very aware of your weaknesses. It is essential to work to your strengths, but always try and eliminate your weaknesses. Self-awareness is critical to being successful in the marketplace.
24) Take regular and relaxing holidays. It is essential to recharge your batteries regularly and not become jaded or stressed. I have always taken at least two holidays each year with at least one of them being overseas in order that I completely get away from my work.
25) Find a Mentor and/or Coach. I have been very fortunate over the years to have excellent Mentors and Coaches who have guided me throughout my career and have been there when I really needed them. I have also become a mentor and coach for others, it’s incredibly rewarding and fulfilling.

Dateline: Monday August 4, 2014

25 Secrets That Have Made Me a Better Tester

1) Diligence – I never give up. If I set out to do something I am 100% committed to it. There is NO second best
2) Passion – I have never wavered in my belief that software testing is a noble, worthwhile and honourable career. After more than 20 years as a professional tester I am still as passionate as if it were my first day
3) Humour – If I can’t enjoy my time at work then I shouldn’t be there. I was once asked to tone down the laughter in my team because if we were having that much fun we couldn’t possibly be working
4) Humility – I strive to be the best I can, but I’m very clear about my limitations and never promote my ideas as the best or only way. I have learnt from bitter experience to NEVER over-promise – if I can’t do something, I’m very explicit about why I’m not the best person for the job
5) Flexibility – I have always been willing to do ANY task I have been asked to do (within reason – I wouldn’t try to perform brain surgery!!). Being precious about (apparently) menial tasks is totally unacceptable if you want to be successful. I would never ask one on my team to do anything I wouldn’t do myself
6) Tolerance & Understanding – I believe that everyone is trying their hardest to achieve the best that they can. Yes, there are poor Managers, Analysts, Developers etc., but there are also poor Testers… I’m not immune from making mistakes either
7) Working Efficiently & Effectively – I have developed tools and techniques that help me solve problems quicker, achieve outcomes more effectively and meet deadlines
8) I am not an Island – Every action I take creates a reaction; awareness of my decisions on others has always been at the forefront of my consciousness
9) Logic – I have been blessed with the ability to think logically and to be able to distill things down to their basic concepts
10) Prevention before Cure – I have always believed that preventing a poor outcome is better than trying to fix something once it’s broken; effective Static Testing will save on Design and Build, while effective Dynamic Testing can only report on the quality and risk associated with a finished product. Prototyping and modelling are great tools.
11) Context is Everything – Unless I fully understand the context within which something has occurred I am unlikely to be able to provide objective and insightful feedback. I never assume, I always ask or clarify.
12) Understanding Others – Human beings are a diverse and complicated species and doing my best to understand everyone around me is an essential part of my daily routine
13) Understanding Me – Being aware of my strengths and (more importantly) my weaknesses has allowed me to grow beyond what I ever imagined. Of course I still have weaknesses, but I know how to compensate for them
14) Problem Solving – Any problem (no matter how minor) is a great opportunity to improve my ability to find weaknesses
15) Sensitivity – I’m totally aware of others needs and beliefs; we are all equal
16) Listening – Learning to really listen is as important as learning how to breathe
17) Preparing and Predicting – Unless I prepare thoroughly for a meeting or discussion I have no chance of achieving a predictable outcome
18) Playing Games – I have always loved playing games. They sharpen my mind and senses and provide a challenge. I still hate losing (something I’m very aware can be a weakness!!)
19) Learning – My education is ongoing, I (still) try to learn something new every day. I have also endeavoured to learn as much as possible about the organisations I work for and the people I work with
20) Seek out Experts – In my experience the really gifted people are very approachable and more than pleased to help. We all like to be asked our opinions….
21) Take Responsibility – I have always taken responsibility for my actions; if it’s to be, it’s up to me
22) Be a Team Player – I have played team sports for as long as I can remember and this has helped me understand the importance of sharing and depending on others around me. I am NOT the centre of the universe!!
23) Don’t Be Afraid – Be very clear about the worst possible scenario – what’s the worst that can happen? If I make a mistake I tell someone quickly and then focus on rectifying it ASAP; I NEVER got fired for admitting I made a mistake
24) Visualisation – I learn and think in a visual sense. If I’m trying to solve a problem or achieve an outcome I visualise exactly how I want that to look. Then I create an image of the outcome to share and discuss with others.
25) Be – Live in the moment. The past has gone, the future isn’t here yet. What I am doing right now is all that matters. Focussing on the now brings clarity and a sense of calm

Dateline: Melbourne; Monday December 2, 2013

20 Reasons Why I Became (& Still am) a Software Tester

1) (It was 1986 and) the company I was working for needed an independent view for assessing whether solutions were fit for purpose (this was the first time that I became aware that software testing existed as a separate discipline within IT)
2) I like to help people
3) People like to “bend” software to do things it was never designed to do; I’m far more realistic about the capabilities of software
4) I like to solve problems and puzzles
5) (After almost 20 years) Coding/Programming had become boring
6) Software is innately complex and someone (other than the Developer) needs to understand how and why it does stuff
7) I’m good at discerning/discovering patterns
8) I don’t like it when people say “Don’t worry, it’ll work when we Demo it to the Customer”
9) Humans over-estimate their capabilities and are far too optimistic when it comes to solving complex problems
10) I started to see Developers writing code straight onto a computer screen and this scared the shit out of me (as an ex-Developer)
11) Too many folks in IT think that they could solve any Business problem with a technology solution
12) I can translate “geek speak” into “non-geek speak”
13) I wanted to have a bigger say in how (and when) projects were implemented
14) I love it when someone says “That’s much better”
15) I was fed up with hunching over a computer all day and not dealing with the recipients/users of the solution; I wanted to talk to REAL PEOPLE
16) (In the late 80’s and early 90’s) IT solutions were becoming integrated on a far greater scale (this was when the www was still using single line text commands)
17) As a Developer, I was spending more and more time fixing other people’s code, I wanted us to get it right the first time
18) As system complexity increased and interfaces proliferated (both inside and outside organisations) more and more bugs appeared in software – some of us enjoyed going on bug hunts
19) I saw software testing as a progression from writing software
20) I’ve met and been inspired by some of the greatest (software testing) brains in the world; a very personal “thank you” to Dot Graham, Mark Fewster, Bill Hetzel, Martin Pol, James Whittaker, James Bach, Paul Gerrard, James Lyndsay, Ross Collard, Lee Copeland, Julie Gardiner, Mieke Gevers, Donna O’Neill and Shane Parkinson

25 Things I Don’t Like About Software Projects

The majority of projects that I’ve worked on over the years have been harder to deliver than they should have been. Mostly this has been down to either lack of experience within the Project Management Team (generally because of poor stakeholder management) and the unrealistic expectations of the client. These two factors are closely linked, but are by no means the only reasons for failure (or near failure). In fact, I’ve only worked on what I would consider a “failed project” on one occasion and that was when I was the Project Manager and I pulled the plug because the software company delivering the (packaged) solution lied to the client (and the rest of the project team) about the capability of their product. Basically, they sold the client vapour-ware and expected the client to pay for the development – we called them out and they huffed and puffed until even they admitted their original delivery dates were many months later than they had been promising.

So, why am I writing about things “I don’t like” when I’ve loved the cut and thrust of project life my entire career? Because I see far too much waste on projects. Waste of money. Waste of talent. Waste of time. Waste of oxygen… etc. etc. Sadly, this list could be far longer….

I don’t like: People who spin the progress of the project (spin is code for lying)
I don’t like: Egos running projects
I don’t like: Writing reports that no one will read, but the PMO insist must be written
I don’t like: Attending meetings that could be replaced by a Progress Report
I don’t like: Being told that the code is 99% complete (again)
I don’t like: Requirements that can’t be linked to a Deliverable
I don’t like: Software Releases that are not accompanied by Release Notes
I don’t like: People who email me when they sit right next to me
I don’t like: Software fixes that fix the symptom, but not the root cause
I don’t like: Project politics – more time is wasted on politics than any other single item (and it doesn’t even have a project code for me to charge my time to!)
I don’t like: lunchtime meetings – I need a break and lunchtime meetings give me indigestion
I don’t like: 9am triage meetings – they distract people from the real priorities of the day
I don’t like: Being controlled or manipulated
I don’t like: Broken promises
I don’t like: Project Managers who tell me someone in my team is upsetting the Development Team Leader (especially if I didn’t get to witness the fun)
I don’t like: Smart-asses who deflect issues and risks to other teams just before the weekly project review board sits
I don’t like: Unclear ownership of requirements and/or solutions
I don’t like: Being told that my team is having too much fun (especially when I’m not with them)
I don’t like: People who come to triage meetings unprepared
I don’t like: Being on the critical path for the project
I don’t like: Asking my team to work the weekend because someone doesn’t know how to manage a project plan
I don’t like: Schmoozing the client
I don’t like: Being given an end date, but still having to provide an estimate to prove that we can make that end date
I don’t like: Counting test cases
I don’t like: Not having enough Test environments to do my job properly

As always, please feel free to add to this list….

Dateline: Wednesday July 3, 2013

How to Manage a Happier Test Team – 25 Tips from an experienced Test Manager

Last week I provided a list of 25 mantras to help us all deal with some of the day to day frustrations we experience in our software testing worlds. It seems that this struck a chord with many more of you than I anticipated, so this week I’m going to focus on doing something about some of these frustrations. This week I’m providing 25 tips for Test Managers who want a more harmonious testing environment. As with my list last week, this was built from my own personal experiences and you may want to add to it either privately or via my Comments Section at the bottom of this Blog.

This is my list of 25 tips to help a Test Manager manage a happier Test team.

Learn the art of listening, your Testers are usually closer to the heartbeat of the project

Build smaller teams (or groups within teams), big teams lose focus more easily

Spend more time thinking, it makes the doing more effective

Anticipate issues – feel the mood of your team

Approve as many training and development requests as possible, encourage learning and diversification

Don’t reduce the severity of a bug just because you can, negotiation is always best

Speak face to face with your team every day – I call it “Management by Walking around”

Ask your Testers what is their greatest challenge each day – and then do something about it!!

Ensure everyone in the team is working for the team – heroes are dangerous

Trust (and empower) your team members – you hired them to do a job, so let them do it

Categorise meetings so that everyone knows why they are being held – there are always too many meetings

Always approve Annual Leave requests – people need holidays and project schedules always slip

Always keep ownership of the schedule, don’t allow others to dictate it

Have an open door policy – make sure you are always available to talk to any member of your team

Celebrate team achievements and don’t single out individuals – the annual review process will recognise individuals

Take responsibility for failure and share recognition of success

Build a positive culture, but don’t be in denial – shit happens…

Delegate responsibility – everyone needs to learn how to deal with it

Get each team member to score each day out of 10, it’ll help them with perspective and context (share your own score with them too)

Develop a buddy system – sharing a problem is always helpful

Make sure you can do every task your team is expected to do – empathy is always under-estimated

Don’t be afraid to ask for help, you don’t have to know how to do everything

Accept that not everyone wants to speak in front of the team, embrace introverts

Do something together as a team at least once a week (even if it’s only a coffee or tea break)

Laugh as much as possible – don’t worry, be happy 🙂

Finally, a message to all you Testers who have read my tips. Please don’t be too harsh on your Test Manager, if they don’t do all of these things (or any of them), believe that they are doing their best and remember that they are only human. We should all look to improve ourselves each and every day.

25 Mantras That Will Make You A Happier Tester

In my experience there are many challenges in the daily life of a Test team and this can lead to frustration and even stress. So, in order to make your day a little less traumatic, post this list of mantras above your desk (or create your own version) and I guarantee your day will pass more harmoniously.

I accept that some of the Requirements will not be perfect
I accept that the Developers have time constraints like everyone else
I accept that our Test Environments will not be ready on time
I accept that our deadlines will be changed
I accept that the Users will change their minds
I accept that there will be more bugs in the latest software release than I anticipated
I accept that the subject matter experts will not be available when I want to see them
I accept that the Triage meeting will take longer than I hoped
I accept that the Project Manager will not understand why my testing is taking so long
I accept that the fixes I was expecting today did not make the latest software release
I accept that none of the Users will know how to define Acceptance Criteria
I accept that the latest software build will arrive at 4pm instead of 8am
I accept that I will have to cull some of my test cases to meet the schedule
I accept that some of my bug reports will be rejected as “features” or “un-reproducible”
I accept that my Performance Testing will start late due to an unstable code base
I accept that someone outside the Test team will estimate my Testing window
I accept that the PMO will want to know how many Test Cases I will run today
I accept the concept of Groundhog Day – I have to enter my Day 1 tests for the fourth time this week!!
I accept that no matter how much planning and preparation I do, my first test will fail
I accept that my Test Data will be the previous version
I accept that there will not be enough time to check all the Batch Cycle results before the next online input day starts
I accept that I cannot re-create the Sev 1 bug in front of the Development Manager
I accept that I will be judged by how many bugs I find, not how many I prevent
I accept that the offshore team will misunderstand even the simplest instructions
I accept that I will also make mistakes – I must not be too harsh on myself…

Remember to breath and smile