.png)
When my business partner and I started Promenade Software 10 years ago, we were engineers with solid experience in medical device software development. But we were newbies in running a company. In celebration of our 10th year as a company, I want to share with you our biggest lessons from a decade at the school of hard knocks. Our mistakes were often hard pills to swallow, so if reading this makes you think we were naive at times, well... you would be right.
1. On Change Management: In one of our very first projects 10 years ago, a startup client was very excited about their project and kept requesting changes as new ideas came to them. Instead of communicating the extra cost, we willingly went along, assuming they understood that changes cost time and time costs money. Oops! When they weren't able to get more investment money, their attitude changed, and they became angry over how much the project had gone over. We now track all changes and get client approval in the form of a change order. It's uncomfortable to track every small change, but 50 small changes can easily lead to weeks of work! Better to deal with the discomfort of tracking early before it's a huge problem.
2. On hiring engineers (Part 1): In our first couple of years, we hired 2 brilliant interns from UCI. They were quite exceptional developers - quick to learn, fast to implement, and produced high quality software. We thought that we had found a secret way to get exceptional engineers on the cheap. We hired more interns and ended up with a pretty lopsided ratio of young inexperienced developers vs. experienced developers. We quickly learned the hard way that the initial 2 hires were the exception, and the subsequent interns' lack of experience in software development, client interfacing, and judgement far overshadowed the benefit of their low salary. Now we always look for experience, and we always pair the new hires closely with experienced engineers.
3. On hiring engineers (Part 2): One of the major things we've learned to avoid are engineers with poor communications skills. There are a lot of them out there. Even if they are very technically capable, our work requires working well with others and with our clients. Poor communications skills are easy to catch, but poor people skills - the inability to listen and understand a client's perspective - i s trickier to evaluate. Now when evaluating potential hires, we include behavioral interview questions and rate technical skills and interpersonal/communication skills at the same level of importance.
4. On finding good sales people: I know they exist - I have colleagues with successful sales teams. But after trying over several years, no one brought in more profit than they cost. So I have accepted that the sales model doesn’t work for us. We have since pivoted to digital marketing and have found that to be effective. In this case the lesson is: if the 4th time you don't succeed, do something else.
5. On working remotely: Overall, the in-person-to-virtual transition has been a success. But last year we hired a very bright engineer who kept finding excuses for not coming to company team-building events, and his virtual meeting attendance was odd. He would flip off his mic after every sentence in an active conversation and often find an excuse not to be on video. His output also appeared on the slow side, considering his expertise. We were suspicious for a while, but after a few months we finally decided to check with his "prior" employer to see if he was still fully employed... He was! Now we do that check much earlier if there is any suspicion at all.
6. On partnering: There is an adage: "If you think it's expensive hiring a professional to do the job, wait until you hire an amateur." That's why our clients hire us! But even we occasionally need to call on a partner for specific expertise. For example, for UI design we use our partners. A while back, a client wanted to save money on User Interface (UI) design by asking our app developer do it, so we assigned it to a developer that liked to do UI design. But not being efficient with the mock-ups and tools ended up costing our client the same as a pro designer would have, and the output was not as professional. We won't make that mistake again.
7. On trust: Not everyone is honest. "Well yeah, obviously," you say. But actually most of our clients are really very honest, and after 9 years we got lulled into complacency. Until last year... we had a startup client growing significantly overdue on payment and blamed it on changes in accounting and a whole gambit of other (ultimately false) reasons for being late. It turned out they did not secure the additional funding needed to cover the purchase order but wanted to squeeze as much work done as possible towards their data collection. This was our first blatantly dishonest client in our 10 years, and we lost considerable money on that project. Now we always make sure deposits are on file and payments are being made before going too far into the red.
8. On being open and transparent: This is a core value that we have had from the beginning, and sometimes a lesson learned can be tangible confirmation that you're doing the right thing! One of our clients came to us with a problem: their prior service provider was withholding information or source code as a method of insuring their dependence on them. At a great expense, the client broke off that relationship and went with us. That type of hostage-holding is never successful. It is also a lesson to anyone using a service provider to make sure the agreement is clear and that the source code is shared.
9. On code reviews and unit tests: Once a major bug slipped out the door for a project, and we had to do quite a bit of introspection on how it happened. We have 3 layers of protection - the developer should have caught it in integration test with the equipment, the reviewers should have caught the bug, and the system tester was not informed this area changed and did not do regression test. That was a shock to our system, and now we emphasize the early verification steps (code review and unit test) and make these a part of the employee reviews. Also, we enhanced our regression test policies.
10. On providing great service: This may seem obvious coming from a services company, but for engineers, "great service" can get translated into just "providing quality output." But good service ALSO means responding quickly to requests and questions, listening to clients' perspectives, and staying in budget. We now train our engineers on the soft skills of service and routinely hold internal discussions to consistently improve our overall service.
The last 10 years have been an amazing journey, and I am sure there are plenty more lessons to be learned in the next 10. I truly thank each and every one one of our clients, colleagues, and supporters that have made this decade a success!
