As software engineers, we like to learn new things to stay relevant and be excited about, whereas product owners tend to be more focused on shipping, tangible value and feedback.
As a software engineer who is ‘just a team member’, you don’t often have an appreciation for the kind of concerns a product owner has and don’t fully understand why a particular deadline is so important. This is an inherent conflict and I hadn’t fully appreciated until I took a leadership role and had to sell our choices. As a result, I now tend to make more sensible choices that fit the skills available, while being fit for purpose. However, as a team lead, I am also responsible for the well-being and motivation of my team, and this leads me to take some risks.
If we take a step back and look at how the Agile movement started, this is actually quite ironic! We preach delivering business value early, eliminating waste and making decisions at the last responsible moment, yet we also learn on the job and experiment with new technologies. Have we as a tech community forgotten what Agile software development means? We should always focus on the business value of what we are doing and make sure that our product owner understands our technological decisions and the trade-offs with the choices we make.
There are some key questions that you should ask yourself whenever you kick off a new project.
Which technology options are fit for purpose?
The first thing you should do is shortlist a few options that seem to be a good fit and discuss the options with your team to narrow down a shortlist of what makes sense given the nature of the project and its requirements. This is common sense and something that most people do naturally. It might be tempting to pick the first option that comes to mind, so make sure you do some research as the options might have changed since you last had to make technology decisions. Technology choice includes both infrastructure (if you do have options), languages and frameworks.
Where does the technology sit on the technology maturity curve?
Different organisations have different appetites for risk and exploration. Some are willing to test something new while others are conservative and always go with what they already know. Your due diligence should at least include looking at trends to see if usage is declining and particularly if you are building a solution that is meant to be used for a considerable amount of time (e.g. more than five years) – you should avoid picking something that is on the decline unless it fits the other criteria well.
What skills are available among the people on the project team?
Whatever you end up choosing, make sure you have enough (ideally at least half of the project team) people with good knowledge of the technology to reduce the amount of learning that is required on the job. This reduces waste, ensures higher quality and reduces dependence on individuals. If I have a team of six developers and I propose that we use node.js as a key technology for delivery, I want to make sure that I have at least three team members with previous experience and at least two with a solid background in node.js. Additionally, who is going to maintain the software after it has been built? If you are lucky, it’s not a project in a traditional sense, but a team built around a product or a portfolio of products. If this is the case, most of the people building the software will also maintain it. If this is not the case and the software is to be handed over to someone else, you also need to take into account what kind of skills the maintainers have and their desire and opportunity to learn something new.
Can I sell the choice to the client/stakeholders?
You can end up wasting time and energy if you keep trying to sell technology that an organisation is unwilling to use. You may also lose credibility. If you sense that there is strong opposition, then unless you have a very good reason to persevere, you should listen to the reasons for why they are not willing to accept your choice and choose something else. It can be demoralising for a team if the reasons for rejection do not make sense, so you should make sure you communicate to stakeholders why you believe your choice is the right one, including both how it is fit for purpose and how a change might affect the team’s motivation. A conversation that you may want to have when working with more conservative organisations is to explain the inherent risk of not taking chances as you may end up on the wrong side of the technology maturity curve sooner and that it might be hard to find people to maintain the solution.
How tight is your deadline?
The shorter the project timeline, the less time you can’t afford to lose. For shorter projects (e.g. less than three months), go with a safe choice that lets you focus solely on delivery to reduce stress. It is usually very hard to negotiate a scope or deadline change if the reason for the change is a poor choice of technology for the circumstances.
As a team lead, it’s your responsibility to juggle project delivery against timelines, the team’s happiness and motivation, as well as the quality of the overall solution. Usually there is give and take in all of these aspects as the situation changes during a project. It is a rare project where everything goes according to plan. The trick is to make sure you keep communicating with everyone throughout so there are no surprises and don’t take on too much risk.