To recap, the last year's gone by really quickly because I've been writing a boatload of code as well as stepping into more of a managerial role at CBITs. Anyone wishing to follow along at home is free to review my recent GitHub commits, but the major project themes over the past year has been preparing the suite of Intellicare apps (link coming next week!) for release and continue to develop Purple Robot.
To recap, Intellicare is a suite of 12 apps for patients with depression and anxiety that each address a single facet of the patient's condition. We have an app that helps the patient implement positive coping strategies (iCope), one that provides tools for better sleep hygiene (Slumber Time), and others that address physical activity, sociability, and more. We're in the home stretch of that project, with four apps to be released to the public next Monday, and flights of four to five apps to be released one and two months later. While building the apps, I've also been bringing a team up to speed on Android, and these team members are responsible for developing and maintaining six of those twelve apps.
Purple Robot is the Android app that builds on my graduate work in context sensing and data collection to gather observations in the world to predict user states and outcomes. It's a core component of many CBITs offerings and it's been taking off elsewhere as well. (We'll be leading a hackathon next week in London about building medical apps with Purple Robot.) My work this year has been more in the maintenance spirit. I've been adding new features from time to time, but the focus is on improving its reliability in the field. This summer saw the introduction of an embedded test suite which has been extremely helpful on this front.
Moving into the 2014-2015 year, I have a couple of other projects lined up, but the major theme of the year for me is shifting from raw software development to managing software developers. The Intellicare experience demonstrated that my knives were sufficiently honed, and the next logical step in my career is finding ways of not just assembling effective code, but scaling up teams that can produce more effective code than I could working alone. I started down this path earlier this year, but I made it an explicit career focus and goal last month.
I think that the trick to succeeding at this is avoiding something called "the Peter Principle". The principle can be stated as
The fundamental idea is that as employees are successful, they are rewarded with promotions under the theory that what made them successful in their past role will automatically translate into success in a higher role. Success translates into advancements within an organization until the employee finds themselves far enough removed in duties and tasks that what made them successful in the first place is irrelevant in their current role. This is certainly a danger in the software development profession. Traits that make a successful developer are irrelevant – or often counterproductive – in a management context.
I've been brushing up on my management reading to try and avoid this situation, and much of the next year will be spent building up these skills. While I've been successful as a developer, using the next year as a crash course in effective leadership will fill a gap in my current skillset that will be useful within a university context, but be even more valuable if and when I decide to strike out in the private sector again. In addition to the usual pitfalls, one of the things that I'll be on the lookout for is being sure to develop skills that are useful outside my current role and not "overfit" myself to Northwestern's organizational peculiarities.
Effectively, this means that I'll be looking forward to less development responsibilities in my day-to-day duties and finding opportunities delegate these to team members over the next year. When something isn't proceeding how I think it should, my first inclination is to jump in and just take care of the issue myself. Much of the next year will be spent tempering that instinct and finding ways to channel that energy into building up a team to handle those challenges, instead.
This change in focus isn't a sign that I'm looking to get out of development – I'll remain just as focused (if not more so) on my side projects. I do worry about falling out of touch with current technical trends (e.g. "Should I learn Swift to do iOS work or keep on using Objective-C?"), and I'll be using my moonlighting endeavors to stay current with the state of the art. It'll effectively be like working two jobs, but I'm effectively doing that already, if the time spent this week on buttressing the Fresh Comics infrastructure is any indication. :-)
I'm looking forward to penning another post in a year's time and evaluating how well this transition plays out by my third anniversary at CBITs. Stay tuned.
comments powered by Disqus