Should I join a newly formed software engineering team?
--
In software engineering, we’re often thinking of old and new systems, the projects that exist and the ones that don’t. Each requires its own level of dedication. Newly formed software engineering teams come to own both greenfield and brownfield projects.
This topic of being new or old is a challenge for software teams every day. And when evaluating a software team, these projects can make or break your career trajectory. This post shares some insights into the pros and cons of joining a new software engineering team.
What are greenfield and brownfield projects?
Greenfield projects are newly made, no development has been done in the past, and teams get to start on untouched green grass. This is an analogy to construction, where there is “no need to work within the constraints of existing building or infrastructure.” Brownfield projects are existing projects and systems. They require maintenance, enhancements, and other optimizations.
One is not necessarily better than the other for careers or teams. It just depends on the nature of the systems and what you prefer. Starting a new project requires much dedication and can be disruptive. There are fewer constraints and fewer system dependencies to consider in greenfield projects, so you get more options. In brownfield projects, engineers identify system flaws or implementation errors and refactor these potentially complex systems by navigating dependencies and side effects. If there are domain or business functions within the system, engineers must understand the impacts and dependencies.
Neither is trivial and requires a different set of skills.
Evaluating New Teams
Here are some questions to ask to understand and evaluate newly formed teams.
What is the makeup of the team?
The team you start with is essential. Could you trust your team members? Can you work with them? Ask how many people are on the team, how long they have been with the company, and what is their background?
It would be best to get to know the members as much as possible when interviewing or evaluating a newly formed team. Newly formed teams don’t have the luxury of time for personal or petty conflict. There are too many unknowns for that. Team members need quickly and effectively share feedback and resolve conflict.
There is interest and support for these teams to get started and report progress early on. This momentum gives many people project experience they often would not otherwise have. To make the most out of joining a new team, you want to evaluate the team’s level of expertise. Will anyone on the team be a mentor, friend, or coach? Will they provide feedback and review of work? Is that even important? It’s helpful not being the only “engineer” or role on a team or even the only two of anything.
Who is leading the team?
I’ve also seen new teams dissolved because the leadership at a company is still deciding who will be part of the team, including the manager.
Leadership is critical in the early stages of forming a new team. Team leads that don’t understand the nature of the work, the personnel, or the business run the risk of building teams that fail. Conversely, they may fail to take action on what is needed to succeed. They should have the skills to bring team members together through a common purpose, mission, and vision. But also have the skills to advocate for the team and secure necessary resourcing from team stakeholders.
So a certain level of skill is needed to understand the work and the business of being a team lead. Ask managers what they’re doing to ensure people have clearly defined roles, responsibilities, and scope of work needed to succeed. Managers who show strong leadership and clarity when asked questions about the team tend to take responsibility for the success of a newly formed team.
What would I be expected to do in my role here?
Teams without a clear mission agree to do the wrong work or all of the work. As a result, they increase the scope of projects and teamwork, and they hire the wrong people. Ask questions about the work at hand and how the team may change or grow in the next year.
Career opportunities take you forward, backward, or nowhere. So it’s important to know if there are opportunities to grow. While we can’t always pick our work, we can identify periods of growth and development of new or existing skills. While we can also e can rely on others in the team, it’s important to have the autonomy to take a path that will lead you to where you want to be.
Should I join a newly formed software engineering team?
Career alignment is doing the right work, for the right reasons, with the right people. If you’re not uncomfortable with any answers or insights shared by the team, evaluate whether those were preferences that are must-haves or nice to have. If making a career decision puts you at a disadvantage there may be other opportunities that will not impact your situation as drastically. Everyone has preferences, where, how, and when they work and what they work on. Make decisions from that.
Concluding Thoughts
This blog post shared some more insight into newly formed software engineering teams. It’s fine not to know all the unknowns, but it’s important to have the skills to navigate them. These questions I shared help you evaluate the potential of a newly formed team, which is difficult to learn through an interview process. Although many interviewers will describe newly formed teams as experimental or “learning as they go,” it’s not an excuse to do the work needed to succeed. And one day, these teams won’t be considered “new.”
Specialized, first of a kind, or unique teams in an organization magnify new team risks. If you’ll be joining any of these specific teams, take time to ask questions or even look on Linkedin and message one or two people to ask how it’s like working at the company or particular team you are interviewing. Most times, recruiters can work with you to chat with additional team members before you have to make a career decision.
I hope this helps anyone looking at newly formed teams.
From my experience, joining a green field project or team is not the safest decision to make as a more entry-level software engineer. However, I’ve seen skillfully managed and built greenfield teams to nurture and amplify potential that doesn’t get as amplified in more stable teams that solely own brownfield projects and opportunities. I’ll talk about inherited work, teams, and what I’ve learned about both brownfield and greenfield development in the next blog posts. See you all soon!
