Forty days in

Calendar math says I’m a few hours into the 39th day since I started at Unity. I’m still well within the honeymoon window, but my optimism and excitement about working here continue to grow. It’s just a pretty damn cool place to work.

I’ve met most of my team face to face, and will spend more time with team members in Copenhagen and Helsinki next week. I still have half a dozen people in Austin and Montreal whom I will track down and meet in person sometime before I hit my hundredth day. I’ve spent a lot of time learning about Unity (I made a simple game), and a bigger chunk of time learning how Unity services work – and more importantly how they’re built, deployed, and tested.

I’ve also spent a lot of time thinking about my role – or in general, the role of a manager of a team of “embedded” testers. Organizationally, I’m the Quality Director for all Unity services – but everyone on my team is an integrated member of a feature team (for the record, one minor complaint I have with the phrase “embedded tester” is that it can sound like a foreign body inserted into a functioning team rather than a test and quality specializing generalist who is an equal member of a feature team).  I’ve embraced the words of Steve Denning in The Leader’s Guide to Radical Management, and provide a framework for the team – and then get out of their way (quote likely plagiarized, but I can’t recommend Denning’s work enough, so take the time to read it yourself).

In a search to find the exact quote (I have a hard copy of the book…but at home…), I wasn’t surprised to see that I’ve heaped praise on Denning before and expanded on the phrase above.

Give your organization a framework they understand, and then get out of their way. Give them some guidelines and expectations, but then let them work. Check in when you need to, but get out of the way. Your job in 21st century management is to coach, mentor, and orchestrate the team for maximum efficiency – not to monitor them continuously or create meaningless work. This is a tough change for a lot of managers – but it’s necessary – both for the success of the workers and for the sanity of managers. Engineering teams need the flexibility (and encouragement) to self-organize when needed, innovate as necessary, and be free from micro-management.

Given that my team is globally distributed, working on a large number of feature areas, and are highly skilled and motivated, any approach within five-hundred miles of anything resembling micro-management would be silly. My role will include helping the team balance priorities; to facilitate learning, collaboration and community; coaching; communication; and, of course, a bit of management administrivia (budgets, approvals, planning, etc.).

I’ve been taking some notes on some of the biggest differences I’ve noticed (culture, practice, tools) between my job for the past 40 days, and my job for the previous ~8000 days. Someday soon, I’ll dedicate an entire post to these observations.

While talking with a dev lead earlier this week, I told him I felt like I was on the edge of almost being briefly effective. I’ll try to keep heading in that direction and post the victories (and setbacks) here as they happen.