Principles for Organization Design
Lessons learned from building Square
As tech companies are focusing on efficiency and rethinking their organizations, I felt compelled to share my learnings on organization design. I believe that well-designed organizations are key to delivering amazing products and product velocity. In fact, I am a stickler for organization design. But how does one approach designing an effective product/engineering organization?
I spent the last 10 years of my career at Square (now Block) and helped the company grow from 600 to 12,000 employees. I learned a lot about org design in that time, not only from scaling my own organization, but from observing how org design impacted the products that were delivered to customers and how teams collaborated. I saw how it made some things easier and others harder, where it created positive and negative tension, and how it shaped the architecture of our systems. Over time, I began distilling these learnings down into principles to guide the design of healthy and effective product/engineering organizations.
I believe these principles are the most valuable when organizations get to a certain level of complexity and size. If your product/engineering team is small enough to fit everyone into the same room, you won’t need this level of structure yet. But if you are scaling an organization and adding new layers of management, or downsizing and instilling focus, you may find these principles for org design useful.
I have intentionally kept these principles brief and intend to follow up with more context in a series on organization design. Let me know what you think!
Principles
Organizational structure should promote clear and unambiguous responsibility, ownership, and accountability. It should be flexible, but durable.
Design your organization to serve its customers. Decompose your domain into logical units and map those to teams. Recursively subdivide as necessary.
Teams should be organized around a clear purpose/mission and empowered to accomplish their mission.
Staff individual teams with the capabilities necessary to deliver value to their customers, rather than organizing by skills, e.g. backend, mobile, testing, etc.
Keep the organization as flat as possible, for as long as possible.
Elevate leaders who amplify the capabilities of their teams. Avoid leaders who seek power, centralize decision making, and do all the thinking themselves.
By employing the inverse of Conway’s Law, you can use organization structure to promote your desired systems architecture.
Don’t optimize for existing service boundaries and on-call rotations. These will adapt over time.
Respect functional job families. People receive higher quality mentorship, career advice, and coaching from leads of the same practice.
Allow for a bit of chaos. Too much order and structure can stifle innovation.