14 September 2016, by Chris Harris
One of the many perks we get at Softwire is access to a Payroll Giving scheme, which makes it easier than ever to support your favourite charities. Signing up to a payroll giving scheme has the following benefits:
- The money comes out of your pay before you see it, which makes it tax-efficient and also psychologically easier to donate more and continue to donate for many years.
- It’s charities’ preferred method of receiving donations, as it reduces the admin overhead of e.g. reclaiming Gift Aid.
- It’s really easy to set up.
We recently took the time to publicise our payroll giving scheme more internally, and found a simple but effective way to reduce the barriers to entry still further: a number of my colleagues volunteered to go round to the desks of people interested in the scheme and take them through the sign-up process. And if it was after working hours, they would even bring a couple of beers along. This led to a doubling in uptake of the scheme, and we now have over 20% of our employees signed up, which we think is fantastic!
We are therefore proud to display our newly-earned “PGA Gold Award” and will be gunning for the Platinum Award next year.
If you were thinking of setting up payroll giving at your workplace, or joining your existing scheme, please do read the testimonials below for more inspiration, or feel free to contact us for practical help.
8 August 2016, by Chris Harris
On my volunteering day I went to Deptford Reach.
I was irrationally scared about doing this, simply because I had no idea what it would actually be like. Of course, it turned out to be fine. So I’m going to present an account of what happened, in the hope that it might make similar opportunities a bit less scary for anyone else with a similar fear of the unknown. I’ll then put some “lessons learned” at the end.
The timings were 8:30am – 2:30pm. The location was a day centre for homeless and vulnerable people, it serves hot breakfast and lunch, and gives out day-old Pret sandwiches for dinner; there’s also an IT room, an art room, and they have yoga and fun stuff like that throughout the week.
I got a very quick induction and was told I’d be in the kitchen. It’s a proper commercial kitchen and I got to wear whites and an apron and feel very professional. My fellow volunteer had been there for a month, and our boss was a trained chef from Zimbabwe called Renee. During breakfast time I chopped a load of mushrooms and was on toast duty for a brief while, during which I had my only interactions with the actual clients. They are charged a small fee for most breakfast items (e.g. 30p for a slice of bacon), but tea and toast is free, so lots of people were asking me for 4 slices of toast.
At about 11:30 it became clear there wouldn’t be any more kitchen work for me, so I made it known that I worked in IT and they asked if I wouldn’t mind working on their website. Apparently even though they get a lot of IT people volunteering, none of them want to do the website as they’d rather be in the kitchen or gardening or something. I actually found the mix of a morning in the kitchen and an afternoon on the computer quite nice. I spent 3 hours making some changes to a WordPress instance, including a bit of design (“add more colour”), a bit of bug fixing and a lot of adding new pages. See here for my handiwork!
I ended up leaving at about 3:15, later than my allotted hours but still a nice early finish. I’d been given some nice food, met some lovely people, had some new experiences and got to use my skills. Success.
Things I learned
I’m sure there are some more but here are the main things I learned:
- Places like this exist. I’d never really been aware of them before, so I know a bit more about the world than I did yesterday.
- I was reminded what it’s like to be completely new to something. I was glad to have an understanding boss, who delegated in a great way (started something off for me, watched me do it for a bit, and then let me get on with it). My goal was to not make a major blunder, so I spent a lot of time checking and confirming before doing anything irreversible.
- My IT skills, although horribly out of date, are good enough to make a difference to a small charity like this.
- My default tidiness standards are not good enough for a commercial kitchen…
1 August 2016, by Chris Harris
This summer Softwire launched an exciting new Employee Volunteering programme with the help of a great social enterprise called Benefacto.
At the heart of the programme is our offer to every employee of two free days this year that they can spend volunteering instead of working. I’m pleased to say that within the first two months of this scheme, 19 people (around 10% of the company) have taken us up on this offer, and have done some amazing things!
17 April 2015, by Chris Harris
Today I’m going to share with you my Risk Log Zero strategy – an attempt to do for my risk log (and risk management) what Inbox Zero did for my inbox (and self-management)
What are risk logs really for?
Risk management can be defined as the stuff that PMs never quite find the time to do. You’re haring around doing the things that obviously need doing on your project, and it’s easy to ignore the nagging voice in the back of your head that says “what if this happens?” Risk logs are intended to make this voice harder to ignore. A good risk log will ask you every week “what are you worried about?”, and will remind you about the risk at the point when you can do something about it. I claim that your risk log does neither of these things.
A bad risk log
Not a bad start – day 1 and I’ve identified 5 major risks on the project. However, the next Monday, I got a calendar pop-up telling me to update the risk log. So I looked at this table, and checked for the following:
- Can I close any of the risks? No
- Have any of these vague transition indicators definitely occurred (definitely enough that I can’t justify leaving it until next week)? No
- Do I need to perform any of the mitigation actions? …No
This isn’t a very useful exercise. There are some major issues:
- It’s easy not to take any actions, and just go back to the comfort of my more tangible (and very long) to-do list.
- If I’m worrying about all these, then I’m not worrying about them enough (or alternatively, I’m living in a perpetual state of worry).
- Most dangerously, because this exercise gives the illusion of risk management, and because I can see lots of pretty risks in my table, I don’t feel any imperative to think up any new, more relevant risks.
Risk Log Zero – the blank page
The principle behind Inbox Zero is that if your inbox is nearly empty, it means you’ve done something sensible with nearly all your emails, and you can now attend properly to the remaining ones. Applied to risk logs, my strategy has more emphasis on addressing risks immediately.
An empty risk log is a great reminder to ask the question “what’s worrying me about the project right now?” – much more incentive to fill it up, compared to the incentive to leave a full risk log as it is.
Actions and checks
Here’s the important bit – the part that enables you to stare at a blank page again next week and identify the newest risks. We are essentially going to ask ourselves this questions for each risk: “what do I need to do right now so that I can stop worrying about this?”.
It turns out that the things you need to do will generally fall into three categories:
- Something you can do right now
- Something you can ask someone else to do
- Something you should check on a certain date in the future.
Emptying your risk log again
All I need to do now, to get back to an empty risk log, is to:
- Add this risk log snapshot to my status email, so the customer / my boss knows what the major risks are.
- Add the actions to my to-do list (or delegate them to others).
- Delete the risk!
When I come back next Monday, I will need to very quickly check if any of the dates in the second table have passed, and answer the question if so. And then I can get on with staring at the blank first table and deciding what to worry about next.
What this doesn’t help you do
This is all very well, but remember it doesn’t help you do any of the following:
- Knowing what you should be worried about. But it does remind you to ask the question! And you should get into the habit of asking everyone else too. Your team, your boss, your customer – everyone.
- Knowing how to mitigate the risk. But I’ve found that if you publicise your risk log (again, to the team, your boss, your customer) then half the time they’ll sort it out for you anyway.
- Actually carrying out the actions. Although it might shame you into doing so – especially if you make it public!
Please do let me know how you get on with Risk Log Zero.
2 January 2015, by Chris Harris
We’ve set ourselves some goals for 2015 to try and make the world a better place. I’ve listed some below and I’ll let you know how we get on in a year’s time. If you have any other suggestions, please let us know – we’re always trying to improve our CSR efforts!
- We love what Tech City Stars are doing, and we got involved in their mock interview process in 2014. This year we want to help them to prepare their students for technical interviews too, so they can find more apprenticeships.
- We believe it’s important to make people aware of the opportunities available to them in the tech sector, so I have set us a goal of giving 200 young people a positive experience of the IT industry this year.
- Jamie has managed to get 28 of our developers signed up to be Code Club Pro trainers. His goal is for at least 13 of them to deliver a session in 2015.
- We’ll also be aiming to run a weekly code club session at a local school throughout the year.
- Now that we sponsor a village in Ghana (Bonkron) through Ashanti Development, we want to do loads for them, including providing beekeeping training and getting the internet installed.
- Our Charity Saturdays were a great success last year – this year we want to raise at least £25,000 through the scheme.
- Iain wants us to achieve the Payroll Giving Gold award. As part of this he hopes to persuade 10 employees to sign the Giving What We Can pledge.
Using our skills
- Alex has had some great experiences being on the board of trustees for various charities, and thereby providing them with invaluable technical advice, and wants to persuade at least one of his colleagues to do the same.
- We use open source software so much, we feel a duty to give something back. Tim wants 50% of our developers to have contributed to an open source project by this time next year.
- We’ve written a few small websites for charities – we’d like to make sure we do so again this year.
25 December 2014, by Chris Harris
Season’s Greetings from Softwire!
Wishing you a wonderful festive season and a Happy New Year!
13 October 2014, by Chris Harris
The following is an excerpt from Zoe Cunningham’s new book, “Galvanizing the Geeks – Tips for Managing Technical People”. You can buy the full book on her website, here.
They won’t go away
Every team and individual works to some kind of ‘to do’ list. It might be in their head, or written down in the form of stories, or stored elsewhere, but we all have one, and some sort of ordering will be applied to this list.
One very common means of ordering is in fact the very opposite of a good order for development tasks. If your subconscious is inclined to lead you along the easy path through life, then you will find that the more simple tasks will tend to drift to the top of the pile. This may result in you feeling very efficient – you’ll be burning through loads of tasks, and probably even getting ahead, which has to be good, right?
Wrong. The apparent gains you make by taking on the easy tasks first are in fact the opposite; they constitute a debt of hard tasks and risk that you’re building up for later in the project. Your burn-up chart will eventually tail off as you hit the harder, less-well-estimated and riskier tasks. And the later you uncover these problems, the fewer options you have for dealing with them.
The best tasks to do first are therefore the hardest ones – the ones that fill you with dread just from looking at them – the ones that you really do not have a clue how to approach – the ones that you hope might go away if you ignore them. They won’t.
They represent uncertainty
Hard tasks are essentially risks. If you don’t know how you’re going to do something, how do you know that it’s even possible? You certainly don’t know whether it can be done within the time allocated. If something is difficult, there’s a good chance that it will take a lot longer to solve that you’ve allowed for.
The other tasks that should be prioritised first are those that are in some way dependent on other parties. If you have developers who don’t like to interact with irrational, unhelpful and unreliable third parties (and let’s face it, who does?), they may be naturally inclined to leave such tasks until they have no choice but to do them. Of course, it’s the unreliable nature of third parties that means that you need to leave plenty of elapsed time (if not actual working time!) to deal with whatever inconsistencies and changes you might uncover, and to work around system outages, holidays and all the other blockers at their end. How many times have you been given a third-party interface definition and tested against the test site successfully, only to find that the live site doesn’t use quite the same format? How many times have you left your testing to the last minute only to find out that the test server is down? The weapon with which you can overcome these pitfalls is time. Make sure you have enough of it.
They might include delivery tasks
‘Release tasks’ deserve a special mention at this point. They’re easily overlooked, for all the reasons I’ve just mentioned. They can be very much ‘out of sight’ during the development phase of a project – they are simply not part of the tasks that you’re doing now; they are part of the next phase. What’s more, they often hinge upon many unknowns. You might not even know whose job it is to figure out the unknowns. If you’re going to have to deploy on to hardware that’s owned by another department or even a different company altogether, there are all kinds of potential hurdles that you’ll need to just identify before you can start planning for the rollout of your software. Some of these things you can do yourself, but some will need the involvement of the guys who run the hardware. Whilst development is still ongoing, dates, exact user characteristics and all kinds of other essential facts can be completely unknown. And this is exactly why you need to start planning this phase nice and early.
If your team is going about its tasks in the wrong order, it will manifest itself in late or rushed deliveries, last-minute changes and a general air of panic as you approach the end of a project. Don’t be tempted to leap in! Managing your team to help them achieve their objectives in such a situation must still be done in the same way: through empowerment and delegation rather than micromanagement. Insist that they try a new way, and let the results speak for themselves.
6 June 2014, by Chris Harris
Softwire’s fifth and final key responsibility is to “treat your time like gold dust”. In other words, we ask employees to “Manage your time carefully, maximise productivity, minimise overheads and aim to achieve five productive days per week.”
So are Softwire employees expected to never take breaks? Or never make mistakes? No, of course not. We can take as many breaks as we like, so long as we get all our work done, and we are expected to make many many mistakes, but we’re also expected to learn from those mistakes, in order to work towards becoming as efficient as possible at doing what we do.
It’s easy to let meetings drag on for longer than the need to. It’s easy to keep doing regular tasks long beyond the time they ceased to be useful. It’s easy to do the thing that sounds most fun rather than the thing that would be most useful. But when we’re charging our clients by the hour, and taking pride in providing great value for money, we can’t afford to do any of these things.
One of the main ways we avoid time-wasting is to keep our eyes on the prize, by setting ourselves specific, quantifiable and time-limited goals, that align well with the priorities of our colleagues and our clients. Another is to make sure we have a foolproof action tracking system that allows us to review and reprioritise regularly (many of us use Workflowy). Beyond that, we just let our natural engineers’ love of efficiency guide us down the best and most effective route.
6 May 2014, by Chris Harris
You can lead a horse to water, but you can’t make it drink. At Softwire, we’ve never tried to force training on anyone, as we consider it a very unproductive use of our time. If you’re not bought into training, then you probably won’t get that much out of it, and more importantly, if you don’t care about your personal development, why should anyone else?
In a similar vein, we try our best not to decide people’s career paths for them: we feel like we should get much better results by waiting for people to decide for themselves what they want to do and how quickly they want to get there.
However, there’s a real risk that this philosophy can be used as an excuse for not providing training, support and opportunities for career development. We do our absolute best to ensure that this isn’t the case, and I hope we’re succeeding. Here are some of the ways we provide this support:
Skill levels and mentors
Not everyone is going to follow the same career path in Softwire, but most people’s paths will look quite similar for the first few years (c.f. the Helsinki Bus Station Theory). For this reason it’s worth everyone knowing the kind of skills, both technical and “soft”, that are most useful to Softwire and have historically helped people to rise to more senior positions. So we’ve written them all down and, via our mentoring structure, helped people to understand which ones they’ve already learnt and which ones they still need to learn.
Linking these skill levels to our end-of-year bonuses is just good business sense for Softwire, but hopefully also provides the right level of “nudge” to individual developers to get thinking about them – while providing plenty of scope for people to learn other skills too.
Training tracks, Lunch&Learns, blog posts, conference passes…
It turns out it’s actually really easy to foster a culture of learning when you exclusively hire people who are enthusiastic about technology. People from all levels of Softwire have written training tracks, given lunch and learns, written countless technical blog posts, and found loads of amazing conferences to attend or talk at – including our very own annual SoftCon.
And when we asked people what our social calendar was missing, the answer was “more technical stuff!” – so we now run speed coding challenges, mind sports olympics and plenty of other geeky events. If you don’t learn anything from all that, you’re not trying hard enough!
30 April 2014, by Chris Harris
This is the third in a series looking in depth at the five “Key Responsibilities” that Softwire asks of its employees, as outlined in this post.
Who is responsible for the successful delivery of a project? In Softwire, the answer is quite illuminating.
Each project is assigned a Project Manager (PM), who is the most obviously responsible for its successful delivery (incorporating commercial success and customer satisfaction).
The PM’s manager is called the “Super Project Manager” (SPM). In Softwire we currently have 4 SPMs, each of whom manages a number of PMs. Here’s what our internal literature says about the SPM’s duties:
The SPM is fully responsible for ensuring that the PM delivers the project successfully by providing oversight and advice as required…
Note that the involvement of the SPM does not in any way diminish the PM’s responsibility to deliver the project successfully. The PM remains fully responsible for successful delivery. The SPM is also fully responsible for ensuring the PM succeeds. I.e. both roles are fully responsible!
A similar principle applies to the portion of a project assigned to each developer. So The developer is fully responsible for both the quality and timeliness of their delivery, but so is the PM and the SPM. And the QA is just as responsible for the quality of the output as the PM or the SPM. You may consider this to be logically inconsistent garbage – or worse, some kind of Orwellian brainwash along the lines of “War is Peace”. The flippant response is “You can never have too much responsibility!” However we need to prove that this overlapping responsibility is meaningful in practice.