On leadership vs management

This post is a flight of ideas. Blame Charity getting my brain going

This morning, I came to twitter to find this thread of tweets from the always awesome Charity majors.

This got me thinking about how it seems many poeple in our field, and so many companies by consequence, have adopted the attitude that leadership comes from above. That you must have a certain title to be able to lead in your organization.

In individual contributors, this can be a sign of lack of maturity. An engineer should not be considered 'senior' unless they exhibit a sense of ownership towards the business and a sensibility towards what's best for the customers. Not only that, but a senior engineer should also be capable of influencing engineers around her to 'do it right'. That sometimes means the longer way and sometimes even means the less 'cool' tech. A senior engineer, even if not a 'team lead', should be able to argue, with data, for solutions that provide the most business value with the least amount of risk.

Similarly, if Junior/associate engineers are to grow in their careers, they should be encouraged to find their passion and translate that into business value. As engineers, we may be insulated from the customer facing work by having support teams and customer sueccess reps but that should not mean we cannot be aware of how the quality of our work impacts the customers and our co workers who have to talk to the customers.

Sadly we do not learn enough of that in our fancy CS degrees. Too much emphasis is put on algorithms and software and not enough in understanding how to talk to the business side of the company, how to have empathy for the customer facing team members and how to behave and think as one team that is ultimately providing a service to paying customers. I was guilty of this as a fresh grad. I was looking to write code, to play with software that was new to me and handling customers' issues was a 'nuisance' that I just had to deal with. It took the fall of my first company to learn that code and elegant design are nothing if they are not providing a business value and solving a problem for a paying customer.

This is also a problem of managers. Micro managers, among many other harms, reinforce the idea that only managers can decide how things are done and make decisions. Select all managers who do not advocate for their team and know how to say no during critical organizational planning imply to the team that they cannot drive excellence themselves but have to be told, by some laid out plan devised by executives, what to do.

Now, that is not to say that the executive perspective is not of value. Far from it, an executive has the position of knowing the market landscape a company is competing in, and owns the strategy of the organization to develop an edge in that marklet. But the executive is not to be expected to know the details and severity of tech debt the company has accumelated and what parts of said tech debt can closely endanger meeting this needed business edge. Without individual contributors understaning their company strategy and making these connections between "this service is old and needs a refactor" and "we need this to make that new product scalable and an easier sell", the executive team may never see their lofty plans to fruition and ultimately the business will lose customers.

So what can be done to make this better?

Yes it involves everyone...

It is important to make 'sense of ownership' a part of performance review for everyone, not just for team leads and line managers. It should be something junior individual contributors strive to internalize in order to grow in their careers and it needs to be something senior team members have to exhibit and are scored on. Remember, it is what goes in the performance review that shows what the company really values. Since it is literally 'putting money where your mouth is'. One thing that is very dangerous, is mistaking when an individual contributor is sounding the alarm about an architectural problem as them being "a cynic" or a "pessimist". That is especially a problem that women in tech face as we are expected to just be merry and happy all the time and when we point out issues during design reviews, it tends to be seen as being 'brash' or 'harsh'. Actively burying concerns from team members and chalking them off to 'personality' or the ever non inclusive phrase 'team fit' will only spell long term dysfunction for your organization. Ignore at your own risk.

Line managers, those whose direct reports are all individual contributors, need to constantly let their reports bubble up pain points in the company tech stack. Involve them in the roadmap planning process. Make sure to communicate to them the strategy and not just 'here is what we will be doing'. For many people, knowing the why goes a very long way in being invested to do the best possible job. Line managers should encourage the quiet ones to still participate in this discussion even if not in front of the whole team. Sometimes the best feedback on 'what needs to be fixed' can come out of 1:1 conversations. Not everyone is comfortable sounding these concerns in a group.

Finally, directors and executives should be open to feedback from all levels of the organization. Do not wait for this to come to you. At my current company we do a biannual survey that is deliberately anonymous but allows everyone to provide the executive team with feedback from all levels of the company. It is super important to not just solicit this feedback but to transparently also create action items based on that feedback and report back to the company on the progress of these action items.

Thanks to Charity and Nicole for sparking this post and to Camille Fournier's book that has given me a great perspective into management.

comments powered by Disqus