Things I learnt working for an I.T Consultancy

This was an old blog post draft that I planned on cleaning up. In the end I decided to post it as the raw stream of thoughts that it is. Each one of these thoughts could be its own blog post.

Things I learnt working for an I.T consultancy, doing the DevOps, building all the platforms, leading teams, and annoying a bunch of people along the way.

aka

Ramblings from a “DevOps Engineer”.

Resource Augmentation vs Outcome based work (the ongoing struggle of chasing high-value outcomes for clients).

The art of getting people to realize stuff (you might know what the “right” answer is for a given technology choice or next step for a project, but how do you bring people along for the journey and give them a chance to input their own ideas).

Hiring, promotions and bonus/incentives.

• 360 feedback — getting honest feedback, and getting it much more often that every 12 months
• how your bonus is allocated — and why the worst time to talk about your bonus is when it’s being handed out
• Why/Why/How you should negotiate $ — know your value, understand the ‘buckets’ of money in companies and the incentives from the companies perspective. Most important understand what your drivers are and what will make you happy. Is is just money, or do you have other wants?

Early in my career I used to think that process was the key, and I overlooked people and my teams.

Agile gone bad. How some so amazing has been weaponized over and over. There are literally hundreds of examples of this e.g: “Let’s start reporting on story points per person so we can compare individual performance”.

What’s wrong with LinkedIn, and (some) recruiters. And why my inbox looks like a dating app (with message after message of poorly thought out copy/paste solicitations).

• Incentive to send messages (to meet quotas)
• Incentive to get you to leave your job

How you should fill a role:

• Ask them what they need done, use that to drive requirements for a role
• e.g fix our pipelines, scale our app, reduce bugs in our app (by half, e.g from 50 to 25)
• write an advanced thank-you letter to give to applicants/new starters so they have a clear goal of what to strive for
• Let people pick their team members

How do you mange your projects? (hint: It doesn’t matter what software you do/don’t use — it’s more about how you manage blockers and how focused the team can be). Physical wall vs Virtual (JIRA board), this choice will be specific to the team and it’s needs. You may need to compromise on level of detail — that’s okay.

AWS. Their approach to development teams. Get on-board for building APIs so other teams in Amazon can consume them, and how it launched them into the biggest Cloud provider today.

Trust the people you hire. If you’re hiring people you don’t trust you’re doing it wrong.

One thread on LinkedIn from a hiring manger had the attitude “I’ll pay you 50% market rate until I trust you”. I really hope they were trolling.

As Steve Jobs said: Hire smart people to tell you what to do.

Train/Grow people. Don’t be worried about “What happens if we train them and they leave?” … be worried about “What happens if we don’t train them and they stay”.

Remote work. Pros/Cons.

Pair programming optional, Reviewing code mandatory.

Platforms. “Built it and they will come” is some of the biggest wastage in I.T departments that I’ve seen.

Documentation, too often it’s seen as not important but just like testing it should be part of the work you do not an “I’ll do it later” type thing.

Start thinking of your internal teams as customers (see AWS note about APIs).

Track/share Metrics. Make decisions through data.

Vision is important, have one, or follow someone who does.

Being talented isn’t always a good thing…

• e.g being right and proving someone wrong in a group setting
• intimidating someone by showing off how smart you are to them
• challenging tech leads, delivery leads, sec, ops in a way that gets them off-side

DevOps teams & how they’re AntiPaterns. https://web.devopstopologies.com/

The power struggle between Ops Sec and the rest of the company.

Some people don’t want change.

There’s no one magic solution, or one magical person that can drive transformational change. Support is needed from the top, but also needed at all levels (It’s great to have support from the c-level, but if ops/sec blocks things you’re not going to have a good time).

Technology is actually pretty easy to work with, people are more complicated. If you manage teams meet with them regularly, care about them, and get out of that office when you have your catch-up. I had most amazing Delivery Manager who would catchup with every single team in our company every two weeks. He’d ask about what’s good/bad/blockers and what and what he could do help me. He also asked how I was feeling and if I was challenged. Mostly he actually cared about me and my life because each conversation felt like one with a good friend — and years later we still keep in touch.