By: Matthew French | 5 min read

Matthew works as a Senior Software Engineer at a popular late stage start-up and regularly creates content focused on creativity and learning at @mattsideabox.

Software engineers don’t work harder than any other profession.

They’re not more dedicated or determined, and often work less than people I’ve seen in other industries. However, what sets them apart is their exceptional project management skills.

Several tried-and-true software engineering practices have been trailed, refined, and adopted by major tech companies.

Giants like Meta and Google pump huge amounts of resources into researching and trialling ways of managing projects, and that trickles its way down to all other tech companies who want to learn from the best.

These techniques don’t apply to software engineering alone.

They hold relevance in other industries, projects, and even personal life management. Consider how you could introduce some of these to your work or daily life, and observe the impact.

1. Make work visible In project management. You can’t fix what you don’t see.

The hidden aspects of a project, the ones lurking in the shadows, are often the culprits behind missed deadlines, bottlenecks, and general dissatisfaction.

This manifests in many forms: an email never followed up on, a forgotten errand, a teammate silently getting pulled into unrelated work.

I’ve come across this problem countless times throughout my software engineering career.

As the go-to-guy for a feature, I’ll find myself bombarded with requests to tweak this, present to a client, or handle an “urgent” task.

Every “yes” I gave led to additional responsibilities and, more often than not, late nights.

Whenever this problem has come to light, we’ve discovered a recurring solution: “Make it visible”.

In the software engineering world, it often means utilising project boards (such as Trello, Asana or Notion) that lay out all our team’s tasks for a given period.

The team collectively decides tasks take priority, and anyone can advocate for moving lower priority items up the list.

2. Break Down Work

Imagine I asked you to bake me an apple pie. You’d have a rough idea of the task and how much time to allocate. But without knowing the recipe - the steps to put it together, you’d be lost.

The crust would turn out wrong, the filling would be a disaster, and you wouldn’t know when to start baking for when I arrived! (I’m assuming you’re not a prolific baker)

This might seem like a roundabout analogy, but it illustrates a point: having a recipe, a breakdown of steps, is essential when tackling big goals. When work goals are large and vague, things tend to go wrong.

Even if you manage to start, it’s hard to gauge progress when the only options are complete or incomplete.

However, when we break down massive goals into small manageable steps, the benefits abound. For managers and stakeholders, it offers transparency on a project’s progress, reassuring them it’s not stuck in a state of limbo.

Furthermore, breaking down tasks allows us to estimate how much time each piece will take, making it easier to gauge the overall project timeline.

In the world of software engineering, tackling large tasks head-on is a no-go.

Any substantial task is meticulously broken down into its component parts until it feels like a logical unit of work that can be accurately estimated.

In cases where no one in the team knows how to proceed, it becomes a “spike” - a task aimed at figuring out how to do another task.

It’s timeboxed (a set amount of time is allocated to the activity) and treated like any other piece of work. And by the way, all these broken down tasks that we’re talking about? They all find their place on the project board, ensuring clarity for everyone involved.

3. Test Frequently

Testing is a topic that can make even the most dedicated engineers groan, but its necessity is universally acknowledged.

For us, testing translates to writing more code to evaluate the code we’ve just written - it just seems like extra work!

"Once I've built this new feature and it works for me, can't I just ship it and move on?" It’s a tempting thought, but the truth is that testing plays a crucial role in product development across numerous areas.

Engineers write test code not only to verify that the feature they’ve built functions correctly but also to ensure its functionality through future changes made to the application.

Code reviews with peers are standard practice to maintain the quality of these modifications.

For substantial features, changes are introduced incrementally and tested alongside clients (which is valuable since clients often don’t know exactly what they want from the outset).

Product teams test hypotheses about user behaviours and preferences by running multiple versions of it and collecting data on what works best.

It’s a testing process that goes all the way down the line, and the insights gained at each point are incredibly valuable.

The principles of testing readily extend beyond the realm of software engineering and into other industries, as well as our personal lives.

If you find yourself endlessly researching, take real action and seek feedback. When confronted with a substantial task, break it down and test a small part of it.

If real-world testing isn’t feasible, consider creating mock-ups.

Whether you’re buying furniture for your home or establishing prices for a subscription service, the process of testing and the feedback it yields is immensely useful.

4. Be Retrospective

If hindsight is 20-20, why don’t we tap into it more often? As software engineers, it’s standard practice to gather as a team every few weeks and engage in the tradition of the “retrospective”. During these retrospectives, we typically pose three questions:

• “What went well”

• “What didn’t go well”

• “What should we try next”

This approach ensures that we not only learn from our mistakes but also holding ourselves accountable for positive change in the future.

Retrospectives extend beyond the regular fortnightly meetings.

We conduct retros (short for retrospective, referring to a brief meeting) for incidents in production systems, retros for completion of substantial projects, and essentially any task or project where there’s an opportunity to learn and improve for the future.

Other industries can adopt retrospectives as they are, as they prove to be incredibly useful ceremonies. Moreover, when concluding major events, projects, or life experiences, it’s beneficial to pause and reflect.

Dedicate meaningful time, ideally with a partner or team, to debrief and plan for the future.

In conclusion

The project management secrets of software engineers may not involve working harder, but they certainly deliver results.

These practices have a broader application beyond software engineering.

They can enhance project management in various fields and even improve how we navigate everyday life.

So, why not give them a try and see how they can make a positive difference in your work and personal endeavours.

What have you learnt from your industry that can be adopted by others? Comment below!