My ways of working

1st Oct 2024

The glue that holds the gears together.

Every company has a unique way of going from ideation to production. I’d like to share with you my favourite approach.

Ideate

Good ideas can come from anyone. It’s important to treat every suggestion with appropriate consideration. Granted, most will be rejected because of practicality, timing, expense, or alignment with long-term goals; but there will still be lots of actionable suggestions. Occasionally, someone will think up something that can create enormous product value or fundamentally shift the way the business thinks.

I prefer an organic approach here, where people initially discuss ideas with those they are most comfortable with. If it gets a positive reaction, they should discuss it upwards in 1-1s or a skip level. It’s important for leaders to make it clear that they are receptive to new ideas.

Stream

All ideas that we wish to action get categorised into one of three streams of work:

• Projects (“On-Project” work)

  Spanning from a week to a few months, projects are scoped, planned, and prioritised. They have high visibility in the company and have upfront solution designs. Teams take time to do an official kickoff, and to celebrate (lunch/dinner etc.) when a project is completed.

  When a team starts a project, all team members focus solely on that project. It minimises context switching, time spent on progress reports, and the number of stakeholders. I know that it often feels more productive to be working on multiple bodies of work, but it is an illusion of productivity that I would recommend avoiding. With context focus, updates can become trivial, reducing the number and duration of meetings.

  Projects are estimated (realistically estimated, with a safety buffer, by the engineers!), and it’s important that most projects are finished by this date. This includes post-deployment aftercare.

• Bite-sized work (“Off-Project” work)

  Small blocks of work, usually less than one person-week. The overhead associated with regular prioritisation and estimation can quickly outweigh the time spent implementing it, so they are treated first-come-first-served in a Kanban style.

  These can be estimated, but don’t have deadlines. Work to plan the next project falls in this category - context switching is just as detrimental to senior managers and project leads as it is to software developers.

  This stream is often less stressful than project work, but also less exciting. It can be used to pay-back any late nights spent by employees to get projects completed on time.

• Bugs

  The way a company handles bugs is a yardstick for its culture. If tech teams are given sufficient time to create a quality product (and have the expertise to do so), then bugs should be minimal, making it feasible to respond to all bugs immediately. But if this is not the case, bugs should be treated similarly to bite-sized work. Even low impact bugs should be fixed or masked from error reporting so they do not conceal high impact bugs or create a culture of bugs being acceptable.

  If you have multiple teams, they can be working on different phases, so that there is always one team ready to tackle bugs quickly without disrupting projects.

Measure

Measuring impact is great for KPIs/OKRs and establishing whether the feature is actually achieving what you set out to do. The main reason I like this phase is a selfish one: I love seeing the impact of my team’s work; the joy in stakeholders’ faces, the servers studiously crunching numbers, product usage going up, and bug counts going down. That’s my primary motivation for becoming a software engineer: building products that people enjoy.