There are two classic stereotypes of software groups that most developers are familiar with. On the left you have the small start-up team with 5-10 engineers all slaving away and working together to overcome that 6 month deadline you have before your competition comes out with your new idea, or worse, the coffers run dry. On the right you have the corporate goliaths with 47 levels of middle management and engineering groups in 23 countries all following multi-year feature release schedules with documentation and specs that rival War and Peace. During a conversation between two engineers, if one of them mentions that terrible start-up that worked them to death, or the huge tech firm where they worked on a project for 5 years and reported to 9 managers, the other engineer can nod and say; "Boy, I know what you mean... that's why I could never work at that sort of company."
Both of these companies have issues (And plenty of them). At the small start-ups you know what you are in for, and the same holds true at the IBM’s and Microsoft’s of the world. Really, regardless of if you’re a junior developer or a VP of Engineering; you just have to figure out what environment you work best in. Strategies for building a cohesive engineering team that generates quality software can be very different at the two. There are great books and blogs that go into many of these strategies, and even a few ideas that work in both environments. However, what seems to be the hardest to figure out are good strategies for all the companies in between. What happens when your small start-up starts to become not so small?
Once a software group reaches 30-50 people you start to enter a dangerous area. Some companies expand and think they need to transition to the "big" model. They quickly higher more managers and before you know it there is a manager for ever 3 people, every engineer has 5 status reports to complete each week, and productivity grinds to a halt. Just as bad are the companies that don’t bring in good leadership and have 50 people all running around with a start-up mentality and interfacing between each team becomes a nightmare. During this growth period you also run the risk of loosing the people that think the company is moving away from the start-up they love and transitioning into the Office Spaces of the world. To get through this you are going to have to figure out what works best for your software group. Different tactics are going to work better at different places, but in general here are a few of the things I have noticed.
- If you have good existing senior engineers and managers that are willing to stick with the company as it gets bigger, make sure they work well as a team. If they don't, it will be a disaster. As new engineers join the different teams they will soon pick up on the conflicts and cliques and division will only get worse.
- Don't outsource. One of the worst things you can do as a department grows is solidify the fact your company is turning into a cold corporate giant where money reigns supreme. Transitioning is already difficult enough without hallway rumors that John's team is next to go, or all of support just packed their bags. Also, early on this will not save your company money. Companies of this size don’t have the manpower to dedicate to the time that goes into managing an off shore team. So you either increase your salary expenses bringing people in that are specifically hired to help manage off shore or you dig into developer time to manage it. Either way is not free, and most likely it will only lower your productivity.
- Be careful with the Architecture Astronauts. If you have senior engineers who already love the 6 month R&D projects that never go anywhere and have been with the company for so long that people aren't even sure who they report to, it's only going to get worse.
- If you are a manager, take the time to compliment other team members (the old, the new, and especially the ones not on your team). It could be as simple as, "I saw that check-in you did last night, nice work!" It's the easiest thing in the world and it makes your coworkers feel connected. As your department continues to grow this really helps the teams feel connected.
- Train the people you want to see move up the ladder. Don't grab the member of a team who has been with the company the longest and throw him into management. If you don't have to time or resources to train them, you are solving a temporary need with a long term disaster. When that person is totally overwhelmed and their team is 6 weeks behind schedule you can see why management by lottery has never worked.
I equate this period to the software department's version of Crossing the Chasm. You need to keep cohesion as you expand. If you pile on the bureaucracy and corporate attitude you might get a big surprise when productivity slows and so does the economy. Suddenly, you have a 15% work force reduction and now you are back to the small team, except with big company red tape. Likewise, you can't continue the fly-by-night coding and no bug tracking and pray the CEO isn't upset when you try to explain not having enough manpower for that next new huge project despite all the new hires. Work slowly at it, and you will find you will keep the good people, even some of the ones that mourn the days when everyone worked out of the coffee shop downstairs.
