Using AI for customer service in your company is a definite method to save time and money. If you’re like most business owners, you’re constantly searching for fresh, creative ways to improve your enterprise. We’re here to inform you that improving AI customer service is a simple and rapid win.
If you have a team of software engineers and want to move them to Mac, you will need to consider a number of things before you do so.
With the war and untold tragedy unfolding in Ukraine, a lot of software companies are helping to make a difference, not just with donations, but by hiring Ukrainian developers, too. In some cases, a LOT of them. One of the questions we’ve received a couple of times in recent weeks has been, “How can we add a lot of developers fast?” This is also relevant to any rapid growth company. While we’ve covered team scaling in the past, we haven’t covered this kind of scenario in as much depth as it deserves.
Most of our blog is a team endeavor and credited to the Gitential Team. It’s my personal preference to not be so public, but it is appropriate in this case to note that I am a US citizen living in Odesa, Ukraine, on the Black Sea, as a permanent resident. I’ve lived here 17 years, moving here straight after serving a 15-month contract in Iraq for EG&G and LSI. There, I served as a civilian contractor in logistics alongside the US Marines at Al Taqaddum and later as the promotions coordinator at our PMO in Camp Anaconda.
Since then, I’ve worked alongside a number of Ukrainian software teams and at the end will share what you can expect from Ukrainian developers and considerations on working with them, whether in a centralized or remote environment. Concurrently, in Iraq, though only a small portion of our personnel consisted of IT staff, it was a massive and rapid mobilization – going from nearly scratch to supporting ~1500 personnel across 28 camps in less than a year. It wasn’t always smooth sailing… for that matter, there wasn’t a whole lot of water around.
In World War II, both the German and American armies massively, rapidly, and efficiently scaled up their armed forces relying on the Rule of Thirds. Before WW2 started, the German Wehrmacht expanded from ~100k troops in 1935 to 3.7 million in 1939. The US Army exploded from 270,000 troops in 1940 to almost 1.5 million in 1941. That counts only the initial mobilization, millions more followed.
In essence, the personnel from one unit would serve as the cadre for three units. A unit would train for 4-6 months. As the training was completed, the process was repeated. One unit provided the “core cadre” for nine units. The training set the stage for privates to be promoted as sergeants and lieutenants to become captains, and so forth. And all of this was done without the benefit of advanced analytics, or even MS Excel.
So, in a similar fashion, one software development team can expand into nine teams in a year – and still retain a reasonable level of efficiency. Analytics and AI can help to make the process if not go faster, certainly much smoother. Leastwise, even the fastest-growing companies will only be engaged in hiring hundreds of developers; not hundreds of thousands of developers.
Scaling is a function of your number of original teams, team member roles and experience, team size, training period, and funding. Agile software development teams have an industry average of ~7 members each, broadly varying from three to nine. The reasons for this tie into issues of efficiency as we’ve discussed in Team Organization regarding the Ringelmann Effect and Metcalfe’s Law.
One of the main points here is balancing cost and performance. Smaller teams (3-4) are more efficient but tend to cost more than larger teams, while the latter are inherently less efficient. When budget is not an issue, finding developers with the specific skills needed often is. The Ringelmann Effect advises (it’s not a law per se) that larger teams don’t equate to greater productivity.
Having the right ratio of people in each role is also important for a smooth workflow, but this varies according to the nature of each project. Team organization varies quite widely, but to simplify, their roles consist of project managers, engineering managers, and software developers, augmented with business analysts, designers, other specialists, and sometimes QA technicians. In many teams, QA is largely the responsibility of developers.
By sticking to Agile principles, we can get some useful numbers to balance cost and performance when planning to rapidly scale up your company.
| Maximum Efficiency | Optimal Cost and Performance | Maximum Capacity | |
| Project Manager | 3-4 projects | 7 projects | 9 projects |
| Engineering Manager and Team Leads | 3-4 direct reports | 7 direct reports | 9 direct reports |
| Business Analysts, Designers, and Other Specialists* | 3-4 teams | Very situational, but it’s rare for companies to have less than 1 designer for every 50 developers. The usual ratio is about 1:10. | |
| * Other specialists can include ML/AI, Data Scientists, QA Technicians, etc. not otherwise part of a dedicated team. | |||
A “typical” engineering manager’s direct reports might include 3-4 team leads, 1 business analyst, 1 designer, and 1-2 specialists (perhaps a data scientist and a QA team lead).
The normal hiring and vetting process can take a lot of time – reviewing resumes, conducting interviews, onboarding, and everything that goes with that. When hiring developers en masse, you have a decision to make – hire them one at a time as fast as you can process them, or hire in waves with common start dates.
Hiring many developers and giving them the earliest possible start dates may be easier to support initially alongside your regular daily tasks. But, doing this adds an enormous amount of long-term complexity in constantly having to shift onboarding efforts, sprint planning, assigning mentors, when to conduct one-on-ones and performance evaluations, and so forth.
Developers like stable teams and environments, the less chaos and disruption the better. Each developer added to an existing team can substantially alter sprint planning, team dynamics, and performance. The chaos typical to a high-growth startup, as we’ve covered previously, can easily push turnover to 25+% per year. That’s likely to be much lower for Ukrainian developers though. Still, this warns against large-scale ad hoc hiring beyond mission-critical expertise.
Staging the hiring and onboarding process on a predetermined schedule dramatically simplifies the effort. It’s not as personal, it can appear like an “assembly line” – but you can more easily compensate for this after each team is formed. It’s not just a matter of getting everyone started, but how you get everyone started.
The goal is to help your teams and developers steadily improve so they can deliver your project according to specifications, on time, and on budget. That’s really hard to do when your team is constantly changing.
It can take 3-6 months for a developer to come up to speed on a new codebase depending on project complexity and how well they are supported. The 90-day review for new hires is a good evaluation point to assess how well everyone is doing, how well they work together, and to identify candidates for your next wave of team leads. Your new prospective team leads will need additional training, discussed below, which could take an extra month.
Though possible, it’s generally difficult to imagine retaining a reasonable level of efficiency with a team expansion cycle time of less than ~4 months. It’s also hard to imagine a company going from 1 to 27 teams in a year just on the basis of funding levels. Even then, developers are in a shorter supply than funding. But, stranger things have happened – the past two years being a bundle of good examples.
Here’s how this kind of rapid expansion might look:
| Original Team Size | 1st Cycle – 3 Teams | 2nd Cycle – 9 Teams | Optional 3rd Cycle – 27 Teams |
| 3-5 | 9-15 | 27-45 | 81-135 |
| 6-8 | 18-24 | 54-72 | 162-216 |
| 9+ | 27+ | 81+ | 243+ |
Expanding rapidly bears a number of challenges, especially in today’s remote work environment. In Iraq when we were starting from scratch – without even an HR manual and everyone making up answers, initial turnover was running over 60% on just 3 months in the country for a one-year contract (coinciding with everyone’s first vacation). This owed largely to inconsistent, conflicting, and constantly changing policies complicated further by an initial lack of managerial training and a common set of administrative standards.
Contract hopping was a big issue then and remains an issue as all software developers are in high demand and regularly approached by recruiters. It’s such an issue that Apple recently gave large retention bonuses to keep Meta from pilfering them. That’s just one of many challenges to keep an eye on – but there are plenty of things you can do to create a smooth(er) transition for everyone. Here are a few.
Challenge |
Remedies |
| Mitigating High Turnover |
|
| Internal Promotions |
|
| “Right” Team Size and Mix |
|
| Learning the Codebase and Coding Standards |
|
| High Code Complexity |
|
| Validate Skills and Identify High Performers |
|
Before your onboarding process begins, it’s important to review your existing developers and team leads for promotion as team leads and engineering managers, respectively. It’s important to verify with each individual if this is a promotion they want as these involve less coding, favor people skills, and can often change the trajectory of their career path.
There are several benefits to gain by promoting from within.
What can be said here also extends, at least in part, to software engineering managers. Team leads are likely to spend much less of their time coding and managers may spend little or no time coding. Both will need more people, leadership, and administrative skills.
Developers on most teams will already have exposure to a lot of the routine – sprint planning, daily standups, retrospectives, one-on-one meetings, use of project management software (like JIRA), and the like. Instead of being a participant though, they’ll be responsible for planning, leading, and managing these activities. That can be a bit different, but shouldn’t be a huge leap. Your original team leads and engineering managers should provide tips, training, and an overwatch role until the newly promoted feel comfortable in their role.
Developers routinely work on complex tasks, but they will need to pick up some HR training. Easy peasy! This extends to validating timesheets, approving and processing vacations and sick days, proper reporting, time management, awareness of company policies and benefits programs, how to handle disciplinary issues, and the like. Most of this is pretty easy, suffice that telling a developer she can’t take the vacation time she submitted a month ago because her expertise is needed to meet the release schedule – yeah, that’s not going to go over well.
Identifying software delivery challenges and how to resolve them is a more complex function for team leads and managers. The AI-Assistant that Gitential is developing can greatly assist all stakeholders in software development – from Executives and BI Analysts to Engineering Managers and Team Leads.
When scaling up rapidly, an AI-Assistant provides invaluable help in simplifying and easing the landing for newly promoted team leads and managers:
Normally, it’s hard to paint an entire country of people with a single broad stroke, but as we’ve seen in the news, Ukrainians make that easy. Ukrainians are polite, diligent, have an excellent work ethic, and tend to not be very dramatic about small shit. There may be some exceptions, but they’re few in number. There’s a lot more to know about Ukrainians though:
Scaling up fast is a complex effort in any situation. The numerous links referenced offer additional guidance for scaling, managing, and improving the performance of software development teams. Our strongest recommendation is to make the effort to properly plan to scale efforts on a scheduled basis. Whether you intend to hire 20 or 200 new developers, it’s worth starting the onboarding process either on the same day or in waves. Exceptions extend to rapidly onboarding developers with mission-critical expertise. Otherwise, chaos is categorically the worst thing for software development teams.
Our thoughts and prayers continue for all Ukrainians. Everyone at Gitential holds zero doubt that Ukraine will prevail, and in an epic heroic fashion as it has already. This should never have happened and we earnestly hope this War ends soon. And, a nice shout out to Anonymous for their efforts to pierce the Iron Curtain to help show “them” what’s really happening.
Published: March 23, 2022
Using AI for customer service in your company is a definite method to save time and money. If you’re like most business owners, you’re constantly searching for fresh, creative ways to improve your enterprise. We’re here to inform you that improving AI customer service is a simple and rapid win.
If you have a team of software engineers and want to move them to Mac, you will need to consider a number of things before you do so.
Here’s what’s new in our January 2023 Release Notes:
* Tables Columns Sorting Improved
* Reconcile Commits Count Between KPI Card and the Table
* Efficiency Tab Improvements and Efficiency KPI Cards Align
