A common question you may hear from founders is.

“How do I make the developers go faster?“

In itself, it’s a reasonable one. We need to keep up with our competitors — thus need our team to move quickly. But it’s only the right question to ask if you actually DO want them to move faster.

Maybe roller-skates are the answer?

Measuring software development productivity often involves the following questions:

“Can we measure the number of lines of code being produced by Developers?”

I mean, we can… BUT do more lines of code mean one developer is ‘better’ than another?

“Can we produce features faster?”

Sure! But should we cut corners? Can we remove any of these important parts of delivering a feature?

  • Design Thinking Time — Before we start actually coding a feature, design thinking time allows us to consider what we’re trying to build. It ensures everyone involved has a shared understanding and consideration has been given to edge cases, failure modes etc. This time is a collaboration between the three amigos (QA, developers, and the product manager);
  • Functional Aspects — The core part of the feature: UI Screens, controllers, services, data access;
  • Quality Aspects — Unit/integration tests at the developer level. Acceptance testing (manual and automated) at a higher-level;
  • Operational Aspects —Putting good logging practises in place so we can debug in production: see when things go wrong, monitoring and alerting in-place, security scanning etc.

When churning out a faster solution what would happen if we skipped these parts of the process?

  • Skip Design — Just start coding and hope for the best. You can always change direction, right? Well, yes. But it can be costly to rework code, tests, and fill in the gaps. As they say, “measure twice, cut once”!
  • Skip Quality Aspects — Skip the developer testing? Do manual testing? Forget about automation? But automation helps with efficiency. Skipping it altogether means your customers are the ones finding bugs. And that doesn’t make them happy customers;
  • Just code the happy-path — Ignore the edge cases and failure-modes. Just focus on a point solution. For integrations, this is a no-no. You must ensure that you can handle what a third-party service chucks back at you, gracefully. You also have to make sure you surface errors that you cannot handle — reporting them back to the Engineering team and wider business to fix;
  • Ignoring monitoring and observability, performance testing, infrastructure provisioning, security etc. — Some of these simply improve our efficiency further down the line. Some result in major fines (data-breach for example if you don’t build in security into the process from development to operations).

Outages in production costs time. What you gain by skipping steps during design, implementation, operations, and testing, come back to bite you in production. That means a 2x, 4x increase in time spent to rectify the problem. You also have to go back through the build, test, integrate, release process which is even more costly.

Skipping these steps means we end up delivering a feature more quickly, but it really doesn’t look great in production. And if it annoys our customers, then it means damage to you as a business.

Ignoring the non-functional requirements in a solution means you end up with a non-functional product!

“Where can we save time? We’re a startup and need to move fast to test product/market fit, generate revenue and improve customer happiness.”

Let’s look at a number of hacks where we can talk about what affects productivity and potential amelioration of the problems:

  • Product Management Hacks;
  • Engineering Team Hacks;
  • Environment Hacks;
  • Individual Hacks;
  • Management/Executive Hacks.

Product Management Hacks

Sometimes, you don’t need to build anything at all. Or you can bisect a solution and just build half of the solution to speed things up.

Consider an off-the-shelf solution to cut corners instead of building something from scratch. I’ve built three businesses to date using just plain old WordPress coupled with some plugins. For learning management — use LearnDash. For commerce — use WooCommerce. It’s not glamorous or pretty, but it just plain works. It saves loads of time and helps you find product/market fit, cheaply. Marketing sites and blogs — I see way too many people build these from scratch when they could just Wix/Squarespace. Focus your time on the core solution required for the business instead! Build/integrate/buy should be your default standpoint.

Another way to go fast is to go manual, before you automate. There’s plenty of examples of this from the Product Management world in terms of prototyping and experiments that can be applied to the Product Development world. AWS mechanical turk is a great example of outsourcing jobs/processes whilst you build out the real solution behind the scenes. If you need to build administration tools to do things such as generate content, consider hand-edited JSON that’s delivered through a headless CMS or just flat-files. You don’t need to build a CMS in 99% of the cases!

Engineering Team Hacks

Setting your team up for success, building motivation, and helping them become efficient in their journey towards high performance is paramount. If the team focuses on sacrificing quality for velocity — they’re always in firefighting mode — they are going to burnout! It’s not pretty having your child wake up at random moments in the night requiring attention, constantly!

As a CTO, there is a common set of problems I see within startup teams that affect their overall productivity:

Taking on too much work in a time-boxed sprint means having to work crazy hours to deliver. This might be because you’re always estimating in a pessimistic manner and unable to meet the target you’re setting yourself . If so, practice estimation! It might be because you’re so swamped focusing on unplanned production issues that your entire sprint/workload is horribly hijacked.

Ignoring the capacity of the team – If you allocate your developers at eight hours of coding per day, I guarantee that’s going to end in missed sprint deadlines, burned-out team members, and demotivation. Developers don’t code for eight hours a day. Try five-and-a-half hours (around 70%) instead. It’s more realistic because you can account for other things that happen within a sprint — meetings, sickness, holiday, production issues, support rota etc.

Visualise and educate your stakeholders on different types of work. The Phoenix Project is a great read here for those who want a novel (yes, a novel) about software and operations. It illustrates several important concepts from LEAN, but it also describes four types of work:

  • Planned Projects — E.g. delivering features for the business to remain competitive, shift metrics
  • System Changes — Things that have to happen: server upgrades, certificate changes, planned downtime for various maintenance tasks. You need to think proactively about this and practice preventative maintenance.
  • IT Projects/Platform Projects — you can’t just deliver features and ignore the platform. You need a great observability platform for identifying changes and fixing things quickly (See MTTR later on). You need projects to address performance issues.
  • Unplanned Work — People forget about the unplanned work. That can often obliterate your sprint, your team’s motivation, and productivity. Your job is to eliminate — or greatly diminish — the unplanned work.

Where does unplanned work come from?

  • Pushing out crappy features without tests. Not thinking about them before coding, finding bugs in production, and then having to put in a fix;
  • Focusing on the happy path and ignoring failure modes and edge cases which causes bugs in production which you either have to fix. OR in some cases totally rework your integration or product feature because it wasn’t thought through. As I said before: measure twice, cut once. Technical design sessions should be required so that everybody understands that “engineering is not just about writing code“.

Continuous Improvement — teams focus too much on delivery and not enough on reflection of the past sprint or quarter. What went well? And what didn’t? If you can’t react and plan to address and improve on the things that didn’t go well, then you’ll never get better at your art. Retrospectives help here at the sprint and quarterly level.

Environment Hacks

One of the biggest killers for productivity is the environment. The space your team spend the majority of the day working in.

If you’re not productive in a specific environment, then change your environment. That can mean working at home on certain days rather than in the office. I’m a big believer in remote working if the team is set up correctly for it and the person has chosen that life. Hey, it can get lonely!

Commuting in cities such as London. You can often write off two hours of your day to commuting. That’s lost time. Unless you can work while travelling — not always possible on the tube! Multiply that by three days (a week) — that’s six hours that could be used more productively. Look at the busiest days for commuting and work at home on those days!

Collaboration and team dynamics come into play when it comes to motivation. Understand where you are as a team. Focusing on how best you work together effectively can be a game-changer. Clifton Strengths can help you identify what you have in the team today, what’s missing, and what improvements you can make. It may mean moving people between teams, or it might mean recruiting for someone with the missing skills for your team. Foster an environment of continual learning, safety (people shouldn’t be afraid to speak up), and non-violent communication.

Noise in the office is another killer. It’s all well and good to say buy a pair of noise-cancelling headphones — that really does help — but having a noisy Sales team next to an Engineering team can be problematic.

Interruptions kill flow and productivity. They might be from managers or co-workers — in which case, set a period of time throughout the day whereby people shouldn’t be interrupted. Try and keep meetings to the morning so people can focus on tasks in the afternoon.

Individual Hacks

Understanding yourself — your own weaknesses — is key to productivity.

What you’re good at and what you’re not good at. Focusing on improving your weaknesses — not just technically, but all round. For requirements, design, test, release, ops, learning to learn, and managing humans. As an Engineer, look past basic coding skills — focus on design and operations.

Sustainable pace. As I’ve got older I’ve realised you just can’t pull 10/12 hour days consistently. I’ve personally found that I can do two late nights in a week before it really starts to hit home. The third night of doing it has a massive impact. Forgetfulness, being grouchy, ignoring work friends/family relationships, tiredness. All of it takes a toll on your mental health eventually. There are visible and invisible aspects to this well. Recognise them and listen to them:

  • Trouble sleeping/Insomnia — either worrying about problems in work or solving problems in your sleep that you’ve left unresolved. Leave things in a good place before you leave (no broken tests, no difficult in-progress refactorings etc.);
  • Decision Fatigue at the end of the day — being unable to make a decision;
  • Physical and Emotional Exhaustion due to continual late nights, early mornings. Not taking a break;
  • Feeling unwell — just stop when it comes to this point. Don’t go into work, don’t work from home. Just stop and get better;
  • Anxiety — this might start off as mild tensions, not dealing with problems and talking about them with others — co-workers and managers — can contribute here. It affects your productivity, but even worse than that it can affect your personal life outside of work.

Management/Executive Hacks

As a Manager, as a C-level Exec, as a VC you have a duty of care and responsibility for those that you manage. Pushing and motivating your team to deliver is all well and good, but knowing where to draw the line is incredibly important. Don’t burn out your CTO, your Head of Engineering, your Tech Leads (and ultimately your entire team). Resentment builds. If they eventually leave due to burnout or illness, then it will get out. You will end up with a bad reputation as a company. People talk (Glassdoor and all).

There’s a great article here by CTO Craft founder Andy Skipper on how to prevent CTO burnout (this applies to any senior technology management member). As a CEO, it’s your responsibility to help spot when this is happening, intervene and call it. I understand you have a duty to protect the company and this is an integral part.

Failure to do this has a massive impact on that individual and on the team they manage — productivity included. Knowing your manager has had to take an “extended break” is not a great sign or precedent to set for others. I’m really interested to hear from others here about these sorts of situations, especially on the subject of emotional resilience. Managing a stakeholder takes its toll as well. It’s not just the work you’re doing as a person, but taking on other peoples problems, managing upwards on subjects such as productivity (see above), general technology, changing demands etc.

Final Thoughts

There are lots of things you can do to improve efficiency and productivity, but focusing on features delivered, lines of code written and always optimising for velocity is absolutely not the way to do it.

I’m a consulting CTO at HWIntegral. com. I’ve seen a lot of companies and helped fixed many of the challenges discussed above. Does it take its toll? Yes. Even more so when the expectation is to do it in half the time due to cost. You can have a very nice telephone/Zoom conversation with me about it, if you’d like.

One area of productivity we didn’t cover was “measurement” — what to include as metrics for your team That allows you to set a baseline for improvement. If you can describe where you are quantitatively then it’s easy for the team (and business) to relate to metrics. Another post will follow to discuss this in more detail.

Accelerate by Nicole Forsgren, Jez Humble and Gene Kim is a great read here and suggests four areas of focus for teams:

  • Lead Time — the time taken to go from code committed to production;
  • Deployment Frequency — how often you deploy;
  • Failed Deployments — how many times you rollback a deployment;
  • Mean Time To Recovery — if a production incident occurs then how long it takes you to recover.

More in another post, but in the meantime I recommend you go buy the book and read it 🙂

***

Jonathan Holloway is a member of the CTO Craft community and the original post ‘How to make developers go faster‘ was published on Medium.

Don’t forget about our forthcoming CTO Craft Con 2021: The Delivery One on 23 – 25 March where we’ll be hosting some incredible speakers. Find out more and get your tickets here!

If you or your CTO / technology lead would benefit from any of the services offered by the CTO Craft community, use the Contact Us button at the top or email us here and we’ll be in touch!

Subscribe to Tech Manager Weekly for a free weekly dose of tech culture, hiring, development, process and more.