When you work in an organisation that has a multi-tiered hierarchy and you’re not the top boss, then you have a person or people above you. Obviously!
What’s also probably blatantly obvious is that when you work for someone, the one thing they value most of all from you is the ability for you to figure out solutions to problems. They want you to do the tasks assigned without creating or escalating problems that they need to solve.
Problems arising in the OSS industry
If you can solve problems, yours and possibly even theirs, then it makes them look good and takes pressure off them. Every boss or leader wants their direct reports to be problem solvers.
When you work in the OSS industry, there are a lot of problems to solve:
- If you’re implementing or integrating OSSs, then there’s a constant stream of challenges to make the solution fit the needs of the client. There are process challenges that need to be worked out such as how to overcome bottlenecks in OSS workflows. There are technology challenges that need to be worked out such as how to integrate applications together. There are people's challenges that need to be worked out such as how to gain consensus on a sticking point that is preventing an approval and holding up progress. There are financial challenges. There are schedule challenges. There are risks and issues. It’s a very long list!
- If you’re developing or modifying an OSS product, then there’s also a constant stream of challenges. There are user-interfaces options to consider. There are options around the best algorithm to use to implement certain functionality. There are bug fixes to diagnose and repair. There are application and data security considerations to provide protection for. There are test cases and regression testing approaches to consider to ensure the developed code doesn’t break anything
- If you’re using an OSS product or integrated solution, then you’re determining the best way to solve problems using the OSS tools at your disposal. This might mean using an alarm / fault / event management solution to fix a fault. It might mean using a network health / performance tool to diagnose problems as they’re forming (and hopefully making a diagnosis and fix before anything untoward happens). It might mean identifying an order that is about to go into a jeopardy state without your intervention
OSS as an industry that solves technical problems
As you can see, there are a crazy number of problems to solve in the OSS industry. No wonder your boss wants to build a team of problem solvers!
For the most part, the world of OSS is full of problem solvers. The industry tends to be very, very good at solving technical problems. In fact, it’s an industry that prides itself on solving technical problems.
Something to watch out for
However, what many in the industry don’t realise is that in solving one problem, such as finding a detailed technical solution, they’re often actually creating another problem. The new problem is often delayed momentum or increased cost to implement. These problems created are sometimes more impactful than the technical solutions that have been solved. For example, we’re often so focussed on solving problems “perfectly” that we analyse too many alternatives or we create too many meetings to discuss possible resolutions.
In many cases, there are just so many variables and possibilities that there is no single “perfect” solution to the many problems that arise. It will undoubtedly surprise many people in the industry that the person your boss needs is one who can solve problems pragmatically rather than perfectly.
You could also consider that this extends to the OSS that we build too. OSS largely exist to help us solve problems. They exist to help us solve complex problems, problems at scale and problems in minutiae. We sometimes need our OSS to solve problems pragmatically rather than perfectly too.
