How to build a successful software organization inside a larger one
I helped build a successful organization with the help of a handful of people. Here are my founder’s secrets.
I helped build a successful organization with the help of a handful of people. Here are my founder’s secrets.
Any software organization is only as good as its people, but it also comes down to other things like having a vision, following a process, ensuring quality work, and above all leadership. Here are a few of the things I’ve learned in my years building my organization.
Funding
Once you have a core group of people, your founders, and you’re ready to start your organization, you need to secure funding. You never hire before your funders have signed on the dotted line. Nothing is worse than having to lay people off right after you hired them.
In my organization, funding comes from other groups in the organization that need software, usually subject matter experts who have secured funding from some other agency and need software to implement their idea.
Getting funded could be a management decision but for us it was about relationships. People want to give money to people they trust. Having relationships with people you’ve worked with or collaborated with is the first step.
When I started building mine, we had a large project in place and only four people to work on it. I wrote a lot of code. Later we received an even bigger commission that needed about twenty people and we had the same four. That led to my having to look through a lot of resumes and call a lot of people.
Hiring
If you’re lucky you have recruiters bringing people in for you to interview. In my organization, no such luck. We had a resume submission system but any further action on the resumes was our job.
I’ve gone through a lot of different approaches to hiring developers, and I’m still trying to tweak the system. I’ll let you in on the secret of getting your resume looked at, however. Keywords.
We get a lot of resumes, dozens, and they come in all different shapes and sizes. Keywords are my shortcut. If I want an embedded systems developer, I’ll look for words like C and C++, Linux, the word “embedded”, maybe “FPGA”. If I want a machine learning person, I’ll look for PyTorch or TensorFlow, but I might look for C++ or some other compiled language in case I run out of machine learning work for a few months.
I do look at GPAs. I’ve found that most hiring managers reject anyone who had an undergraduate GPA lower than their own. I try not to be so snobby but I do look for mitigating factors if the GPA is low. If there’s no GPA, I’ll ask for it. GPAs are good indicator of how conscientious you are. I occasionally have terribly boring stuff you need to do, documentation, training, process-related drudge work. If all you like to do is hack, then you can find an organization where other people do that for you. Ours does not support one-trick horses. Also, graduate GPAs are meaningless.
Process
The word is Agile, Agile, and more Agile. We follow Agile not because it’s trendy but because it works. Since we are an R&D division, when starting a project we often have no idea what we are supposed to be doing. The customer doesn’t know what they want out of the software. There are no pre-existing requirements.
There’s more to Agile, though, than sprinting and scrums and backlogs though. If you have a lot of pre-existing code, there is also refactoring. That gets worse as time goes on. It is impossible to make code so perfect that it never needs to be refactored because you will be asked to do things that you were never asked before.
These days we write a lot of code in “open architectures” so that code can be reused more easily, but that doesn’t mean you never come up with better ways of doing things.
We often tell customers that there is a tax to reusing code. That tax is refactoring. It is cheaper than doing it over from scratch. I’ve seen other software organizations flounder because they never explained this to their customers. If all you do is code from one delivery to the next, your code will become a fragmented mess. And if you try to reuse it across projects without refactoring them into a single, united whole, you will just end up with multiple versions of the same code and none compatible with one another.
Then there are code reviews. One of my professor colleagues and co-teachers once told me that, after talking to hiring managers from Google, Facebook, Apple, and the like at a conference, he was told that the #1 quality they wanted in new developers was the ability to write good testcases. In most of these organizations, test case coverage is a requirement to getting code checked into a main codebase. They didn’t care about anything quite so much.
Vision (a.k.a. Saying “No”)
Having a vision for your organization is more important than you would think in a large organization. After all, you might ask, doesn’t the larger org take care of that? Not necessarily.
Every division has a mission and purpose but within that there is a vision, an idea of where you want your organization to be in a few years. You have to be able to say no to people when what they are asking you doesn’t fit with that. Organizations that say yes to everyone find their staff divided, distracted, and discouraged. Their management can’t keep track of everything that is going on. And half the work being done is one-offs that don’t benefit your organization at all. Forget being Agile when you are sprinting on five different projects at once.
There are risks to having a vision. If funders don’t agree with it, you may find yourself unable to pay your staff. It is more work than just always doing what you’re asked to do. On the other hand, it pays off when you become the one-stop-shop for whatever you planned to become. Then nobody can say no to you.
You have to give visions time to mature as well. In our organization, it wasn’t always clear what our vision was. We had a “product” but where that product was going to go after it “hit the shelves” wasn’t clear. We didn’t know at the start that we would pursue machine learning or robotics, which weren’t in our core areas at the start. A lot of our vision was achieved by writing proposals and securing internal R&D funds. As time goes on that vision becomes more clear.
Leadership
Having a strong leadership team is part of the difference between people working as a team and an organization achieving more than the sum of its parts and having a bunch of cats who are occasionally herded together. In a large organization, there are a lot of cats and cat herders. Don’t let your organization be one. Whether it is about process, vision, or just basic tasking, let your organization speak, but then make a decision.
The difference between being a boss and a leader is that leaders suffer down in the trenches with the people who work for them. You have to have almost a servant mentality. You serve your organization and its people by coordinating them.
The leadership team also has to be in sync with one another. If they are constantly sabotaging each other, you are going to end up a fractured organization. Leaders have to have it all: they have to be smart, experienced, conscientious, invested, and have good people skills. They also have to care. They need to care about the people who work for them and about the organization as a whole. A lot of leaders are good, but they only care about one thing. They ignore everything else and leave it on other people’s plates. You can’t be a good leader of people if there’s only one product or project that matters to you. You are better off just being a product/project director in that case.
It’s a Team Effort
Building an organization is a team effort. No company was ever built on the strength of a single person. No matter how much media face time or stock that person has, a crowd stands behind them. In my organization, I was lucky to have several people I could count on from Day 1.