Reflections on building the Credijusto tech team in 2018
We’ve had a killer year since I last wrote about what we’re up to on the Credijusto tech team. We released two new financial products (credit lines and commercial leasing), doubled the size of our team, and raised $60MM USD (around $1BN MXN) from a cohort of globally respected VC and debt investors. We’re more convinced now than ever before of our core thesis about Mexican SMEs: that we can originate and manage credit at scale in a high-complexity, high-risk market by building our lending platform from the ground-up.
All of the growth that Credijusto experienced this year created a ton of product demand, which quickly became a mountain of product debt. For our team members this has been a constant opportunity for outsized impact: every line of code that a Credijusto engineer writes immediately empowers a teammate in the operation or delights a customer. At the same time, if not managed effectively this debt threatened to kill stakeholder buy-in and bottleneck our growth. We had two options: change the way we work to become more efficient, and/or increase team bandwidth by hiring more devs. We’ve chosen to do both, and have been learning a ton in the process. In this post I reflect on the past year, sharing a couple key insights from the road. Hope they’re interesting to you!
Know who you are, and hire for cultural/technical fit
Engineering teams, particularly those in quickly growing startups, operate in complex environments. As the team grows along with the business this complexity increases geometrically and threatens to derail the team. The Netflix culture deck has a great slide about how this often works:
Teams that don’t focus on retaining and recruiting high performers have three bad options: stay small and have less impact; avoid rules and suffer chaos; or become significantly more policy-oriented, at the cost of being innovative and retaining talent. When creative, impact-seeking people can’t innovate or experiment, they will leave.
We can’t accept any of these, so we aggressively focus on finding and developing the best people. This creates a natural brake on our pace of hiring. Growing headcount without attention to quality creates more problems than it solves. We hire slowly and fire quickly, rigorously vetting for technical capability and culture fit, and either training or saying goodbye to our low-performers. When we do let someone go we are fair, transparent, and financially generous.
We define culture fit as a strong belief in our team mission, and an overall adherence to our eight core values. This isn’t just important for defining who we’re looking for. Teams tackling complex problems need strong cultural values to guide and focus their work (see Andy Grove on managing teams in environments with a high “CUA factor”). And we’ve seen that a team with a strong sense of core identity ends up creating a more awesome community. We’re all about that.
Here’s our mission statement: Credijusto engineers are technological enablers. We make complex products, workflows, and customer interactions work flawlessly at scale. We seek to delight our customers with the flexibility of our products and the quality of their experience. We commit to empowering our operational teams to offer the best possible service to SMEs, and to experience daily the positive impact of our technology.
The mission defines our shared sense of direction. Our values define what a Credijusto engineer looks like, and guides how we screen for culture fit. We have eight core values that we flesh out in detail on our team engineering page. These are:
- Multi-disciplinary — We look for creative problem solvers with a variety of hard and soft skills.
- Excellent — Being badass at execution is a must. We never compromise the technical bar.
- Autonomous — If you’re someone who requires supervision, then this isn’t the team for you. We look for people who are confidently self-directed.
- Ownership-seeking — Our engineers seek hard problems to solve. They drive toward the best possible solutions with total commitment.
- Collaborative — A team is more than the sum of its parts, and often produces better ideas and stronger execution individuals.
- Humble — We don’t let our egos get in the way of improving ourselves or our work.
- Empathetic — We always try to put ourselves in the shoes of our colleagues and users, building with them in mind.
- Reliable — You can count on a Credijusto engineer, and on the work that she produces.
Two quick notes about these values. First, they are aspirational. We don’t practice them perfectly by any means, but usually when something goes wrong we can trace the issue to a failure to express one or more of these values. Awareness of the gap between where we are and where we want to be pushes us to improve. For example, as our code base continues to grow across a range of independent services, supporting multiple financial products, we’ve had an increasing incidence of bugs and production failures that have been frustrating for our operational teams. This is a reliability issue that we are addressing through a combined emphasis on QA, and improving our continuous integration/continuous deployment architecture.
Second, some of these values compete with each other. For example, there’s a natural tension between being an autonomous developer and a collaborative one. Or between being multi-disciplinary while also having the deep expertise necessary to be truly excellent in a programming language or framework. We view these tensions as productive and accept that we each have unique combinations of strengths and weaknesses. This is part of what makes the job fun and professionally fruitful.
Our values define who we are. Our operating principles deal with how we work. These are guides/models that we’ve found useful in the day-to-day when navigating the following considerations (you can read up on these as well on our engineering page):
- Impact versus urgency — Do I do this now, later, or never?
- Impact versus reversibility — Do I “move fast and break things” here, or bounce this decision off my squad lead first?
- Leave it better than you found it — Should I spend 10 minutes simplifying this conditional logic before sending my PR? (yes)
The attention that we’ve placed on mission, values, and operating principles may feel soft, but we believe it’s critical to our survival as a hard-hitting engineering team. We don’t hire faster than we are able to integrate new team members into our culture and train them to be excellent developers in our stack. Doubling the size of our team in the past 3 months has stretched all of us, but we’re heading into the holiday season with a great group. We believe that our current base of talent will provide a strong foundation for the next round of major hiring, coming up in 2019.
People > policies (but do find the right amount of structure)
The result of this careful screening, paired with an ongoing emphasis on our values and mission, is that members of Credijusto engineering don’t need all that much institutional structure. This makes them that much more agile when attacking the product roadmap. Even so, we’ve found that adding some structure to the team has been helpful for managing the volume of communication and competing priorities that our engineers are exposed to. On our team, structure isn’t about managing engineers, but rather about helping them to focus on doing their best possible work.
For the first year and a half of Credijusto engineering we had an extremely lateral team with basically no intermediary layers of management or communication. This was great. All engineers had ongoing, direct engagement with stakeholders, and it was pretty easy in the morning standup for all of us to get on the same page with respect to product priorities. It looked something like this:
This is a good model for a young team. At this stage, introducing any additional structure would have been stifling, so we didn’t do it. As our team, company, and product roadmap grew, however, we quickly ended up here:
This did not work nearly as well. Furthermore, having a highly lateral team structure complicated our internal dynamics as the number of lines of communication grew. We went from this:
…to this:
With each new hire or each new business initiative, it was becoming harder for engineers to know what to focus on. Credijusto’s products depend on an ecosystem of integrated services, and it was becoming increasingly difficult to coordinate engineers around priorities on the product roadmap. The quality of product planning and deployment was diminishing quickly. We felt that specializing or siloing teams/engineers at this stage would (a) be boring for a lot of our team members, (b) reduce key awareness of how our architecture works, and (c) slow the pace of product deployment by making it harder to assemble cross-functional teams. And yet we really needed to channel all the communication that was happening and up the product planning quality bar. Here’s what we settled on:
The legend in the graphic breaks down how this works a little bit more. One of the most important innovations to team structure was bringing in product managers (PMs) to both channel communication between engineers and stakeholders, and spend dedicated time planning deliverables. Each PM is assigned to a squad and works shoulder-to-shoulder with a squad lead. The squad lead’s responsibilities are technical planning, technical contribution, and mentoring developers. The PM’s don’t manage the squads. Rather, their role is to work with developers as allies in navigating our product roadmap. This structure is helpful to our team members on the operational side of the house, too, because it’s now clearer who they need to talk to when they have an issue or request (almost always either a squad lead or PM).
We delegate business priorities to the PMs, who plan engineering tickets collaboratively with the squad leads. We currently have two full-stack software development teams, both of which have the diverse skillsets necessary to work on any service that touches a product priority, and a dedicated data science team. These new responsibilities are challenging and exciting for our leadership team, and we’ve been spending a lot of time making sure that they have both the resources and the knowledge to succeed. Our PMs have been doing a book club on Product Leadership, while our squad leads have been reading and discussing Debugging Teams. The latter, in particular, is a fantastic read that will soon be a key part of our onboarding for new hires.
We’ve pushed daily stand-ups, planning, performance reviews, and mentorship down to the squads. This has been a bit uncomfortable. A totally lateral team with no formal management or planning structure may be chaotic, but the common sense of purpose and community is refreshing. We want Credijusto tech to mean the same thing for everybody, and avoid a situation where squads no longer share a common identity. Our mission and core values make this possible, as does rotation of squad members, PMs, and projects. In the presence of a bit more structure, those same values keep us extremely lateral: the most junior member of our team knows that he/she is welcome to chat with me or Matheus, our Director of Engineering, at any time. We’re also being more intentional than ever before on reinforcing tech team identity through team building. One of the ways we do this is with twice-per-year team retreats, like the one we just finished in Santa María Huatulco, Oaxaca.
The structure we have today focuses communication and planning without stifling creativity and room for taking ownership. We know this model isn’t perfect and are constantly fine tuning it. We’ll do this based on what empowers engineers to do their best work, confident that the technical and cultural quality of our team is only going to get stronger with time.
A few other thoughts
What makes Credijusto engineering really challenging is also what makes it so exciting. One of our squad leads, Charly, noted that a developer on our team has two major challenges when they join: (1) Learning the logic of our business and the products that we offer to our customers, and (2) learning our stack, and getting a handle on how we develop and deploy. A third element of challenge, perhaps, is the rate at which we’re evolving this team and figuring our new stuff as we go along. Here’s a sample of some of our big questions at the moment:
- Some of our engineers are really missing the direct stakeholder engagement they had before. How can we get back to this, without slipping once again into communication chaos?
- As we up the tempo of feature releases and deploys, how can we make sure our internal stakeholders and customers are always in the loop?
- Do we have DevOps as a separate, supporting element, or do we bake DevOps discipline into each squad?
- Is our backend too diverse? Should we be looking for more language standardization?
- Should we have a separate squad dedicated to front-end design? Would this include front-end devs, or just UX designers?
We don’t know what the answers will be, or what new questions we’ll shortly be wrestling with, but I’m positive that we will be successful. Evolving and adapting is in our blood, and we’ve thrived on the challenges we’ve taken on together to date. By staying true to who we are, and seeking structures that empower rather than constrain, we’re going to continue to do so.
Join our team
Now more than ever before we are hungry for the best team members that we can find. We have expanded our search to include full-stack engineers, front-end engineers, data scientists, UX designers, and product managers. If that’s you, or you’re just interested in checking in and learning more about we’re doing, hit us up at careers [at] credijusto [dot] com or check out the application form on our engineering page. Also, we’re delighted to be hosting Women Who Code this Wednesday, November 21. If you’re a woman who codes, and are interested in what we’re doing, come through!
