Everything I learned about improving processes when I went from developer to product lead

Posted by: Adam Lynch /

Adam Lynch, who’s currently leading the development of a new product at Teamwork (what is it, you ask? We can’t say just yet!), shares some of the biggest lessons he’s learned in his time as a product lead.

Last time: managing people. In this post: improving your team’s processes.


In the last post, I wrote about what I’ve learned from working with people.

As I mentioned last time, the product lead role is people-oriented. But it’s also about maximizing the abilities of those people with better processes and systems.

Here are a few things I’ve learned about developing — and improving — workflows that actually help your team.

On process:

Don’t go overboard on process at the beginning. Set as few rules as possible and strive for minimal viable bureaucracy. My advice is to start small, experiment, and keep what works. Make it clear that the process is evolving and can always be improved with a suggestion from a team member.

Team members’ past experiences and opinions on what works will vary a lot. Each team is different, and what works for one combination of people might not work for another. Doing it this way lets you discover the best processes for your actual team, not your hypothetical one.

Agile coach and technology consultant Dan North has a great outlook on this: “You shouldn’t start with the Spotify model. Spotify didn’t start with the Spotify model. You shouldn’t start with Scrum. Scrum didn’t start with Scrum. You should start by identifying what you want to improve, and introduce constraints that force the improvement.”

I recommend doing daily standups; they’re really good when done properly. Your standup should ideally be at the same time every day, as early as possible. If everyone is in the same location, actually stand (otherwise people tend to talk for too long). If one person is remote, everyone should connect to the video call separately and ensure sound quality is good. If someone’s late without notice or can’t make it, start without them.

Implement some basic ground rules for your standups:

  • Listen to each other, otherwise there isn’t much point.
  • People shouldn’t go into too much detail or interject when others are talking.
  • If a discussion needs to happen, finish the standup first, then anyone can stay for the discussion if they want.
  • Basically, keep it short and efficient.

You should also make sure to schedule a regular chat with each team member individually. Give them a chance to highlight successes or issues. This could be related to code, colleagues, your leadership, the company, their personal life, whatever. Listen and empathize. Make sure you’re up to speed on the work beforehand; these chats should be about them, not a status update for you. These conversations are really good; you’ll be surprised by what comes up or how honest people will be.

On efficiency:

Always look for ways to make your team’s life easier so they can do their best work. Reduce friction. Shield them from company politics, pointless meetings, and other unnecessary distractions. Resolve disagreements.

Emphasize knowledge sharing. Avoid someone fixing bugs related to X because they implemented X originally. Single points of failure are hard to avoid. People love to own their work. Taking responsibility is good but often leads to one person holding exclusive knowledge of something. Give someone territory and they’ll likely become defensive. Instead, focus on getting to a point where everyone can learn from each other and get their best possible work done.

Keep an ear to the ground. Too much talk within the team might indicate a lack of productivity, decision-making, or that they’re not being challenged. If it’s a bit too quiet, it might mean there’s not a lot of collaboration happening and there’ll be problems once their code is integrated, or that people might not be getting along.

On coding:

Even though the role is certainly people-oriented, people do come and go; what we build remains.

You might be used to coming up with elegant solutions to clear problems as a developer, but you will now have to resolve hazy problems with far reaching solutions. Focus on the long term when it comes to a design decision. Is this solution advancing us towards our overall goals? Is it compatible with foreseeable future changes? You don’t want to make a decision that makes it more difficult to make changes or add features later. Strongly consider long-term maintainability, architecture, deployment, stability, availability, scalability, and so on. Think about the whole ecosystem of apps and alignment.

It’s important to still be hands-on with code. Some lessons can only be learned this way. Keep in touch and stay up to date. Identify patterns over time and keep an eye out for anyone implementing a pattern which’ll come back to haunt you. But be careful when dropping the team lead role to play full-time developer, as other unnoticed issues might bubble up until they’re too big to solve quickly.

In general, I’d promote test-driven development, as well as continuous integration, deployment, and delivery. Check out Steve Smith’s Measuring Continuous Delivery talk if you haven’t seen it. You should also measure app performance, feature usage, and so on. Don’t go overboard but carefully select a few key metrics to begin with.

Let the team influence code style. I absolutely hate arguments over code style, like tabs vs spaces. Discuss as a team and agree, but keep it short. Document the outcome. It shouldn’t be acceptable to argue about it in pull requests; code either matches the code style or not. Plan a separate time to discuss a change to the code style if needed. Where possible, use linting tools which automatically formats code as it’s written or pre-commit (like Prettier).

Monitor gaps in the team’s knowledge and fill them. If a new developer joins the team with valuable insights or coding style, re-align the team to integrate that.

It’s easy to get sucked into the current work and dragged into the weeds, but try to stay ahead of the team. Look at what’s coming down the line, anticipate problems, find solutions, and prototype. Steer the technical direction based on these discoveries. This, like everything else, is a lot of easier once you have great team members who you trust.

This post was originally published on adamlynch.com and has been edited for the Teamwork blog. Thanks for letting us share your tips, Adam!

Do you have any tips on developing solid processes for your team? We’d love to hear them. Let us know in the comments.

enterprise

Keep your projects on track with Teamwork

Streamline. Connect. Collaborate.

One account works for all Teamwork apps. Have an account? Sign in here.
    

Adam Lynch
Product lead of Teamwork CRM

One Comment

Angela Mosier

Great read! I couldn’t agree more. When I transitioned to lead, I went through a similar learning and experimentation period. I felt I knew what didn’t work and was eager to find new processes that worked both for management as well as the developers.

Can’t wait to hear about your new project. So far I love everything that Teamwork has done. I know it’s helped our processes.

Reply

Leave a Reply

Your email address will not be published. Required fields are marked *