Engineering With Empathy

In a bright and airy office building in the middle of Belfast’s city centre sits our small but mighty tech team. We're focused on web and software development, and are using innovative tools and approaches to create magical solutions for our partners. We’re on the cutting edge of what is possible and we’re always looking for new opportunities to solve business problems using state of the art technology and design. While we can utilise our technical expertise and experience to create complex solutions and products for our clients, our greatest strength lies in how we’ve built our internal processes, to foster innovation, collaboration and adaptability.

Our team is often faced with unique and complex technical challenges, and each time, we take them in our stride. But even with the best tools at our fingertips, we’re not magicians. Great software doesn’t happen by accident - it takes intention and teamwork. Which is why we’ve built a set of internal processes that don’t just support good work, they support good developers. Because in the world of ever-evolving technology, we have to have something stable to build upon. 

We follow Agile principles, but we’ve made them our own by adapting the process to fit our team’s strengths and needs. One such workflow is how we estimate and plan our work – it’s imperative that we really nail this part of our process so that we can accurately communicate timelines to our stakeholders and other internal teams. 

Instead of trying to predict how long it will take for us to complete a task, we estimate our work by level of effort. Why is that? Well – according to the Planning Fallacy – “We aren’t just bad at estimating task duration. We specifically and predictably underestimate how long a task will take to complete.” This is due to a number of factors, so instead we use effort, which taps into our team’s experience and instincts. But “effort” can mean a lot of different things to different people, so for our purposes, we distill level of effort into three distinct categories: 

Volume – How much work is there to be done?

Complexity – How tricky or complicated is the work?

Uncertainty – How many unknowns are there?

We use an abstract set of points to comparatively demonstrate the level of effort of our various tasks and then we track how many points we complete over time, to help us plan with confidence and manage expectations accordingly. Tasks with a level of effort of “1” are estimated to be less effort to complete than tasks with a higher point value, for example. This method has helped us more accurately estimate our work, which helps us avoid overextending our team and gives us a clearer picture of what lies ahead. 

The way we gather and agree on estimates for work is arguably more important than the estimate itself. As a team we discuss the task or chunk of work to be completed and then privately each team member makes an estimate based on level of effort. Then, all at once, we “show our cards” and reveal our thoughts. This system encourages each individual team member to really think about the solution or the set of steps required to complete the task. If everyone has a similar estimate, that’s great - we’re all on the same page. If we disagree and the estimates vary widely, it sparks a meaningful discussion. 

That’s the beauty of this process - one person may have spotted a particular complexity that no one else had experienced before. Or maybe someone researched a new tool recently that can reduce the volume of work required. It’s a low-pressure, high-value process that turns individual perspective into shared understanding. 

So what are we sitting around estimating will take all this effort to complete? Well, one thing we have worked into our process is that when we’re creating a product or tool, we try not to write “tasks” for our team to complete. Instead, we write “user stories” which are short, simple descriptions of what an end-user may want or need from the product we’re building. For example, “As an online shopper, I want to be able to see all the items in my cart before checking out, so that I can confirm I have everything I need and nothing I don’t.” 

A good user story helps our team dig into the why behind the product feature we’re trying to build. By avoiding being overly prescriptive of how the team should build the feature, it encourages us to think of comprehensive solutions that are strategic, effective and scalable. It’s sort of like a doctor diagnosing an illness - they’re trying to treat the root cause, not just the symptoms the patient is displaying. By fully understanding our client’s goals and their customers’ needs, we can design and build solutions that can scale and adapt as the product grows and changes long-term.

We don’t just rely on tools and processes - we rely on each other. We believe that building great work isn’t just about having the right tech stack, it’s about everything we build around that. That’s why our internal processes are designed to foster both dialogue and curiosity amongst our team. Because we know that just as great products evolve over time, so do teams. 

Nothing we’ve outlined here is revolutionary. It’s not a shiny new technology or tool that we’re selling. We're not chasing trends for the sake of being trendy. We're investing in infrastructure that supports both great engineering and great engineers through thoughtful planning, continuous collaboration, and shared purpose. In a world full of AI and machine learning, we’re choosing to embrace the human element of our team, and build proven processes and systems that lean on what we bring to the table that our technical counterparts cannot.

If anything you've read here piques your interest, we'd love to hear from you at hello@poppins.agency