3 Book Recommendations to Help You Earn Respect from Software Engineers

Technical Background Needed?

Companies like Google are notorious for preferring technical product managers.  (How dare they forgo your talents just because you don't have a C/S degree!)

Yet, if you look under the surface, you'll find many exceptions.  For example, take a look at Google product manager Kamila Staryga, who used to run the (now defunct) Google Helpouts.  She does not have a computer engineering background.  Her prior career background was with companies like GlaxoSmithKline and Procter & Gamble.  

Lest you think this is an exception, take a look at Serena Keith.  Serena is heads product at Lovely, a mobile apartment hunting app (acquired by RentPath).  Serena graduated college in 2008 as a social studies major.  Then, she worked a handful of jobs in non-technical roles.

So, What's Going On?

You could assume that Serena or Kamila simply relied on their industry expertise and strategic prowess.  Perhaps you're right.  Or, you could give them the benefit of the doubt.  Perhaps they really studied up on technical matters.  People like Serena worked really hard to overcome their technical deficit to earn the trust of the mobile and web engineers on their team.

I have seen this humanist-turned-technologist narrative play out first-hand with people like Shanely.  Shanley used to work at Heroku, an uber-engineer kind of place.  The engineers there told me first-hand that when they worked with Shanley, they had no idea she was not from a technical background.

Meaning, basically, you get there by taking time to learn.  Big surprise!

Take Action and Read Up!

So, this is the part you've been waiting for.  Book recommendations that closes the technical knowledge gap.  That's right, you got to earn that respect from your engineering team. There's no free lunch, my friends.

I found a few books on Leanpub that should be worth checking out.  Best of all, they have a nice satisfaction guaranty.  So, hop to it and beef up your technical library!

        

Growing Agile: A Coach's Guide - This book is a collection of our workshops that will help you run similar workshops to create agile Release Plans. 

Inceptions, Starting a Software Project - A professional software craftsman has many tools under his belt. Many are technical in nature, but many others are considered soft skills. This book focuses on one such soft skill; The Inception Workshop.

Talking with Tech Leads - A book for Tech Leads, from Tech Leads. Discover how more than 35 Tech Leads find the delicate balance between the technical and non-technical worlds. 

day5 - beef jerky, culture, and why performance reviews are toxic

Reflections on beef jerky day - feeling like my colleague was a jerk

I'll just share the video I recorded at the end of the day. I basically felt like there was some gap in the engagement and accountability in the team.  You can tell I'm a bit pissed off in the video.



We are delusional as people

So almost immediately after recording, and feeling discouraged about lagging engagement, and thinking back on the day, I had a realization.  It's interesting the two of us incorrectly perceived our contribution and role in the team. Who was who's apprentice?

And we're just freaking two people! We are delusional.

Good intention to help people not be delusional
I can now better appreciate why organizations create measurements and performance reviews - so as to check members from becoming 'delusional.' For example, if my manager and I agree that I was a 4 out of 5, and have it on paper, then I can't come back and say 'but I delivered more revenues than he/she who also has a 4 rating!'

Performance reviews are used to avoid perception of unfairness.

But it's wrong
While I can now appreciate first-hand the organizational leadership's position in defaulting to performance reviews, I also believe that it is the wrong step to take.

What you really want are individuals to become more self-reflective, self-aware, and self-sufficient. You can't enlighten people by banging them on the head with 360 reviews. That only makes them less engaged and bitter and resentful. It is a sure sign of distrust at a deep level among the team members. Instead, focus on dialogue and communicate your grievances.

Instead, focus on dialogue and communicate your thoughts. Support each other and help the counter-party see the reality. Difficulty conversations aren't supposed to be done through mind-numbing written performance reviews using sanitized words. (Didn't you always love that guy who had no filter in his mouth and said whatever the hell came to his mind?)

Talk to each other. Know that hard is good.

Yet there's a tension
I can also appreciate the tension present here. It is the tension between having great people, and being able to scale growth. If you had to hand-pick and cultivate great people one by one, you might spend too much time recruiting for the team.

How are you resolving this tension in your organization?

Learning by doing

To see what this overall project is about, see the original 12appyDays entry.

Today was project 5 - a skeleton eCommerce site for beef jerkys.  On the previous day, we built a simple and simplistic site using google map api to show the path back to the car. And on the prior day (project 3 pickr), I wrote about the experience of how knowing what's hard is ... hard.

And I'm learning so much, because I am building. Lot more so than I could by thinking and reading. 

12 days 12 apps - an experiment in building and teaming

What is 12 days of coding?

It is 12 projects in 12 days. Each project would be started, finished, and shipped in a given October day.

It is an experiment in coding and learning. It is an experiment in teaming and creating a culture of doing. I will be blogging about our experience in my blog, starting with reflections about attitude over aptitude and critique of learn it quick mentality.

Appy days are Happy days

Why 12 days of coding?

Josh and I both had time to kill. But, not too much. We wanted to do something fun, build up our coding skills, and our portfolios. (The project will not always take place over consecutive days - but basically we are saying a half a month is low-risk enough to invest in an experiment ... whatever may come of it.)

And we wanted to learn: learn to be better coders, learn to be better builders, learn more about our interests. And that was it. We don't want to get ahead of ourselves.

We thought a good way to do this would be to create a set of constraints around our efforts. Constraints are key to discipline and focus.

• One of the first choices we made was to keep it short and simple (KISS principle).
• We are devoting around 2-weeks to this experiment.
• We are keeping this to 2-person engineering team.
• We are doing projects we can reasonably finish in a day.

Methodology

What about the process? No ground-breaking principles here:

1. Build on strength - for speed, use familiar technology (for us, mostly Ruby on Rails)
2. Prepare - for new technologies (e.g. a Node app), do some advance reading/tinkering
3. DRY - Do not repeat yourself - look for gems wherever possible
4. Best practices - we will use TDD; red-green-refactor; frequent commits
5. Pragmatism - product should work; function over form (i.e. it doesn’t need to be pretty)
6. Modularity - we will try to build templates we can reuse on subsequent days

A lot of these ideas are well-known to software engineers from works like Rework and The Pragmatic Programmer.

How you can get involved

You should join with your own mini-rapid-project(s). Do it solo. Do it as a pair. What would you like to get out of a process like this? How would you structure your efforts? Write about it and send us a link to your post or project.

• Josh Wilborn - joshua.j.wilborn@gmail.com
• David Kim - daviddarden11@gmail.com

Project & resources

You can find full-project page/link here - 12 appy days!

Please let me know your thoughts about attitude over aptitude and the get-rich-quick mentality that makes one-month-rails type of marketing so tempting.