Developers typically drive value creation in a tech startup.
When a business reaches hyper-scale, the pressure is on the tech team to be highly productive; after all, startups that score highly on the developer velocity index — a measure of efficiency — yield a 60% return to stakeholders and are more innovative.
And while hiring more devs seems like the easy option, tight resources, a fierce battle over Europe’s tech talent and missing the right tools can hold your team back from growing the team and reaching peak performance.
So, what it really comes down to is empowering your existing talent with the right team structure and tools. We spoke to experts from software delivery platform Harness, payments and buy now, pay later fintech Zilch and SME lending platform Trade Ledger about how they keep their devs motivated.
Sprinting ahead
But productivity is just one piece of the puzzle — and some startups choose not to measure it altogether.
“At Zilch, we’re on a mission to create the most empowering way to pay on the planet, and to do this we need talented developers that thrive on unique challenges. So, as a rule of thumb, we prefer not to measure developer productivity on the individual level,” Thomas Matecki, chief technology officer of Zilch, tells Sifted. “We find this can have a negative impact on the broader team and create a hostile culture. So as an engineering team, we alternatively use several well-proven techniques and metrics within individual teams to measure and improve the flow of work.”
One of those techniques is working in sprints, or set periods of time where the team tackles a dev problem or product build together. For Zilch, each lasts around two weeks. Sprints can be a key driver as a business reaches hyper-scale, as they keep product work organised and to a schedule — and aim to produce a complete piece of working software at the end.
Matecki adds that instead of measuring individual dev productivity within a sprint, they review each sprint’s velocity and burndown (or hours of work remaining in the sprint) “to ensure teams are maintaining or improving their output based on their historical performance”.
As a rule of thumb, we prefer not to measure developer productivity on the individual level
“This is not solely to measure performance, but to also identify if there are any issues or concerns which need to be remediated,” he says. “An example of this could be an uneven flow of sprints, which can indicate that teams have too few or too many items in the backlog.”
Sprints also allow for a level of transparency within teams, as “daily standup” meetings discussing work completed and the current day’s plans keep the sprint moving, and allow the team to address any issues.
Communication is key
Communication has always been a challenge for dev teams where work tends to be largely independent — and hyper-scaling companies that see teams rapidly expanding often cite communication breakdown as one of their biggest issues. And that’s not to mention the challenges of remote work.
“A key takeaway from the remote working of the pandemic was that agile development teams can quickly become isolated and frustrated in a 100% remote environment,” says Matecki.
Laura McFadden, senior software engineer at Harness, agrees: “Of course, because it’s 2022, how teams work together outside of an office is a challenge of its own.”
She says a combination of the right communication tools and meetings is “essential” for empowering remote developers.
Agile development teams can quickly become isolated and frustrated in a 100% remote environment
“A good communication tool — Slack, Teams, Zoom — anything that works for you and your team,” she says. “Once you have that figured out it’s the balancing act of how many meetings to have and whom to involve in them.”
Whether a daily standup or weekly all-team, meetings are key for keeping a team of devs working towards the same goal: “Personally, I’m a fan of a big whole team meeting to start with,” McFadden says. “Even if some of those in the room can’t contribute as much as others, it’s a learning experience for next time.”
But in-person communication can’t be replaced. Many businesses, like Zilch, have implemented a hybrid work model for their devs: “Some days are in the office and some are from home, and this is achieving the best of both worlds,” says Matecki. “Developers use the in-office days to sit alongside colleagues and discuss problems in a casual, ad-hoc manner as well as plan future work together. Remote days can provide that needed focus time and a calmer setting to work through those moments of complexity.“
Keeping the team together — apart
Team structure can be an underrated driver in productivity for any team — and for a hyperscaling company, the structure can quickly get lost as the dev team grows.
“Once we reached a certain threshold of around 15 engineers a new level of complexity was introduced. It has been a challenge to ensure a high velocity and grow the team at the same time,” says Matt Born, chief innovation officer and cofounder at Trade Ledger. The fintech, whose platform enables banks to lend to SMEs and mid-market corporates, says it reached hypergrowth last year and tried various team structures to enable scaling, and ensure speed of design and validation of features.
Moving the responsibilities to the team makes them feel needed and valued, and boosts their motivation, while they are in control of the project direction
What they settled on was organising the dev team into "pods" of two or three engineers that would work on building any given feature at a time — this avoided having too many cooks in the kitchen and allowed developers to individually assume greater responsibility.
While inter-team communication and collaboration are crucial to staying on track, Matecki also found handing individuals more independent responsibility led to better productivity, because having ownership over even one feature or component leads to more ownership over the end result.
“We’re keen to empower individuals and teams to let them run the projects,” he says. “Moving the responsibilities to the team makes them feel needed and valued, and boosts their motivation, while they are in control of the project direction. This is the best way to get things done well, and done fast — by leveraging the energy and enthusiasm of our teams with great skillsets and empowerment.”
The empowered dev’s toolbox
While communication tools are one part of the puzzle, having tools that can scale alongside your business is also key for productivity, as they ensure devs can spend more time on “tasks worthy of their talent,” says Harness senior director Dave Nielsen.
For example, continuous integration and continuous delivery (CI/CD) software like Harness let engineers and DevOps teams build, test, deploy and verify software on demand.
This is important because as a company scales priorities can change fast. CI/CD software helps workers understand the software engineering requirements and expected strain on the growing team, and automate as much as possible to keep up with demand.
Using Harness was a key driver in Trade Ledger’s hypergrowth; chief technology officer Matt Carpenter said the company’s most immediate need was to adapt and scale their deployment management software to their growing company size. They then switched over to Harness’s CI/CD product from a smaller service, which he says allowed them “get to new solutions at speed”.
Harness operates on the idea that speed of deployment is not the true barometer of success — changes, fixes and patches (or updates that address security vulnerabilities) are just as important. By applying artificial intelligence and machine learning to the post-deployment phase, automated deployment pipelines can deploy, verify and recover from any failures in minutes — saving hours of manual dev work.
“This allows for hundreds, if not thousands, of tests to be run at once,” Carpenter says.
Harness is also trying to create safer testing environments, which is better for end-users: “Your production environment is the best place to test, but also the riskiest if it’s not done correctly,” says Nielsen.
Targeting smaller demographics of your client base, for example, can help perfect features before they’re rolled out at scale. Harness’s software allows products to be tested on as few as 5% of customers, selected by location, in the way that LinkedIn or Meta do, to expedite feedback and improvement.
This allows for hundreds, if not thousands, of tests to be run at once
Ultimately, the right tools should free up dev time. As Carpenter tells Sifted: “More features mean that we need to take charge of how we test and deploy the platform at scale to focus on building a product that is of ever-increasing value to our customers.” This means more independence to work on innovative products that will propel the business forward.
Download the e-book “One Developer Experience” to explore best practices for developer productivity and developer experience when building and deploying software.
