net Magazine issue 286 – Exchange part one

For the November issue of net Magazine I was invited to contribute to the Exchange section, where each month four selected experts answer readers’ questions. As only three questions make it into the magazine I asked whether I’d be able to publish the answers that didn’t make the cut or were too long. This post is the first of two, in which I’ll be sharing my answers that weren’t in the mag. You can read post two here.

If you’re interested, you can find my three answered questions in printed form in the magazine. These were: “How do you remedy the isolation of working alone or in a small team?”, “Is it realistic to expect a healthy work/life balance when running a small business?”, and “How can a small team of coders compete in a large city’s industry?”.

Let’s get started!

Can you start an agency on a part-time basis or do you have to go full-time straight away?

Asked by Benjamin Christine

I’d say that this is entirely dependent on the situation of yourself and your co-founders, plus the level of resources and guaranteed work that you have access to. A team of five people, all with children and mortgages to pay, plus no projects lined up are probably going to need to be a bit more hesitant than two people with no dependents, money in the bank and guarantees of instant work.

It comes down to a personal decision with how happy you are to take on risk. As a lone person your considerations will likely be very different to if you want to hire staff – when they become your employees you have to factor their wellbeing into your risk levels. However, here I’d also question whether ‘agency’ is an all or nothing approach. Having premises, permanent staff members and fixed offerings can work really well, but it’s not the only way forward. If your projects are likely to have variable requirements around skill-sets, or if you need to balance different levels of work (perhaps whilst also creating products as well as offering services), a flexible collective of partners may work well.

On the other hand, if you go part-time or work as a collective, how do you balance this? How do you split work and pay? What happens if people have other commitments, leaving you in a hole? What are the tipping points that you’d need for you and your partners to all go full time? These are all important areas that you and your team would need to agree on, so in this respect all going full-time can be much more simple.

How do you balance tech debt with delivering the features?

Asked by James Dykes

When I was a developer agency-side, for a period we had regular time booked in to address error logs and technical debt. Most people hated it – everyone wants to be working on shiny new things rather than struggling with really tricky legacy issues – but it was one way of guaranteeing that you balance the new and the old. The danger there is if this time is seen as ‘lesser’ than new projects, especially those up against it, as it’s easy for the time to get chipped away to nothing. The main issue, if we’re being honest, is management rather than technical challenges.

I’m a fan of building with both the past and the future in mind. You need to build with the expectation that things will change, and that means to an extent, removing some of that technical debt as you go along. If you can turn a debt issue into delivering new features (refactoring that one horrible function whilst you’re extending it), then you’ve killed two birds with one stone… as long as this was factored into expectations. Having an awareness of the lifecycle of different project elements, and a view of what changes could be worthwhile in the near future is key here.

Where your technical debt is perhaps a little project in itself or can’t be chipped away at through newness, I’d recommend that this isn’t approached in a way that it can feel like a punishment to whoever works on it. Regular meetings can be held where suggestions to improve the codebase, products being used, processes, or even areas where people feel they need up-skilling can be voted on, and then these can be addressed in a positive way. The main thing, again, is management. If you de-prioritise making improvements, whether they’re code-related or limiting the happiness of your team because they’re still using ancient software, then sooner or later those new features you’re focused on delivering will start to grind to a halt.

How do you measure your development team’s success at a board level?

Asked by James Dykes

Most people look to traditional metrics to measure this – are projects getting delivered as expected, and how problematic are they? The development team is often seen as being successful if projects are running smoothly, to time and to budget. I’ve seen several organisations that give lots of visibility to the status of how many issues are being reported/open/closed, where projects are tracking etc, through the use of public dashboards on screens, but with data it’s important to consider the level of granularity that is needed by different audiences. Board-level members may need a summary of certain areas only, or may jump to conclusions that aren’t entirely accurate if information is perceived incorrectly without context.

Sharing this kind of information can work well in terms of raising awareness of general issues. If you’re always seeing a high number of bugs, are your developers short-staffed, over-worked, or do they need some training? Are the QA team reporting the right kind of issues? All of these questions can be asked. This brings me onto what, for me, is much more important to report at board level – how happy is our development team? Are we supporting them doing their best work? Focusing on the number of lines of code written or how many pull requests have been rejected is one aspect, but those can easily be impacted by issues such as general team happiness, whether their skills are stagnating, and a lack of diversity. These areas, for me, are a hugely important indicator of whether the team should be considered successful or not.

How do you know when to turn down a job?

Asked by Q

With the luxury of nearly 4 years working for myself under my belt, my thoughts of this are now very different to when I first started out, and it’ll likely be the same for everyone. When I first started out, I’d consider jobs that I probably shouldn’t have taken. The fear of being without work is a big obstacle to overcome, and it’s why I first started subcontracting in general roles that were offered to me rather than approaching people with a plan for how my specific skills could help them.

Saying yes to everything can lead to not doing your best because the fit wasn’t right in the first place. I’m thankfully now in a position where I have a lot more experience, a buffer behind me and I’m confident in the areas that I work with my clients, so every job I take on is something that I’m happy is a good fit. With that in mind, my advice on jobs would be to turn work down if:

• You don’t like or trust the people that you would be working with.
• You have no say in what you’re doing, when, and how.
• You’d find the work boring and soul-destroying, leaving you with little motivation to get it done.
• You don’t believe in it what your client’s doing.
• You don’t have the skills needed, and won’t do a good job. Stretching yourself to learn certain elements is one thing, and doing a job for this reason is a great way to grow your skills, but it’s another matter to take something that you know you just can’t do.
• The money isn’t what it should be.
• Hours are antisocial, or you’d have to travel in a way that would hurt your personal life.
• You don’t have enough time to do it.

However, sometimes there will be times when you’ll need to consider the combination. Perhaps you’re willing to spend a lot of time away from home if the money is really great. Maybe you don’t have enough time to do all of the work, but could bring in someone else to help. Or perhaps taking a particular project that you know you will find less interesting (but can still do a good job on) will give you the ability to later put more resources into a side project that you’re really passionate about. There are never any right or wrong answers, but I find that I do my best work when I’m surrounded by smart, passionate people who are willing and able to try new things, working on a subject matter that I am interested in, where I can make recommendations about how we should try to investigate and solve problems. I like projects that are both user-focused and technical, and involve a mix of technology, process, and helping people. Once you know what drives you, it’ll help you to be more confident in your decisions.