Scaling Pain (Questions)

I wrote about Scaling Pains a couple of months ago. It’s a post that goes into detail about challenges that companies face when growing - it’s a warning sign about hiring too many people. The style of the post follows closely the mentor approach. As of someone that went through those pains themselves and is now sharing it with someone else. I would rather do a different exercise today.

The coaching approach creates the right environment for the receiver to reach an answer by themselves - rather than someone telling them what’s what. It’s the act of asking and pondering about a question. But this mental exercise is done by the person being coached. The coach acts as a guiding line and shouldn’t interfere too much in the thought process. The questions truly are more important than the answers.

I am still targeting small to medium companies. I don’t feel I can offer much with big tech:

1. Why are we hiring?
   1. Is it because we are not going fast enough? And if so, compared what or to whom?
   2. Is it because our customers are demanding more features than we can cope with? If so, are we really doing a good job at prioritising? Are all customers equality important? Is there an overlap, or root mechanism that underlies these features?
   3. Is it because the existing team is unproductive? If so, is it because of technical debt? Or is it because of human reasons? Or both? What are we doing to address these problems?
   4. Are there external pressures pushing us to hire more? And if so which ones and why?
2. How long would it take to onboard someone?
   1. Do we have any guides, or checklists ready?
   2. How can we make it faster?
   3. Are we willing to have another engineer to go slower, until the new joiner is up-to-speed? Can we afford that in the short-term?
3. What’s the level we are hiring for?
   1. Is it a junior? If so, are we prepared to up-skill them for likely months? Do we have the necessary conditions to make this happen successfully?
   2. Is it a senior? If so, is adding one more senior in a team already filled with experienced people the right move? Senior engineers like to mentor less experienced people, so it might be a good way to keep them engaged with their work.
   3. Is it a staff? If so, would they be the only staff in the team? How would the existing senior engineers react to that?
4. What’s the impact on our runway?
5. Will it require a change in our software development processes?
   1. We can keep things simple and organise work for 3 or 4 people, but if we double the team, we likely need a dedicated person for this. Are we thinking about that?
   2. What about the communication? Are our existing ways of communicating with each other ready for 3 or 4 more people? Likely having quick calls with 2 or 3 engineers work, but with 4 or 7 it won’t. How do we make sure information is shared across everyone? And how do we make sure that everyone can contribute to the decisions?
6. To whom will they report to?
   1. Do we have an existing Engineering Manager that has the capacity to do it? If not, are we ok to be in a place where we hire engineers, before their manager? Should we hire the manager first and then task them to hire the engineers? If we are not hiring a manager, do we risk a situation where people are not receiving meaningful guidance from whoever is managing them?

I am certain that I will add more questions to this list. In the meantime, answering these questions, by yourself, and thinking through the answers will likely reveal concealed alternatives you haven’t considered.