Building and Motivating Your Development Team: An Interview with LearnZillion’s CTO
Building and Motivating Your Development Team: An Interview with LearnZillion’s CTO https://csuiteold.c-suitenetwork.com/wp-content/uploads/2017/08/building-and-motivating-your-development-team-an-interview-with-learnzillions-cto.png 1000 644 C-Suite Network https://csuiteold.c-suitenetwork.com/wp-content/uploads/2017/08/building-and-motivating-your-development-team-an-interview-with-learnzillions-cto.pngLearnZillion 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…
