Some Leadership Lessons I Learned In My First Startup

My first company grew from 2 to 200 people in five years. A colleague and I started it in 1995 when we predicted that a new technology, Java, would become widely used because it could run in browsers and would be boosted by the Internet. We were right.

The company, which was called Digital Focus (not to be confused with other current companies of the same name) won the “DC Fast 50” award for being the eighth fastest growing company in our region, which was the DC/Maryland/Virginia metropolitan area of the US.

Indeed, we would have gone public if the Internet bubble had not burst in 2001. The company survived that and continued to do well, but an IPO was off the table and the company was eventually sold to another startup for $16M.

While this is not a “Google” level of success, the rapid growth did challenge us, as did the rapid pace of the technology and the business environment. In fact, between 1995 and 2002, the company had to radically change its core model twice, and did so successfully. The first shift was from a tech-centered company to a solution- and customer-centered company: we created practices in financial services and supply chain. The second shift was to identify strongly with the use of Agile methods, which adjusted our approach to solution delivery and the dynamics of our customer relationships. These changes were made to stay competitive.

Between 1995 and 2002, the company had to radically change its model twice.

Digital Focus was a very serious company. We built things for a fixed price – hard things that were Internet-facing, which was new in those days, and that were highly reliable and secure. (I organized a security conference and had the CTO of Verisign and other security-conscious CIOs and CTOs present.) And we did it fast too – usually three months for a system or a major iteration (the shift to Agile shortened that). Examples included customer-facing business platforms for FedEx, McKesson Pharmaceuticals, Capital One Bank, United Overseas Bank, and many others.

What we built worked, we delivered it on time, and we were profitable every year from the start. And our people were happy to work there: we did not have a high pressure environment. Our company was calm and deliberate. People have told me that it was one of the best places they had ever worked.

Some Leadership Lessons That I Learned

The leadership lessons that I learned have born out over the years. The ones that come to mind are,

1. Treat people with respect.
2. Think through the “failure modes” at the start of each project.
3. Mentor and teach people.
4. Don’t micro-manage.
5. Don’t track time.
6. Don’t try to control costs by being more granular about work.
7. Test the heck out of things before you turn them over.
8. Be responsible for what you deliver to your customers.
9. Create a relationship with each customer before selling them anything; help them to realize what they need.
10. Have an engineering culture.

Rather than expand on each of these, which would be a long article, I will highlight the ones that are most important, in my opinion.

Treat people with respect

Of course, treating people with respect is always important. But what I really mean is treating them as individuals. Get to know them. Make it personal. Take an interest in your people. I did that with some of the people in Digital Focus, but not enough of them. That is something that I would do different today. It matters, because these people are investing their time with your company. It’s a partnership. It is not a mercenary situation – at least not if you want people to do their best. Getting to know them informs them that they are seen as people, not as faceless bodies, and they will return that same lens in their view of the company and its leaders.

Think through the “failure modes”

The second one, about failure modes, is one that is almost always overlooked in tech projects. Here’s what I used to do: After the start of a project, after people had had time to think through the basic design, I would meet with either the team or the team’s tech lead, and we would talk through all the ways that the design might fail. It was an intellectual discussion. I never gave them a solution: but that discussion got them thinking about situations that they had not thought of. It also taught them to think that way. For highly reliable systems, thinking ahead of time about failure modes is really important. I believe that it had a significant impact on the quality of what we built, and the relative lack of problems that we had after delivering systems.

Don’t try to control costs by being more granular

Another key lesson that I learned was learned from a mistake that we made. There inevitably ends up being cost pressure, especially as competitors become more numerous, and the wrong way to manage that for product development is to try to control the costs at a task level. You can’t: not for software, and usually not for product engineering. In fact, while focusing on costs is great for things you buy from providers, it is terrible for things you make that are one-offs – things that you need to design uniquely each time. I am not talking about bridges and buildings: I am talking about software or complex hardware products like machines and digitally enabled consumer products.

Instead of controlling the costs at a task level, daylight the delays that occur in the course of designing and building things. Use “Lean” techniques to remove delays and other sources of waste. If you do that, the costs will drop; but you will not have squeezed things that cannot be squeezed. You will not have caused anxiety for people who don’t really know how long it will take them to design and test a new widget – they really don’t know, and no amount of pressure can make them know. But by focusing on removing unnecessary delays, you will have achieved your goal of minimizing cost. That’s actually a basic concept from Lean manufacturing, and it applies very well to product engineering and software development.

Test the heck out of things

Testing is another lesson: test the heck out of things, but from the start. At Digital Focus we built an in-house performance testing lab, using our own funds. It cost us $500k, which was a lot for a company of our size at that time. But we could say with confidence that the systems that we built would work at scale. And we discovered that there were entire different classes of problems that show up at 10 concurrent users, 100 concurrent users, and thousands of concurrent users – not to mention millions.

Later I learned that one should do this kind of testing from the very beginning. That’s what DevOps is all about. Get automated integration testing set up right at the start, and make component-level and integration tests your main focus. That lesson was less important during the Digital Focus days, because systems were far less distributed than they are today.

Be responsible for what you deliver

We also felt responsible for what we delivered to customers. We treated each customer like a partner. If there was an issue with something we had created for them, we made it our business to solve it.

We also did not sell anyone on anything up front. Instead, we had a process that we called “Envisioning”, whereby a customer would spend a week at our office (we had a really nice room with a glass ceiling for those sessions). During that week they would spend all day with a team, including the project manager who would support them, the sales lead they had been working with, a technical architect, and sometimes others, in addition to their own staff. By the end of the week, they had a good understanding of what they actually needed, and it had been co-created by them and by us.

Through the Envisioning process, we were invested with our customer in the outcome. In effect, we made ourselves a partner and trusted advisor – not a vendor. That creates an entirely different kind of relationship.

Conclusion

I’ll end my summary there. But the other lessons listed above are also important to varying degrees. They have stood the test of time. And I believe that these lessons apply not only to a 200 person startup, but also to a business function or division in most companies. I hope these are helpful!

In another article I will share some leadership lessons that I learned through many years of working to help leaders improve the actual agility and effectiveness of their teams. These lessons will be especially helpful to project managers and group leads, but they should also inform senior managers on the challenges that their people have when trying to actually improve performance.