Fantastic engineering management is…
Tuesday, July 12th, 2011I’m going to write a series of posts on different career tracks in software engineering and design over the next few months. This is the first of ’em, I don’t have a timeline for the rest but will get to them all in due course, and am happy to take requests in the comments š
Recently, I wrote up two Canonical engineering management job descriptions – one for those managing a team of software engineers directly, another for folk coordinating the work of groups of teams – software engineering directors. In both cases, the emphasis is on organisation, social coordination, roadmap planning and inter-team connectivity, and not in any way about engineering prowess. Defining some of these roles for one of my teams got me motivated to blog about the things that make for truly great management, as opposed to other kinds of engineering leadership.
The art of software engineering management is so different from software engineering that it should be an entirely separate career track, with equal kudos and remuneration available on either path.
This is because developing, and managing developers, are at opposite ends of the interrupt scale. Great engineering depends on deep, uninterrupted focus. But great management is all about handling interrupts efficiently so that engineers don’t have to. Companies need to recognise that difference, and create career paths on both sides of that scale, rather than expecting folk to leap from the one end to the other. It’s crazy to think that someone who loves deep focused thought should have to become a multithreaded interrupt driven manager to advance their career.
Very occasionally someone is both a fantastic developer and a fantastic manager, but that’s the exception rather than the rule. In recognition of that, we should design our teams to work well without depending on a miracle each and every time we put one together.
Great engineering managers are like coaches – they get their deepest thrill from seeing a team perform at the top of its game, not from performing vicariously. They understand that they are not going to be on the field between the starting and finishing whistle. They understand that there will be decisions to be taken on the field that the players will have to make for themselves, and their job is to prepare the team physically and mentally for the game, rather than to try and play from the sidelines. A great coach isn’t trying to steer the movement of the ball from during the game, she’s making notes about the coaching and team selections needed between this match and the next. A terrible coach is a player that won’t let go of the game, wants to be out there in the thick of it, and loses themselves in the details of the game itself.
An engineering manager is an organiser and a mentor and a coach, not a veteran star player. They need to love winning, and love the sport, and know that they help most by making the team into a winning team. The way they get code written is by making an environment which is conducive to that; the way they create quality is by fostering a passion for quality and making space in the schedule and the team for work which serves only that goal.
When I’m hiring a manager, I look for people who love to keep other people productive. That means handling all the productivity killers in an engineering team: hiring and firing, inter-team meetings, customer presentations, reporting up and out and sideways, planning, travel coordination, conferences, expenses… all those things which we don’t want engineers to spend much time on or have rattling around at the back of their minds. It also means caring about people, and being that gregarious and nosy type of person who knows what everyone is doing, and why, and also what’s going on outside the workplace.
An engineering manager is doing well if every single member of their team can answer these questions, all the time:
* what are my key goals, in order of importance, in this cycle?
* what are the key delivery dates, in this cycle?
* how am I doing, generally? and what is the company view of my strengths and not-so-strengths?
* how do I fit into the team, who are my counterparts, and how do I complement them?
Also, the manager is doing well if they know, for each member of their team:
* what personal stresses or other circumstances might be a distraction for them,
* what the interpersonal dynamics are between that member, and other counterparts or team members,
* what that member’s best contributions are, and strongest interests outside of the assigned goals
For the team as a whole, the manager should know
* what the team is good at, and weak at, and what their plan is to bolster what needs bolstering,
* what the cycle looks like, in terms of goals and progress against them
* what the next cycle is shaping up to look like, and how that fits with long term goals
Really great management makes a company a joy to work in, as a developer. It’s something we should celebrate and cultivate, teach and select for, not just be the natural upward path for people who have been around a while. If you truly love technology, there are lots of careers that take you to the top of the tech game without having to move into management. And conversely, if you love organising and leading, it’s possible to get started on a management career in software without being the world’s greatest coder first. If you think that’s you, you’ll love being an engineering manager at Canonical.
July 12th, 2011 at 7:32 pm
“Iāll summarise interesting comments and threads in the next post.”
-your last post
š
July 12th, 2011 at 8:24 pm
Very well put! I wish I had more managers like the ones you describe here.
But what you’re saying is that an engineering team manager doesn’t need to know squat about what his team members do? Let’s suppose I want to be a software engineering team manager, but I don’t know much about programming, I can barely read and write bash scripts… I don’t have any management oriented formal education, nor much experience in managing people, but I think I do have the skills you mentioned here, so, hypothetically, will you hire me?
July 12th, 2011 at 8:53 pm
“A great coach isnāt trying to steer the movement of the ball from during the game, sheās making notes about the coaching and team selections needed between this match and the next. A terrible coach is a player that wonāt let go of the game, wants to be out there in the thick of it, and loses themselves in the details of the game itself.”
I unfortunately had a soccer (EU football) coach that did exactly that, and it hurt the quality of the team big time. I can definitely see how this maps over to a technical team. I find myself drawing many comparisons between sport and work. This one is spot on; thanks for sharing.
July 12th, 2011 at 9:03 pm
What happens when you fall from Division 1 to Division 4 because of some injury or situation and end up coding on the sidelines as a volunteer, never able to get back up to the top or even earn a living wage?
Analogies are fun!
July 12th, 2011 at 11:56 pm
The question is how does one transition from a lackluster developer to a decent manager? It should be a separate career track, but there are very few to no starter positions for engineering management.
MBAs are useless, and project management certifications are only marginally useful without hands on experience.
Any ideas?
July 13th, 2011 at 7:19 am
You perfectly summarize why working for some IT companies it’s so a pain. I’ll show this post to some colleagues, thanks š
July 13th, 2011 at 7:28 am
@Felix
If you think you’d make a better manager than developer, start managing! Most teams can do with help on the organisational front; even well-managed teams have a wishlist of non-dev things that would be great “if we got to them”. Putting in an hour a day extra, with non-dev purely organisational, motivational or information oriented work, will get noticed, and will make you a candidate for internal assignment to a management role in one form or another. Alternatively, it will be a training ground for you to apply for such a role elsewhere if your efforts go unnoticed.
July 13th, 2011 at 7:31 am
@TuxSax
Yes, a manager must know the domain to be effective. In the hypothetical example you’re giving, no, I wouldn’t hire you.
There’s a difference between knowing the domain and getting into the game. Your knowledge of the domain tells you what questions to ask and how to evaluate the players, it helps with team selection, feature prioritization, the allocation of responsibilities etc. But you don’t have to be able to take a judgment call on details – make sure you have a great lead engineer or architect to do that with the team.
July 13th, 2011 at 10:39 am
I found, when doing engineering management, that the way I observed the project was very different from when I was working as a developer. The points about understanding social dynamics, helping the team succeed, etc. are all spot on. But another factor is how quickly you need feedback to feel like what you’re doing is useful. As a developer, the feedback cycle is very quick. You write a failing test, write some code to make it pass, and you’ve made progress. That process usually takes a minute or two. Even if the change you’re making takes hours or days to complete, that regular sense of moving forward is a strong motivating factor for a developer. As a manager, many of the activities you will undertake will take days, weeks or months to play out. It can be hard, especially if you’re used to the tight feedback loop of development, to adjust to that change. I found I spent a fair amount of time thinking about how I could reduce the length of feedback cycles, so that I’d have opportunities to course correct more often.
I also found that, when the team was functioning well, I almost had nothing to do except observe well (that’s not really true, I was always very busy, but there’s some truth to it). While standing back, I’d often see things start to go sideways before those closer to the ground would, and it was often hard to not jump in and “fix” the situation. More often than not, I found that sitting back was better. If you have a good team (and I had the best) people care and will resolve issues themselves. In the end, I found that I would only really need to step in when teammates misunderstood the vision or when a decision had to made that no one was willing to make. I found that stepping in too quickly and taking decision making away from people was often destructive, even if the decision I chose was the right one. This is also a very different attitude than the one a developer has. Developers like to feel in control, if you take too much of that away, they lose motivation. When you see a problem with the code, sitting back and waiting for things to fix themselves rarely works.
Maybe it’s because I’m a generalist, but I think both of these perspectives are important to understand for all parties. Even if you’re not doing a particular role, you can better support someone who is by understanding how to view the world from their perspective.
July 13th, 2011 at 10:46 am
The same things described here I see everyday in my own field (far removed from IT)… Great people excelling at their jobs get “promoted” into managerial positions as part of there career paths… and almost always you end up with a sad/annoyed employee and a very bad/mediocre manager…
If only all HR Departments could get the concepts listed :/
July 13th, 2011 at 3:09 pm
“Itās crazy to think that someone who loves deep focused thought should have to become a multithreaded interrupt driven manager to advance their career.”
THANK YOU.
July 13th, 2011 at 3:15 pm
@TuxSax I think you’re misunderstanding Mark’s words. Keeping in line with the “coach” metaphor: you shouldn’t be filtering out basketball coaches based on their shot accuracy from the free-throw line, but at the same time you also wouldn’t hire a basketball coach who doesn’t know the rules of basketball. They need to know how the game is played and what skills are involved, but they don’t need to be all-star players themselves to be a good coach.
July 14th, 2011 at 4:38 am
Many software companies will reward a good software engineer with a promotion, making him a manager. Better pay, but not necessarily a good match! Additionally, if the engineer is a good one (which is why he got promoted), he’s bound to get frustrated by being a manager and not an engineer! The same happens in academia (my line of work) where we promote senior professors and make them department chairs. Then we wonder why they suck at administration š Some become deans, and they suck even more. Its fairly rare to have both skills in the same individual.
When in doubt, look for merit. Meritocracy rules!
July 14th, 2011 at 1:50 pm
I am in South Africa, is Canonical setting up offices in Cape Town in the near future?
July 14th, 2011 at 8:22 pm
fsargent: As someone whose just starting the transition from developer to tech lead to management, the key for me has been getting the notice of the higher ups, so that I’m given the projects and sub projects to get more of that experience.
Developers and other tech types tend to be shy. If you have an opinion in a meeting – voice it, if you see an opportunity for introducing and/or writing some software to increase productivity, write up the case, and present it your management. Make friends with the sysadmins and see if you can get a vserver, or make it part of the users installed software packages.
As others have iterated, being in management is about seeing the larger picture. So – rather than looking for things that are fun or interesting to do, look for products and practices that increase productivity, raise the profile of the company, reduce costs, increase morale, and then drive the adoption of those.
July 15th, 2011 at 4:49 am
Mark, this is really superb article!
While I’m not applying to Canonical (yet?), what you said about engineering management is truly spot-on. Can’t say it better.
Thank you Mark.
July 15th, 2011 at 5:39 pm
Very well put.
Most commonly in organizations, project management is a career upgrade, with double negative impact:
1- win a terrible project manager
2- loose a great engineer
Some of us do make the transition (ok, maybe I was not a GREAT engineer), mostly because it is in our genes… and this is what this article talks about: the endemic characteristics which make a person better suited to be a manager than an engineer.
But Project Management is a profession on its own.
It requires as much of personal adherence (the same way we choose engineering and not artistic careers) as well as “formal” knowledge. We may be suited to be managers, but we must go through formal learning process, aka, “school”!
This is also something that is difficult to grasp for most people. Managing requires a totally different set of knowledge, and learning it “the hard way” seems such a waste of time. 80% of whatever has to be said about project management is already available out there, and is even being “standardized” (google for PMI and IPMA).
So, for those willing to get into the project management arena, here are my personal hints:
1- make sure that is what you want: don’t let yourself be pushed in to it and don’t do it for a promotion
2- find a good “school”: don’t expect to get a lot of knowledge in 2 or 3 week training courses. Try one of those, only if you are in doubt (item 1 above). If what your learn in those “little courses” does not make much sense to you … beware, it could be a early warning signed that this is not your “ground”. My first “formal project management school” was a post-graduation (1 year), … and I loved it (I had a second one 2 years later)
3- learn from others: pay attention to other Project Managers around you, they will have a precious edge over you: experience. They learned, and applied their knowledge in the field…
4- use it: there is no better way to learn something than to use it. Beware, people will give you “funny looks” when you try to use what you have learned. Remember, Project Management is also about “educating others” about what P.management is (in opposite of what they think it is).
5- a lot of project management is about “people issues” … be ready to deal with all “the crap” that comes along with it. Be respectful with everybody regardless of their opinions and ideas and moods, motivate and guide them, face the problems with them side-by-side, share success with them and … be prepared to loose them.
It is a challenging profession, and although there are more and more “certified” managers out-there, good project managers are always in need. If that is your thrill, I welcome you.
BR
Rui ProcĆ³pio
July 17th, 2011 at 5:01 am
While greater leaders are crucial, there also needs to be engineering tracks which reach the same heights as management. All too often, great engineers become mediocre managers because they feel the height of the management track is greater than the engineering track. The top engineering positions should be earning the same salaries as the top management positions. The management career track should be chosen by folks with a passion for leadership, coaching, cheer-leading, organizing, etc – it should never be chosen by a great engineer who’s felt a ceiling has been hit and management is the only route upward.
July 17th, 2011 at 4:47 pm
Right on point post. Engineers that are very good, can only be compensated when the follow the MGNT track reluctantly in the absence of a reward system for the truly gifted in depth engineer.
I also think that a manager that loves the game and like competition has to devote a large chunk of his time to strategy, strategy for developing his team, their goals and increasing the competitive edge of his company since he has the extensive knowledge as opposed to the intensive that his team posses and he has a broader view of the business and the skills he is in charge of or need to hire.
July 18th, 2011 at 4:00 pm
[…] art of software engineering is totally different than the art of software engineering management, writes Mark Shuttleworth. He details considerations for managing your techies. […]
July 18th, 2011 at 9:06 pm
Thanks for the post, Mark. It isn’t anything new, however.
Joel Spolsky (of “Joel on Software” fame) has been blogging about this topic for quite some time now and – through his company (Fogcreek Software) – has recently published numerous articles, videos and even a training series, on how to build and run superior software teams.
So since you asked for suggestions as to what you can blog about in this series, could you please offer us something unique to Canonical?
Here’s an idea: Fogcreek has a single office and all their software engineers work at this office. Thus, nowhere in their training articles and videos do I find useful material on what it takes to manage virtual teams.
Now at my software company, we all work from home. And as far as I know, some (perhaps a significant amount?) of Canonical’s software engineers also work from home.
Therefore I, for one, would be keen to learn from your unique insight into what it takes to successfully manage a virtual software engineering team.
(And just to second the very first comment at the top; what happened to your follow-up post on your previous blog entry? Many of us were looking forward to it).
July 19th, 2011 at 12:33 pm
The Good Manager can be just a Good User because he’s got the users’s point of view instead of the dev point of view.
July 19th, 2011 at 2:14 pm
Thx for your post and showing your ideas. I am studying “Business Engineering and Computer Science” on technical university in vienna and i am very interested in a management career in software engineering.
I think this comment is in my mind:
“itās possible to get started on a management career in software without being the worldās greatest coder first”
But i think a good manager should know about coding. I think to know about conding is very useful for acceptance in a team, effort estimate and overview of the tasks and goals. Further i think that soft skills like information distribution and the joy on interpersonal dealings are also essential for a good manager. And on every position there must be an identification with the product and company, and recognition from superiors to give full performance. Especially this recognition has to be forwarded from management to the employees.
July 19th, 2011 at 5:03 pm
Many companies claim to have dual paths. I worked at places 15-20 years ago with the same approach.
The issue is generally how to get on the first run of the management ladder. You need to have done something first.
Anyway, as to the more general points about management:
These types of thing are easy to say but less easy to do.
The key point in your post is “clarity”.
Each level (team member, team leader, manager, senior manager, director) needs to be clear about what, why and when they are delivering something, which goes up and down the chain.
The glue that holds it together is 2-way communication and agreement at each level. This enables a common understanding with agreed (and therefore realistic) schedules.
Without clarity and communication everything falls apart, as people will pull in different directions, or stop pulling.
The how and who becomes a function of each level, proposing something to the level below or outsourcing or acquiring the skill.
It all sounds easy, till you consider each word:
– what – this requires specs, that can’t always be defined completely up front, with requirements that change due to market conditions or customers
– why – this requires a business case or a strategic view that may be dynamic since the world is changing
– when – this is planned to be fixed but is often dynamic since problems occur, people get sick, requirements change, timelines are agressive
– how – this may require the acquisition of new knowledge or skills and dealing with unknowns
– who – this may require resource scheduling (and negotiating with other managers) or recruiting new people, or finding external suppliers.
This requires a management team that can cope with the dynamic situation and provide clarity for the guys below. Development is more black and white, but the world is shades of grey.
It be successful takes:
– experience, which is a function of time
– a certain aptitude for analysing lots of requirements and thinking clearly, sorting the wheat from the chaff
– effective communication
– and a certain something that makes people want to follow you (since in a company you can’t order people to do stuff, you have to make them want to do stuff).
The question, linking it back to the original post, is whether being good at software provides you with the skills to do this? I would say there is no single route that is suitable and you can come at it from a number of angles.
The formal processes and tools are there to help you do the job in a quality focussed and reproducible way using agreed phraseology, but the tools and processes are not the job itself, i.e. charts and graphs and lists are there to help make informed decisions, but it is the decisions that matter.
Which leads to the issue of making decisions. When it is your neck on the line, those obvious easy things when looking up from below, suddenly look a bit less easy. Having the courage to make decisions, back them and be accountable for them requires a certain type of person too.
July 21st, 2011 at 9:53 pm
When I started reading I begun agreeing and ended up disagreeing with you [I agreed because I use a similarly analogy to describe the concept of soil fertility), and whilst I accept that good management, whether on the field or in the office is about managing and structuring individual talents so that they compliment each other; when it comes to the creative arts, and lets face it the future of software is in being creative(i.e. intelligent and self referential systems) then such creativity needs a similar management environment. Creativity in this context means developing software that solves problems and has multiple applications. In terms of management, this next level will push that role into a new field.
Good management has always come down to being a bit of a jack of all trades and master of none. Such a manager sees how one part relates to another, they see the virtual structure, the communication pathways and in some respects are visionaries. In a lot of management roles vision can potentially be obstructive but in the next wave of software development vision more than anything is what will drive it.
Vision that goes beyond the management of the team and into the consequences of the teams efforts in the wider environment. Such vision originates from and requires knowledge of the wider environment and in a software context that means understanding the intended application(s).
Similarly software development in an open source context is not about winning, as in a football game, ‘for there are no opponents to defeat here’, nor is it about displaying great team structure; instead its more about entertainment, playing ‘Brazilian style’ showing the World something new and then watching it propagate as it is copied by that World.
Thus the managers of the development of software in the future will need to posses expertise; not in management per-say, nor, as you note, in programming, but instead expertise in the wider environment of software application. They will need to know what the ‘crowd’ came to see and whilst they will continue to need to be ‘jacks of all trades’ in the office, on the pitch they will need to introduce new rules, new techniques and game styles that will set trends and guide innovation across the globe. They will need vision!
SO WORK WITH MORE VISIONARIES!
July 23rd, 2011 at 1:14 am
In order to lead people, rather than just manage them, you need to provide some goal or vision that people can buy into.
The organisation/group/overall endeavour needs to have a vision or mission statement, so that it knows where it is going. As you work your way down the hierarchy this becomes an umbrella under which more bitesize pieces exist.
One part of the managers job is to explain to their people what pieces they are doing and how they fit into the overall picture, i.e. why their contribution is important.
Another part of the managers job is to foster innovation and recognise good ideas. To then sponsor those ideas and help them become part of the vision, whilst not claiming them for their own (visibility and credit are important to people and significant motivators). No-one has a monopoly on good ideas.
I think it is correct to highlight the wider environment.
If you want to encourage uptake and use (i.e. success for your software), rather than writing things for academic or personal interest, then a focus on the end-user experience is key. Solving a problem, or providing a service or solution in an intuitive, useful and efficient way is vital. An understanding of the user and the use-case you are addressing is needed.
But whether the manager is the best gate keeper and decision maker is debatable. Really you would want this user-focussed culture to be instilled in all members of the team, plus you can have specialists or guidelines to focus on this. Sometimes engineering people come up with logical practical solutions that are not quite so user friendly to non-engineering people.
I think another big requirement for a manager is to recognise people’s efforts and say thanks sometimes. It shouldn’t be hard, costs nothing, but somehow seems to often gets missed. This is even more important in a distributed environment.
Sometimes, when under a continuous workload, it is possible to lose sight of what has been achieved, so it is sometimes useful to step back and recognise the good things. I think it helps to foster the team spirit.
I also reckon it is useful to create an atmosphere where problems can be openly discussed. No-one sets out to screw up, so understanding why they occurred and how to fix them helps. You also cannot micro-manage, which means giving people the space to make (non-critical) mistakes so that they learn and grow.
July 31st, 2011 at 9:31 am
How to move from been an SW engineer to management ?
The additional difficulty been we are often talking about engineers often working in virtual teams.
I tend to believe that we live in cross functional world. There is uniqueness in every work environment, but each work environment is primarily made of people, and people all been different, at the end of the day have also a lot in common.
As much depth we can get by working in one type of environment, it can also lead to what I call ābeen institutionalisedā. Like in managing ones life, moving from engineering to managing SW engineers, is about finding the best available answers for given problems , not necessarily only and only based on practice solely in the SW community. It is about managing all resources, people been the most important.
I see Mark that you only briefly mentioned motivation.
In 21st century I think people tend to overlook motivation people have when approaching work. We might be working for a great company, be well paid, but if on a daily basis we are not motivated to give our best, soon or a later that will show up, somewhere along the ā production lineā.
Yes we can all be replaced if job is not well done, but high turn over is never too good for a company.
In motivation lies the Catch 22 situation at work.
Motivation of SW engineers in VT lies in hands of manager .
At the same time , for an engineer to move to management , she / he has to be motivated. Motivation can be a personal desire but it is also environment than can influence it .
Having virtual teams additionally adds to problems, since commonality for people working in virtual teams is the purpose ā this is what holds them together. Purpose which is ONLY translated into common goals, individuals tasks and expected results within the given deadline .
MIT did a study , where by they found out the following :
as one move from less complicated ( mechanical ) to more cognitive (information-processing abilities of humans, including perception, learning, remembering, judging, and problem-solving) demanding tasks , money becomes less and less a motivating factor for doing a good job.
There are 3 motivating factors
– autonomy ( example : Atlassian SW development company in Australia)
– mastery ( example : Linux ā challenge mastery and make contribution)
– purpose ( we are purpose maximisers )
Please see this video
http://www.youtube.com/watch?v=u6XAPnuFjJc
August 3rd, 2011 at 10:06 pm
It’s true that good engineers do not always make good managers and that “promoting” an engineer to a manager can be bad both for the guy and the company. I know a few guys who were promoted to a Team Leader and after a few months or years of struggle they are relieved they could come back to being an engineer.
The problem is that the engineer (or developer) career path is very short. You have: Junior Engineer, Engineer, Senior Engineer and that’s it. That’s as far as it gets. You can come to the end of that path in 5-10 years after graduating. And you still have 20 years to the retirement. The only way to get a raise is to become a manager. And if you don’t make a good manager (and as you said most of us don’t) then, well… you’re screwed.
Anyway, great article. Wish me luck finding my new career path.
August 8th, 2011 at 5:47 pm
Ask your average engineer what kind of manager he/ she prefers and they’ll tell you most of the time is should be someone who has some actually engineering experience themselves. Managers who don’t have that background are typically clueless when it comes to estimating development tasks, prioritizing on different scales (not just the product driven one), understanding the basics of an architecture, how different projects fit together technically, and how decisions impact engineering on the longer term (technical debt). Etc.
I can somewhat agree with your statement about the different competencies that are required for management vs engineering work, but I don’t agree with the implicit notion these are static in people. I’ve played different roles in the past, from ‘deep thought’ engineering to ‘interrupt heavy’ management and other work, and found it fairly easy to switch/ adapt. The key thing I believe is not to have people dangling in the middle; you either give someone a management role and the ability to delegate the ‘deep thought’ stuff, or you let someone dive deep without hassling him/ her with interrupts. But aside from that, I think it’s entirely possible that people switch roles during their careers, and have plenty of example of where people pulled that off. In fact, I believe the most successful managers in engineering are those that have an engineering background themselves and regularly get their hands dirty enough to keep things real.