Week 26–Four Painful Lessons Learnt From Leading a Tech Team
--
How many of us start a project, outsourcing the technical side of the mission, only to end up producing something totally different from what you’ve envisioned?
I came into the Pratu and TrueSign projects with the illusion that I was simply going to throw the technical part of the projects to these professionals, and all we had to do was just manage them and wait for magic to appear on our screens.
Obviously, my naivety was exposed quickly when problems began to pop up, changes begin to happen and confusion ensued.
I soon realised, shit … This is not as easy as it seems. Whether or not it was dealing with a professional development house or a team of student developers, I found patterns when it came to understanding and managing the relationship between our customers and the technical team we were in charge of.
Handling a technical team is something every entrepreneur has to learn, whether you’re dealing with an inhouse team of developers or a band of outsourced mercenaries, you need to be absolutely clear with your approach with your troops if you want to achieve mission success.
Here are 4 of the biggest lessons that I’ve learnt so far.
Lesson #1 — The difference between the aesthetic layout and data fields.
When we first got the wireframe for the first version of Pratu, I honestly didn’t think too much about it. It seemed so simple to build from my perspective and simplicity was what we were going for because having a complex prototype usually costs a ton of money and it leaves the door open for potential confusion with the technical team even before starting on the build.
It unnecessarily increases the risk factor of the project. That’s not what you usually want unless you’re rushing for time and you have deep deep pockets.
On the surface, the wireframe looked great and it seemed really simple to build. What I failed to discern was the difference between the how the product looked aesthetically and the logic behind the underlying data fields in your website. These are two completely different considerations. As a non-technical expert in this field, I could not differentiate between the two concepts.
What’s the difference?
The aesthetic layout (or user interface) of a product usually deals with how the customer looks at it. Whether you want it to resemble an ecommerce site or whatever kind of user experience do you want your customers to go through, that’s on your research.
This is important to get right because it’s always a steep learning curve that a user has to overcome in order to fully experience what the app/ site has to offer. Realistically you have less than 5 seconds to grab the attention of a prospect. You have to make full use of the limited time.
On the other hand, the data fields are the foundation that your aesthetics are built upon. If you do not have your foundation right, your app or site won’t work the way you want it to.
To illustrate my point, one of the most fundamental functions any website should have is a registration page.
It should be pretty easy from a users’ perspective to sign up for a service. But, underneath it all, some questions need to be answered.
How are you storing your users’ information? Are you GDPR compliant? What other stakeholders require access to your users’ information apart from your administrators? Can your administrators access the information and edit it? If so, that needs to be conveyed to the tech team clearly because this shapes the outline of the administrators portal where admins can access and make the appropriate changes.
If your users’ type in the wrong information, are they able to edit the information? If that’s what you want, then you need to build a users’ portal with a page to edit and fill up the information.
Understanding this would have saved me so much trouble and frustration.
Lesson #2 — Having a technical product lead saves a boatload of time and pain.
This lesson has alot in common with the previous one. When you’re trying to create something completely out of your field of expertise, it is extremely valuable to have someone that can bridge the gap between your software developers and your product lead. Often times, that requires an individual with the ability to understand what the tech team is saying but yet can explain things to you in the dumbest possible way.
This individual should also be able to process requests from the product lead and turn it into a diagram where the team can refer and know exactly what they are building.
One of the most annoying issues that we had to deal with was the fact that our TrueSign software developers seemed to be working in silos, communication was poor and it was our fault. We failed to identify an individual to piece together the progress and work done, someone that could give the developers direction from a technical standpoint. It was only after a chat with mentor Kwai that we realised our blind spot. We needed a technical lead that knew what he was doing and knew how to communicate in the right ‘language’.
Because there wasn’t a such a person, we ended up with developers wasting time building 2 of the same things.
Once we had appointed a technical lead, things became way smoother and we looked to our lead for status updates and for him to organise the troops to the best of his ability.
Having someone fill that specific role could save you months of back and forth with the technical team, rectifying avoidable errors and wasting time making minute changes.
Lesson #3 — Set expectations with your customers.
For me, this remains one of the biggest challenges that I’ve yet to conquer.
When you have the product design in place, you’ve drawn up your battle plans and you’re in the execution phase, you’re determined to build the product.
But as you reveal your product to your customers’, you realise that they start to request for additional functionalities that you didn’t account for in the beginning or you find that certain features that you initially thought was easy to build turns out to be a nightmare to deal with and you intend to drop it for the time being.
Many times, I felt like I was caught between 2 parties, between meeting the expectations of the customers’ as well as making sure that I was not putting the tech team in disarray by continually adding new things to build on top of what was originally planned.
Needing to wait for replies and for the tech team to reconvene and adjust the developmental timelines delays the project further. Therefore it becomes crucial to know when to push forward certain aspects of the build, when to pull back certain features and knowing the right moment to say not right now to a new request becomes absolutely critical.
Lesson #4 — It’s not about the ability of the team, it’s the ability of the leader.
Throughout the whole process of working on TrueSign and Pratu, the story of Jocko Willinks leadership experiment during his time as a Navy Seal kept surfacing in my mind.
As an instructor in the notorious BUDS course (Navy Seal selection process), there’s a part of the training that required the trialists to be split into different rubber dingy boats. There, the tortured souls would all head to the shore line and begin racing each other. The winner would sit out the next race and would be rewarded with a well deserved rest. The boat crew in last place would unfortunately have to continue racing and be kept in the crosshairs of the watchful instructor.
Jocko witnessed the pure domination of boat crew 2, racking up win after win while boat crew 6 continually laboured in last place. The men in boat crew 6 began to bicker and curse at each other, blaming each other for not doing something right. What made things worse was boat crew 6’s leader. He seemed resigned to his fate that he had been dealt a shitty hand and nothing was in his control.
Jocko’s senior chief knew what was going on and decided to propose an interesting idea. Why not swap the leaders of boat crew 2 and 6, and observe what would happen?
Boat crew 2’s leader was visibly unhappy while boat crew 6’s leader was delighted at the change of his fortunes.
As the change was enacted, the instructors lined the trialists on the shore yet again and signaled the start of the race.
The boats began to thrash about in the water, multiple boats furiously paddling, vying for the win.
As the fog cleared out, there were only two boats ahead of the pack. It was boat crew 2 and 6. Neck and neck as they heaved and paddled, boat crew 6 for the first time began to inch forward ahead of their fierce rival until they pulled ahead more and more and more. The new and improved boat crew 6 had won their first race.
This story never fails to illustrate the concept that there aren’t bad teams, just bad leaders.
No matter how inadequate the team might seem, the onus lies on me as the leader to lead the team out of a bad situation. If I can do everything in my power to help my team members be successful, then we will all be successful. If I am selfish and start blaming everyone and refuse to take responsibility for anything, it will be a detriment to me and the team.
Nothing gets done.
I hope you’ve enjoyed these 4 lessons that I’ve learnt! Avoid making these mistakes if you can, but if you can’t maybe these lessons would serve as a memory jolt, to remind you of the things to look out for.
Till next week! Bye!
