This is part of my live blogging from QCon 2015. See my QCon table of contents for other posts.

make talent #1 priority

Why should you care about retention- leaves gap in knowledge, morale and resources to do work, your competitors are making progress while you try to re-hire and re-train.

Everyone is trying to be recruited on linked in. Startups/new company IPO threat in San Francisco (ex: uber)

#1 – on day 1, make team a process
There is a taboo about talking about what happens after they leave. talking about career, doesn’t put thoughts in their head. If you know what they want, you can form a partnership and find internal opportunites as they come up.

Do you know if person wants to be a manager or individual contributor. And know if/when changes.

They recognize that everyone is going to leave linked in one day. Discussing goals makes journey ore transformative. More learning. More growth. More throwing self at these oppportunties. The idea is to try to make it so wil grown more by staying than leaving.

This gets people to talk about leaving before already decided so other opportunities n come up.Sometimes still leave,but at least a conversation.

#2 – maximize employee engagement
Competitors are doing the same thing as you. How keep engaged when having problems – financial, support time, etc.

1. Inspire – knowing big picture makes it so tasks don’t feel repetitative
2. Challenge
3. Inspiration

#3 – talk about recognition

1. People need to know they are seen and valued – don’t want to feel invisible
2. People stay where seen/appreciated
3. Receiving feedback is difficult for most people – even if they say “no big deal” still means something
4. Needs to be specific, timely and personal. Not just “good job guys”

be prepared – by time person comes to management about leaving is too late.

1. Observe – behavior change
2. Assess – personal? work related? intrest. Reasons engineeers become unhappy include- FUD, friends leaving, lack of opportunity, nobody is listening (never solve problems), lack of recognition
3. Connect – try to discuss/openup. Leave the office; go for a walk. People more comfortable opening up when elsewhere. The goal is to find out root cause. They might not know or be able to articulate it. Don’t argue about how they are wrong about wha perceving. Be emotionally supportative. Try to buy time to solve actual problem.
4. Act with urgeny – if not highest priority, is it worth retaining person

Q&A

1. What if eeryone can’t be lead? People get caught up in title. See why want? Titles are flexible. Look at impact.
2. How deal with public feedback? Better to be individual than public. Some people prefer one-on-one communiction to public. Give example to show paying attention
3. Some people like to move around. If understand objectives, know like to move around. And why? Is it about new languages?If just about change, they should leave. Three months isn’t enough time to learn something.
4. What can non-managerial senior engineers do? Mentoring. Safe erson to talk to
5. What about people who change jobs once a year? Average attention span for a new thing is 12-24 months. It’s a bell curve though [Luckily tech changes often so the “same thing” changes overtime]
6. What happens if not ready to do what want? Coache. Help get there. Create “apprentice manager” role to give it a shot.

Interesting and a lot applies to communication in general. Including mentoring/tech leadership.Not just about retention. That said, it was mostly about management stuff.

This is part of my live blogging from QCon 2015. See my QCon table of contents for other posts.

Coding isn’t enough to be a good engineer.

“Mature engineers lift the skills an expertise of those around them” – John Allspaw “On Being A Senior Engineer” – bit.ly/senior-engineer

Must understand why doing things. Teaching to fish is an essential skill at this level.

Why to be a good mentor?

• Mandatory for career advancement
• Needed for their careers too. Having a mentor is often the difference in staying in the industry
• Your company needs you to mentor junior engineers because they need senior engineers. Who are hard to hire
• Our industry’s future. The next generation is trained by us, not by university

Need – vision, goals, mentor with expertise Need to be able to evaluate them and provide feedback

Becomes negative feedback loop. Think if bad and fail, won’t have to do it again. Just witing for time to pass. Never get better if don’t want to try.

Good to have small/clear goals so can progress/grow. Within vision of company. Good if like mentee/stay in touch have lunch/etc. [I agree. Easier to respond to feedback when have trust]

Lessons learned by speaker

• Be eagar to help. Or at least appear to be. If you look like you are angry when someone asks for help, they will be afraid to ask. Need to seem excited to be interupted. (or preferably actual be). You don’t want your apprentice to be blocked. He/she isn’t learning anything and you can’t evalulate. We overemphasize figuring things out on your own.
• Know what your apprentice doesn’t know. ex: github, pm, working on one thing at a time. Try to anticipate these questions. [This is why I like a buddy system when there are mutiple new people. It’s harder to keep track of what multiple people are up to]
• Admit when you don’t know. It models that it is ok to not know things an not be embarassed when don’t know. Also helps teach problem solving
• Ask apprentice for help. Can do code review even if don’t find much/anything. Still learn. Still create good patterns

Excuses for why not to mentor

• “I’m an introvert” – controlled interactions are easier. Predicatable. Apprentice is likely to be an introvert too so understand each other. Introverts listen. Can develop a relationship
• “I can’t explain what I know” – can teach by working together; don’t have to explain to teach. If it can be explained, it probably is in a book somewhere
• “I’m a bad mentor” – It is a skill that improves with time/practice
• “I just want to code” – Some people don’t like leading young people. History of craftsmanship with master/apprentice relationship. Making the investment can change how you think of yourself. Satisfying feeling when work

Q&A

1. I asked about you becoming Google for trivial facts by never letting your mentee block. He said that he thinks we are so far on the side of not wanting to be interrupted that trying to always be open will help shift to middle. Someone brought up the idea to timebox that window. Such as an hour of blocking max.
2. How do you balance how much time on your work vs apprentice? Your apprentice is the #1 priority.
3. How deal with multiple apprentices? Best if one to one. Cuts back on pain of being interupted
4. Interns provide muscle. Should intern be involved in your project or a separate one? Interns are not muscle. Not significant productivity compared to what take from you.[I disagree. I think we came out ahead four of the five summers we had an intern on my team]
5. Can be scary to mentor. Imposter syndrome. Knowledge atrophy. Ok to admit what don’t know. Have wisdom even if less tactical

I like the session. A case study of good/bad internships was a good way to present the material.

This is part of my live blogging from QCon 2015. See my QCon table of contents for other posts.

Excited to see Mary as the keynote. Good speaker and good role model.

Abstraction
The presentation started with Moore’s law going back to the very early calculators and covering the different generations of hardware. We are a trillion times faster since 1940’s. Massive minuiturization as well.

Happened both by becoming small and by abstracting out how classes of things. For eample, no motherboard in 1970’s.

Then she went into how code changed over her career. Fortran to HTML Baby steps as far as abstraction is concerned. Same generation. Changes not as vat in hardware.

Generation changes – reading/writing, printing press, personal computer, internet, culture of participation.

Currently a project where you can design your own sensor and plug into your phone.

Federation
Federation scale

• mini-computer evoloved to embedded – control you rown process
• pcs evolved to servers – retail software packages
• internet evolve to services – websites
• smartphone evolve to wearables – apps interact through the cloud

Federation leads to wide participating. Can share from own serice. More open source. Sharing helps industry grow. Reputation on sites like ebay allow anyone to share. Share practices on blogs. Education online.

If thinking about scale, think about how you can share.

Friction
Large systems don’t deal well with friction. Container ships helped with this. Standards size/shape.

Enterprises have databases. We create deep dependencies across apps because all hit same data. Which means high friction because hard to change. Amazon microservices have local data. Trying to decouple.

What is a microservice

• A microservice must be indpededently deployable to be useful.
• Small team-endto endreonsibility. You build it. You monitor it. You fix it
• No central db. Extensive automation and monitoring. Canary releasing. Smart versioning services. Double mock contract services

Companies with very high volumes like Amazon seem to require microservices. Requires strict discipline/operational excellence. Teamsnee situational awarenss. Must know all the time how service impacts customers and providers.

If you and provider change rapidly, how do you know mock returns same value. Create a pact so can check. See pact github project

Goals: limit risk and lower friction

How do you deal with a monolith if you have one?
Pack dependent code into containers. If put service and dependencies into a container, can put box around it and isolate it. Refactoring to make smaller/simpler. [I like how nicely she got from container ships to virtual containers]. This gives you portability, consistency, isolation, ease of use and better server utilitation. Most importantly, get lower friction and less risk.

Smashing it doesn’t work. Poking it does. Smashing is like a releae. Poking it is continuous delivery.

DevOps
If have branching, aren’t doing continuous delivery. Deploy mainline always with new features on switches so can turn on when ready.

Some people want to be safe (safety goals) and some want to be experimental (aspirational goals). With safety, failure/setbacks cause more efforts. With aspirational goals, prasise causes more effort. For safety,attention is for bad behaviorand asprirational, it is for good. Ops tends to be safety and dev tends to be aspirational. Marriage works well when have both, but must work towards same goal.

Who is responsible? Everyone. “Nobody succeeds unless everyone succeeds”

Getting to continuous delivery isn’t inherently harder than other tech issues. The main obstacle is organization.

In military, need to maintain situational awareness one level up and command awarenestwo levels up.

Great talk. A nice start to the day. I like that she sprinkled book and blog references throughout