#teambuilding
12 posts

Being a great engineering mentor

Be ready to listen. Your mentee should always feel free to ask you questions, especially in the first few weeks of onboarding.
Read more

Being a great engineering mentor

  • Be ready to listen. Your mentee should always feel free to ask you questions, especially in the first few weeks of onboarding.
  • Help anchor them socially in the new place. If possible, carve out a weekly team ritual.
  • Let them feel safe enough to pursue novel solutions by showing them how to evaluate risks within the context of your organization and team.
  • Explicitly inform your mentee of technical safeguards in place as well as providing non-technical assurance of help with failures.
  • Understand their strengths and weaknesses, and encourage as well as challenge them technically with tasks that let them level up while having fun, gradually adding more unfamiliar or challenging jobs. Offer code hints but don’t unnecessarily prime them with warnings of difficulties ahead, and occasionally add stretch goals and praise their resolution to build confidence.
  • Have 1-on-1 discussions and reinforce when you notice they are doing a great job while challenging them to do even better and share business context they might not readily see, as well as the engineering context of their project predating their on-boarding.

Full post here, 8 mins read

Maximize your team: How I created an engineering roadmap

Draw up a roadmap for the team: Identify a long-term focus. Evaluate previous efforts. Allow visibility into what the team is focusing on. Ensure planning efforts and workloads are easy to timebox and monitor so the team knows when they are ahead or behind.
Read more

Maximize your team: How I created an engineering roadmap

  • It takes considerable effort from you as a leader for your team to be successful. Draw up a roadmap for the team: Identify a long-term focus. Evaluate previous efforts. Allow visibility into what the team is focusing on. Ensure planning efforts and workloads are easy to timebox and monitor so the team knows when they are ahead or behind. Collaborate with other teams and use your business needs to prioritize value over cool factor.
  • Set the roadmap at a meeting and brainstorm together to visualize the destination you want to arrive at, and when you want to get there. Use a value system to filter or prioritize the ideas generated - nice to have, important but not urgent, critical for efficiency, debugging needed right away, important and urgent.
  • Create a roadmap document:

a) Summarize team and business goals.

b) List responsibilities and desired outcomes for the team. Include a list of all the things the team is managing and what is likely to be phased out or removed to help prioritize.

c) Review achievements for the previous year both for tracking goals and for motivation.

d) List this year’s goals, with 4-5 overarching objectives with 3-5 subheads each. Organize each section in a similar way to the main roadmap document.

  • Avoid cluttering the document with too much detail of plans and solutions to issues targeted - that’s a different exercise, which you should restrict to the relevant team and not the entire larger team.

Full post here, 6 mins read

Distributing operational knowledge across a team

Start building your knowledge repositories. These are for information needed in the long term by many different team members.
Read more

Distributing operational knowledge across a team

  • Knowledge management isn’t just a concern for larger companies. Small teams can & should adopt knowledge management practices and tools right from the beginning. It helps in building a scalable team and an effective on-boarding of new members to the team.
  • Start building your knowledge repositories. These are for information needed in the long term by many different team members.
  • To begin with, use simple tools for task management and collaboration and you can always move to a more feature-rich tool if and when you need to. To make sure people actually use a tool, make the tools usable and relevant and offer any necessary training needed for your team to get comfortable with the tool. Define expectations around particular tools for particular tasks, so that work or concerns are not addressed unless logged with that tool.
  • Find a comfortable signal-to-noise ratio of communication: start with more communication and gradually filter out what you realize you don’t need, rather than missing out what you didn’t know you need to know.
  • Remember the importance of face-to-face contact as well, in person or via VoIP, for clarifications, resolving long-standing issues and building morale. For teams across time zones, make these meetings asynchronous or organize several meetings at different times to allow a fair spread for participation.

Full post here, 9 mins read

3 research-backed principles that help scale your engineering org

Circumvent Brook’s Law (aka the Mythical Man-Month), which says adding manpower to a late project makes it later. If you must add team members to long, large projects, look for people who already have hands-on experience with the codebase
Read more

3 research-backed principles that help scale your engineering org

  • Dunbar’s research says that the most evolved part of the human brain can maintain a maximum social group size of about 150. Heed Dunbar’s number and keep a maximum team size of 150 and this should be entirely a standalone system. Ideally, have 10 people or fewer per team. Add system-level interfaces, roadmaps, and tools like Jira once you exceed 35 members. Institute monthly cross-team demos to share knowledge and make time for relationship building at personal and not just a professional level.
  • Use Conway’s Law to your advantage by strategically building your organizational structure to reflect your desired software architecture, since you will typically find the systems you design anyway mirror your company’s communication structure. This inverse Conway maneuver also means merging teams building similar systems so that duplicate systems converge.
  • Circumvent Brook’s Law (aka the Mythical Man-Month), which says adding manpower to a late project makes it later. If you must add team members to long, large projects, look for people who already have hands-on experience with the codebase or consider shuffling people across teams (in consultation with their managers). Complement this by factoring in time needed to onboard new people and train existing ones when committing to a schedule.

Full post here, 5 mins read

The 5 levers to address ‘org smells’ and ship higher-quality software (faster)

Clarify roles and responsibilities for both teams and individuals, including where these overlap, to help everyone understand what they should be doing, who to approach with questions on a given area and what is a shared endeavor.
Read more

The 5 levers to address ‘org smells’ and ship higher-quality software (faster)

  • Clarify roles and responsibilities for both teams and individuals, including where these overlap, to help everyone understand what they should be doing, who to approach with questions on a given area and what is a shared endeavor.
  • Create living product documentation to share insights and stay aligned. Regularly update product development processes and key product documents such as strategic objectives and roadmaps.
  • Hold productive and engaging meetings, with separate people facilitating and leading each of them. As a facilitator, share enough context beforehand, lay out an agenda, track time, keep people focused and maintain minutes of the meeting. As a leader, decide what needs to be done synchronously at the meeting and what can be achieved asynchronously. Set expectations for the how, when and where of communication within and across teams.
  • Develop good relationships with your team members so you are able to have difficult conversations with them with ease. Remember people crave BICEPS - belonging, improvement/progress, choice/autonomy, equality/fairness, predictability, and status.
  • Share context and critical milestones of progress through stages widely with the entire organization. Explain the reasoning and history behind decisions made.

Full post here, 14 mins read