A framework I codified to help me manage and scale our Software Engineering team at VideoBlocks. If you're in engineering management, whether at a small startup or larger company, you'll likely find some useful tidbits that will help you on your journey.

1. Engineering Management Framework
Building an Awesome Software Engineering Team

2. The Engineering Management Framework
People
Processes
Technology
Culture
+ Hiring / talent standards
+ Talent development / mentorship
+ Organization structure
Sub-areas Explanation / details
+ Eng teams live and die based on talent / tendency towards action
+ Grow eng skills internally via L&L’s, mentorship, pair prgming, etc
+ Create well-defined roles & responsibilities that fit team member
talents and aspirations
+ Roadmap Development
+ Sprint Planning & Req Gathering
+ Dev → QA → Deploy pipeline (GSD)
+ Bug / issue reporting & resolution
+ Product leads with heavy input / buy-in from Eng team
+ Crux of making sure all teams are on the same page
+ Maximize throughput while minimizing tech debt / bugs
+ Ensure we address urgent customer issues ASAP and provide
mechanism for reporting bugs
+ DevOps / infrastructure
+ Front end architecture
+ Backend languages / architecture
+ Tools
+ Ensure uptime and agility
+ Create a great customer UX that’s maintainable
+ Create maintainable backend codebases to support your UX
+ Foster productivity with “right tool for the job” approach
+ Autonomy, Mastery, Purpose
+ Psychological safety
+ Bottoms up and top down (provide a
vision / empower the team)
+ Ensures the team is engaged and minimizes turnover
+ Psychological safety is THE most important ingredient in team results
+ Culture has to come from both directions to succeed
Details to follow on each sub-area

3. Engineering Mgmt Framework
People
Hiring / talent standards
Talent development / mentorship
Organization structure
Process
Technology
Culture

4. People: Hiring / talent standards
ENGINEERING MANAGEMENT FRAMEWORK
Overview
Sourcing candidates
+ Hiring quality engineers is absolutely critical to building a successful team.
+ Hiring should be a top priority for leadership when you have open roles
+ Sourcing quality candidates can be tough; leverage platforms like Hired.com and Angelist, encourage the team to
send referrals, and use recruiters as a last resort
Interview process
+ Three rounds with a HW problem b/w 2nd and final seems to work well; keep the pre-final round screening process
the same for all candidates to ensure consistency
+ Make sure the candidate writes code!
+ Having a fairly consistent interview team is important but it’s also good to give people a “step-up” opportunity by
participating in the process; make sure to balance these competing priorities
+ Team might be on the fence about some candidates; figure out a strategy for handling this ahead of time (additional
homework, always no, etc)
Other considerations
+ Promote internally where possible - try to avoid hiring above someone unless it really makes sense
+ Culture is super-duper important so reject candidates for cultural reasons

5. People: Talent development / mentorship (1/2)
ENGINEERING MANAGEMENT FRAMEWORK
Overview
Review process
+ Developing talent internally is super-important and should always be a consideration when making decisions
+ Regular review processes and formal / informal mentorship are both necessary
+ Ensure some sort of x-team knowledge sharing occurs on a regular basis (iron sharpens iron)
+ Review process should take place every six months to ensure people are always getting feedback they need
+ Align on a structured framework & process ahead of time that enables a holistic approach with 360 feedback
+ Engineers should be assigned mentors who will be in charge of collecting feedback and writing a fair review
Promotions
+ Regular review process provides an easy forum to review performance and assess whether or not someone is
ready for a promotion
+ Generally, a promotion should recognize a role someone is already playing (though exceptions can be made)
+ Should generally be agreement amongst engineering leadership on the promotion; strong dissent likely means the
person isn’t quite ready yet
+ Promotion recommendations should be provided to the CEO for blessing though it’s mostly “rubber stamping”
+ Comp is a bit tricky. Let’s review in person.
Performance issues
+ Performance issues should be addressed fairly quickly by someone’s direct manager
+ If problem persists, bring it up the chain to discuss potential options; if performance is bad enough to lead to
termination if not corrected, make sure to mention it to the Management Team
+ Head of Engineering should have a very frank conversation with the person. Perf. improvement plan should be
kept relatively short, 2-4 weeks, to be fair to all parties involved. Probation period afterwards of 1-2 months to
encourage continued better performance assuming they’re not let go.

6. People: Talent development / mentorship (2/2)
ENGINEERING MANAGEMENT FRAMEWORK
Mentorship
+ All engineers should have a formal mentor who’s in charge of directing their development over the long term
+ It’s also useful to encourage an informal mentorship network where strong engineers can provide mentorship to any
engineer who’s interested
Knowledge sharing
+ Encourage all engineers to share their knowledge with the rest of the team through some mechanism, e.g., “Lunch
& Learn”, documentation, Slack, email, etc
Leadership training
+ Provide leadership coaching, guidance, and training to engineers who are interested
+ Consider future organizational needs and ensure internal talent will be prepared to help address them

7. People: Organization structure
ENGINEERING MANAGEMENT FRAMEWORK
Overview
Designing an
organization
+ Finding the right people for roles & responsibilities makes everything much easier
+ Org structure forces people into certain mindsets so design it carefully
+ First, map out what needs the team has (e.g., someone needs to own DevOps, QA, Acquisition, etc)
+ Next, try to group related stuff together where possible so that you don’t have a bunch of 1 engineer teams (e.g.,
maybe we have a team called “Strategic Tech” that does DevOps, Data, and Search stuff
+ Adjust the above if necessary for talent constraints and/or individual development needs
Other considerations
+ Make sure the org structure aligns with business needs and generally “makes sense”
+ Don’t change it too often if possible
+ Be flexible and design it so most engineers can change teams if necessary → bus factor = 1 is very scary
+ Consider development trajectories and emotions
+ Keep great teams together if at all possible → research suggests that it takes time for teams to “get in a rhythm”
and they’re much more productive when they do

8. Engineering Mgmt Framework
People
Process
Roadmap development
Sprint Planning & Req Gathering
Dev → QA → Deploy pipeline (GSD)
Bug / issue reporting & resolution
Technology

9. Process: Roadmap Development
ENGINEERING MANAGEMENT FRAMEWORK
Overview
Considerations
+ Long-term product roadmap essential to developing a great product
+ Mostly Product Management’s responsibility though Engineering should be heavily involved for input
+ Business rationale: Double check that the roadmap makes sense from a business perspective
+ Ensure that timelines are reasonable (e.g., engineering leads should do high level LOE estimations)
+ Tech debt: Ensure that it accounts for technical debt cleanup / other behind the scenes tech stuff that product may
not be as aware of
+ Think about how it might influence Engineering AMP / team morale
+ Think about how it might influence team structure
+ Consider whether or not it affects the hiring plan

10. Process: Sprint Planning & Req gathering (1/2)
ENGINEERING MANAGEMENT FRAMEWORK
Overview
Requirements
gathering
+ Gather requirements, estimate effort for tasks, and prioritize stuff in the short term
+ Product takes lead on the “what” though we as engineering have a heavy responsibility to help prioritize and provide
an active input where we can do things more efficiently; ideally there’s a well-groomed backlog
+ Product should take lead on pulling in other stakeholders
+ Make sure we’re getting good enough requirements
+ Ideally engineers can point out when requirements are clear enough and problem solve with Product Mgmt to
resolve the issues
Handling problems
+ Unclear requirements: It’s best not to commit to something in a Sprint when the requirements aren’t clear enough to
deliver; however, high priority situations will require that we be flexible
+ Uncertainty around an ask: If you know something could come up in the future, book Sprint time (e.g., 360/VR ask
for NAB) even if it’s a bit vague; with a well-groomed backlog we can keep chugging even if we don’t end up
executing against the vague ask
Estimation
+ Let the entire team participate in point estimation where possible; it builds buy-in and ensures that the team doesn’t
feel like it’s just taking orders as much
+ Try to keep point estimations constant over time
+ Slowly but surely increase point allocations / eng / day as long as you keep delivering though make sure this isn’t at
the expense of work/life balance; you genuinely want the team to get more efficient

11. Process: Sprint Planning & Req gathering (2/2)
ENGINEERING MANAGEMENT FRAMEWORK
Retrospectives
+ Make sure to do retrospectives every Sprint so the teams can continue improving
+ What went well, what can be improved

12. Process: Dev → QA → Deploy pipeline (GSD)
ENGINEERING MANAGEMENT FRAMEWORK
Overview
Development
+ Core engineering process that delivers new functionality
+ Where Engineers (ideally) spend most of their time!
+ Minimize meetings and distractions: Ideally, engineers should spend most of their time developing features
+ Includes Design and Code Reviews, which are crucial to building a great GSD pipeline. Otherwise you’ll leave
massive amounts of tech debt in your wake
+ Fairly tightly coupled with some tech choices (Git/GitHub for source control)
QA
+ TDD and a TDD culture are a must!
+ Unit tests, integration tests, Selenium / end-to-end tests
+ Tests should be fast!
+ Devs should do manual testing before handing it off to formal QA
+ We should have a fairly strong manual QA team
Deploy
+ Ideally our test suites are good enough for us to do Continuous Integration if we want
+ Should have push-button deploys
+ Rollbacks should be super-simple
+ Anyone should be able to deploy but there should be people available to help fix problems if they arise (e.g., no
middle-of-the-night deploys when you’re the only person awake)

13. Process: Bug / issue reporting
ENGINEERING MANAGEMENT FRAMEWORK
Overview
Reporting
+ Bugs and other issues are certain to occur
+ We need to have a process for fixing them and communicating appropriately with stakeholders
+ There should be as few channels for reporting bugs as possible while ensuring that urgent issues are always ID’d
and resolved quickly
+ It should be easy to report bugs / issues and the “how” should be easy to remember
+ Non-urgent issues should be kept in a backlog of some kind
Fixing issues / bugs
+ Standardize a process for addressing bugs / issues that everyone aligns on. Might be part of Sprint planning, might
be it’s own process (e.g., Dev Requests)
+ Ideally all engineers help fixing bugs / issues -- don’t create two “classes” of engineers (coders and bug-fixers).

14. Engineering Mgmt Framework
People
Process
Technology
DevOps / Infrastructure
Front end architecture
Backend languages / architecture
Tools

15. Process: DevOps / Infrastructure
ENGINEERING MANAGEMENT FRAMEWORK
Overview
DevOps
+ DevOps should enable the team to move quickly and ensure our products are available for our customers
+ DevOps is a strategic asset b/c it lets you move faster than the competition when done well
+ Ensure that most of the team can do at least some DevOps and understands the basic concepts
+ Makes sense to have a specialist or two once the team reaches a critical size
+ Docker rules!
+ Remember, the goal is to leverage DevOps to move fast!
Infrastructure
+ Our infrastructure should support our current needs and be prepared to scale to 10x our current volume
+ Make sure it’s flexible for new demands even within the 10x volume
+ Make sure it’s not slowing you down or costing too much
+ Know the architecture! Current architecture leads to a lot of business constraints that you have to be able to
communicate to the executive team.
+ Have a plan for the future! Even within the 10x volume constraint our infrastructure will need to evolve to support
future needs (e.g., OneAccount)

16. Process: Frontend Architecture
ENGINEERING MANAGEMENT FRAMEWORK
Overview
ReactJS / Flux
+ Our frontend architecture should support an amazing customer UX and also be maintainable
+ ReactJS / Flux combo seems to be the best option at the moment
+ The future! Easy-to-understand design pattern makes for an extremely flexible way of building web apps
+ The one downside (thanks to Kim for calling this out) seems to be CSS transitions
Everything else
+ The past
+ We should eventually migrate to ReactJS / Flux where it makes sense

17. Process: Backend languages / architecture
ENGINEERING MANAGEMENT FRAMEWORK
Overview
Backend languages
+ Ideally, we should use the right tool for the job
+ Transitioning backend to microservices will enable the business to move faster
+ Good options for VB: PHP, Node, Scala
+ Many other options are ok depending on the circumstances
Microservices
+ Backends for frontends with microservices
+ First build a monolith then split out services once you’ve scaled (code well initially and this is much easier)

18. Process: Tools
ENGINEERING MANAGEMENT FRAMEWORK
Overview
Tool selection
+ Super important to choose the right tools for the job because they dramatically affect productivity
+ Version control: Git, GitHub, and SmartGit
+ IDE: anything JetBrains
+ Use a debugger!
+ CircleCI for unit testing
+ Not sure for Selenium testing
+ Sequel Pro (Mac) for MySQL
+ Sublime Text for editing random txt docs, some code
+ BeyondCompare for FTP / file diffs
+ AWS!
+ Docker Hub

19. Engineering Mgmt Framework
People
Process
Technology
Culture
Autonomy, Master, Purpose
Psychological safety
Bottoms up and top down

20. Culture: Autonomy, Mastery, Purpose
ENGINEERING MANAGEMENT FRAMEWORK
Overview
Autonomy
+ The secret to building a happy, motivated team; HUGE for retention!
+ Straight from Daniel Pink’s “Drive”
+ The power to make impactful decisions in your day-to-day work
+ Improves autonomy: building new stuff, flexibility to select your projects
+ Decreases autonomy: processes, just following instructions
Mastery
+ Continued growth and development
+ Improves mastery: learning new technologies & skills, solving hard but tractable problems
+ Decreases mastery: simply doing the same thing over and over again
Purpose
+ Connecting work to a larger cause than yourself
+ Improves purpose: delivering value and Getting Shit Done (GSD)
+ Decreases purpose: impossible problems, working on inconsequential stuff
On all of these, what matters is how teammates feel,
not necessarily the facts of the situation

21. Culture: Psychological safety
ENGINEERING MANAGEMENT FRAMEWORK
Overview
Psychological safety
+ Psychological safety is THE most important aspect to succeeding as a team
+ Team bonding, building trust, and having “good” conflict that doesn’t disparage people are all important aspects
+ The shared belief that the team is safe for interpersonal risk taking. In psychologically safe teams, team members
feel accepted and respected.
+ Benefits are manifold: improves likelihood that innovation will be successful, increases amount team members
learn from mistakes, boosts employee engagement, improves team innovation
+ Two key leadership aspects help create it: participatory management and inclusive management
+ Two aspects of a team that really help improve it: well-defined team structure where team members understand
their roles; strong relationships between cohesive team members
Build strong
relationships
+ Strong relationships are key to psychological safety so it’s important to ensure they exist on the team
+ Focusing on building trust / ability to have productive conflict is crucial: consider reading “Five Dysfunctions of a
Team” together
+ Encourage team interactions outside the office such as offsites, happy hours, hanging out, etc
+ Family-like atmosphere
Encourage feedback
and growth
+ Encourage team members to seek constant personal and professional growth
+ Encourage team members to provide each other feedback on a regular basis

22. Culture: Bottoms up and top down
ENGINEERING MANAGEMENT FRAMEWORK
Overview
Top-down
+ Culture must come from the top-down from leadership and be strongly supported bottoms-up by team members
reinforcing the culture
+ Team leadership needs to formally establish the culture by defining principles and values for the team
+ Leadership should also vocally support Autonomy/Master/Purpose and Psychological Safety
+ Be consistent in rewarding behavior according to principles
Bottoms up
+ A lot of bottoms up culture happens through a combination of hiring the right people, rewarding behavior consistent
with cultural principles, and supporting team AMP
+ Encourage the team to “own” culture and provide an environment where that’s possible