TL;DR notes from articles I read today.
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
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
Get these notes directly in your inbox every weekday by signing up for my newsletter, in.snippets().
Top comments (3)
I'd like to add a point to this is you don't mind Arpit. One thing I've had great success with is building for scale from the beginning.
For example, I'm the primary developer at the small company I work for at the moment. I use branch policies, pull requests and all that Git goodness even though it's only me who really commits any changes.
However, when developer 2, 3 and 10 come on board it is seamless. Rather than needing to change the complete development lifecycle to manage a team.
I totally agree that having a base process eases some of the growing pangs. Over a period of time, we internalize some of these processes and start doing them even in our personal projects that nobody will ever see.
Obviously any process is accompanied by the caveat: "Is this necessary at this juncture?" It's imperative for all of us to be objective and flexible to be add/remove process steps when they no longer serve the purpose that they set out to fulfill.
I agree 100%! It's important to constantly re-evaluate processes to make sure they are still relevant or if they need expanding to become more supportive.
It's a great point on internalizing into personal projects, unit tests is a big one for me. I try and write them no matter how small the application is (and I'm still not great).
A small utility app in Git doesn't NEED tests, but it's a good habit to build upon.