If there’s one thing that I want for the 10 of you that read this blog (hi dad!), it’s that you know that I want to be as transparent as humanly possible with you - about both the successes and failures. I started with Concur as a development manager about a year ago and was promoted to director a few months ago. This is post is an update of what’s gone well, what hasn’t gone as well, and some areas where I’m not really sure whether what I’m observing is good or bad.
The Good
Keep in mind that this is a self-assessment, so if we work together and you disagree, please come and tell me. There are few things worse than having a set of beliefs about yourself that are not even close to shared by the people you work with.
Hiring
Over the past few months, we’ve been able to attract some really incredible talent to the team - to the point where we’ve actually passed on candidates, not because of capability, but because of the team’s assessment of “cultural fit”. This is an amazing problem to have and I like to think that in my own excitement for our team and our mission, I’ve been some small part of creating that attraction. I’ve always said that I want to hire the same people that I would actively pursue for a startup, and I feel good about having built up a team that fits this description.
Supporting Growth
Whether it’s hardware, training, or jumping in and pairing, I think that I’ve been successful at supporting my team through various challenges and activities. Obviously, they are the true judges here, but this is my perception nonetheless. The data point that I am most proud of on behalf of the team is that almost all of them joined knowing relatively little of the technology stack that we’re using (node, MongoDB, shell scripting, Docker, CoreOS, AWS, Vagrant, etc.) They have all learned and been able to apply an incredible amount of knowledge an a pretty short amount of time. And given the continued rate of evolution - particularly in the DevOps space - I feel confident that I have the right folks in place for the road ahead.
Shipping
Even though we’re a small team, we’ve been able to deliver several significant bits of software over the last year. Some of these, such as the Starbucks connector and the Developer Center, have been public-facing releases. Others contributions have been internally focused and have included foundational tools and processes in support of containerization and DevOps.
The Less Good
While I’m overall satisfied with how things have been going, there are several different areas where I know that I need to grow. I’ll discuss them, as well as some of the strategies that I’m currently executing against to improve my effectiveness
Playing Nicely with Others
When I joined, there were just 3 of us and we had an immediate challenge to go solve. All 3 of us were already pretty like-minded in terms of vision for building and shipping software, we all 3 had a bit of an “us vs. the world” mentality when we looked at how software was built throughout the rest of the company, and though we fought (oh did we fight), the focus was always on shipping our project and demonstrating that everyone else was just wrong. What turned out to be simultaneously good and bad here is that we succeeded. We shipped our project in just a handful of months after the same project had basically stalled out after a couple failed attempts over the previous year. It created a lot of individual success for our little team, and was probably a big catalyst for the team’s growth. At the same time, it had a negative effect in that it further solidified the “us vs. them” attitude - not just in the sense of how we viewed the rest of the company, but also in how the rest of the company viewed (and still views to some extent) us.
To be honest with you, I don’t mind some of that as I think that fostering a sense of elitism can build cohesion in a team. I also think it can make the right people in other teams uncomfortable in a way that pulls them out of complacency and contentment with the status quo (more on that shortly). However, in a recent one on one, an advisor whose opinion I really value, said this to me - “as a dev manager, your primary focus is to make your team successful; but as a director and a leader within the larger engineering organization, your focus needs to shift into making not just your team, but also other teams successful”.
I clearly have some growing to do here, but here’s what I’m currently doing. If you’ve traveled this road already, I would love to hear more of your story on how you grew through some of these challenges.
- Building and strengthening relationships with counterparts in other teams. This is a tricky one because it’s not just about finding the “top person” in a team, but rather about finding the “right person”. One of the things that I’ve learned is that the folks at the top of a particular organization are many times disconnected from the execution. So one of the things I’m doing is finding the individuals that can make things happen in those organizations, working closely with them, and then singing their praises to my direct counterparts in those groups, as well as up their management chain.
- Toning down. I don’t bring it up as an excuse, but I came up as a high-energy developer and I spent nearly a decade at Microsoft. The result is that my natural way of interacting with people tends to be pretty biased towards getting things done and I have a tendency to overlook the cues of how people are feeling. This wasn’t ever a completely good thing, but it served me better as a developer than it does now that I’m leading a team. The strategy here for me is simply to pay closer attention to those cues, and ask more questions. I suspect that I’ll continue to develop a better sense as I go along.
Knowing Your Audience
I don’t have much natural respect for titles (another thing that has gotten me in trouble in the past). And as such, I don’t really expect for anyone to give me any respect or deference just because of my title. I do expect, however, to be respected for the quality of my knowledge and experience, and so my natural inclination is to weigh into most technical discussions on the team where I think I have something to contribute. One of the interesting observations that I’ve made recently is that not everyone holds my same view regarding titles. There are actually many people inside of the company and outside, that for a variety of different factors, have a much higher sense of power distance than I do - and so when I give a technical opinion on a topic, those folks tend to interpret that opinion as an order. The result is that they either silently execute on something that they haven’t thought through or [worse] silently do something they disagree with and grow bitter.
The thing I’m trying to get better at here is learning an individuals view of organizational dynamics and then shaping my interactions to pull out the best of what each individual has to offer. I don’t really have great strategies for this at the moment, so let me know if you’ve found some things that work.
Bringing People Along
The thing about getting people to follow you, whether on your team or across teams, is that you’ve got to give them a compelling reason. And that reason needs to be much more substantive then “you’ve convinced them that you’re better.” I realize that this must sound pretty obvious, but can you think of a person or a team that has used this tactic before with you? Have you been guilty of it yourself? If not, you are a better human than I.
There are really 2 strategies that I’m trying here.
- The obvious. play nice with others
- Go beyond the ideal and theory. It’s not enough to tell someone that they should do something because some RFC or famous Internet person said that they should. You need to dig into their scenarios and really understood their concerns and drivers. I’ve found that I too easily I just assume that because someone doesn’t drink the kool-aid on something that I’ve bought into, that they just don’t get it and that’s the core problem. I’m learning to go past that and understand what is behind their beliefs - and many times (not all, but many) I find that there are very legitimate reasons for their beliefs. The result is almost always a collaboration and solution that satisfies both sets of goals and constraints.
Good or Bad??
During the time that I’ve been hiring a bunch of great people into the team, I’ve been losing people - particularly, people that were with the company from before I joined. Remember that tester I mentioned in a previous post? Gone. And there have been a couple devs on the team that have gone along with him.
Now this is a tough one, because every individual is different, and everyone’s motivations are different. Clearly in the case of the tester, I handled things poorly from a communications perspective and didn’t take into account the individual’s feelings. That’s all on me, and I’m working to improve.
However, I push the team constantly - and am hopefully an example - to be constant learners, to always challenge the status quo, and to never be satisfied with where things are. One of the things that I’m starting to see, though, is that not everybody wants to have that kind of a work life. I don’t know whether this falls under the same umbrella as the 9 to 5 Programmer - my gut tells me that it doesn’t - but I could be wrong here. Anyways, recent observations make me question whether its unfair to impose my value system of constant and rapid evolution on the team (whether implicitly or explicitly) or whether its OK that this mindset is an understood part of being on the team - and that related attrition is not only expected but even a good thing.
In Sum
When I first started running into some of these challenges, my first thought was, “oh crap - I’m experiencing the Peter Principle. I’m now doomed to failure!” However, as I’ve reflected on the last year, the biggest thing that I’m realizing about that initial fear is this.
The Peter Principle is not static - not by a long shot. It’s a choice to accept new definitions of success and evolve your strategies and tactics.
So have I peaked? Nah - I’m not ready to do that just yet :) I expect to fail - and I expect to learn - and I expect to grow.
“There’s a famous old quip: ‘A lot of people in business say they have twenty years experience, when in fact all the really have is one year’s experience, repeated twenty times.’”