LearnZillion has a big mission — to empower districts and states to take ownership of their curricula, providing teachers with the best tools there are to help engage their students. They’re the world’s first curriculum-as-a-service offering (CaaS), combining digital curricular materials, an enterprise platform, and professional services, all working together towards their mission.
Ian Lotinsky, CTO at LearnZillion, joined when the company needed a technical leader after raising its Series A. When you have a goal that big, you learn a few things about leadership along the way, and Ian has some great lessons that other tech leaders can learn from.
Allowing for Autonomy and Motivation
One of Ian’s core management tenets is that he encourages his engineers to not just think about the software they’re writing, but about the product they’re building.
“As software engineers, they’re putting ideas into code — because of that, they’re faced with reality more than anyone else on the team, even the product manager.”
This means they’re in the ideal position to have the most context on what LearnZillion’s goals are. It also means they’ll face the constraints and contradictions that emerge when you put something into code — problems that aren’t apparent in an idea, a wireframe, or on a feature spec list.
Ian leaves it up to the engineers to identify when that happens and come back to the team when there isn’t a direct answer or approach to solving the problem. “I want them to think about the problem they’re solving and to help steer the overall product, not just the software,” he notes.
Why this somewhat free-form approach?
Ian wants his engineers to realize the importance of their code in the bigger product picture, adding “In my experience, a lot of software engineers just want to write software, they want to be told ‘build the product this way.’ It’s fascinating, because people in general often prefer autonomy and problem-solving, but there are engineers who want perfect specs ahead of time.”
The problem is, that’s not a fair thing to hold the rest of the team to, as far as Ian is concerned — they aren’t the ones faced with constraints, they’re working off of brainstorming lists in Google Docs or drawing up UX wireframes, and there are things they can’t know when working in those mediums. Ian specifically seeks out engineers who are willing to work this way, and feels that his team creates better products for it.
Because of this approach, it’s important to help engineers understand the importance of their role outside of the material contribution of only writing code.
“I picked this up from a book called Multipliers, which talks about getting 110% out of your employees. It actually has very little to do with artificial motivators, and is more about giving people meaningful work, getting out of their way, and making sure that they can get the work done.”
The trick is, you also need to be giving people something a little bit beyond their capability so that they can grow into their work and responsibilities. This is why Ian lets his engineers figure out when a problem is something they need extra backup on, instead of over-supervising them.
Autonomy tends to motivate people, but a potential downside to giving your employees autonomy is that they will inevitably make mistakes. However, this isn’t really a downside as far as Ian is concerned: “You should be providing a safety net for them if things don’t go well and they need some help.” Ian notes that there’s a fine line here: “It shouldn’t be all falling on one person, but people also shouldn’t be completely shielded from responsibility. If no one is specifically responsible for something, then that thing will likely fall through the cracks.”
“If no one is specifically responsible for something, then that thing will likely fall through the cracks.”
Dependability and Predictability
Another way that Ian helps balance out the autonomy he gives his team is by expecting dependability and predictability. With engineers, the most obvious metric for dependability is code quality — factors like:
- Is it easy to understand?
- Does it follow the conventions established by the team or outside sources?
- Is it self-documenting?
- Are there too many abstractions in the code?
In general, Ian doesn’t like relying too much on technical metrics to judge engineer performance, but one of the ones he does keep track of is bugs produced compared to features produced:
“Software engineers should be conscientious about the number of problems they’re going to create for users and for others on the team, and be able to learn from their experiences about how to improve their quality.”
He requires engineers to fix their own bugs to gain and build this thoughtfulness.
Another factor of predictability that’s important to his team’s workflow is creating a predictable cadence to the work you’re producing.
“People try to force this with Agile Scrum, sprints, and check-ins, but what I’m talking about is more about an individual’s ability to be self-directed, to timebox their own work, and give accurate ballpark estimates on how long something will take.”
Ian’s favorite metaphor for thinking about dependability and predictability in a team?
If a player of a sports team isn’t predictable, it affects the whole team. For example, if you look at soccer, if one player isn’t predictable in terms of when they get the ball or who to pass it to next, it can throw off all the plays that the team planned and drilled together. The team simply won’t function if that person isn’t predictable in terms of their ability to get the ball to the right person at the right time and the right place when a play is in motion.
He considers this a basic requirement for his team, so he looks for it in interviews and during evaluations — some of the things he looks for during those are:
- Ability to get help when needed
- Not waiting for people to reach out and ask if something is wrong
- Taking leadership in their contributions
- Being able to proactively communicate with others about their workload
- Bringing scope concerns to other team members or team leads before it becomes a huge issue
Building Cross-Functional Teams
After seeing cross-functional teams work well in other companies, Ian decided to incorporate them into his software product development process. At LearnZillion, whenever they need to work on a new feature or product, they put together a team made up of:
- A software engineer
- A product designer
- A product manager
- Another member of the company — depending on the feature, it might be someone from the academic team, customer success, marketing, or sales.
All of these team members participate in scope discussions and the kickoff for the product:
- The product manager coordinates the schedule, makes sure that the right people are involved, does the pre-work before kickoff (user interviews, testing, surveys, and so on), and establishes a goal and objectives for the feature
- The product designer’s does UX, design, and implementation of that feature
- The software engineer does all the backend work — data modeling and backend code — and they work very closely with the product designer
- The others are participating in the conversations or helping to evaluate iterations of the product and might also be producing material (in LearnZillion’s case, the curriculum or other supporting material for the feature/product)
His final words on the topic?
“Innovation tends to happen in the context of a team, and having a diverse set of experiences and perspectives in the mix is going to lead more insights and better solutions.”
This post was originally published at the Clubhouse blog.
Illustration by Michele Rosenthal
Source: B2C
No comments:
Post a Comment