Professional software development at an enterprise scale is inherently, and at every level, social. How does comprehension of this fact help teams to perform better?
Who are the people who matter most to the product your team produces? I’m sure you’re probably thinking about this in terms of end users: the people who spend time on the platform, working their way through carefully crafted workflows you’ve been crafting.
The people who use our products are the ones we obsess over the most. After all the chances are that they play the most significant role in generating the revenue our organisations need.
However, in any organisation there are other groups of people we ought to give significant consideration to. When we acknowledge and seek to meet the needs of these other groups I think we are the most effective we can be as a software team.
Two of the most significant of these are those higher up the chain (stakeholders) and those who are closer to the product (engineers). There are others in the wider team too (power users) that we should also give consideration to.
Stakeholders
Are stakeholders users of our product? It would be a mistake to see them as such, even if they use it themselves. Their unique perspective puts them in a responsible position towards users. However, their recommendations, suggestions and feature requests need to be validated and researched if the actual needs of stakeholders are to be met.
What do I mean by that?
Imagine a stakeholder requests a feature, which is added straight to the backlog. The feature is built and shipped, the stakeholder’s requirements are satisfied. But the feature proves to be a waste of time.
Why?
Without due diligence is done beforehand, we are not meeting the real needs of stakeholders. After all, we didn’t ask the most important question before any further work was done: “why do you want this feature?“. Anything other than “I think it would be good” is an acceptable answer here.
Without that thought process, we could build a feature that nobody will use. Or we could build something that doesn’t solve the problem the stakeholder was trying to address.
So ask them, what is it you’re trying to achieve?
Even after we’re clear about what is being requested, that’s not the point it should reach the backlog; we would only be satisfying the real needs of stakeholders by doing proper due diligence.
We might need to do further research about whether it’s a good fit for our product, whether competitors have already implemented it or not, and why, whether users think it’s a feature they could benefit from, and how much time might it take to build?
The main idea behind all of these is principally, “is it something that will add value to the product” and then, “is it worth the cost of implementation”?
Stakeholders exist to improve the value of the product. If they’re not achieving that, they’re not going to be fulfilled. That means that knowing the implications of what they’ve asked for is a key driver to their decision making.
Team members
Ensuring the success of people who use what we’re building as well as those who are stakeholders in the product should be as important to us as the success of the individual members of the team involved in constructing it.
How are they doing? Are they having a good day, a good week, a good experience working for you?
It’s only when we help facilitate them being able to find their place within the team that we get the most out of them.
That means that if they are disengaged, its our job to find out why that might be the case. Often it boils down to three reasons.
- Tasks are too challenging
In this case, the person might benefit from some extra coaching or support to achieve objectives. Their backlog could be cleared to help them focus if they are easily distracted, or tasks can perhaps be broken down to improve focus. The size of a ticket matters less about it’s percieved difficulty than it is possible to do for the one who fulfils it. So customise tickets: write smaller tickets for those less able to focus, larger ones for those who can.
- Personal problems
How well do we know what’s going on in the lives of those we are responsible for? If there is no “idle” conversation, then how will you know if a bereavement has affected them? If they are having issues with a colleague? If they are struggling with impostor syndrome?
Get to know your people. Being an effective leader means being someone who represents the company’s consideration for them when they’re going through a rough patch. You’ll get so much more out of them in terms of years of service as well as productivity if you make a friend instead of just a colleague.
- Lack of clear direction
We don’t want to be seen as treating people like they’re infants, but often what someone perceives as clear direction is much more explicit that we might expect. Have we clarified what is expected of them for this task? Have we asked them to outline their plan verbally to us? (often this is a really good way to check understanding, a simple “how do you think you’re going to approach it?” is enough).
More importantly than either of the above questions is “do they feel comfortable approaching us if they don’t understand what is expected of them?”
If your response to their questions give even a slight hint that you’re expecting them to already comprehend fully your requirements, then you’re doing it wrong. There should be no hesitation on their part to ask you for more clarifications, more detail, or to challenge anything about the work you have scheduled for them.
Otherwise it is likely that the delivery will suffer, and so will their confidence, which could lead to other significant issues and underperformance.
Knowing our team personally and making sure individuals are comfortable approaching us for clarification is a big step to creating a team that is as productive as it can be.
The wider business
So far we’ve looked at individuals within the business. But are the people who are impacted by changes in our product ever involved before we release new features?
I have found there are often key people within a business, whether that’s power users or that one technical person in the 1st line support team, who have a deep understanding of the product. Do we consider them?
Even if we just tell them what’s coming up, it can empower their decision making and the way they give support to others significantly. If we also ask them for involvement in scoping features, or even suggesting new ones, we’ll tap into a potential goldmine of new ideas that can inject more revenue into a business from unexpected angles.
Start and end with the people
The people are what make up everything about our business. Look holistically at our product. It’s definition might be a piece of software, but it’s the result of interactions between people. When we focus on that instead, zooming out of implementation details, and instead focusing on what can do to fulfil stakeholders, generate effective teams, and involve the wider business, we will build things that are wanted, needed and enjoyed. By all involved.