A winner is someone who recognizes his God-given talents, works his tail off to develop them into skills, and uses these skills to accomplish his goals.
— Larry Bird
In the previous post, we looked into the foundational character attribute of our Engineers: the Personality Layer. The next layer, the Capabilities Layer, adds to the foundation by layering in the Engineer’s abilities. Put mathematically, Personality + Capabilities = Engineer. With that said, let’s dig into the next cross-section…
The Capabilities Layer
This layer focuses on what the Engineer brings to the work based on past training and experience. I see the Capabilities Layer looking like this:
- Skills – one of the most important valuable aspects of an Engineer is the skills they bring to the job. This is a combination of more tangible skills such as “Coding in Java” and “Writing SQL” as well as more vague talents like “Object Oriented Design”, “Rapid Troubleshooting” and “Designing Efficient Algorithms”.
- Knowledge – I differentiate knowledge from skills by classifying by “things you know” (knowledge) from “things you can do” (skills). In software, it’s not as clear-cut because an Engineer “knows Java” and “Codes in Java”. So, for the most part, I’m talking here about knowledge of the business domains our software is used in, as well as technical processes [1] or methodologies [2].
- Experience – the last piece of the Capabilities layer is the experience the Engineer brings from their past roles, teams and companies. There are some things you can’t teach and experience [3] is the only way to learn certain lessons.
You should make sure that you have a formal record of the Skills, Knowledge and Experience of each Engineer. This serves several purposes – one is as a baseline for helping the Engineer determine which Knowledge, Skills and Experiences they want to acquire. The second purpose is to have ready access to an inventory of which Engineers know what, which makes project staffing discussions easier. I will be introducing a Staff Dashboard template in an upcoming post that you can use to track everything we’re talking about in the Layers model.
The next post talks about what’s happening to the Engineer in the present moment. In the meantime, feel free to comment below.
This post is based on or excerpted from the upcoming book “De-Engineering the Corporation” by Darryl Ricker
Footnotes:
[1] such as Continuous Integration / Continuous Delivery.
[2] such as Scrum.
[3] also known as “The School of Hard Knocks”
Leave a Reply