In this world that is filled with fast-changing innovations, software emerges as a fuel that drives business survival and success. Business people invest in software development to take the lead in their industries.
Business transformation is critical. Transforming your company from a cost center to a profit center entails strategic business efforts. And this is the point where the relationship between the business people and software people plays an important role. If there is no effective collaboration between these two entities, it results in dismal software. Unlocking the full potential of your software development team as a business leader plays an important role in bringing your business to the next level.
This post aims to help you establish the right collaboration with your software team as a business leader.
Share your problems, not your solutions
Building software is a matter of whom we ask, and what we ask of them. Companies should recognize that software developers are creative problem solvers. When immersed in the right environment where freedom and a sense of autonomy are allowed, can even create more quality software, with shorter cycle times that produce happy users on a long-term basis.
The more you give freedom to software developers, the more they engage themselves and the more fire and energy they exhibit in creating a solution that will account for your problems.
Unfortunately, most companies don’t exercise this and treat their developers as math and science whiz when in fact they are more similar to a song or novel writers. For developers, code is more than a job - it is a form of outlet, a creative one.
If you ever wonder why software takes longer than usual, then most of the time it is because managers tell developers what solutions to build rather than including them in the earlier phase of defining the problem that needs solving. Companies must share the idea of what needs fixing and let the responsibility of figuring out what to do based on how the existing systems are constructed be on the developer’s shoulders.
Streamline communications between developers and users
There is a misconception that a developer has to receive the requirements of the product, implement their codes, and deliver the project. Nothing could be more wrong. When a customer presents their problems, who can better define its technological requirements better than the developer? Business leaders must not ignore the view of a programmer just because of the common perception that they lack communication skills or worse an introvert.
As the company grows, the less this direct line of communication between end users and the developers becomes in place. A cut in communication will eventually result in a lack of empathy for those people who interact with the product, thus affecting the software’s quality.
A frustrated customer wants their new product finished immediately. When this happens, business people should not make any fake promises just to please the customer. With a developer interacting with the customer, they can navigate through the situation and set realistic expectations to make customers at ease.
Streamlining the communication between the end user and the software team helps build empathy in the developers as they start to see the actual users of the product and face them as human as they can be rather than just being distinguished as code monkeys during the development phase.
Create a culture of experimentation
To innovate, it is vital to experiment with new ideas first. The more experiments there are, the more ideas flourish while others fail. But failure is a part of experimentation. It is natural and very human to want to achieve success. Without fail, you will never be able to achieve one great idea that results in a breakthrough innovation.
The airplane invention of the Wright brothers, for example, is a testimony to this. They ran lots of experiments and they are willing to fail a big amount, even when their bodies are at stake. If the Wright brothers could commit to experimenting persistently until they land success, so can the rest of us.
In more recent technological achievements, let us take Amazon as an example. This company is known for experimenting in the mobile phone market. However, users were not happy with the device they created. But this does not result in any stagnation for the company. They moved forward and continuously innovated. Then they ended with an Amazon Prime video, or a Kindle developed.
Experimenting with the software works the same way, although much easier and faster. Every app or website that is running- they are updated hourly or weekly. Many don’t realize that lots of experiments are being implemented within many of these apps or sites. Some new features are implemented for a small percentage of the customer, then if feedback is good, the feature is scaled to a larger audience.
Most companies kill experiments when they see that it is not yet generating the level of revenue that they are trying to achieve. But you have to realize that it is impossible to know which new experiments will be the next big 200$ million line of business. Just like seeds that you plant, instead of cutting or stepping on those small sprouts, why not water them and put them in direct sunlight and let them grow? In short, on the business side, invest more. Anyway, every big idea starts small. A good way to establish a culture of experimentation starts with small teams. Don’t tell the developers what to build, rather tell them which customer to focus on and which valuable problem they can solve for that customer. Then agree with certain metrics of what a successful experimental outcome should be. When experiments are winning, you should remember to have the resources to give the needed booster to these teams. A good example of this is Amazon, again. Alexa, the AI virtual assistant, was an experiment until it started to take off, Amazon realized it needed to be fed. From a small Alexa team, it was scaled up by hiring new members. When experiments are not striking gold, most companies punish their teams. To build a culture of experimentation, the business leader must not punish the failing experiments, rather, accept, and move forward. Just like the previous Amazon mobile phone example. If the experiments seem to put you in a fuzzy situation, change your tactics. If your tests are not giving you any answers, try to test differently. It can also be a problem with your developers. Try to check on them regularly to understand the problem or help guide the experiment. Developers know deeply the details of the experimentation, which is why it helps to consider their point of view.
Business leaders need to build a culture of experimentation and should not be afraid of failing, rather, think of it as a learning experience that would just expand the knowledge of the developers and themselves.
Hire developers smart enough to tell you what to do
The US Bureau of Labor Statistics predicts that by 2029, demand for developers will increase by 22% which indicates that it is a tremendously competitive industry for talent. Most companies entice developers with high salaries and incentives like bonuses or even perks. This is becoming a trend now since intelligent tech leaders or programmers are already working in tech giants - Google, Amazon, or Microsoft. The good news is, you should not follow this mentality. The key is to treat developers as merely human beings. This means they are humans that are hungry to learn and grow, searching for motivations to do their best at their work. A company that gives importance to developers and treats them as just people rather than code monkeys results in developers being engaged and active contributors to your company. Therefore, while others offer these smart developers a high salary, try to offer them just a fair enough salary and bombard them with offers of new learnings, mastery, and how big their talent will impact a lot of people who will use their product.
Perks or incentives are all good but only up to a point. In the long run, developers will seek a type of culture where they “fit”. Fit in the sense that they can create amazing things and learn from smart people. The very best developers are always hoping to be pushed, motivated and mentored.
Speaking of mentorship, this is the hurdle of hiring a technical lead often surfaces. In the first phase, hiring a strong technical leader is hard and time-consuming. But when you eventually acquire the best ones, the rest of the great developers will follow because these leaders are smart, they only want to mentor competent developers as well, then you end up having a strong software team.
Conduct open project reviews
An open project review keeps the tabs open for other developers who may have dependencies with other teams. It is also a room for learning. Allowing other teams to attend meetings of other groups would result in constructive criticism that can help the team get better. Meetings can be tough but opening it to a larger audience or even to the whole company gives that sense of preparedness to them before showing up knowing that there will be lots of people who will witness their performance. Another benefit of conducting an open project review is that the teams will have a sense of accountability since decisions are being made in front of a large audience which means that everyone knows what is expected of them to deliver. On the other hand, having open meetings makes room for embarrassment when you can’t answer questions from leaders. Therefore, it is advised that leaders should be able to help the teams solve the issue in a forceful but supportive way. We don't want the meetings to be an arena of fear.
Remember that the purpose of an open environment is to learn the faster way. It should be a venue for teaching the teams how to think strategically and make arguments on their feet. Ask tough questions but coaching them on the right answers at the same time in front of the group will help everybody learn. Through questioning, teams will learn to teach themselves - the essence of a learning environment. Build a mindset, a way to analyze a problem and come up with preventive and corrective action.
Go deeper than the surface level when addressing an issue
When things go wrong, two things can happen - blame others or utilize the bad outcome as a learning opportunity. When mistakes happen, address them as an organization. Go dive deeper into the situation and point out all probable root causes of the problem and address it as a whole company.
For example, a bug was introduced into a code which resulted in a website that needed to be shut down. You can revert to the earlier version and get back to servicing. This is how it is usually done. After that, companies tend to end the problem with that. What could be done to facilitate learning from this mistake is to take the time to analyze what happened, and figure out the root cause/s that might have led to the bad outcome. You cannot gain anything if you blame others. Even the best engineers or developers make mistakes. Blaming them will only result in them being demotivated and less likely to want to write code. Performing the 5 Why Method to identify the probable root causes of the problem is a good strategy to implement. It is one of the most effective tools in RCA or Root Cause Analysis
As a practical example of how the 5 Why method works, let us take a look at this problem:
The air conditioner in your bedroom is leaking.
If you implement 5 Why you can start by asking yourself:
Why did it leak? The drain line is clogged. Why did it get clogged? Debris-like dirt accumulated. Why did it get so much dirt? The filter was not cleaned regularly. Why was it not cleaned regularly? You did not avail aircon cleaning service Why did you not avail of the cleaning service? It will cost you some money.
5 Why Technique was developed by Sakichi Toyoda and was used at Toyota in their manufacturing industry. The number of steps is not limited to 5. It can be less or more than 5 until the diagnosis of the problem has arrived. It results in a quick diagnosis to rule out the symptoms and arrive at the root cause.
Be open to learning by doing
No one can learn how to play golf only by watching videos. Same way in software development. You can start to implement learning by doing small projects that even if training leaders fall short will still not affect the regular operations.
For example, when you hire Bootcamp grads, you may want to consider training them with pay for 3-6 months as a transition stage from learning to doing.
As business leaders strive for people to demonstrate their willingness to learn. People who changed professions mid-careers or those boot camp grads usually possess this trait.
Build a memorable customer-centric culture
This “customer-centric” value seems overrated but making it more than just something hanging on the walls of your company makes it valuable. Let your developers wear the shoes of your customers. Engaging in forums can help connect easily with customers especially in acquiring their suggestions or reviews about a product or service. Customers are very good at expressing their problems.
Don't underestimate small ideas from your customers. It often leads to big impacts. Your customers see you as a responsive and customer-focused organization.
Connecting the line between your customers and your developers will give way to humanizing your customers. Instead of only knowing what the customer requires for the product, they will understand why they need it. Developers want to see customers use and love the results of their work.
