The “Roadmap to a team’s excellence” is (going to be) a series of very opinionated (as everything else here) why, when, how, do and don’t’s to achieve, or at least move towards, fostering an excellent software development team.
The “solution” is as complex as starting to write about it. It needs to take into consideration a plethora of variables and circumstances that are never the same in two different organizations. As such, to go about this, I’m taking a step back and describe the basic steps I would go about to give myself the best fighting chance of having solid grounds to build a solid team on. Consider this an organization’s team audit if you will.
Notice that I’m not saying that this is guaranteed because it isn’t. We’re aiming at the core principles. A team, a company and the world with all its economic, social and cultural trends, are all living and moving organisms crammed in a tight ecosystem that is constantly changing. If one thing is certain, is that there is no such thing as a perfect team, only best attempts to answer the core fundamentals, principles, at any given time & space. It’s a constant and permanent effort to balance the unbalanceable, achieve relative happiness, or when that’s not possible, strive to make “everyone equally unhappy”, as a very wise man once told me.
Disclaimer
From Intern to Director and any role in-between, I’ve done it all. I’ve moved offices, waxed floors, painted walls, scrubbed toilets, designed, developed, tested, hired, fired, sided with HR, fought HR, protected teams, pissed teams off, was the good guy, the bad guy, challenged upper management’s rough decisions but also enforced very unpopular measures across the board. This is what all means.
There are no bragging rights here, but there is an awareness of all levels of an organization and that success is not limited, nor caused, by the excellence of a software team alone. So, unlike most articles out there, this is not a one sided dreamlike exposure of all the perfect circumstances a team must be awarded to make the world a better place. This is acknowledging that a tech team is the make or break of a software-centered business, as is management, sales, marketing, and so forth; and as such, provide down to earth do’s and don’t’s that work on the real world when it comes to solving this very impactful part of an organization.
The Cinderella shoe
Just like in Disney’s Cinderella, one size does not fit all. What the epic leaves out is that the so well fitting shoe will, probably, stop being a perfect fit one day. Either because as pretty as they are, they are not fit for a countryside exploration trek; or perhaps Cinderella’s feet got swollen as she gets older; Or maybe glass is in such high demand in some future that it becomes socially inadequate to walk around in a non Eco-friendly apparel. This dystopian ramble only means to show that it’s more utopian to find and keep that “perfect” team than it is to find a foot to fit Cinderella’s shoe.
Creating and maintaining an excellent software development team is a multifaceted challenge that starts with a deep understanding of the business and its unique context. A product company has a completely different type of needs than a software house, for example. It also attracts different types of profiles, carries different types of short, medium and long term expectations, different types of resources and although, admittedly, there are a lot of overlaps, both are managed in different ways.
The gap between these two is considerable, and we haven’t mentioned other metrics just as relevant as these such as budget, size, structure, culture, etc.
Let’s start to list all things I would take into consideration before starting to map out what type team I’d start to work on, and eventually how.
Budget
Understanding the budget is paramount as it directly affects most of the other considerations. It doesn’t matter what team one is aiming to build if one can’t actually pay for it.
There are immediately two types of budget considerations to make: Total budget and recurring budget. Total budget is usually something we discuss when investing a specific amount in a business. It’s the amount we’re ready to spend before the well runs dry; A recurring budget is usually applied when there is already some form of money coming into the business, being through revenue or other forms of investment. Some times we can have both.
They may seem two sides of the same coin but each brings a set of limitations we need to take into consideration. Just as a one example, let’s assume a 120k total budget VS a 10k/monthly budget for just one simple example:
- With 120k you have the choice between moving really fast and hire decent talent and a small team for a few months through a specialized software-house. In one month you can have a fully functioning, hyper productive team working on your vision, very motivated and eager to get the job done.
- With 10k/monthly your options are very limited. Seniority is probably out of the picture as it will eat up most of the budget and it won’t necessarily move the product faster. Seniority is most valuable in a team context, to mentor and direct other team members into doing the best work possible. 10k won’t get you that much of a team.
On top of that, most seniors would probably not feel inclined to join a less ambitious dream. They would not be living up to their potential nor having the best impact that they could have on a business.
Ultimately, both the how much as the when and how in budgeting matter when deciding which approach one should take when building a team. It’s also not because we can afford a specific team that it automatically makes it the better team for that given scenario.
The considerations and impacts are countless and the exceptions plenty, specially when adding all the other factors to the mix, however, budgeting and how it’s available defines pretty much what is possible and what is not.
Type of Company
There are as many types of companies as there are snowflakes. A company is a whole and every aspect adds up to its style, which means that I will (again) start by stating that there is no One solution for each specific type of company as there is not really a limited amount of types, but there are definitely specific contexts that end up steering some decisions left or right, some of them up or (many times) down.
At the bare minimum I would consider the difference between a Product and a Service oriented company. This could easily be a whole article on its own because the nuances are immense, so I’ll just stick to the basics.
Product and Service are, at the bare minimum, separated by the topic above, budget, in more than one way.
Products tend to have a more predictable revenue model. Classically, clients buy into a product for the long run, and use a service for the short run. Stability and being able to foresee more into the financial future is pure bliss when it comes to making decisions and investments.
Not only that, but (good) products tend to have a more scalable revenue model. A product company with 50 clients and 100 clients can have roughly the same structure and workforce. A service company will most definitely need at least double the workforce to accommodate for double the client size.
But besides the size, what does this mean for a given team’s composition? Everything.
Some basic examples:
- Costs: Some profiles can be too expensive for service-based. The bulk of a service’s workforce is made by people who produce work, who are invoiceable, and said production has both a fixed cost as a charging cost. This means that when you hire someone for a service, you’ll need to know if that person can actually be profitable. Even if one can charge more for a specific resource, is it consistently being done? Is it strategic? Does it add up elsewhere in the team?
- Learning expectations: Two projects are never the same in a service-based company, and this is its most interesting and appealing factor. Within the software fast-paced, ever-changing industry, there is always something new to learn and service-based companies provide ample learning opportunities. It’s the army version of a software team, filled with challenges, life lessons and tremendous growth potential. Some people can thrive in both Product and Service, but most people are only looking for one of these, even though they might not know it.
- Progress expectations: Deeply related with learning, the speed of progress is much higher in a service-based environment (specialization is a whole different thing). Someone eager to earn their stripes fast will prove to be a tremendously motivated coworker in a tougher environment. Someone that is looking for stability is probably going to struggle with adapting to service, whereas product tends to have a slower intensity and churn. Time is usually not as pressing because clients are not buying on the team’s current productivity, they already bought the existing product.
- Career expectations: Great developers are made in the service fire and move on to amazing products to kickstart their retire (quoting myself here), which can take 30 years, and there is absolutely nothing wrong with this. Exactly because services cater to technical growth and products to stability, it seems natural that this is the case. Product profiles expect better salaries, perks, and have higher expectations for long-term career paths and climbing that longer hierarchy tree. Someone who is not ready to settle, will not be a fit for product.
Long story short, one always needs to know the type of company before deciding which profiles are better suited for it, both short and long term.
Maturity
An organization’s overall maturity impacts Product and Service roughly in the same manner. For example, a bootstrapped product start-up can be more chaotic and fast-paced than a decently established service-based company. This is because maturity generally brings stability, within its limitations of course, and opens up to different types of roles and boasts a different type of potential for new hires.
Depending where an organization sits on its evolutionary track, some profiles can be too early or too late to consider. For example, a newly formed software-house can totally hire a bad but very cheap profile to get the job done. I don’t mean junior nor young, I mean a sub-optimal not very long-term promising profile. This happens consciously, all the time. However, once it has a reputation and a solid client base, it’s too late to look away.
The same for a top profile. If the same company reached a point where it already has a solid client base but not a team big enough to justify a Head of Engineering, it will either struggle to hire a candidate that takes this unfitting challenge, or worse, it will hire someone.
Lastly, an organization may be on the verge of stepping up its game and just needs the right team to do it. Referring to the latest example where a company has indeed reached the point where the next step is not hire more developers, but focus on a few lead or management roles to really solidify its core, and bring the best out of every other team member.
Size
We might feel tempted to automatically link size to maturity but this is not really the case. It’s true that nowadays software companies have less and less excuses (and freedom) to do wrong by their employees and boards. Admittedly, there are many things to figure out and opinions to take into consideration but I believe that for the vast majority of the cases we are way past trying to figure out what does and doesn’t work. We can argue what works best on a specific case but we do know what typically works and typically doesn’t. This (typically) makes bigger organizations a safer bet when it comes to being more mature, because they have better budgets, more structure, but it’s hardly always the case. I could name many very big companies that I’ve personally worked with that were an absolute train wreck (but I won’t); and then we can look at 37Signals, the guys behind Bootcamp, as an example of a very effective, mature but small rather organization.
So if not as a sign of maturity, why is size important? Size severely impacts the organizational structure of a team, and that’s what will eventually lead to stability and open up to maturity.
Do the teams need to be bigger? How many PMs or POs does a company need? When is it time to opt for a Head of Product? All of these a much more have to do with size, but the worst questions are the ones that start with “Do we have too many…” as these sometimes mean three things: Extra costs, bad decisions, tough choices.
Again, it’s not about the team you can have, it’s about the team your business should have.
Location and Culture
One of the first things we need to think about when creating a team is location and culture. These used to be a lot more intertwined than they are today, specially in the case of software companies as they are the role model for remote work. With the boost of this trend more and more companies have a global mindset and approach to culture, each having their own “quirks”. Regardless, both location or culture are a make or break for many people.
The choice of having on-site, hybrid or full remote teams has a huge impact on how you go about creating it. This alone opens up the following obvious considerations:
On site / hybrid
- What does this say about trust, culture and embracing of modernization?
- Are we risking filtering out specific type of profiles by doing this?
- Is there only one office or multiple offices?
- Is there a factual advantage to creating teams around the same office, or can we split teams between offices?
- Does any form of management need to be on site for teams or can these be managed remotely
Remote
- Which countries and time-zones are permitted or favored?
- Is there a factual advantage to creating teams around the same culture and language, or can we split teams between countries?
- How is hiring budget affected by location choices?
- What other roles do we need to invest in to make sure the remote work does not affect productivity, communication and overall deliverables?
Based on these questions and their answers we will know, and hopefully influence for the better, the limitations we should have when thinking about a team structure and its costs. I keep mentioning costs because this is, again, a huge factor when taking the teams globally, as production costs are not spread equally around the world.
Short and long-term plans
Most of the topics above answer the “what company are we now” and obviously the “what do we need now”, but do little to answer “which company do we want to be” and “what do we need to get there”. Also, all of the topics above affect to which extent an organization can even think and act on this, still, it’s a very important vision all companies should have very clear in their minds.
Stack & skills
And only now we’ve gotten to the stack an skills part of the mix. This is pretty self evident and explanatory. It’s both limited as driven by all the other aspects mentioned above. As obvious as it is, it’s still lacking a few considerations, like:
- How secure and locked are we to a specific stack? We might want to consider, or not, a benefit to have more experience outside of our comfort zone, if that is useful.
- How often/fast do we expect to be able to (have budget for) pivoting to newer technologies? This cold mean we need to find people with solid service based experience, for example, to tackle the unknown, eventually. This is also impacted by the long-term planning, of course.
- How do we value knowledge in our current stack? One of the best things a team can hire for is potential and that usually means being more lenient on immediate hands-on skills, but that can pay off greatly in the future. This also means we need a slightly bigger structure to accommodate time and budget to nurture these roles.
- What is the best balance of seniority for the teams and organization? This depends on size, budget, short and long-term plans.
Etc. Many more can be asked, specially when combining the long list of considerations I’ve laid out so far. It’s easy to see how complex setting up a team can be, but at the same time, how easy it is to undermine all of these things and how hard it is to keep all of these in “perfect” condition at all times.
Once we’ve achieved the first step which is deciding what team(s) we want to create, then the real work starts: Creating it, fostering it, and making sure all of these variables are kept in sync (which they will never be) just to have one piece of the business puzzle under relative control, and gearing towards success instead of slowing it down.