A Crash Course in Tech Management ConFoo Montreal 2017 ©vmbrasseur Good afternoon, everyone, and thanks for coming today. The topic of this presentation is "A Crash Course in Tech Management." This is a subject about which I feel very passionate. There are a lot of bad managers in the world & I'd like there to be fewer. So I may speak very quickly. Flag me down if needed. VM (Vicky) Brasseur 55 @vmbrasseur ^ vmbrasseur ^ confoo@vmbrasseur.conn I'lTi your presenter VM Brasseur, but you can call me Vicky. You can find me on Twitter ©vmbrasseur. I've had nearly 20 years in this industry. Currently I'm a Senior Engineering Manager at Hewlett Packard Enterprise, serving a team who works on upstream open source development. Slides! http://archive.org/details/ confoo201 7-nnanagement The slides are already available, for those who would like to follow along at home. I'll show this URL again at the end of the presentation. Every single team is different. Every organization has different needs. What I'm about to cover are the points which are more or less generally applicable to all teams but, naturally, your mileage may vary. So when you ask me specific questions, please expect me to answer with "it depends." On that note, there will be time for questions at the end of the session so please try to hold them until then. Also, despite my managerial and business-ness, this talk is going to be light on the business and management jargon. It's less about theory than about what to expect in practice. That said, let's start with just a little bit of theory. Management Defined OrtWrt.COW I n (,UM m I l(riOV How TO DO ims tOlt U) tHC DtP(VttTWt)lT. At UA^t WH6H VOO m evBKYOf^e YOD COOLD H^LP COytK ‘iOWt OP tH^ WC^CUJAD. Knowing everybody else^s job doesn*t ccwipensate for not knowing your own. [ pause for people to read slide ] So what *is* management? Image courtesy of onefte.com; 2011 - 07-07 While we all THINK we know it when we see it, we're usually wrong. That's because many of us learn about management from examples and those examples are BAD. So let's define it... It turns out to be pretty hard to define. "Management is a multi-purpose organ that manages business and manages managers and manages workers and work." Peter Drucker, The Principles of Management Peter Drucker is frequently called the Father of Modern Management, so it makes sense to start with him. How does he define management? Drucker says that "Management is a multi-purpose organ that manages business and manages managers and manages workers and work." Well. That's sufficiently vague and recursive, isn't it? I gotta say, this isn't Drucker's best work. Let's try again. “Management is an individual or a group of individuals that accept responsibilities to run an organisation. They Plan, Organise, Direct, and Control all the essential activities of the organisation. Management does not do the work themselves. They motivate others to do the work and co-ordinate (i.e. bring together) all the work for achieving the objectives of the organisation.” Theo Haimann, Managing the Modern Organization Theo Haimann, author of 'Managing the Modern Organization,' has a definition which is considerably more specific, [read the quote] This definition works but I'm not particularly comfortable with it. For that, we'll turn to Mary Parker Follett. “Management is the art of getting things done through people.” Mary Parker Follett "Management is the art of getting things done through people." In my opinion, this is nearly the best definition of management. It's succinct while still hitting three important elements of management: skill, productivity, people. But it could use a little tweaking. craft! “Management is the ^ of getting things done through people.” Mary Parker Follett Laura Thompson of Mozilla & I had a good conversation about this talk once. She suggested this correction and I agree, it's much better. Now that we have a working definition, let's get a little deeper into it. craft! “Management is the ^ of getting things done through peopie.” Mary Parker Follett There are three main elements to this equation: Craft, Getting Things Done, and People. I'll go into each of them in some detail, starting with... Craft The Principles of Scientific .1 lanagement r>f m; > wrv^^nw TAVLOft }JUL, Sc.a • kl' rtlll i*' »««r« ^ Ml. It •-C*L 1» -■ '’■Ifc# IIAKrVR A r.fi f f r-. irt«» vniK iJio zr.Uitm Image courtesy of Wikipedia Despite the efforts of Frederick Winslow Taylor to quantify it back in the late 1800's, management is not now and never will be a science. Management is a craft. Like most crafts, it can be learned but it goes more smoothly if you have an aptitude. Some of the skills you'll need to have or develop: A tendency toward organization. Not Good With Image courtesy of deviantart User Meatball-man People Be generally good with people. ..or at least enjoy interacting with them. Empathy is the primary requirement for the job. Be comfortable with playing the game of office politics. If you're offered the position of tech manager and you don't want to learn these skills of the craft then please politely decline the offer and walk away. Sometimes walking away has nothing to do with weakness, and evenrthing to do with strength. We walk away not because we want others to realize our worth and value, but because we finally realize our own. Image courtesy of Flickr User deeplifequotes; CC BY-NC-SA No one will fault you if you do. Not every person will enjoy or be comfortable being a manager. It's OK for you not to accept a position with which you don't feel entirely comfortable. By walking away you're doing a great service to yourself and to your team by not taking on a role which you will not enjoy. GTD craft! “Management is the ^ of getting things done through people.” Mary Parker Follett The next important element of management is getting things done. If you're not getting things done then you're not a manager, you're just administrator. A part of the job involves project management and keeping all the ducks in a row, but I'm not going to go into project management in this talk. Project management is a part of the job but only a part. Project Management and Technical Management are two entirely separate but related roles. Today we're only discussing the latter of the two. deep thinker wi or problem soivi H 23 35 41, 9 Image courtesy of Flickr User Tomasz Stasiuk; CC BY-SA Many people get into tech because of the interesting problems that need solving. You'll still be a problem solver as a manager, but the problems will be considerably different. For instance: Image courtesy of Flickr User futuraprime; CC BY-NC-SA Managers have a lot of goals beyond just completing a feature, refactoring a module, adding to the test coverage, or performing usability studies. ourtesy of Flickr User stevendepdib; CC BY You'll have to attend to matters affecting enterprise profitability. if Satisfied... Tell Others Image courtesy of Flickr User Frank Gruber; CC BY-NC-ND You'll be held directly responsible for customer satisfaction. responsible for the efficiency of your team, your processes and your product. Image courtesy of Flickr User mag3737; CC BY-NCSA 1 You'll be responsible for product quality. THE BEATINGS WILL CONTINUE UNTIL MORALE IMPROVES Image courtesy of Flickr User Gen Kanai; CC BY-NC-ND You'll be responsible for hiring, firing, performance reviews and team morale. T You'll be called upon to make informed decisions on a daily basis. Image courtesy of Flickr User Billtacular; CC BY-NC-ND The key here is informed. A great deal of your time is going to be spent gathering and parsing information to prepare you to solve problems and make the necessary decisions which are going to arise during your average day. In order to make these informed decisions, you'll need to know your product, both functionally and architecturally. If you've come from the development team then it's possible you already have this one covered. If not then you'll have to learn. You'll need to know your domain and your users, i.e., know your market. Who are they, what do they want, what are they trying to accomplish? The quickest way to get up to speed on this is to grab a product manager or a member of the marketing team, take her to lunch and pick her brain. You'll need to know your budget. Keep in mind: 'budget' means more than just money. Any limited resource must be budgeted, the most dear of which will always be time. All men can see these tactics whereby I ; conquer, but what ribhe can see is the 0tB:egy out of which victor0s evqlved.%:m ~ Sun Tzu Image courjesy of Flickr User celesjnnechua; CC BY You must concern yourself with the strategy of the business, of your department, and of your team and make informed decisions to accomplish and balance those strategies. The business of tech is a series of talks all on its own, really. You'll need to know your company. What are its business goals and how does your team fit into them? Who are its competitors? mbq master of business administration Image courtesy of Wikimedia Commons Which is not to say that you need an MBA in order to be a tech manager. MBAs and management degrees can be useful and have their place, but they are not necessary for this job. —2 lara * -rou'afc APISTOTT. AOrs n t. V 11 O I H 1 I K I! ARISTOTELIS P O E T I C A LIBER KX >Xfti|OKK THEODOR I CO UL ST ONI. LfcTiovis vaxiitatim i CoDD. IV. Bib.io* TMTC.1' M»PIC*i«fc VlifSOHUM iKOICtM IT OatIKVATIoMlI »TA» AOJUHtIT T- W I N S T A N L R Y, A. M. Co V u H « > T. S c >; \ O X O N I 1, ,.<1 t; : :3 Cr 9 W X>CC LXJCX. V . V - -- To be honest, studying poetry, philosophy, and the human condition can do almost as much to teach you about management as an MBA “You are certified by the community you serve.” Sanjit “Bunker” Roy, TED talk, October 201 1 If you're inquisitive and diligent you can learn everything you need without dropping $100K on a degree. You do not need that degree to validate your skills as a manager. "You are certified by the community you serve" is one of my favorite quotes. It applies so well to so many things. What you do, what you say, what you deliver will speak more loudly about you than any letters after your name. People craft! “Management is the ^ of getting things done through people.” Mary Parker Follett So, moving on to the most important element of management: the people. “Why is it that when I ask for a pair of hands a brain comes attached?” [read quote] Henry Ford was a great and influential man. He revolutionized manufacturing and changed the world. He was also an anti-Semite and, if this quote is any indicator, he mustVe been a first class jerk to work for. Your team are not just hands. Your team is the most vital asset of your company. THEY are much more important than YOU are. This is part of the reason I object so strongly to the term "cat herder" for what I do. It dehumanizes my team and devalues their contributions. In my opinion, if you're a tech manager and have to do any sort of herding— cat or otherwise— then you are doing it WRONG. COMMUNICATION You're doing It wrong Image courtesy of Flickr User Art Rock (Hennie); CC BY-NC Managing is professionalized relationship building and maintenance. As with any relationship, the golden key to success is communication. Your team members will perform best when you communicate with them fully. When they not only know what it is they need to do but also why it needs to be done. What are the reasons leading up to the task? What does the company hope to get out of it? How will they be contributing to the greater good of the organization? What difference are they going to make? You will find that everything will go more smoothly if you're as open as possible. Image courtesy of Flickr User mag3737; CC BY-NCSA There are some very good reasons to hide or not share some information with your team. Personnel matters are entirely verboten, for instance. If your company is going IPO, get VC funding, or is in the middle of some sort of merger or acquisition then there are SEC laws which prevent you from sharing information. But for most matters I find that it's best to be as open as possible with my team. Providing your team with as much information as possible them context, empowers them and enables them to make educated decisions in the course their duties. The openness needs to apply to your door as well (figuratively speaking if you, as I, do not have an office let alone a door). It's important to speak regularly with your team so you can keep them informed, provide feedback and make sure all projects are chugging along nicely, but people must also understand that they don't have to wait for a meeting to talk to you (and it's often better if they don't). Doors allow traffic to pass through them in more than one direction. Don't wait for a regular meeting to provide feedback on remarkable events... be they good ...or not so good. This is not the sort of information which can wait for a regular meeting. "Ya remember that thing you did two weeks ago...?" is never a good way to start feedback, good or bad. You should always speak with people as soon as possible after a remarkable event. Image courtesy of Flickr User Brenderous; CC BY-NC-SA Aside from timely, feedback also has to be effective. Think of it like a feature request or bug report. When one of those crosses your desk, what do you want to see? Details! This thing broke... Image courtesy of Flickr User sheeshoo; CC BY-NC-SA ...at this place... ...when I did this... Image courtesy of Flickr User MarkyBon; CC BY-NC-SA .on this platform. When providing feedback, include as much data as possible. Tell people what they did, when they did it, and why it was remarkable. Remarkable events are those which either exceed or fall short of expectations. When providing feedback, be specific in what ways what they did did not meet expectations (either positively or negatively). If comnnunication is the key to managing then expectations are the key to communication. It is paramount that you set up expectations at every step in the process. Behavior-driven development ☆ In Angtno^ng, b^Knvof-drlv^n dovoloprmnt (BOO) is a sottwart devek)pmsnt procass that amargacj from tast-dnvan davwHxnent (TOO) ’ B^havw-dnvon cteve^opmant comt>naf tha gaoaral tachnipuas and prmop^ of TOO with idaas from docnam-dnvan dosM^n and onantal ana^y^ and d»gn to provida sohwara davak}pciant and nnanaparnant taams wtth sharad to^ and a sharad procass to coMaPorata on xtftwara dava«oprnant ’ ^ AntxKigh BOO IS pnrc^paliy an daa aPout how sohwira davak)pfT>ani shocM Pa rnanagad by boh busmass mtarasts and tachrx^l msight. tha practica BOO doas assuma tha usa of spacMad K>ftwara toots to supp>rt tha davak)pcnant prooasa - Although thasa toob ara ottan davatopad ipacihcaiy for usa in BOO proyacts. thay ca» ba saan as spaciahrad fomns of ^ha tooing thal suppols tast-dnvan davafofmant Tha toots sarvs to add automahon totha uDKjuftous Uingijaga that »s a cantrai thama of BOO. BOO IS largafy faci&tatad through tha usa of a smpta lorran-spach'c Uinguaga (OSL) usmg naiurU lanpuaga constructs (a g., Enghsh i^ santancas) that can axprass tha bahavKX and tha axpactad ot^ocnas Tast scnpts hiva long Paan a popubr apphcaitKin of OSts with varyv>3 dagraas of sophstcaton BOO m considanad as an aftactrva tachnicai prachca aspacsHiy whan tha *probiam spaca* of tia busr>ass proPtann t> sofva is oompiax Think of it like Behavior Driven Development for your team. We can express this in pseudo BDD terms... Given you are performing $role When $event Then you will $action. Make all expectations explicit and specific. As I mentioned earlier, management is professionalized relationship building and maintenance. Just like any other relationship, you cannot hold people to unexpressed expectations. That's how relationships break up. Expectations will be the end of you EXCEED THEM Image courtesy of FUckr User R_rose; CC BY-NC-ND So let's say you HAVE expressed your expectations clearly. If so, then you MUST either hold people to them or tell people that an expectation is no longer valid. A process or rule which no one uses or enforces is just noise and distraction. It's a burden, both mentally and organizationally. No one will take you seriously if you dictate superfluous expectations and processes. Just don't do it. There's another set of expectations that are always required: CONSEQUENCES. We all think of these as negative, but they're not always. Once you've established the expectations you also have to establish what happens when those expectations are met or exceeded. Your team should never be in the position to ask "Or else what?" Image courtesy of Flickr User origami don; CC BY-NC-ND Take care when establishing all of these processes and expectations. People, in general, are suspicious and somewhat resistant to change. Try not to add too many things at once or you'll overload people. Phase your changes in. It's like iterative development. Start small. Make a little change... Image courtesy of Flickr User plums_deify; CC BY-NC-ND ...run your tests to make sure you haven't changed expected functionality... ...make another small change... ...test again and, uh, naturally fix anything that may be wrong. Image courtesy of Flickr User plums_deify; CC BY-NC-ND By the end of the iterations you'll have a fully formed and functional process. If you make a lot of changes at once you'll break your relationship build and backing out the changes is nowhere near as simple as a "git revert". Subjecting people to a lot of changes at once makes them very uncomfortable and frustrated. It's really bad for team morale and productivity. There, are of course, many other things which can have a negative effect on morale and which you should try to avoid at all costs. Uncertainty... Gold-bricking team members... 505 Version Not Supported ► Lack of managerial support... Unappreciated- ' j^deiucled youns sos5ipin;5 Tinny H ^^'Thoishc hijgoifitD cxcecdnsi) furni/. he tolr. ndf Alory > To X'ber John Djfy . ^ i , Wlh 5 TiI^!S that x/sre cKeerPui ands.iun>-^ i/M ooleuiu Jghi' Duiy (.'julil twvc iSSA See joVes evea »v^en they we'e clever Tie lookc.f suTTic Ir\ Mi r)0LtKii \d Ki eyei Wii luMini tAaP poor Uinny Tri>\.p<' li - ^ V; / ' ‘ '^-nv: ' •e '•O * Unappreciated effort... Image courtesy of Flickr User Aria Nadii; CC BY-SA Working stuff that never gets used. on Boredom Bored people quit. Image courtesy of Flickr User nineonesix; CC BY-NC-ND As a manager one of your most important tasks is to make sure that your team is challenged and that each of them grow professionally. V. WELL TRAINED PETS a PEOPLE I«ll| riesy o lisaaiisaiaiBisiiE wigart; CC BY-NC-ND Professional development and training is important to a healthy relationship. ConFoo CA March MO. 2017 '^anjcj H ; Pro^ifn V“ TTur ci»f?*Cor^‘jrt Biog aoch^ ^ What People Say About ConFoo e ^ \O0 UI^ is 3 rnulUHtft > 1 56 presanfCiiCJom by popiiarvitmiaCkjnd Speakers WHAT PEOPLE SAY > Foooedcsnpra^rnatksokiCkinsfor webdMioper^ > Gredt content and amazing experience. ABOUT s Sr /“ Cimw;gd ^ Oii r . tt)fy kamed 3 dayfthonm Syemo/ Montreal 201 7 sponsored by Books, workshops, training sessions, conferences like this. These can all help prevent boredom and stagnation. I've actually fielded questions from new managers who are freaked out by the idea of helping their team learn. "But.. .they'll grow out of their current role and LEAVE!" Sure, they might. Or they'll grow out of their current role into a more senior role on your team. And I'll let you in on a little secret: It's all but inevitable that they're going to leave anyway. Let's have a show of hands. How many of you in this room have only had one job? OK, keep your hand up if you intend to keep that job for the rest of your professional life? Right. Point made. Hands down. People move on. It happens. Naturally you should try to minimize it. It's expensive--both in time and money--to hire and train new team members. But you need to be prepared for it and make departures friendly and productive. AND \VS 6yE-67£>c;Q0D6Y£^ I Do your best to keep team happy and productive and learning, but recognize that sometimes people just need to move on from a relationship. While, yes, fostering professional development has the potential to lead some people to evolve off your team its benefits far outweigh the risks. 4 Hours You'll get increased productivity... MeBERIlUDA Tr|A^JGLE“/ ...improved product quality... BE A HAPPY WORKER! Image courtesy of Flickr User Personeelsnet; CC BY-SA ...team members who are challenged and pleased to be at the office. Another good way to keep morale up is to dictate as little as possible. You'll need to assign tasks of course, but other than that I've found things go better if I tell people to do things as little as possible. "Because I said so" is never a good reason for any of your team to do anything. Lead. Don't control. Just because you have authority it does not mean you have license to use it at every juncture. This isn't going to work unless you hire people you TRUST. Hire them, provide them the training they need, point them in the right direction, get all obstacles the hell out of their way and watch the magic happen. Trust is KEY. If you don't trust your team then you need to replace them because they were bad hires. If they're not bad hires then you just have trust issues which is WAY out of scope of this talk. Respect is the currency of the realm in tech management. Respect is impossible without trust Hire people you trust, Provide them the training they need, Point them in the right direction, Get all obstacles the hell out of their way And watch the magic happen. So let's go back to something I said a moment ago. Hire people you trust, Provide them the training they need, Point them in the right direction, Get all obstacles the hell out of their way And watch the magic happen. You cannot get things done through people if your people cannot get things done. This not only means getting your team the resources and training that they need to do their jobs, but it also means running interference for them. You are a human shield, protecting their time like the priceless treasure that it is Image courtesy of Flickr User Andrea_R; CC BY-NCSA You need to defend your team. Have their back. When Sales knocks on your door asking for a flying unicorn you need to be able to (politely) say "No, that's not possible right now and this is why," rather than taking on an unreasonable burden for your team. Are you lonely? Tired of working on your own? Do you hate making decisions? HOLD A MEETING! Yqu can — • See people • Sho’A charts • Feel important • Point '//ith a stick • Eat donuts • Impress your colleagues All on company time' MEETINGS Image courtesy of Flickr User lain; CC BY-ND FHt PRACTICAL ALTERNATIVE TO WORK Also, you have to keep the meetings to a minimum. Don't have a meeting if an email will do. Don't invite more people than necessary just because you don't want someone to feel left out. Don't hold meetings w/o an agenda. Always start on time. Never run late. Your job is to attend meetings. Your team members are paid to code, to test, to document, to design. They are not paid to deal with administrative and political bullshit. You are. This is your responsibility. Image courtesy of Flickr User dogwood & poppy; CC BY-NC When the shit hits the fan, the role of "The Fan" is played by you, not by your team. If you're not OK with that then please reconsider tech management as a career choice. Since we're on the topic of the less appealing aspects of tech management, you should know that it can be a fairly lonely job. rc% ne Reason for Change f ^ ' j ' V / Image courtesy of FUckr User barefootsong; CC BY-NC-SA If you're moving into a management role within your organization you're suddenly likely to find that you can no longer talk to your work friends anymore. You're going to be dealing with a lot of things which are personnel related in one way or another. As I mentioned earlier, while in general 'open' is good, these things can't be shared with anyone. You can't really commiserate with your team. When Sales DOES show up asking for a flying unicorn you can't blow off steam by complaining about it in a team meeting. You cannot publicly throw other departments under the bus like that. It's patently uncool. Even if another team or department is populated entirely by asshats and chowderheads you do NOT vent to the team. Don't talk out of school. Don't be a jerk. Don't be That Person. i 1 k * Trrr i /AM * c - AM Alt Image courtesy of Flickr User kayepants; CC BY-NC-SA So while the other department is filled with asshats and chowderheads, your own is undoubtedly brimming over with brilliant, clever and interesting people.... People with whom you'd love to sit down and chat at the pub. Performance reviews in Hell. People whose performance reviews you'll be writing. \im\N. closetohome. com People you may one day need to lay off or fire. / n K No matter what, be cautious when becoming friends with your team members. BY ALL MEANS be friendly and personable and get to know them as the spectacular humans that they are, but be careful if you become friends with any of them because you may need to hurt them some day. If you do a good job of relationship building then there'll be plenty of time to be friends with them after they (or you) inevitably move on. The big question... Now on to the big elephant in the room. “Will I still be able to code?!” Image courtesy of Flickr User vinche1985 CC BY-NC-ND "Will I still be able to code?!" NO Well. ..OK, maybe. A bit. Kinda. Image courtesy of Flickr User Visionello; CC BY-NC 07.03 ofX!fr:tack-d ii.r:>ii 4 .DC Coffen Klatiih r» . 0. Ti... Of: or C.. H.. Can... w IHK nr. tal Pi M.30 11. 2D [tent Li«xi atiim] N iWtl . DPSVaiialU... 12 nc 12. 3C Meet wit,.. CPP - 3 . 2 D M{!ei with Mo.. DPS Team I. in W ‘tyinb iiTinb GOm 12 J... 03 .. 12 J... 03... t;vinb Go. Call iivtiii. Project BliM. 17 X 0 1st Suridny at Kt'XJ Call Ailfi ^ 12:30 Ljnch VMith b... When Tm not freelancing, this my work week. Granted, this example is a little severe but it's not too atypical. It also doesn't include time producing deliverables from all those meetings. If you were a manager or project manager, would you entrust features or bug fixes to someone with a schedule thus encumbered? You'd be a fool to put your product at risk that way. If you are hired as a tech manager then your primary responsibility is to manage. You are no longer paid to write code. That said, you still need to stay in the loop, technically speaking. If you don't you'll be incapable of making those informed decisions that I mentioned earlier if you don't understand the product, the code and the technology. So how do you do this? You can attend and run code reviews... You can run technical design meetings. You can (and should) read commit notes/diffs ''lit o vmtxasseur / laupload OCote It 0 PiM r>Q u i Wiu Oopc. L«tt floma d«lMig lln«« In tft«r«. ^movod rtow. — »l »r vmPcMPUf c o m miatd on Miy 16. 20i4 BhOMTQ 1 ctf^nvv j ’ V wf9t C abdlUdrtt ttd 4 diitl icn# 4 mmm pjr ❖ ftdfiU - filM • ^ Ci) »¥ 0 commtfvip Ofi conml llMtf4 You can (and should) fix small bugs... *• a OkM o Umwttch ^ 1 #aiiw « VPM 1 I parent Wiccfl r«^it nMif«63»4tM)f2f417c1M^3Pef«M114c44 UnMIid 8p«il Vlfw fi LOdi POItelfMflBM rr READMEjnd Internet Archive S3 API: Documentation Thli ifm ur» **g l-rie?r-eff r*?^•vl1r API, ?ik's 'lAfi'l • T’ct "Ictxlei 3XJd^sno=• is a tec'*nlo3J ide^Jy o'*e whD s corrl:tt3We h the L "uxOJNiX cofriran; I ie e^vifomreni ^n% c^-muTmil in ji** nTWr^finn-writ y/iir< ;t**d % nnt ^.*rhtiin cir siorxirtftd Inturmi Arnh vw. P M^tnie ..mi h n .'yij.. -run- >%ir-i ih^ iMfln jU lASri vinni. T^enraf nn. an !-n aupanrt Mgn r v r..*^ IntnrnfWftin- ahoi.l rana VI-.5 5-ppDl fcr :he ooc.n^nt 3nd IAS 3 . Contents » IniroAjrUnn • S Jirnwy of API F jndb'-al 1y and FAOs • Gating S-pport for Tha Doc jmentation • O^'ink 53 t 9 irt ratTrAr^ » nyfttiam FkWMlrnT»«nrfl • CoTipalDllly wtnAniazonSS » Paaang Author zation Credent eta to 1AS3 » Idertfera » & ^laHrirm/ rrf »r« Pan aavi ri^'^Arr* You can write the documentation. PROTOfYPES 5S9 2? Image courtesy of Flickr User noodlepie; CC BY-NCSA You can assign yourself something larger to work on but only if it has a flexible or non-existent delivery date. OUtradChy S>v<m C^3:A**?:rrn s nK ‘r*. * Outreachy helps people from groups underrepresented in free and open source softv/are get involved. We provide a supportive community for beginning to contribute any time throughout the year and offer focused internship opportunities tvwice a yearwnth a nun^ber of free software organitations. Currently^ internships are open internationally to women (cis and trans), trans men, and genderqueer people. Additionally, they are open to residents and nationals of the United States of any gender vrho are Black/African American, Mispanic/Latln@, American Indian, Alaska Native, Native Hawaiian, or Pacific Islander. Wc arc planning to expand the program to more participants from underrepresented backgrounds in the future. Free and open source software organizations and supporting companies arc Invited to express Interest in offering internships or sponsoring the program in the next round by August 22, 2016. Applications for the program will open on September 5 and the deadline for applying will be October 17. Participants 41 ifvtirAi tar ?Di: wiinfl y tft 1 IntMMA '.vhft up AfJ Iftr hnrh CiitrMrt'y in*! SuTimif 0 * :rd after cwrcln:: between acmi*kctrator& of xti cfc^rams, -lACfc acDcptoc •>cr C*<c«lr 5^ ifk"*c^of Cede! https ://www.gnome.org/outreachy/ "• You can mentor junior coders. bg h / sign 141 pKspb projods «v9nts fraring donata ^ OpenHalch is a non-profit dedicated to matching prospective free software contributors with communities, tools, and education. & We provide online tools for new contributors Build skills i^lrh nnnnnn :Dnttn»ingpc!; with cur training missions Find a project nnoiMW •fiUKfi Artfnr.fi o^nn snurcc by skill, difficulty, cr crcject Get help Afik ufi qunr.rl6nfi «bo.if finding p^npnts and cent' bj’.Ing ♦ Add your project ufifr rnifi filfft fo rt\Akt ynur ’Bvontc projee: r->nrc sy64coniing « We organize and support outreach events ^ Open Source Comes to Campus "'iTft.igf i^r.r4shr.ps c.nUgit’. wp twv:h •'ip iprt* Qpw-'h'i r.f ^•.de'its 'k.'bw 1r. Ari-cp.vp r cpAi :f.i.r*.p cr.rm.nlllw; In-Person Event Handbook Wa AhATft ulvkp nn i.rrl^ ajc^'a^am ;n1ntA t'.vrkAtPr.r ii>n w.nliAia::A^tfc1lfYJ’Ar^*vf.r*rt:i.*r.nJf. r.nA^Ltr.i.nr.p .'imA:*. And of course you always have open source. Just please don't make the mistake of thinking you'll still be able to contribute code at anything like the productive level you used to. If you try to balance both coding and managing you'll very quickly find that you're not doing either very well Goal So what's the end goal of all of this tech management claptrap? Not the business goals, but your personal goals for the management role? That's up to you, really. BEING DISPENSABLE As for myself, my goal is to make myself dispensable. No, really! If I can leave for a week and nothing goes off the rails then I know I've done my job well. It proves that I've hired the right people, trained them well, and set up and documented the procedures and expectations which meet their needs and the needs of my product and my company. Learn more Each one of these slides could probably become an essay. There's so much to say on this subject. So here are some ways you can learn more. I* I . I I : R h . DRUCKER • ^ ^ » I ■ ■ t t » -• ♦-* — • •>-4 ^ • ♦ Tlic Practice of Management Peter Drucker, "The Practice of Management," is a good place to start. It gives you a decent (if dated) foundation on management and business. "Managing Humans" by Michael Lopp, aka Rands of 'Rands in Repose' is a fun read that'll further introduce you to some of the challenges you'll face as you move from managing bits to managing people. Every single book by Bob Sutton should be required reading for most managers. His book titled "The No Asshole Rule" is one of my all-time favorites. Harvard Business Review THE MAGAZINE BLOGS VIDEO BOOKS CASES VJ Re^gistered | limitpjj acce5« HBR Blog Network Get dally Dosis h /cur inCox Q http://blogs.hbr.org/ The Harvard Business Review blogs are a great place to learn new things. And, unlike the HBR itself (which is also a great resource, BTW), the blogs are free. Manager Tools podcast OREILLY • ' ... • , » • i' >. > r*. < rwid 1: 1 Making Users Awesome 1 No, it's not considered a management book. But it really, really should be. The mindset which goes to making your product's users awesome is very similar to the one which is needed to make your team awesome. Either way, you should read this book. zotero Cr»sli CourM in Tccti Maaiigcfficnt ED https://www.zotero.org/groups/ crash_courseJn_tech_nnanagement/items VM (Vicky) Brasseur 55 @vmbrasseur ^ vmbrasseur ^ confoo@vmbrasseur.conn And, of course, there's my own professional blog. There's also my Twitter stream if you don't mind sifting through me randomly talking about coffee & cats. If you have additional questions, you can also reach me via email ©vmbrasseur.com. Q&A @vmbrasseur confoo@vmbrasseur.conn http://archive.org/details/confoo2017-management ”Wc h9'/t(tinc}cr jiJitcnt tliii rflaUs to ncih<% i*/«Ve btea islk n^ ^6wti(. " Thanks for listening. Now, are there any questions?