Experience - where is it? [take 1]

I have been thinking: where is my cumulative knowledge from ~26 years in my field stored? 

I am less capable of writing code into our current code base then any of the developers. I am also less capable with managing our infrastructure then anyone on the devops team. I have never been good at UI work. Done project management on a need to do basis: I know how to conduct meetings, have some proficiency in managing Scrum teams, incl. the backlog, daily-s, stand-ups and retro-s. But not strong in budgeting and planning. Basically, for any one capability I can probably point to someone that is better at it than me. But still I have always been busy reading up on the aspects that I have had to tackle at work: people, process, technology. So where has this knowledge gone?

I guess the answer is that I have gradually gained increased scope (w.r.t. the software life cycle), better sense for what works when (and pitfalls), and more options when solving a given problem. I hope.

  

Optimizing in software development

What is the most efficient way of reaching business goals? We have three major parameters to play with: technology, processes and people. Of course it is best to be proficient on optimizing for all three at the same time, but it can be tricky to do. A simpler optimization problem is keeping two parameters fixed and optimize for the 3rd, but which one should you to start with?

The intention here is to be best prepared to solve any business goal, there are three parameters we could start with (keeping the others fixed).

1. Hire the best people and create powerful teams. Make sure that they have a clear goal and the fewest obstacles possible to reach them (servant leadership). 
2. Setup best practice processes and infrastructure. Focus on lean principles to identify process improvements.
3. Use the best possible technical design and keep the technology continuously up to date.

Probably depends on where you are presently at with these parameters where you start. But of the three it is probably most costly to get 3) back into the optimal zone, so I would recommend optimizing for that first.

It can be helpful to look at this is as a regulation problem, where you regulate for the most important parameter first, then the others. This adds a constraint as to how far you go in optimizing for the first parameter before you go onto optimizing for the next one.

Where we fail

I think it is possible to generalize that we tend to fail in two areas: experimentation and persistence, both personally and in teams/companies.

The reason I mention this is that I think these are two key ingredients for success and their lack of explains why we end up in a rut.

These factors can be in some cases opposites, i.e. where the persistence converts to obstinance. But they can also be complimentary where persistence ensures that we don't give up on the experimentation at the first hurdle.

Experimentation is best implemented through iterations: short plan-do-check-act cycles. It helps with setting/correcting the direction and keeping motivated.

Persistence does not only apply to following through on the experimentation it has also to do with keeping the lights on: pulling everything/everyone through (and not just launching detached experiments). I find the iceberg metaphor/illusion motivational when I need to keep persistence/focus:

(not sure who is the original author of this drawing)

What is a team

Team members have i) a common goal, ii) common responsibilities, iii) help each other out, iv) and have a structure to how they split their work. 

I have heard of the term 'organic teams', i.e. teams that organize around these four attributes by themselves. My belief is that you will always require one team-role at minimum, i.e. a team lead, somebody that is responsible for the team itself, making sure that the four attributes above hold. The team lead does not have to be a dictator, i.e. setting the goal, responsibilities and structure, it could just as well be a facilitator that facilitates setting these attributes with the other team members.

The purpose of software development and its associated primary capabilities

The purpose of software (product) development is basically to create a product, timely, that is useful, hopefully pleasurable, secure (this is perhaps not an universal) and maintainable (because we aim to build on top of what we have already delivered).

To be successful in fulfilling our purpose we need to i) know how to manage (=gather, analyze, tweak) our users' requirements, ii) build in quality (="0" errors), usability, security and maintainability, iii) Be great at deployment/roll-out and iv) provide excellent service.

All other capabilities are secondary to these. 

 

P.s.

I am aware of that the cost aspect is missing here and of course someone has to keep the cost-revenue in check, but that is just one of many external constraint, other such constraints are the skill-set of the team you have, and the maturity of your users and their environments, and more.

The hiring process

I have probably conducted several hundred job interviews, ended up hiring close to 100 people. The process starts with a need, this spawns an advert, then the interviews, negotiations and contract finalization. I wanted to record some 'lessons learned' here.

The reality in Iceland is that we get a manageable number of applications, meaning that it is possible to read through them all and before deciding on whom to invite to an interview. The number of invitations are normally between 3 and 20. The number of interviews rounds are 3, but I have also done 4. Usually I try to squeeze the whole process into 2 weeks when possible.

The first interview - why you?

Initially I did ~1h first interview where I spent ~30min going through introductions to the company, products and processes. Recently I have shortened this to 20-30min by sending out a (abbreviated) introduction, a copy of the advert text (required skills etc.) and the interview questions/topics I would like to cover. This allows me to shorten the interview and put the focus on the applicant. At this stage, as I see it, the applicant is 'proving' (s)he is a good fit for the position.

The latest batch of interview questions I use is:

1. Something unclear regarding the invitation text?
2. What makes you interested in the position?
3. Where do your strengths and weaknesses lie w.r.t. the skill requirements and job environment?
4. What are your professional ambitions?
5. How do you think your coworkers would describe you?
6. Other questions from me related to the CV/introductory letter.

It is not important to go through these questions in order and in many cases when the interview 'flows' they get answered without being specifically asked.

I usually get someone to sit with me through this interview. I have been assisted by tech-leads, project managers, product managers, developers, testers, and HR personnel. It can help with the flow, but also getting a second opinion after the interview. I keep notes during the interview. Use a simple grading mechanism, giving a score of 0-10 for: Drive, Collaboration, Technical strength. It is important that the applicant has some drive, it can be for technology, the domain or best practice; can collaborate within a team; has the necessary technical capability. But I also look for fit w.r.t. the existing team members and our projects' requirements.

The second interview - why us?

The second interview is focused on issues that the first interview left unclear. Could be the need to drill down into certain technical skills or people skills. It is also an opportunity for the applicant to ask questions. But here the tables have slightly turned, now we are interested in hiring the applicant and we need to 'prove' that we are a good fit for him/her.

Usually I will get the helper from the 1st interview to sit in with me again. Before the interview I will have either called myself or asked HR to call the references for a basic background-check that goes mostly to character reference.

This interview does not have known list of questions, it can take 30min to an hour.

I will ask after both interviews if the applicant is interested to take the next step in the process and explain what time-frame I working with.

The third interview - how much?

Previously I would take the contract negotiations, but now this is done by the director of the department, I might be present or not during this interview.

Closure

I think it is important to send an email to those who did not get the position. Those not invited will get a rather standard email, but I will try to have a personalized email for those I met. The intention is not to spur a further discussion on merits, more an attempt to give the applicant a proper closure.

Development manager: where should you place your attention?

Your attention is a limited, valuable, resource. With attention I make the distinction between placing continuous attention (being pro-active) vs. temporarily placing your attention where needed (being re-active). So the question I would like to investigate is more specifically: on what to keep continuous attention.

At a high-level it can be said that the development manager has two (related) objectives: i) maximizing throughput of new product functionality and ii) minimizing product quality problems. 

Mapping your attention to those objectives results in:

i) Be involved in solving problems the teams face during development. I find the best vantage point here is to be involved in DevOps because they are all day solving these (technical) pain points. But also be involved in the developers' discussion on architecture, processes and tools to spot the technical debt that is holding them back.

ii) Be involved in solving the quality (correctness, usability, efficiency, reliability, integrity, adaptability, accuracy, robustness¹) problems that surface in the final product. Here the best vantage point is to be involved in release testing and monitoring of the product in production.

---

Note 1 What is missing: continuously paying attention to people and team dynamics. Frequently the problem analysis will reveal problems related to people (e.g. training), teams (e.g. communications) and processes (e.g. unclear responsibilities) and then you move your attention to those (re-actively) to solve the problem. When the problem has been solved your attention moves back to the main objectives. 

Note 2 This is my current thinking, I acknowledge the view (HR-take) of cultivating people and teams will lead to great products. That approach requires a certain leap of faith and does not fit as well with my engineering problem-solving outlook.

---

1 Taken from McConnell's Code Complete^↩

The roles of the development manager

I have had the title of development manager now for 13 years. It has had slightly different meanings throughout this period; I find it best to talk about different roles I have served while having this title. I think the following list of roles is fairly complete, although the naming can be improved upon.

• Project manager - I have lead various business (revenue generating) projects. This is strictly not a role for the development manager, but I belief it is often the case that some project management work accompanies the title.
• Process maker - the development process needs to be designed and deployed. It is important to be proactive, but the work is necessarily done in cooperation with all stakeholders.
• Process guardian - this is the process policing, making sure the processes are followed (teaching/guiding/finger-pointing). This also includes managing internal documentation/data.
  
• Infrastructure owner - responsible for keeping the IT infrastructure operational (and cost effective). Including the CI/CD tool-chain and dev/test/staging environments.
• Release manager - making sure that release schedules are kept, enforcing code-freeze dates, managing release testing and delivery/hand-over to Service.
• Human resource manager - hiring, firing, training, conflict resolution, setting up teams, office managing (w.r.t. seating, equipment)
• Dev(sec)Ops manager - enabling team decoupling and team empowerment.
• Liaison to external developers - providing test environment and managing communications.
• Liaison to intra-company dev-teams - facilitating knowledge transfer with dev-teams in other departments.
• Technical manager - facilitating and (sometimes) initiating discussions on architecture (monolith to micro-services), framework (angular, vue, react, e.g.) and tool selection (UI libraries e.g.). 
• Asset manager -  this is perhaps covered by the other roles, but I think worth mentioning. This is the management of (digital) assets of the department, such as data in shared network drives, in wikis, in issue management tools, videos (Stream), collaboration platforms (Teams/Sharepoint), and software licenses.
  

Making (new year's) resolutions - a framework/categories, take II

Approximately a year ago I posted on this same subject. Now a slightly different take, perhaps a simplification.

 The following categories are useful to setup the right goals (resolutions):

• Basic skills ('the engine') - the foundation that the rest builds upon. I need to keep the physical and mental facilities well maintained. In my case I will be focusing on running and meditation.
• Mastery. It is important for my self-worth to gain mastery. I actually think I have done so in many subjects but I have not capitalized on it yet and my primary focus will now be on identifying it.
• Purpose. 'Higher purpose' if you like. Last year I focused on my 'micro' environment (friends & family). Now I am considering on expanding, adding a 'macro' component related to nature and fellow humans. Not going full-on altruistic, but in that general direction.

I would like to focus on a certain values to guide me through the day-to-day decision making. I will keep the ones I had last year.

P.s. Perhaps you can see a similar pattern here to the one in Drive by Pink: Autonomy, Mastery, Purpose.

Evaluating the health of a software development unit

[ Out of scope (but extremely important): Are we producing the right thing? ]

If I were to evaluate a software development unit, I would ask the following questions:

(measures of current health)

1. How long does it take after an new idea is conceived until it starts being used by end users?
2. How long does it take until a change request or a bug is discovered until it is deployed?
3. How consistent are these times?
4. How many errors are being deployed to production, and how are they discovered?

(measures of continuous/improved health)

1. Are developers growing?
2. Are processes being improved?
3. Is technical debt managed?

 

To probe further as to where the areas of improvement lie, I would investigate the following key attributes of the product:

1. Maintainability (e.g. coding standards, test automation, documentation)
2. Release management (e.g. CI/CD, traceability, planning, configuration mgt)
3. Risk management (e.g. single-point-of-failures, technical debt, regulatory compliance)
4. Quality management (e.g. testing, code reviews, repeatable procedures)
5. Serviceability (e.g. logs from production (errors, statistics), handbook, su configuration)
6. (Security (e.g. scans, audit, access mgt, policy))