Building Great Software Engineering Teams

1. Image Credit
2. Who is this guy? • http://BrianLink.me @blinkdaddy • Engineering Manager Experience – – – – – – – – Dell Software Engineering Director of 5 teams Dell KACE Engineering Manager for ITNinja.com CTO and Engineering Manager at ShapeUp.com CTO and Engineering Manager at Toobla.com (dead) CTO and Engineering Manager at Digg.com CTO and Technology Advocate at NSB Group 13 years in software development consulting at Cambridge Technology Partners VP of Engineering at other startups and companies • Just a guy passionate about technology glorifying a hobby into a career 2
3. What will I get out of this? • If you are an engineering manager or aspiring to be one – How to be better at what you do – How to hire and manage great development teams – How not to screw it up • If you’re a software developer – Learn how to participate and contribute to your team – Learn what you should expect from your manager – Learn how to support your manager • Every great engineering manager was once a great software developer 3
4. What Makes a Great Engineering Manager?
5. What is an Engineering Manager? People Process Technology Product Execution Staff Mgt Change Agent Architecture Lean Thinker Budget Scrum Master Strategy Vision Risk Mitigation Problem Solver End-user Advocate Instigator SME Programmer Roadmap Planner Recruiter Career Guide Mentor Obstacle Remover Facilitator Culture Cultivator 5 Coordinator On-Time Expectation Setter Operations
6. Do You Need to Be Good at All of These? People Process Technology Product Execution Staff Mgt Change Agent Architecture Lean Thinker Budget Scrum Master Strategy Vision Risk Mitigation Problem Solver End-user Advocate Instigator SME Programmer Roadmap Planner Recruiter Career Guide Mentor Obstacle Remover Facilitator Culture Cultivator 6 Coordinator On-Time Expectation Setter Operations
11. 11
12. The Ideal Engineering Manager Scores High in All Areas Manager (People) Strategist (Product) 5 4.5 4 3.5 3 2.5 2 1.5 1 0.5 0 Scrum Master (Process) Architect (Technology) Programmer (Technology) 12 Leader (Execution)
13. If You Don’t: Share Responsibility and Delegate You • • • • Someone else on your team Manager: Strategist: Scrum Master: Leader: • Architect: • Programmer: Great (4) Great (4) Awesome (5) Awesome (5) Manager (People) Strategist (Product) 5 4.5 4 3.5 3 2.5 2 1.5 1 0.5 0 Scrum Master (Process) 13 Manager (People) Leader (Execution) Strategist (Product) You Ideal Architect (Technology) Programmer (Technology) Awesome (5) Awesome (5) 5 4.5 4 3.5 3 2.5 2 1.5 1 0.5 0 Scrum Master (Process) Leader (Execution) Tech Lead Ideal Architect (Technology) Programmer (Technology)
14. Horrible Engineering Managers Obvious • Not technical enough • Coding full time • Arrogant • Overprotective of team • Stubborn • Too nice • Indecisive • Jumps to conclusions • Poor Communicator 14 Not so obvious • Talks too much
15. Essential attributes of an Engineering Manager ‟ ‟ ‟ ‟ ‟ ‟ ‟ ‟ ‟ ‟ ‟ ‟ ‟ 15 Build trust Earn respect Ask good questions about challenges and technical details Contribute code and insightful ideas Express an opinion Know when to delegate Be transparent, share company news, executive decisions Protect team from unnecessary interruptions Involve team in decisions whenever possible Drive productivity by creating just enough process for your team size Be an advocate for your developers Shield developers from politics But shine a spotlight on successes and amplify their voices
16. What Makes a Great Engineering Team?
17. Recruiting People Staff Mgt Recruiter Career Guide Mentor Facilitator Culture Cultivator 17 Image
18. Horrible Hiring Strategies Bad Ideas • Coding syntax • Coding problem • Theoretical questions • Specific thinking Q’s • Tell me about your jobs • Deep on most recent • Tell me about yourself • Ask for specific stories • Best/worst attributes 18 Good Ideas • Proud/regret stories
19. Richard Branson – Founder and CEO of Virgin Group "The first thing to look for when searching for a great employee is somebody with a personality that fits with your company culture. Most skills can be learned, but it is difficult to train people on their personality. If you can find people who are fun, friendly, caring and love helping others, you are on to a winner." 19 Credit: LinkedIn “How I Hire” series
20. Jack Welch – Successful Executive from GE Must haves: Integrity and IQ. Should haves: Energy (lasting enthusiasm), Energize (infect others), Edge (make hard decisions quickly), Execution and Passion (work and life). Game changer: “Generosity Gene" (passion for people, rewarding/positive manager) 20 Credit: LinkedIn “How I Hire” series
21. Steve Blank – Retired Serial Entrepreneur and Author Senior executive: “Searching For” or “Executing”… a business model? Greatly affects characteristics. Make pie chart of desired attributes change size, measure candidates by how well they cover each pie slice. Compare visually. 21 Credit: LinkedIn “How I Hire” series
22. Randi Zuckerberg – Zuckerberg Media, Facebook Marketing Excited about your specific company. Knowledgeable of interviewer. Could I see myself ever working for them? Learn from, be inspired, taking company to next level. Relevant and interesting social feed. 22 Credit: LinkedIn “How I Hire” series
23. Eric Ries – Author of The Lean Startup Finding great engineers: conduct good tech interview. Requires a whiteboard. Ask question like creating an algorithm, which forces them to show you how they think, execute collaborative problem solving. 23 Credit: LinkedIn “How I Hire” series
24. Elon Musk – CEO of Tesla, SpaceX, SolarCity “It Matters Whether Someone Has A Good Heart” and Passion Biggest mistake: Hiring the wrong people. (Don’t hire talent over kindness) Better to balance personality and kindness with talent to find better hires. “No a**holes policy” “I hire people in spite of an MBA” 24 Credit: http://read.bi/J1dBlO
25. Personality, heart, passion, culture-fit, intelligence, aptitude • Resume ‟ Not real important • Experience ‟ Think carefully about what matters ‟ Use standard questions? Use a coding test? • Recruiters ‟ Don’t just trust the recruiter. Coach them. • Personality and Culture Fit ‟ Start here. Everything else can be learned. • Trust your gut ‟ Think you found an under-qualified person who might just surprise you? ‟ Think some senior guy can learn a new language and be your tech lead? ‟ Be open. Paint a very true picture of reality of the role and your expectations. 25
26. Culture People Staff Mgt Recruiter Career Guide Mentor Facilitator Culture Cultivator 26 Photo Image Credits
27. Building a great company culture through hiring “More than just atmosphere (great benefits, snacks and ping pong) the best developers want to be challenged, fulfilled and rewarded for doing work they love in a way they can help define.” 27
28. Embodying Company Values • Netflix culture deck describes 9 company values (behaviors and skills): judgment, communication, impact, curiosity, inno vation, courage, passion, honesty, and selflessness • Facebook lists their values up front on its jobs page too: focus on impact, move fast, be bold, be open, build social value 28 Netflix Culture Deck Facebook Hiring
29. The Manager’s Behavior Directly Changes the Culture • • • • Honesty Always Not rewarding hours worked but quality, focus Live the work-life balance you want for your team Groom and reward responsible people (selfmotived, self-aware, self-improving) • The developer has an equal responsibility in maintaining the company culture • Everyone must embody the company values • Happy developers are loyal and hard working 29 “A great workplace is stunning colleagues” “Responsible people thrive on freedom and are worthy of freedom” -- Reed Hastings
30. Team Mgmt People Staff Mgt Recruiter Career Guide Mentor Facilitator Culture Cultivator 30 Credit
31. Hiring Strategy • How quickly can you ramp up a developer? 3 wks? 3 mos? Build a timeline. • What mix of senior and junior developers make sense for your team? • Do you need to hire another senior person before you can absorb more junior ones? J 31 F M A M J J A S O N D
32. Team Management • Management style should complement your hiring strategy ‟ Are you a better disciplinarian who can coach and mentor junior team members? ‟ Do you focus on product and process and rely on a senior self-managing team? 32
33. What’s the right team size? • Agile says 5 +/- 2 • Five seems to work well • But decide for yourself and experiment • Complexity of intra-team communication increases according to Metcalfe’s Law • As team grows, split into more teams • QA: dedicated or central? • UX: shared? how thin? • Defining roles and structuring teams is an art. I often trust my gut instincts and commit to adjust as needed 33 Credit
34. What can a developer do to help the team? • • • • • • • • • 34 Culture of sharing vs. heroism. Demo day Fridays? Speak up when something’s not working Volunteer to help people in need Understand why you’re building stuff Contribute ideas that solve business problems Identify risks Keep track of technical debt Be brave about trying new things Be bold about trying new technology, but ask first
35. Career Guide & Mentor People Staff Mgt Recruiter Career Guide Mentor Facilitator Culture Cultivator 35 Credit
36. Career Guidance and Performance Feedback • What do you want to do with your life? ‟ Don’t be selfish as you give advice about career growth • Annual reviews ‟ No one likes them. Why? ‟ Be direct. Be succinct. Truly aim to help your team grow, meet their goals. • Performance feedback. Good and bad ‟ Be timely in sharing feedback. No surprises in annual reviews. ‟ Praise team members. Share appropriately. • Poor performers and culture misfits ‟ Immediately on an improvement plan. Remove if appropriate. ‟ PIP needs to happen right away and create an audit trail. Build path to success. 36
37. Mentoring • Are you the architect or are you grooming one? ‟ Should the engineering manager tackle all the most difficult problems? ‟ If you help someone else solve the problem on their own it’s much more beneficial • Mentoring is about understanding people’s goals, instigating them to explore areas they’re good at or need improvement in + coaching them on how to grow 37 Credit
38. Technical Leadership • Ask dumb questions • Look for opportunities for sharing and spreading knowledge ‟ “So when I run this code, this happens… oh nevermind, I figured it out” ‟ Everyone can learn something from each other 38 Credit
39. Regular Communication • Best if manager schedules regular 1:1’s with each direct report ‟ Weekly or every other week as needed ‟ Two way open agenda. What’s going on? What’s on your mind? • What do you do if your manager isn’t doing this? ‟ ‟ ‟ ‟ 39 Proactively send a brief status every week perhaps Schedule a 30 minute meeting to discuss your topics Ask for specific advice Send short messages on achievements and successes (review fodder)
40. Agile Scrum Process Change Agent Scrum Master Obstacle Remover Coordinator 40 Credit
41. Scrum Best Practices • User stories, estimated with story points. Track and adjust velocity each sprint. • Just in time everything: estimates and design. (Limited documentation) • Daily standups kept brief: what’d you do, what’s next, any impediments? • Use epics to plan a healthy yet rough roadmap for 12-18 months • Concentrate on 1-2 month horizon in detail, some detail on next quarter and fuzzy goals beyond that • Don’t waste time estimating a future that will change • Software company? Consider release planning process to set expectations 41
42. Scrum Master – Obstacle Remover • Owner of process – adjust as needed ‟ ‟ ‟ ‟ Just enough process Adjust process with team size as needed Ears open for ideas in hallways Rigor in tracking, updating ideas as they change • Remove Obstacles to Lots Do ‟ Politics or prerequisites ‟ Dependencies on upcoming sprints Bad Thing 42 „ Remove „ Protect Team Success
43. Strategy Technology Architecture Strategy Problem Solver Instigator and Advocate Programmer 43 Credit
44. Technical Strategy • What does a CTO do? [article reference?] ‟ ‟ ‟ ‟ Vision Future roadmap and impact on technology Architecture Technology selections • Engineering manager hat ‟ ‟ ‟ ‟ ‟ Logistics like code streams Team structure and hiring plan (balance of skills) Technical debt and technical backlog items Estimation gut check and unturned rock finder Process challenges › › › 44 Product strategy coordination – clarity on user stories QA integration, continuous delivery model (2:1 ratio?) UX integration, ahead of time or just in time?
45. Advocate Technolo gy Architectur e Strategy Problem Solver Instigator and Advocate Programme r 45
46. The Developer’s Advocate • Are developers visible enough? ‟ A good manager amplifies the voices of his or her team ‟ The best ideas often come from the developer who’s quiet ‟ Let everyone be heard. Encourage it. • Focus ‟ “Can I ask you a quick question?” 30 second interruption can cause 30 minute delay ‟ Communication style. Meeting window? Most productive time? Flexible hours? ‟ A good EM is the roadblock remover and team productivity protector 46
47. Programmer Technology Architecture Strategy Problem Solver Instigator and Advocate Programmer 47
48. You’re not that slick anymore! • The Engineering Manager is also a programmer, maybe hasn’t coded full-time in a few years but stays sharp so he can still think like a programmer. • Good career trick: straddle the line between technology and management • No matter how much responsibility, I think it’s important for the Engineering Manager to contribute some code occasionally 48
49. Roadmaps Product Lean Thinker Vision End-user Advocate SME Roadmap Planner 49 Credit
50. Lean Thinking • Goal: Eliminate waste ‟ Does this product even make sense? Can we prove it? ‟ What’s the least we could do to validate our idea? • Feedback: Hey, you, would you use this? Tell me why not. ‟ People tend to give positive feedback. V1 Working Product MVP Prototype Paper $5K $5 Million 50 $1 Million $50K
51. Roadmaps Product Lean Thinker Vision End-user Advocate SME Roadmap Planner 51 Credit
52. If Product Owner owns product what does Eng Mgr do? • • • • • • Should have a strong cooperative relationship Help prioritize the future roadmap Help define product with technology bent in mind Add clarifying details (“don’t forget about this and that”) Facilitate conversation between engineering and product Ensure estimates are conducted properly using story points Product 52 Technology
53. Product Definition • User stories, MRD/PRD or requirements doc • Why create an Marketing Requirements Doc (MRD)? ‟ Clarity, purpose ‟ Metrics, expectations ‟ Go back and validate, track those expectations. Teams rarely do. • Well structured User Stories ‟ As a <user>, I’d like to accomplish <task> because it will <benefit> ‟ Acceptance criteria › › › 53 Must work in the following browsers, OS’es, etc. Don’t forget to try doing this without logging in Must prohibit two users from performing action at same time
54. Tactical window vs. Strategic window • Different kinds of product roadmaps and timelines • Short term: what are you doing this month or so? • Long term: what are your goals by quarter? Sprint Backlogs Release Plans Product Roadmaps 54
55. Risks & Delivery Execution Budget Risk Mitigation On-Time Expectation Setter Operations 55 Credit
56. How to delivery on-time and mitigate risks? • Use your tools: communication, metrics, hire/fire, process changes, team changes and don’t forget about you (you are the twelfth man) • Ultimately, you’re responsible for getting things done. Everything. ‟ Not meeting goals? Address it. Not getting there fast enough? Hire or innovate. • It means owning the budget. ‟ Working with the business. Spending their money like it’s your own. • It’s understanding, recognizing risks and knowing when to take them. ‟ Also, knowing how to build mitigation strategies. • Execution is the intersection of process, technology and people. ‟ Your job is to craft the recipe just right. 56
57. Summary People Process Technology Product Execution Staff Mgt Change Agent Architecture Lean Thinker Budget Scrum Master Strategy Vision Risk Mitigation Problem Solver End-user Advocate Instigator SME Programmer Roadmap Planner Recruiter Career Guide Mentor Obstacle Remover Facilitator Culture Cultivator 57 Coordinator On-Time Expectation Setter Operations
58. Summary • People: Great engineering teams are built first on great people • Process: Agile drives success through predictability • Technology (Architect): Steer the ship but amplify the team’s voices. • Technology (Programmer): Must earn respect to lead a great team. • Product: Do the bare minimum, then iterate. Stay lean my friends. • Execution: Requires style (rope vs. whip). Heavily depends on culture. 58
59. Thanks! Contact Info http://brianlink.me Questions? Twitter @blinkdaddy Email brian.link@gmail.com Linked In linkedin.com/in/brianwlink Download Presentation: bitly.com/greatsoftwareteams slideshare.net/blink21

Editor's Notes

Hi. My name is Brian Link and I’m here today to talk about building great software engineering team

Just to set your expectations, I’m not a mobile developer. But I do manage an iOS + Android dev team right nowI’ve been building and managing software dev teams since the 90sMostly in the web spaceAt both established and fledgling StartupsCoolest job was as the first CTO at Digg.com where I hired 40 people and ran all of tech for 3 years

I know there’s a mix of software developers and managers here.I do spend a lot of time focused on the development managerBut I do think the lessons about hiring, culture, product and process are relevant to anyone who works in a team building softwareI’m hoping that no matter what your background you’ll find a thing or two from my talk today that you can bring back and help your current team in some way.And this last point, I say perhaps with some prejudice. It may be an ideal and a high standard but that’s what I’m talking about.

So let’s start here – before we get to teams and more detail – let’s talk about what makes a great engineering manager

These 5 categories are the critical competency areas that every EM should have. TOC. people manager. direct reports, drive hiring, guide career, mentor, deal challenges and cultivating the culturefocus on agile today – owns the development process. coordinate with QA and user experience, drive the scrums removes obstaclesTech 2 roles. Prog+arch. strategy and everything technical are your responsibility. still able to program –and be problem solveroverlap between Prod+tech.as u define work and build roadmapsThen execution. Job to get things done and deliver.That’s a lot of stuff!

It begs the question – does an engineering manager need to be all of these things?

The answer is YES. I realize this image dates me. I am a child of the 80s.

A great engineering manager will be highly skilled in all 5 of those categories. Have you see this? Radar chart or spider chart or star chart. The graph is the blue line and this depicts the ideal – EM scores a 5 out of 5 in all 6 roles (5 categories with tech counting twice)And I’ll say If you aren’t strong in all those areas – you can really screw it up.The reality though, is that it’s super hard to find people like this.

What’s more likely is something like this. Maybe you’re not a technical all-star Maybe you were once a Microsoft Project gantt chart producer who learned how to get more technical…The red area is just there to show the area where this person has this weakness.So what do you do? Easy – you need to delegate to a senior member of your team. The same is true for any of the other big roles we’re talking about here. I’ve worked with some great engineering managers who were just lousy people managers. Funny how that happens.

And we’ve all worked with some lousy managers, right?More than just not technical enough – some personality traits really make for a lousy manager. Some reasons are obvious.But there’s other things maybe not quite so obviousPersonally I think a dev manager coding FT leads to problemsBeing overprotective or too nice can also be bad.I’m a friendly manager + people pleaser, but it is definitely bad to be “Too nice” - Leaders must take charge, be responsible, and have an opinionSo what are the other aspects and personality traits that do make a great manager?

There’s a ton of things that are important:Trust, respect, ask, contribute, express, delegate, transparency, protect, involve, drive, advocate, shield, shine, and amplify

OK so now I’ll shift focus to the team. Using the same 5 categories. First we’ll start with people.

I’ll spend a good amount of time on people and talking about hiring because I think it’s super important. It’s the core of building a great engineering team.

not a lot of focus on establishing standards or coaching people on hiring. expected to interview +make good selections. maybe that works. But I have opinions do and not to do.C++ of a copy constructor. So Microsoft and Google are famous for these “manhole covers” and “gas stations”. fun over beers – there’s a better way to find out how someone thinks. MySQL vs. Hadoop. Instead recent project specific details about problems they solvedWhat are you passionateabout. What do you do in your free time that’s technical in nature. What technical achievement are you most proud of. What’s something you’ve done that you now regret. Asking for stories helps you better understand people.

OK – so instead of just standing up here and telling you what I think about interviewing I thought I might also share some quotes I found from successful people I respect. These quotes are kinda cool. And they do happen to echo a lot of the things I believe in when interviewing.Richard Branson for example focuses heavily on personality and culture. He says he looks to find people that are fun and friendly and that care about helping others.

Jack Welch look for classic intelligence and integrity. He also looks for people who have energy and can infect others with their enthusiasm. He also focuses on passion, which you’ll hear me mention a lot. And he too like Branson talks about generous people – who are passionate about helping the people they manage.

Steve Blank wrote the book the 4 steps to epiphany. When hiring a senior manager: craft or create a business. They can be very different people. He also suggests using a graphical pie chart to easily compare candidates on the metrics that matter to you. I think part of the value here is just knowing what these metrics are. So if someone has bigger pie pieces all around they’re the best candidate. It’s smart to put a little science into your hiring process.

RandiZuckerberg wants to make sure the candidate is truly excited about the company. She tries to imagine what she’d be able to learn from working with this person. And no surprise, working at Facebook, she also puts a strong emphasis on what the person shares online - what’s in their social feed.

Eric Ries – the lean startup guy says you need to use a whiteboard when you interview any kind of technical candidate. Then ask detailed questions – like creating a certain kind of algorithm that forces them to both solve a problem and communicate visually on the whiteboard. It’s a great way to see how people think – and how well they communicate and collaborate.Funny - I just realized putting this deck together that Eric looks a little like Seth Rogan.

Alright ElonMusk is a super smart guy. He hits on some of the same themes with having a good heart and being passionate. But he also says some of his worst hires were when he focused too much on technical skills and not personality and kindness. I think you find that in hiring all kinds of senior roles. The exact technical skills matter less – aptitude and adaptability are so much more important. Elon also doesn’t put a whole lot of credence on MBAs which I think is funny.

Sosome themes that stand out. Personality, heart, passion, culture fit, intelligence and aptitude.Here’s a few more things I focus on when interviewing.Resumes don’t matter much –careful filteringExperience: Be careful because it can be deceiving. You may decide Recruiters: coach them. Be super clear. Tell them exactly what you need. And what you’re tolerant about. Give examples of good vs. edge cases.Personality and culture fit: everything else can be learnedThe ideal candidate is passionate about some aspect of your business, goals, technology and/or vision

OK that’s enough about hiring. What I want to talk about next is another super important topic for engineering managers and building great teams. And that’s culture.

See if you agree with this.“More than just atmosphere (great benefits, snacks and ping pong) the best developers want to be challenged, fulfilled and rewarded for doing work they love in a way they can help define.”I tweeted this last week and it resonates with people. It speaks to the culture of a technical team – one that respects the team members and involves them in everything.Culture means lots of things. It’s only partly defined by nerf guns and beer and work/life balance type topics…

When I think of culture, I immediately think of the deck that Netflix put together. Howmany people know what I mean when I say the Netflix Culture deck on slideshare? It’s 126 slides and I don’t care whether you work at a startup or a big dumb company, you need to read this deck and instigate your team to think like this – and adopt as many things as you can from this presentation. Just search for netflix culture deckStarts with company’s values and how that represents how they drive their company and what they expect from employees. It’s brilliant.Facebook does it too. values front and center on their jobs page. As technologists when we look for jobs – the culture and the way a company treats its employees is of critical importance.

The way a manager interacts with and treats the employees directly affects the culture. These things are obvious – but it comes down to small actions. Focusing on quality. Enabling great work life balance.Everyone needs to embody this culture.Perhaps it’s obvious but “Happy developers are loyal and hard working”. There’s some more quotes from that netflix deck that I added to this page. A great workplace is stunning colleagues. Responsible people thrive on freedom and are worthy of freedom.That’s a great way to think to build a great team.

OK. More People stuff. Let’s talk a bit about team management

This is probably super obvious, but it took me a while when I was the CTO at Digg to get it right. I have huge expectations on people to get up to speed quickly – and throw people into the fire as soon as I can. people learn on the job really well that way. Maybe no critical tasks – but give them real problems to solve and they’ll get to know what they need to know quickly and your team will rally to teach them in that context.But how fast is too fast to assimilate new people? You need to find your own cadence, but generally you need enough senior people to help mentor and train before you hire more junior people.

The way you structure your team – with who reports to who and your attitude about building an agile self-managing team can greatly affect your hiring strategy.Some people like to crack a whip and manage by fear and maybe therefore it suits them to hire a bunch of more junior peopleI like to give my teams a lot of rope. But that also means I have different expectations about their ability to self-manage and help make decisions.My own mgt style tends to work better when my team is more senior. That way I can focus on strategy, vision and product my strengths.

Without getting into too many details about agile, I’ll just say that team size is very important. Agile best practices say about 3 to 7 people on a team makes sense.The diagram on the slide illustrates Melcalfe’s Law – which states the value of network is proportional to the number of users on the network.If you draw lines between every person on a team and think about the number of conversations that can and need to happen in order to coordinate things – the complexity dramatically as the team grows.As a rule of thumb, if you get over 6 or 7 people, split your team into two. You’ll likely be smarter and more productive.

What can a developer do to help the team? I tend to focus on the mgr –that’s my role. there’s a lot every team member can do to help make the team great.Your team should encourage sharing. Do demo Fridays so people can share work and problems solved. Better than code reviews.Understand Why. Why are you building stuff? What business problems are you solving? Suggest other ways to solve problems for your customers.Be brave and be bold – about trying new things.

Last people related topic. You are the career guide and mentor for the team.

I like to help people outside the context of our current roles and positions. People move around a lot and I’m still connected with people I worked with 20 years ago.Instead of big company templated annual reviews – I focus on 1:1s weekly and give direct and timely feedback.Share freely when people are doing well. And don’t hesitate to give constructive criticism when needed. A manager should strive to improve everyone – and sometimes that means putting someone on a PIP and if they don’t improve – be decisive and move on

As EM it’s sometime difficult to not step in and solve the team’s toughest problems. But if you help someone else solve the problem on their own it’s much more beneficial.You are also the mentor, helping coach both senior and junior developers. This means you must be technical enough with great breadth in skillsto ask good questions and offer advice to anyone on the team.Mentoring is also about understanding people’s goals and instigating them to do more, explore their strengths and grow.

Establishing a culture of learning is important. You can do brownbag lunches, demo fridays like I mentioned. Lots of ways for someone to share stuff they’ve learned. Especially as your team gets bigger – everyone no longer knows everything that’s going on.I also think there’s a talent in knowing how to ask good dumb questions. It’s funny how a developer often solves a problem simply by trying to describe it to you.

Regular 1:1s are important for both the manager and the developer. Dev should keep a running long of things to discuss. Goals, challenges, complaints, career, tech ideas.And if your manager isn’t doing this? Schedule a meeting yourself. I still sometimes do this – I’ll just keep an email draft with a bunch of thoughts and send a periodic update to my boss. Make sure you do this with small successes – accomplishments, big problems you solved, ideas you contributed. EM’s are busy – they’ll steal your content for annual reviews!

So process. As an a EM you are the process owner and that means facilitating the daily scrum and removing obstacles for the team.

Agile is a big universe. I’ve coached and trained many teams. This is a short list of stuff I think is important.Use story points and velocity. Keep user stories at business value. Comparative estimates – login=breadbox. Allows consistent estimating and velocity accommodates perfect-work-day challenges and avoids counting hours. Even if you team sucks at estimating, adjust velocity per sprint. Do daily standups.Do sprint planning so you know the next few sprints in detail over next month or two. Wait to estimate future stuff later.Sprintswork best at 2-3 weeks

As I said, as process owner – establish least amount of process necessary. A small team can be chaotic. As you get bigger, may need MRD or some sort of approval processes, etc.Today I mostly manage virtual teams – but one thing is the same – ykeep your ears open for ideas in the hallway. In meetings as questions come up – encourage everyone to write stuff down – put items in theThere are many kinds of obstacles that can get in the way of productivity. Renewing a domain name. Getting approvals from management. Getting ahead of dependencies. Fighting political pressures. Both stupid and strategic things. Your job is to keep your team productive, no matter what it takes.

Now on to the topic of Technology. You wear multiple hats here.

As Architect, you should take from your experience to help guide, craft, and teach what architectural patterns or strategies make sense for the products being built. Like a CTO – you should have an eye to the future, and own everything technical.As Engineer manager – more detailed things like code streams, team structure, managing technical debt and ensuring your team’s estimates are in check. And deal with with all and any proces challenges. Coordinating things with QA and UX

I also like to think of myself as an instigator – looking for things that might slip through the cracks.And I’ve always been an advocate for developers – to make sure their concerns and ideas are voiced to the rest of the company.

In all the team’s I’ve managed,someone with great ideas who’s quiet. Encourage team to share ideas. Are the developers visible? I make it my job to make sure developers voices are heard.The other thing I’m an advocate for is respecting the dev process. You all here understand. Interruptions can kill productivity.A developer with multiple windows open and a complex set of changes’ context in his mind is like a big stack of cards and can be knocked down easily with the simplest interruption. What can you do? I’ve tried a few things. Maybe no-meeting windows, if say your team is most productive in the mornings. No meetings before 11. I also think IM and group chat goes a long way to help this problem – dev can ignore. I don’t subscribe to the Joel on Software everyone gets a room with door.

OK if you’re a great manager you might still think of yourself as a great programmer. Like a slick sports car. (this was my best opportunity to sneak in a picture of a Tesla)

The reality is, if you’re like me, you’re not that slick anymore. But it’s OK. You do still need to be a programmer – maybe you haven’t coded full time in a few years but you sstill think like a programmer.And that’s why you can be a better manager. Devs won’t share tech details with a manager that doesn’t get it. You miss stuff. Plus I don’t think you can earn enough trust if you can’t keep up and speak the language.No matter how much responsibility you take on – I think it’s important to still submit some code occasionally.Being the lead technical guy. It’s like being the store owner of the shop on the corner. After everyone’s left for the day, and before you lock up you make sure everything’s ok and ready for tomorrow

It may be surprising to some that I made Product one of the 5 categories that an engineering manager needs to be good at. There’s actually a lot you can do to help the product team.

It all starts with Lean Thinking. This is the underpinning of agile. Lean was inspired by Toyota carmanufacturing – eliminate waste, build sustainable continuous process improvementMake sure your ideas make sense before you build them. Will customers use it or buy it?Instead of marching immediately towards your V1 or MVP – consider prototypes or better yet pen and paper. Take that and ask for feedback. Find mistakes before you even start coding.And when you ask for feedback – as why somone would NOT use your product. People tend to give positive feedback only

The VP of Product or Product Owner is the one that owns the roadmap. But the engineering manager has a lot they can do to help.

What can you do? With technology dependencies in mind you can help prioritize the backlog and future roadmap.There’s a tight relationship here and you need to figure it out. I’ve been CTO for a number of small companies where I’ve been both product and tech so maybe it’s closer for me.You don’t want to step on PO’s toes – so come up with a strategy where you can work closely with them and step in and help when needed.

Maybe you’ve decided to do MRDs. Maybe you just write really good user stories. As a user I’d like to do this because it will help accomplish that.Either way, as EM your job is to make sure there’s enough detail about the bus. Reqt’s that the team can implement it.Not talking about technical spec here – just completeness. Edge cases. Negative tests. Consequnces – after you do this, this other thing should happen. Dependencies – cross platform, multiple browsers, etc.

I use the term roadmap really loosely. There’s really 3 terms I should use to be more specific. Sprint backlogs. Release plans. And Product roadmaps.Every company I’ve worked with has struggled with this. Pure agile essentially says – I have no ideas 6mos+ - but it’ll be most important.Mgmt and marketing don’t like that – especially at software company. They need a FY roadmap. Multiple major milestones planned out. So I suggest prioritizing epics and keeping it very fuzzy – but setting realistic high level expectations only.

OK last category. Execution.EM is on the hook to delivery on time and on budget. And that means managing and mitigating risks, setting expectations and ensuring smooth operations.

As EM you have a number of knobs and dials you can control to adapt to change and mitigate risks. Level of comm. Metrics. Hire/fire. Make process changes. Shuffle roles on teams. And don’t forget you are your team’s insurance policy. You can dive deep wherever you team may need you.Ultimately you need to make sure things get done. Own the budget – spend it like it’s your own money.Understand and recognize risks. Also – know when to take risks.Execution is the intersection of process tech people. Your job is to craft the recipe just right.

As you think about what makes you and your team great. It’s finding the stuff in all these buckets on your team. The engineering manager owns them – but will smartly delegate what he can to senior team members.

So to reflect on these 5 categories Great teams are built first on great people.Process using Agile drives success through predictabilityAs technology manager wearing your architect hat – steer the ship but amplify the team’s voicesAs the programmer, you must first earn their respect to lead a great team.As for product - Do the bare minimum and iterate. Stay lean.And to execute requires style (I prefer rope vs. a whip) and it heavily depends on a great culture.

Please feel free to connect with me online or ask me questions. And you can find this presentation on slideshare. Feel free to share and use this if it’s helpful.Thanks for having me today. Hope it’s helpful.

Building Great Software Engineering Teams

You are reading a preview.

Building Great Software Engineering Teams

More Related Content

Similar to Building Great Software Engineering Teams

Featured

Related Books

Related Audiobooks