Archive for the ‘CTO essentials’ Category:

Building, serving and scaling high performing engineering teams as part of your strategy

The world wide web is the most important global platform in our age. Digital disruption is everywhere regardless of the industry. It is happening in communication, entertainment, transportation, education, agriculture, healthcare to just name a few. Therefore a good business strategy must include a well thought digital strategy. Whether your business sells PAAS or SAAS you must have a way of building, running and scaling your product. There are many ways of dealing with software development from resourcing and structuring perspective: world wide distributed teams to outscoring the whole or keeping it partially or entirely in house. In this article I am intended to discuss the latter case.

When you keep your development in house the goal is to build and scale high performing engineering teams those not only cover its cost but bring value and eventually revenue in to the business one way or another – think of a business that uses digital as part of the overall strategy like a bank that has a bespoke online banking platform or as a second example think of Uber that can not be exist without its digital platform as that is its core.

Problems in crafting softwares most often can be caught in either lack of quality, lack of essential communication or in a less lucky case even in both. The answer can be this: Creating a high performing engineering team that balances out quality and delivery.

How to build and scale high performing engineering teams? Is there a model of some sort that we can apply? Within this article I would like to show one model that has no secrets or any unknown or untold elements. Yet I believe this is an art and there is no recipe. It is an art – probably easier to write about it then to evaluate it. Since I am writing from my experience I am sure it is possible.

Foremost I am going to be slightly more technical in the wording from now on. I created a list of the most important things to have and to actively practice.

  • Leadership
  • Test driven development
  • Collaboration and pairing
  • Continuous integration and delivery
  • Communication and ceremonies

In this part I attempt to discuss the very first point: The engineering lead. The right person can create the right engineering culture. Provides great help with operations from selection and recruitment to mentoring, educating individuals and also participates the evaluation of your digital strategy. This person is key to your success so let’s have a closer look of the most important skills to meet.

Servant leader

First and foremost the servant leader is not powerless at all, however, this type of leader uses its power to help others to grow. The servant leader is not the source of the power but a mediator. It has clear requirements and goals for every individual in the team. It helps to create a plan for the team members to overcome certain obstacles and grow to the next level whereas also helps other players to be great leaders through delegating part of his own duties to them. This type of engineering lead always stays close to the team and aware. How can one stay close to its team? Although the engineering lead has to wear many hats can sometimes fork in to actual work through pair programming and should always have time for regular and even occasional one to ones.

Awareness

The leader who aware on both personal and technical level has its way using certain tools and techniques to measure the current progress, finding obstacles and spot issues early as possible. Sometimes this can be simple as asking around to see who aware of what is being done what is missing and what is left to be done? Also there are tools like JIRA and many other softwares to monitor and keep track of progress.

Presence

The right leader is always present and approachable – stays close to the “battlefield”. Also the right leader can communicate on different levels such as senior management, customer or even at stakeholder level.

Good sense of humour

The good sense of humour is very important. Being open, ready to admit any (even personal) failures and being able to laugh can help to create a great and transparent culture. On the flip side being late to be judgmental never making jokes of someone’s faults or personality/disability/disadvantage is crucial.

Knowledge

Understanding the root of a problem, helping the team to grow and earning some respect all requires strong knowledge. The leader of the team might not be the master of all topics, however, it can be a specialist on a certain subject e.g continuous delivery pipelines and can provide useful insight. Alternatively it can be a generalist who has certain methodology to learn and prototype fast to find the best possible way around a technical challenge – creating a good example and leading by an example. The person also has to speak the language of the team even if it is highly technical in some case.

Impact

Making a positive impact on the team and its members as well as with in the organization is the purpose and the ultimate goal. Helping the team to deliver and grow is a great achievement. Looking ahead and being a step ahead can also make a good impact on the long run. In the end of the day once everything has delegated and the team is up to speed with smooth delivery (it often can take even a year) then the next step is definitely looking ahead for the future challenges that the team might have to face and making preparations to stay in the competition in our digital age.

The good leader is open, knowledgeable, passionate, helpful, transparent and approachable but most importantly creates other leaders through mentorship and delegation.

To be continued.

 

Archive for the ‘CTO essentials’ Category:

Building, serving and scaling high performing engineering teams as part of your strategy

  1. Unified environment for all (whether it is a MacOS or a Linux distribution)
  2. GIT/GitLab/BitBucket for version control with an agreed flow e.g Gitflow
  3. Tracking tools like Jira/YouTrack/Trello to keep bugs, stories and progress registered
  4. Team communication tools e.g. Hangouts, Slack
  5. IDE of your choice e.g WebStorm, VS Coder, VIM
  6. Unit test framework of your preference with set up (including code coverage report) and gotchas e.g. Jest and Enzyme
  7. CI/CD pipeline including Linting/Testing and Deployment – very important!
  8. DEV/TEST/UAT environments
  9. Good chairs, desks and screens e.g adjustable desk for switching between sitting and standing position
  10. Good team spirit – the most important!

Archive for the ‘CTO essentials’ Category:

Building, serving and scaling high performing engineering teams as part of your strategy

React App (1)

I spent some time over the weekend to ellaborate on what sort of tools we can use to fix delivery issues or even what tools we can use to set up a good project. This is part of my research on what makes one a great leader in software development. What makes a team great, agile, pragmatic yet flexible?

I cloned the Create React App repo and some other tools (Redux etc.) and put together a mini project to collect all the tools, skill set and methods that possibly or rather very likely we need to use in order to create value.

The elements in the periodic table are not exhaustive and I am looking to add more terms in the following weeks or months.

 

Archive for the ‘CTO essentials’ Category:

Building, serving and scaling high performing engineering teams as part of your strategy

Technical director (TD) is an interesting role. According to Wikipedia the role itself stems from the television/movie industry but you can find it in gaming and also software development. People quiet often confusing it with other roles like CTO or Head of engineering perhaps Lead engineer. Sometimes it is okay to blend roles although I think the best is to keep them separate as much as possible.

What are the responsibilites of a Technical director (in software development)?

  • Cost analysis and budgeting.
  • Identyfing problems and grey areas.
  • Forecasting potential bottlenecks.
  • Help with technical hiring.
  • Technical prototyping.
  • Discovering 3rd parties, softwares and technologies.
  • Negotiating with 3rd parties.
  • Liasing with the architects and technical leads.

What should not be in the responsibility of the TD?

  • Managing the development team on a personal level.
  • Writing code on a daily basis.
  • Micro managing anyone (should not happen at all).
  • Getting lost in project details and daily delivery issues (You have scrum master, right?).

Besides all above it is possible to be flexible with this role and writing some code every now and then or even stepping in the shoes of a delivery manager perhaps a scrum master but it is not ideal unless it lasts for an interim short period until hiring happened.

This role can be key to your success and delivery to ensure you do not run out of budget, make the right hirings and arrange the right technology. I wouls also suggest to have one TD per project/key client instead of assigning multiple projects to one TD. Finally, keep things separate and do not blend this role with Head of…

I also believe that the role of TD is complex and cross discipline. The person who looking to fulfill such a role should have a strong background in hands on software development (ideally full stack) and years of experience of delivering software and not to mention a grasp of budgeting around software/cloud. It should also have very good range of analytical skills and firm communcation skillset to face stakeholders and customers (non IT savvy mostly) when needed.

Are you looking for someone to fill the Technical director role described above? Hire me.

If you are not sure what should you expect from your Lead developer then continue reading here.

 

Archive for the ‘CTO essentials’ Category:

Building, serving and scaling high performing engineering teams as part of your strategy

If you are a developer who deals with code then you are either amongst those lucky people working for Google labs or you are very likely to deal with legacy line of business code on a daily basis. Despite the fancy tech talk after your sucessful fizz-buzz bullshit where the guys wanted you to write technical test too top on an in depth conversation around React and some recent Redux stuff which includes immutability and React Router, Context, Relay – they can be a little bit surprised when you are throwing them the question on your second day – why the heck are we using 5 years old JS code with jQuery? The answer is probably they have been told to maintain legacy nightmare for now and also to going away from this code soon. You are trapped. Why??! Consider this from a business point of view. If your company selling clothes online and you convert their already working Backbone code (the whole framework is a huge anti pattern OMG BTW) in to fancy immutable React Redux unicorn – how much money they can save? Probably nothing much or if slightly more than nothing – is nothing to do with your code re write. However you can always improve things, make them faster etc.

What (business) people are paying for?

UX with A/B testing

If you can manage to create user experience – user journey that increases conversion and revenue then you are in a good position to do slight improvements and proving them by numbers. Going step by step and backed by statistics.

Devops optimizations

If you can find patterns in the daily usage of resources or you can optimize the daily workflow then you are saving money to your company and I can not see the point not to do so unless a very political environment that is too slow to move (e.g. from self hosted to AWS).

Code quality and integrity

Unit tests. Easy to sell. Do it. Code reviews, Git worflow or pull request – try it – nothing to lose here.

What business usually does not buy

Complete rewrite

Rewriting ugly code just for the sake of it. Even when technology is emerging – you have to make a very strong point to convince an organization that commited spend money wisely on a complete code refactoring. Unless the code was that much bad and unmaintanable or resources had become recently too expensive and difficult to find (let’s say that is a C++ legacy system) then you probably can not do it. Fancy a complete NodeJS microservice backed React stack? The good news is that you very likely to find a team, bad news is not going to be that much cheaper due to the high demanding and bids of full stack front end engineers.

What start ups usually buy

Are you fancy of a recent Angular or React stuff? – But be careful here

Start ups are mostly the only places on Earth where someone willing to pay you for applying recent technologies. But be careful here. If you are one those early employees you migh have chance to put down your two cents next to a technology although things are moving so fast that you could easily see you code either getting rid of in a short term or being claimed unefficient due to lack of time to reasoning around the correct usage and patterns of too young tools. If you are coming on board little bit later then you can see proud and huge code base of React missing the immutability or complete Redux – one of those things that without React is not that big deal or something else that is not even published yet but tomorrow potentially will change the way how we modern engineers approach things. Just think about your React-Flux code 6 months ago… would you write a completely different stuff today possibly with Redux? What about tomorrow Elm or some RxJS? Right now IMO generators and yield together rocks when it comes to NodeJS control flow but I might change my mind about it tomorrow if something else comes up. Business does prefer stability and predictable stuff. The code should stay in place for a while despite technology changes rapidly. That is one of the reasons why employers should hire the right engineers.

It is sad but most of us (90%) can only reason around new tech in spare time or sometimes even during working day if we are enough lucky to work for a company that knows something about the 20%-80% time usage. That leaves us with some side projects and being strong advocate of code quality/test, agile and business side – customer experience and product/service driven mindset – to make/save money to our companies even through an ugly legacy code.

Dear recruiters (good ones) should understand that and cut away the bullshit. No need for marketing buzz here. Do not put React-Redux and AngularJS, Backbone in to the same advert or do not put anything like that at all. Do not ask people to know everything that is recent. A framework can be picked up in 3-4 weeks but someone who really does a quality job both on coding and consulting side is hard to find. Do not scare them with bullshit. Put some expectations on someone to be a good fit and positive personality who knows about unit testing, code management, common challenges and may be ES6 advantages when destructuring an object/array is important.

 

 

Archive for the ‘CTO essentials’ Category:

Building, serving and scaling high performing engineering teams as part of your strategy

birds

Coding your application\project\website on a daily bases? Nope. I would expect something much more and valuable.

Mentoring
Pointing people to the right sources and promoting trainings, conferences and anything that helps to keep the knowledge floating. Help team mates to find their best purpose within the team to make them feel important and activate them to use best of their skills.

Workflow
Lead developer(s) should be responsible to set up the best way per project to manage the code base (Github etc.) and find a strategy to follow. It can be adjusted time to time based on the actual needs.

Tooling
Setting up a project without CI at least for dev. and test environments is a non-sense and there is no acceptable excuse for this in 2016. It has to be an automated workflow that runs all the tests and deploys the code across your environments. Also need to set up build tools like Gulp, Webpack, Make etc.

Quality
Ensure that writing every kind of tests that make sense are part of the daily practice and everyone understands, follows this. Be test first! Be test driven!

Standards
Must kick off with some initial coding standards and lint rules.

Resources
Should try to find the best place for everyone in the team and also make sure that the project has the right and enough resources attached to it.

Support
Support can determine the quality of your software/services. Your lead developer and its team should aware of bug fixing and bug tracking — setting up principles and tooling is very important.

Finally keep the good thing growing and cut the bullshit. Sounds easy but it is truly hard work!

Archive for the ‘CTO essentials’ Category:

Building, serving and scaling high performing engineering teams as part of your strategy

What makes you a good CTO? What makes you a bad CTO? I have seen examples of both and I’d like to share these adding my own insight with a little hope that I can change the world.

(more…)

Archive for the ‘CTO essentials’ Category:

Building, serving and scaling high performing engineering teams as part of your strategy

Do not worry and appreciate
Nothing is perfect. There is no perfect tool set, technology or architecture. There are always nifty bits and you can try to balance out things (you have to).

(more…)