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 project management practices have been trialled, 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.
Make Work Visible In Project Management – You Can’t Fix What You Don’t See
Why Invisible Work Causes Problems
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.
How Software Teams Make Work Visible
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.
Takeaway For Non-Tech Roles
If work isn’t written down or visible to others, it’s easy for priorities to shift without anyone noticing. Making tasks visible creates accountability and protects your time.
Break Down Work Into Manageable Steps
Why Big, Vague Goals Go Wrong
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.
The Benefits Of Breaking Work Down
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.
How Software Engineers Handle Large Tasks
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.
Takeaway For Non-Tech Roles
Breaking work into smaller steps makes progress measurable and timelines clearer – especially when a task feels overwhelming or undefined.
Test Frequently And Seek Feedback
Why Testing Feels Uncomfortable (But Matters)
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.
Read: How To: Rubber Duck Debugging – A Problem-Solving Tool Beyond the Code
How Testing Works In Software Engineering
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.
Applying Testing Outside Of Tech
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.
Takeaway For Non-Tech Roles
Testing early reduces wasted effort. Feedback, even on small experiments, is often more valuable than weeks of planning in isolation.
Be Retrospective – What Went Well, What Didn’t, What Next
What A Retrospective Is
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”
Why Retrospectives Work
This approach ensures that we not only learn from our mistakes, but also hold 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.
Using Retrospectives Beyond Software
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.
Takeaway For Non-Tech Roles
Regular reflection turns experience into improvement. Retrospectives help teams avoid repeating mistakes and build better systems over time.
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!
Leave a Reply