Phil Knight, the founder of Nike, said in reflection on his fifty years building up his company “A businessman can be an artist as much as a writer or a sculptor.” Any leader might describe the organization built as an incredible masterpiece of their work. As a technical leader this may require a shift in mindset from a previous role where building the software product was the primary goal. In fact, there are many similarities that uniquely equip technical leaders to be good at the art of building a business.

I’ve always loved building products. I love the tangible feeling of creating a software product that I (or others) can use. I love the feedback loop of hearing what others think. I love the problem solving of pushing the boundaries on what can be done. I love the feeling of accomplishment.

I see many technical professionals with the same love for building products. At the same time, I see technical leaders struggle with the transition to leadership roles that take them away from the hands-on technical responsibilities. The shift in role can feel awkward because you are told that your job no longer is to code or do technical design. Instead you are expected to spend more time on exactly those things you used to dread in between the “real work” you did. You attend meetings and write e-mails. Your may feel you role has hollowed out the things you loved about building products.

I realized my technical leadership role was to build an organization. In turn, I found more satisfaction in my new role as I felt the accomplishment of building something meaningful. Apply some of the lessons from building software products to your role building organizations.

Automate everything. As a software developer, I rarely did something more than once without finding a way to automate the task. I hated doing work that a computer could do better (and more easily) than I could do. I would write scripts to automate anything that didn’t require my attention. As a technical leader, I learned to create systems that ensured routine work was completed as expected. Whether using checklists or workflows, having a system to complete routine work in your organization ensures the kind of automation that isn’t dependent on tribal knowledge or individual ownership.

Work to the solution. As a product creator, I would typically start with the end in mind. I knew I wanted to develop a product that performed a certain function or task and would dive in to get it done. I rarely created a vision for my end product by looking around at what parts I had in front of me. If I needed a new language, library or tool I would go get it. As a technical leader, I have to remind myself to define the end-state of the organization or business and work to that solution. It may be disconnected from the path I am on (not enough resources, time or money). Go get what tools I need to achieve the results for the organization.

Use the best tools available. I always believed that having the best tools possible armed me (and other developers) with the edge to be successful. Great tools are a mental and physical edge; your software runs faster and you feel as though are armed for anything. As a technical leader, you need to seek out the best tools - including people - for your organization. The term “best” is subjective, and it isn’t equal for every role or organization. In some organizations, you may need to seek out the people who can solve the hardest problems. In other cases, you may need people who can work together on a team highly effectively. However you define “best”, seek out the best people you can have for your organization.

Perform continuous integration. I fell in love with the idea of continuous integration as a fast feedback loop to know immediately when new code committed to the repository would break the build. I feel naked without the blanket of knowing that once my code is committed, I will have tests to tell me immediately if my application is working as expected. As a technical leader, you need this sort of continuous feedback on your organization. We must ask ourselves “how will we know when our organization begins to show signs of failure?” Are you asking for feedback? Do you have a mechanism in place where you can learn about failures in your organization due to changes like new staff, new projects or new environments?

Balance your technical debt. You can take shortcuts for some time in software, and the result can be a boost to get something done quickly. Over the longer term, these shortcuts can become dead weight that drag you down. The balance is important because it isn’t the right answer to always take the shortcut or the long-path, it’s a balance. As a technical leader, there is the same balancing act. You may have to ask your staff to work long hours or take shortcuts in order to meet a particular deadline. It is important to balance the shortcut and avoid the crushing weight of continuously thinking in short-term goals for your organization.

If you like this post, please share using the links below, and subscribe for more posts like this one.