You’re an engineer who’s got big ideas with team-wide potential – but there’s a limit to how much you can achieve by coding harder.
Translating your ideas into impact means finding ways to influence others. Luckily, you don’t need to be in a position of authority to scale yourself across a team, organization, or even an entire company. All you need is a strong idea, the energy to drive it, and the right pattern for the situation.
Scaling via people
The first three patterns we’ll look at involve bringing people together in some form. If this isn’t something your team regularly does, or if it’s unfamiliar territory for you, it’s best to start small and concrete. A tiny idea executed well has a bigger impact than an ambitious idea that goes nowhere, and you’ll usually learn something along the way that gives you insight into how to handle more challenging ideas.
The working group
- What this looks like: A voluntary, temporary group of people interested in supporting your idea who devote part of their time to work towards a specific goal.
- Example: You’re interested in whether the team should change cloud providers, so you recruit a working group to evaluate alternatives and propose a path forward.
The key to a successful working group is to create a collaborative space for people who are all interested in your idea. This doesn’t mean you need to have a lot of experience running meetings – your biggest contribution could be the act of creating this group and setting the overall direction.
However, it’s easy for working groups to become all talk and no execution, so decide upfront what the output of the group will be. If you think it will be hard to keep everyone on track, you can recruit someone who’s good at doing just that, such as a program manager.
If the concept of working groups is new to your team, make sure that all members are on the same page about the group’s focus, the expected involvement, and when the group will disband. Since working groups are extra commitments on top of people’s day-to-day responsibilities, having an end in sight is important so that folks don’t take on too much for too long. Knowing the group is temporary also challenges you to find a long-term home for its output. For example, a working group that produces documentation also has to find an owner to make sure the documentation stays updated in future.
The special interest group
- What this looks like: A permanent group of people who meet to discuss a shared topic of interest. This can be within your team, or organization-wide.
- Example: You are interested in the latest developments in AI, and start a reading club to discuss scientific papers on a monthly basis.
Creating an interest-based group can be a powerful way to spread your own knowledge and passion for a subject. You can lead a group as an expert, where you teach others about your topic, potentially evangelizing your team’s work across the company. Alternatively, you can chair a study group to learn along with your peers, bringing new ideas back to your team. Whether your focus is technical or otherwise, creating a culture of curiosity can have a big impact on your team.
Unlike the working group, there’s no expectation that this group produce any output or results. Instead, the focus is on the cross-pollination of ideas and the sharing of knowledge. Sometimes the topic under discussion will produce ideas for action, but these are taken up in normal work channels, such as being added to product backlogs. Because of this, the time commitment and meeting frequency are expected to be low.
Running this kind of group for a long time can get tiring, so consider having other people lead meetings rather than chairing them all yourself, and invite new members on a regular basis to keep the group lively.
The stewardship group
- What this looks like: A long-lived group that meets regularly to discuss and advance something under shared ownership.
- Example: Your organization has multiple teams all using the same core libraries, which are not owned by any one team. You start a stewardship group where contributors to these libraries can discuss and plan changes.
No matter how your team is organized, there are cross-cutting topics that need ownership. Coding standards, shared components, and cultural practices often fall into this category. You can create a permanent group to actively steward these topics, bringing members together from different teams and roles. These groups often start with great enthusiasm, but can lose momentum as members juggle their day-to-day responsibilities with the extra work generated by the group.
This type of group can often benefit from a strong facilitator – this person doesn’t have to be you. Start the group with the expectation that individuals will pick up items from your discussions and follow through on them – and hold them accountable to it. Because of this additional workload, people can burn out over time, so pick a timeline to rotate member responsibilities. Six months per person tends to work well.
Scaling via work
Scaling yourself doesn’t always mean bringing a group of people together; it can mean influencing the entire team’s work by changing how they work. There are two steps to this process: proposing the change, then implementing it.
Proposing the change often starts with you writing a design document and then getting others to agree that this is a good idea. This can also result in the formation of a working group – having more people involved at the creation stage can make it easier for others to agree to adopt it. However, a document alone doesn’t change much, even with the best intentions. The next two patterns are about implementing that document in the work systems you use every day.
Technical automation
- What this looks like: Changing the way your team works by automating a step in the development process.
- Example: You’ve noticed inconsistencies in your team’s codebase. You create a coding standards guide, get buy-in, and implement pre-submit checks to ensure all new commits meet these standards.
Automation is a handy way to scale yourself – your ideas become part of the fabric of how work gets done, and you can have a lasting impact with only a small amount of technical work. However, it’s also easy to get caught up in the implementation details and lose sight of the bigger picture. Stay focused on the “why” behind the change, and test it out with the people it will affect.
While you can do the technical work for this on your own, it’s still important to get the rest of your team on the same page about the value of the work, and what impact it will have on their day-to-day. If there is potential for disagreement, test out the change first – for example, doing the job manually before automating it, or starting with a smaller scope before rolling it out to the whole team.
Creating work systems
- What this looks like: Introducing a change to the way your team plans work, executes, makes decisions, collaborates, or communicates.
- Example: You have noticed a lot of build instability that the same few people triage, so you propose a new role of “build captain”, making someone responsible for looking into build failures every week.
As an engineer, creating automation is probably in your comfort zone, but you might have more impact if you look at how your team works as a whole. Can you improve how you communicate, launch, triage or hire? Think about how you can make your change the default path forward so that it’s harder for people to not behave in the new way. What are they already doing, and how can you slot into that?
When implementing a work system change, consider whose help you will need and who owns the processes involved. Get their input at the design doc stage, and collaborate with them on a plan for rolling the idea out.
As non-technical changes often have a lot of different potential implementations, you can get caught up in bike-shedding. One way to cut through this debate is with concrete results – is there a smaller part of the idea that you can implement that will help inform your decision-making?
For example, if you want to propose a new way of interviewing at your company, you could test it on your team first. If the change is reversible, you can also cut through indecision by setting a checkpoint where you decide whether or not to continue with it. This also requires you to come up with a way of measuring whether or not the change is successful.
Final thoughts
We’ve looked at ways to scale your ideas by both bringing people together and implementing systems. While these can seem like opposites, systems are often most successful when built in collaboration with a group of people who care, so try combining the two for the greatest effect.
Next time you find yourself saying “We should…”, take a moment to reframe that thought. What is the end goal you’d like to achieve, and more importantly, how can you get others to come on that journey with you?
