I ran a dev shop in Manila from Stanford for 3 years and this is what I learned from failing.
Most of these learnings apply to developing software and selling it but is specifically geared towards development shops or IT consultancies.
Finding the right people:
Most of the time, clients don’t know what they want. This is why companies hire a development shop in the first place. Even when a project is scoped very well, clients may ask for adjustments. When talking to clients, expect that they don’t really understand the jargon being used by software developers. This is why engineers, especially client-facing ones, must be extremely patient. They need to be able to empathize and understand that the client isn’t as technologically savvy as we are. We’re hired to translate their needs into user and technical requirements.
Measurable Metrics for Success (KPIs)
Have relevant metrics to ensure that people are actually moving the metrics that they need to. This is why many companies are investing millions into making dashboards for their KPIs. This is why data tracking in logistics companies alone is a multi-billion dollar industry. The real challenge is in selecting the correct KPIs.
It is possible to be so laser focused on pushing the needle on the KPIs set that people don’t stop to question if moving this datapoint is actually the most effective way to help the company. This is merely a pitfall but all departments in a startup or dev shop, especially product development and sales, must have KPIs to measure how well they are doing their function.
These are some of the ones we’ve decided to use:
During Development:
Team Velocity — Estimate how many weeks it would typically take to finish this project and set milestones with the percentage that needs to be done by specific dates. How much faster or slower your team is would be your velocity. This is a non-objective metric and should not be used to see performance. It’s just a way for a team to see if they are hitting the goals they have set for themselves or not.
Open/Close Rates — See how quickly opened issues are closed. If they are closed right away, this means that architecture earlier in the project was done well which is why issues are easier to solve. It could also mean that the team is closing issues efficiently. This metric helps you see if your architecture is off or if your team is unable to rework the codebase created easily.
Update Cycle Time — Track how efficiently your team can get back to a client regarding a requested change. This helps you identify flaws in either communication with a client or overall development practices.
During Production:
MTBF (Mean Time Between Failures) — Track how long it takes to patch up errors. The time should be tracked is when the error happens up to when it is solved. If this number is very high, it could either point towards an issue in a.) team finding out quickly enough when there is an issue b.) team putting out the fire too slowly
Disclaimer: KPIs don’t tell the full story. You still need to communicate with the client and the team to gain a full understanding of performance. Product development is a process which varies greatly between teams and clients, that’s why it’s so challenging to design the right KPIs. Either way, they help teams track within themselves if they’re achieving their goals and how quickly they are responding to client requests.
Precision of Language
In interpreting and sharing technical ideas.
“I want an AI system that will talk to my clients and sell our products! Give me a quote for that.”
Wait. What?
This is what my first client said during our meeting. We were wondering why a medium sized corporation selling paper would need a feature this complicated.
Later that meeting, we realized that they actually wanted a set of questions to redirect the user to different products like:
“What kind of curtains do you want?
Options: Industrial, Commercial, See-through, Black out (Selecting answers filtered the products being displayed)
Really all they wanted was a simple webpage with filters. More often than not, people we work with aren’t as tech-savvy but that’s why we’re getting paid in the first place. It’s the skill differential in the first place.
The greatest mistake made in these scenarios is building without asking them why several times. Understand their reason for wanting a certain type of system because that’s why they’re paying up in the first place. Without asking, the project ends up having a lot of scope creep especially since something they don’t even need what was built. They’re not paying you either because they didn’t receive any benefit at all. We had a project go on an entire year because of this reason.
In technical writing (contracts, documentation, etc.) need to be precise and written down. The same project mentioned above stretched for so long despite us accommodating changes and saying these would be the last ones. Why? There were many small features being added on top again and again. They kept saying that without this one last feature, the software would be useless for them so we had to just agree.
This is exactly what we experienced with our first high paying client. The project spanned a year and two months because of a lack of clarity. We sent them screens of what we were planning to build, they approved it, then suddenly after building it they “realized” they didn’t need what we had sent at all. This was a huge loss for us because the value of the client’s trust and the money we were supposed to get from finishing the project was worth more than the cost of litigation. In our experience, both sides of the deal were clearly feigning amicability. Just openly talk about the issues you have with one another and everything should work out.
Scope creep will be a scenario you’ll be trapped in when working for other clients quite often especially if you don’t critically think or care about what your client asks you to do. If the project doesn’t resonate with you, don’t take it or it’s the next six months to a year of your life. Added to that maybe a decade or two of maintenance.
Sometimes, no matter how much thought you put into it though, you’ll miss some of the required features. That’s why we need tools and thought frameworks to prototype!
Rapid Prototyping
It seems like a huge irrelevant pain in the ass but I guarantee that this is worth it. Skipping over this simple task really screws both you and your client in the long run. There are tons of tools today like InVision for web or mobile apps but we can go even simpler. At Stanford, we were always told to create Wizard of Oz prototype where we actually ask somebody to use a version of the software on paper, while the Wizard moves around the relevant pieces. This makes sure that: 1.) You and your client are on the same page with all the features 2.) There aren’t any loose ends meaning all the data needed is collected.
While building https://devsavings.com, we realized that sending over a prototype to the clients will never work. You’ll have to go there and actually be on the ground with your users. It’s like any other product, you can’t make a solution for a problem you can’t understand.
Ride the highs but stay lean
It is very tempting to hire fast when deals are being closed week after week. However, this is the major concern with running an IT Outsourcing company, there are times when the sales team is on a hot streak. Other times, you’ll be looking for $500 projects on Freelancer because of a lack of tasks for the team.
Keeping operations lean is of utmost importance. Make sure that you have enough running capital for the next few months and that you’re always anticipating a drought.
Communication
This topic deserves it’s own article so check back next week. I’ll add the link here as well once I write the article. The experiences I’ve gained from working with a team remotely on multiple projects have helped me think of a systematic way of making sure all bases are covered. I want to share those secrets with you. An often overlooked factor is the mental well-being of remote work since they no longer have the emotional support of seeing workmates everyday at a communal space. This must be supplemented with clean and constant communication. Lessons from this experience definitely transfer as well to running a corporation where everyone is in the same place as it also helps cut the amount of time wasted. A book that introduces you to these concepts is Remote, made by the creators of Basecamp.
Enjoy the Process
If you’re the type of product creator who just wants to work on one thing at a time and dedicate all their time to it, this isn’t the business for you. You’ll constantly be on call in case one of your old projects breaks down to put out the fire. They’ll expect you to reply within 30 minutes even if you’re on a transcontinental flight. You’ll have to be able to shift your mindset and be able to look at the documentation your team has written to remember how to solve the problem.
Since most dev shop jobs build completely custom systems, taking a project is at least a 10 year commitment. Aside from money, the company has invested significant human resources to make sure that you understand their current needs. Turning over all of this information costs a lot of money which is why a lot of people are willing to pay a premium for more reliable outsourcing companies with a track record.
For any article requests or questions, feel free to comment or hmu on LinkedIn. https://www.linkedin.com/in/kingalandydy/
More where this came from
This story is published in Noteworthy, where thousands come every day to learn about the people & ideas shaping the products we love.
Follow our publication to see more product & design stories featured by the Journal team.
