Building an engineering organization

Starting with the product

I joined App in the Air in 2013 and built its first Android application. In the early team, development, analytics, user feedback and product decisions were closely connected. As the product grew, I took on hiring, internships and the development of the Android organization.

I used individual development plans to connect what people wanted to learn with work the team needed. Responsibility grew with their capabilities: mentoring an intern, owning a release, evaluating a candidate or leading a technical decision.

Making the next leader possible

One engineer grew from a student hire into our Android technical lead. His responsibilities expanded through mentoring, onboarding and technical assessment. I handed technical leadership to him and continued supporting people development and coordination with the rest of the company.

He designed and ran the team's technical processes. When code review became a bottleneck, I proposed distributing it more widely, including to junior developers. The aim was to develop judgment across the team while sharing the work.

Day-to-day technical management ran independently of me for two years. When the technical lead later left, the team continued operating, although its pace slowed. Distributing responsibility had made continuity possible.

Giving technical expertise room to lead

When the application needed a more maintainable architecture, I set requirements around delivery, onboarding and long-term maintenance. The technical lead proposed the design. We evaluated it with new developers, refined it over two to three months and brought in experienced engineers from another company in our group for an outside assessment.

My contribution was to define the problem, organize evaluation and support the rollout. The technical design belonged to the engineer leading that work.

Learning can end with a decision to stop

I introduced two paid hours a week for professional learning. One engineer used that time to evaluate Kotlin coroutines for our application. After about six weeks of experiments, he concluded that a migration would not meet our production requirements at the time.

That was a useful result: the team gained knowledge and avoided committing to a change it could not yet justify.

Extending the work beyond Android

In parallel with leading Android, I helped build company-wide people-development practices. This included a learning group for team leads, hiring an HR specialist and internal work on well-being during a period of substantial change.

My interest in psychology and psychophysiology gave me additional questions to ask about learning, motivation and workload. The practical work remained organizational: understanding people's goals, clarifying responsibility and improving the conditions in which they worked.